AI Is Changing the Game: Building Modular, AI-Ready Platforms on Top of Legacy Systems
Large enterprises often struggle with expensive, tightly coupled legacy systems that hinder innovation due to rigid release cycles and high structural risk. In highly regulated sectors like finance, these systems are difficult to modify, making the integration of iterative, experimental AI features nearly impossible without risking systemic failure. This creates a productivity gap between business departments, which can now rapidly prototype solutions using AI, and IT departments, which are constrained by monolithic architectures.
The proposed solution is the implementation of a modular control layer that decouples business logic from the underlying infrastructure. This architecture utilizes stateless agents—which can be either AI-driven or traditionally programmed—that communicate via a standardized REST contract. These agents remain agnostic of the environment, while the control layer manages orchestration, security, and governance without needing to understand the specific business logic within each agent. To handle large-scale data flows without the bottlenecks of a centralized data warehouse or the slowness of JSON, the approach employs Parquet files as a common data exchange format.
Key technical takeaways include the use of a control plane, such as one built with Django, to manage the registration and execution of independent jobs. By replacing monolithic orchestration with these modular workflows, organizations can swap AI models or update business logic locally rather than systemically. This separation of concerns allows for rapid deployment and continuous iteration of AI features while maintaining the auditability and stability required by regulatory standards.
This description was generated by Open-Source AI using the transcript of the session and the original submission contents.
This session took place in track Programming & Software Engineering & Testing and was classified suitable for intermediate domain by the speaker.
Submission
The proposal as submitted by the speaker before the conference.
AI Is Changing the Game: Building Modular, AI-Ready Platforms on Top of Legacy Systems
AI is no longer a future topic—it is actively reshaping expectations inside organizations. Domain and business teams can now prototype new rules, validations, and analytical logic themselves, often within days. While this accelerates innovation, it puts enormous pressure on existing IT architectures, especially in environments dominated by legacy systems and monolithic platforms.
This talk explores how software architecture must evolve to absorb this pressure instead of breaking under it.
Rather than embedding AI capabilities directly into legacy systems, the presented approach introduces a modular, AI-ready platform built around independent, stateless apps orchestrated by a central control layer. These apps can represent classical reporting logic, risk calculations, or AI agents, all treated as first-class architectural components.
The talk is highly relevant for the PyCon track “Programming, Software Engineering & Testing”, because it demonstrates how to design, orchestrate, and integrate AI-driven workflows in complex Python-based platforms. The central control layer, implemented using Python and optionally Django, provides workflow orchestration, security, tenant management, and self-service registration of new components. This allows domain teams to deploy AI agents or agents written with the help of AI within days, while IT retains governance, auditability, and operational stability.
By showing how AI-driven pressure can be turned into an architectural advantage, the talk provides patterns and practical lessons that apply far beyond finance, making it relevant for any domain dealing with legacy systems, modular design, and AI integration.
Architectural Concepts Covered
The talk introduces the key architectural principles behind the platform:
- Independent, stateless apps that declare their data needs and outputs but remain unaware of infrastructure, environments, or other apps
- Strict separation of concerns between domain logic, orchestration, persistence, and presentation
- Technology-indifferent design, allowing apps to run on different databases, reporting tools, or compute backends
- Parallel and distributed execution as a default, not an optimization
This architecture allows legacy systems to coexist with modern components instead of blocking innovation.
The Control Layer as an Enabler for AI
A central part of the talk is the control layer that orchestrates all components. Implemented using Python and optionally Django, this layer is responsible for:
- workflow orchestration and dependency management
- authentication, authorization, and tenant isolation
- self-service registration of apps and AI agents
- resource allocation, monitoring, and auditability
Django is not used as a traditional CRUD backend, but as governance infrastructure: providing APIs, admin and self-service portals, and security mechanisms that allow fast innovation without losing control.
Example: Integrating an AI Agent into a Regulated Platform
A concrete example demonstrates the architecture in action: integrating an AI agent for e.g. anomaly detection in regulatory reporting.
The example walks through:
- developing the agent as an independent, containerized app
- registering it via standardized APIs
- declaring required data and produced results
- orchestrating it within existing workflows
- testing, monitoring, and scaling it without touching legacy systems
This shows how new AI capabilities can be deployed within days while maintaining stability and compliance.
Why This Matters Beyond Finance
While the example comes from regulatory reporting, the patterns discussed apply to many domains facing similar challenges: data-heavy systems, long-lived platforms, and increasing pressure to integrate AI safely.
The talk concludes with lessons learned and architectural patterns that help future-proof systems as AI continues to raise the bar for flexibility, speed, and modularity.
Transcript (auto)
Auto-generated from the recording utilizing Open-Source AI. Speaker labels (Speaker 1, Speaker 2) reflect diarization, not identity. Timestamps refer to the recording.
Speaker 1 [00:06]
Hello everyone, welcome to the final talk of the evening session before the lightning talks. Before I introduce you to the topic and the speaker, a quick reminder that please post your questions on talks.pycon.de and don't ask your questions during the talk because we have online users as well. So moving on, the topic for today's session is AI is changing the game, building modular AI-ready platforms on top of legacy systems. And this talk will be given by our speaker, Werner Gothain. A quick intro about our speaker. He's an experienced software architect and risk management expert. He has 25 years of experience in developing and integrating financial systems, orchestrating complex workflows, and enabling rapid AI deployment. So without any further ado, let's get started. And please give a bigger round of applause for our speaker.
Speaker 2 [01:23]
Thank you very much for the introduction. So, most of me is already told, but perhaps some information about me, opposite to most of you, I'm, let's say, more or less at the end of a long career, starting, as you see, with a Commodore C64 and did economics, made my PhD in applied computer science and worked in different companies in management positions. So instead of retiring, I decided to turn back to the roots and become self-employed as an enterprise architect, software developer and a consultant. and so far happy to share my experience and what I've learned.
Speaker 3 [02:19]
And
Speaker 2 [02:21]
What I've learned in the different types of consultancy projects I had in the past,
Speaker 3 [02:28]
Um,
Speaker 2 [02:29]
I came over one of the major problems in all these big enterprises. They have tons of very expensive, big, big legacy systems which are interconnected with expensive interfaces and each of these systems costs you, costs the enterprise several millions and changing something as well and building a new interface so introducing a new system is extremely expensive.
Speaker 3 [03:00]
these
Speaker 2 [03:01]
The structure leads actually to the situation that you have leases systems which are very slowly in change, so quarterly leases is more or less optimistic. Most of them try to prevent, to do any type of release changes because it's so expensive and so difficult.
Speaker 3 [03:22]
And so...
Speaker 2 [03:26]
you have only a very little amount of variance, and therefore stability is one of the most important aspects in this type of system and system architecture. They are highly regulated, they are highly audited, there are so many things you have to look at, so BCP S239 in the financial industry, DORA and more of regulations which are simply IT based
Speaker 3 [03:57]
and
Speaker 2 [03:59]
Everybody is thinking about AI and everybody thinks about how you can pimp up all their systems by making something with AI and actually starting with SAP to think about it and all the other companies as well.
Speaker 3 [04:19]
but
Speaker 2 [04:22]
enterprises like these are not made for actually doing such small experiments and AI more or less is the opposite it constantly changes you have many many variants and failure is is normal you have to iterate continuously to improve But one problem is not on this slide. The relationship between the business department and the relationship between the IT department is changing completely because on your fingertips as part of the business department, it's very, very easy to design a solution for your problem. So in the past, they have Excel and Access and all this stuff and tons of software are the sort of shadow software in each enterprise. But this becomes much, much easier and much easier for people who don't have any IT experience.
Speaker 3 [05:27]
and therefore
Speaker 2 [05:30]
in this context
Speaker 3 [05:31]
um and
Speaker 2 [05:33]
generates a big, big pressure on the IT departments because you have these big legacy systems and it's extremely difficult actually to get these type of business department problem solutions inside your existing architecture. And that's more or less the beginning of the idea what can you change actually to solve these type of problems.
Speaker 3 [05:57]
and
Speaker 2 [06:01]
So you just integrate one more service, you're hardwired into something, so in the end you get tight coupling.
Speaker 3 [06:12]
tight coupling
Speaker 2 [06:13]
coupling you have fear of change so change everything in around the system is dangerous therefore slow innovations and if you change something in some system you always have the risks that the whole environment can break down so i have been working software companies where
Speaker 3 [06:33]
Um...
Speaker 2 [06:34]
All these 150 developers just were waiting until the bug, somebody left, was found. And you will say, can never happen if you test properly, but all these things happen all the time, unfortunately.
Speaker 3 [06:51]
and
Speaker 2 [06:54]
Therefore, AI features is not good for the enterprise. It becomes more and more a structural risk.
Speaker 3 [07:02]
Therefore,
Speaker 2 [07:04]
the productivity of the enterprise is continuously declining because many people are thinking about how you can integrate it, but actually it's extremely difficult to make use of it. So what is my idea in this? I mean, it's a very, very simple thing. So
Speaker 3 [07:31]
So, um...
Speaker 2 [07:32]
If you have...
Speaker 3 [07:33]
some
Speaker 2 [07:36]
something like in the middle a sort of layer which controls actually the architecture you are working on.
Speaker 3 [07:52]
so
Speaker 2 [07:53]
The layer is responsible for orchestrating, who runs, secures, and governs and isolates. And if you want to do something new, if you have a new, let's say,
Speaker 3 [08:06]
and
Speaker 2 [08:07]
agent, and if you have an agent, it's not important where this agent comes from. So is it really an agent who does something like, has a fancy idea of doing something which AI enables, or is it simply an agent which was built by the help of AI, simply faster if you have regulated infrastructure it's much easier actually to do these type of regulations give them in the future something like cloud code and it will produce this type of algorithm very soon and very fast. And therefore, it's not important if these type of agents are using AI or if they are actually produced by AI. Therefore, the idea is having a control layer that controls everything, what is doing something in terms of business is, let's call it an app. Whether it's classical business logic, it's a reporting pipeline, it's an AI agent risk model.
Speaker 3 [09:32]
It's
Speaker 2 [09:33]
It's just an app which can be stateless, disclares inputs, outputs, no knowledge about the infrastructure and communicates via, for example, REST. So I did a MVP for this type of infrastructure. I did it with REST.
Speaker 3 [09:51]
but
Speaker 2 [09:52]
If you look at REST, you have the contract where you just control the agent. So the agent is controlled by some simple endpoints like starting its status, ask for the status, stop it and ask for the health or so.
Speaker 3 [10:12]
And, but
Speaker 2 [10:13]
But these type of agents, if you look at dispositive systems in banks, financial industries, and so on, they are typically working on more or less big data flows or pipelines. It's not that they have just a REST API where you can put the data into it. into it. Therefore, you only need the REST interface to integrate it into an orchestration layer, but to have
Speaker 3 [10:50]
the
Speaker 2 [10:52]
data you will need a sort of layer where you can put the data in and put the data out
Speaker 3 [10:59]
and
Speaker 2 [11:02]
I have some code here, but I have some pictures as well.
Speaker 3 [11:06]
So, um...
Speaker 2 [11:07]
If you look at an agent, the agent has some simple...
Speaker 3 [11:13]
We'll see.
Speaker 2 [11:15]
starting points and you have the orchid control layer which simplifies and forgets orchid ports from outside and the agent is running through the different status like pending running and completing and what is important about it is that you don't have any knowledge inside the agent about the environment which is around it. And on the other hand, ORCID, this is how I call it actually, the control layer, is not knowing anything about the business logic which happens completely inside the agent. And therefore, it's very much a matter of concern that you don't mix these type of responsibilities.
Speaker 3 [12:11]
And
Speaker 2 [12:19]
In the end, it's a matter of registration, so you have simply one call to do the registration.
Speaker 3 [12:29]
And, um...
Speaker 2 [12:31]
it's important that legacy systems which are around are not touched at all. So the difficulty which arises actually to build this type of architecture is you need a sort of data system where you can just share the data. I decided to do it was with using Parquet files, which is simply
Speaker 3 [13:00]
a
Speaker 2 [13:01]
sort of lingua franca actually for interacting with data.
Speaker 3 [13:09]
but
Speaker 2 [13:11]
This is...
Speaker 3 [13:12]
um
Speaker 2 [13:13]
make sense on dispositive systems but it does not make sense if you are inside let's say a classical input system so if you look at SAP systems which are usually in the area of typing in the data contracts and so on and on the other hand you have systems like risk systems, regulatory reporting system, business warehouses and so on which are more on the dispositive side where do the reports out of this data and as soon as you are in the area of reporting the data it's much easier actually to just make these type of action to be completely independent from these systems and therefore it's important to make these separation and this decoupling of systems as early as possible as soon as business logic is inside the primary systems it's becoming difficult and it becomes more and more difficult actually to do this type of separation. So the idea here is probably for most of you not completely new because it's nothing else than let's say a classical stateless rest architecture but it's important to understand that
Speaker 3 [14:36]
that some
Speaker 2 [14:38]
Something has been done in enterprises to change the way enterprise architectures are organized.
Speaker 3 [14:45]
And the problem is,
Speaker 2 [14:46]
The problem here is that classical software developers or classical software development firms are in this type of vicious circle where they have the situation that they just know that they have to change, but they cannot change their complete business model, actually, and the complete structure of the software, and therefore there is actually place for
Speaker 3 [15:15]
So...
Speaker 2 [15:16]
new ideas, how this type of architecture can come into companies. So, running a workflow is here, just illustrated by Daniel Koehl.
Speaker 3 [15:32]
Um...
Speaker 2 [15:33]
call to the running service.
Speaker 3 [15:37]
and
Speaker 2 [15:39]
the most important thing about the
Speaker 3 [15:43]
the
Speaker 2 [15:46]
The architecture here is that you can interconnect legacy systems with software which comes from other sources than the original software providers. You can integrate them in a system where all these requirements for quality, for testing, for auditability, can be handled actually with the help of a control system. You need a sort of small data management system to interact for bigger data, which is shared between different legacy systems or parts of the legacy system. And in the end,
Speaker 3 [16:33]
And you can...
Speaker 2 [16:38]
come to a situation where changes become local and not systemic.
Speaker 3 [16:44]
and
Speaker 2 [16:46]
This is let's say
Speaker 3 [16:48]
Um...
Speaker 2 [16:50]
easy implementable idea. I did it so here I did it with Django as a control plane.
Speaker 3 [17:00]
I mean...
Speaker 2 [17:01]
This is another matter of...
Speaker 3 [17:03]
of
Speaker 2 [17:06]
how AI influences the world of software development. Before Christmas, I thought about talking here, not really knowing what happens actually, because probably mostly young people, mostly very experienced in the Python area, and having suddenly a topic which is more, let's say, high level. so I tried to make an M4P actually to make sure that I know what I'm talking about. So as being very happy with Django as a web framework, I told Claude, which I used the first time actually, Claude Code, to do it with Django. But in the meantime, probably many people would say, why do you use Django for this, especially if you have developed it with the help of agents like Cloud Code. But on the other hand, this type of control plane must be, in some respect, controllable and usable by people who are not only people or artificial agents, must be real people to be sure that auditability and all these requirements and what happens inside an enterprise architecture are fulfilled. So therefore, it's for me, it's a difficult question if you can solve this simply by AI engines and prompt it or if you have some sort of controllable interface. Other people are saying Django is too big actually, too much code for, let's say, a small layer of software which you're needing here. And probably this is a matter of...
Speaker 3 [19:19]
um
Speaker 2 [19:21]
of different perspectives there are people who like it and there are people who don't like it and would they make a difference so I don't see that there is a real strong argument for or against Django actually to use this type of thing but at the end of the day Django is not the major reason how it works or not so the major thing about it is to have this type of
Speaker 3 [19:54]
of
Speaker 2 [19:55]
separation of concern, of decoupling, and the possibility to deploy new engines completely independent.
Speaker 3 [20:06]
and
Speaker 2 [20:07]
and to swap models without touching, actually, existing workflows.
Speaker 3 [20:14]
Um, the, um...
Speaker 2 [20:18]
A control layer between legacy and AI gives you the possibility not to hardwire AI into pipelines. You have the stateless apps with a simple REST contract instead of deep framework integrations. You have workflows.
Speaker 3 [20:40]
Um,
Speaker 2 [20:41]
where you can just integrate in terms of directly access graphics.
Speaker 3 [20:41]
but,
Speaker 2 [20:50]
You have independent jobs, so a workflow is nothing else than in the end a combination of different types of agents.
Speaker 3 [20:59]
um,
Speaker 2 [20:59]
monolithic orchestration replaced by these type of workflows. I mean there's many many things around starting with Airflow and Duda and what they're called. There are many possibilities actually to do these type of things and it depends probably on the size of the enterprise. So I've seen situations where Airflow projects becoming bigger and bigger.
Speaker 3 [21:26]
But,
Speaker 2 [21:29]
I don't know, as there are so many different approaches, there are advantages and disadvantages actually for each of these possibilities. In this case, I've done it with Django or Django 6, but in the end, it doesn't matter. You have always different infrastructures for that.
Speaker 3 [21:55]
and
Speaker 2 [21:57]
I took Parquet to exchange the data between different systems or inside the control layer. There are different possibilities actually as well to do this. You can start with DuckDB or simply JSON. So in my last company, we started with JSON.
Speaker 3 [22:18]
Uh...
Speaker 2 [22:20]
a lot of advantages actually but in the end Jason is
Speaker 3 [22:24]
Um,
Speaker 2 [22:25]
To use it for batch processing, it's too much text, too slow, too big, and the same purpose actually can be fulfilled with something like Parquet as well. So the intimacy of Schemata, which you have in JSON, can be built in Parquet as well.
Speaker 3 [22:50]
and
Speaker 2 [22:52]
In the end, it's important to have something which enables you to have not-so-strict schemata, so classical data warehouse infrastructures, which are in the middle of all this, usually fail because they try to have a common data model for everything. And so, in the end, the data warehouse is in the middle of the monolithics, and every change in the data warehouse is extremely expensive, And therefore, if you have a more distributed architecture to integrate these type of things, you need to separate it.
Speaker 3 [23:32]
And...
Speaker 2 [23:33]
distributed type of data modeling as well and you have always a situation where if you look at the agents they have specific needs for for the data they are working on but in the end
Speaker 3 [23:46]
And you...
Speaker 2 [23:47]
You don't have completely different data models for each type of agent, which are using more or less the same infrastructure. So, for example, if you're in the financial area industry, you have cash flows, you have credits, loans and things like that.
Speaker 3 [24:05]
um
Speaker 2 [24:08]
five agents which are working with cash flows, you can argue so each has its own requirements, so perhaps one agent has the view on cash flow this way and the other one the other way around, but in the end you're not happy about it if you have completely different models how you model cash flow in your infrastructure. So this type of compromise is necessary somewhere to keep flexibility on the one hand and to handle the chaos on the other hand in some respect. So it's not a solution for everything, but the idea in the end is keeping this independency.
Speaker 3 [24:58]
and
Speaker 2 [24:59]
So this is more or less what I've done, so I have a little bit of
Speaker 3 [25:07]
of
Speaker 2 [25:08]
code, which is actually, unfortunately, I saw still private, so I will make it public if somebody is interested how it looks like.
Speaker 3 [25:19]
and
Speaker 2 [25:26]
Each of you have already built such type of systems, so I assume
Speaker 3 [25:31]
Um...
Speaker 2 [25:32]
This is built with Django and you see here some agents which are just working inside the systems and you have um,
Speaker 3 [25:53]
have
Speaker 2 [25:53]
I built a credit generator, cash flow generator, liquidity.
Speaker 3 [26:00]
um
Speaker 2 [26:01]
liquidity aggregator report.
Speaker 3 [26:01]
uh And so.
Speaker 2 [26:05]
So these are building a workflow actually together, but it's not important actually to see this run Press on the button run the workflow
Speaker 3 [26:15]
And, um...
Speaker 2 [26:16]
see how it works. In the end, it is software which is not so difficult to implement.
Speaker 3 [26:25]
And I think
Speaker 2 [26:27]
I think it's worse, actually, the effort to experiment with these type of architectures because it's really an alternative for companies which are in a situation I mentioned in the beginning to change the game. And this pressure coming by AI is pressing, actually, the situation between business departments and I think departments, and therefore there must be solutions perhaps like this actually to these type of problems. So you are showing me already that I'm more or less ready, so I'm happy for some questions. Sorry, in the middle I was a little bit...
Speaker 1 [27:23]
Thank you for the talk. Yeah, I didn't mean to pressure you, by the way. So, yeah. All right. Q&A time. First question. It seems a very long question. Seems like an abstract. Okay, I'll read it. If you decouple legacy systems in a financial institution from modern, maybe AI-driven systems and building business logic into the modern systems, then the modern systems have to fulfill all regulatory requirements as well have you experienced that release cycles become very long like four times a year even with state-of-the-art CICD approaches or do you have a good idea on how to keep the speed of change and adoption high in a financial institution Thank you.
Speaker 2 [28:16]
So if I understand the question right, it's a matter of...
Speaker 3 [28:21]
being
Speaker 2 [28:23]
being confirmed to any types of regulation which are which are existing inside an organization like this and I mean this is the major advantage in the major charm but because I'm thinking about these type of things if you have an infrastructure where you fulfill all the things but
Speaker 3 [28:44]
but
Speaker 2 [28:45]
testability, documentation, auditability, so you have a sort of rule for your apps how they must be built.
Speaker 3 [28:52]
built then
Speaker 2 [28:54]
You can
Speaker 3 [28:55]
uh, uh,
Speaker 2 [28:57]
you can solve actually the problem of big release changes. Because if you have simple and small apps which fulfill all the requirements in this direction, you can change them without changing the rest of the system. And this is one of the major goods which gives you such a type of architecture.
Speaker 3 [29:20]
you
Speaker 2 [29:21]
You don't have to change the whole system to keep it alive. You can do small changes. So people who were starting with, let's say, SOAR projects, which were before West comes around, and so you had the situation that they, in the end, have one big system, which is communicated between microservices and so on as well. And you don't have any advantages in the end. If you change a big system, which is consisting of many small systems, if you cover it as, if you treat it as...
