By Dmitry Borisov
For most of my career, I measured success by the elegance of a PL/SQL package. The cleaner the logic, the tighter the exception handling, the better the architecture. That definition no longer works.
When I was designing a natural-language query system for a heavily customized Oracle ERP – AskEBS – one thing became clear: the role of the enterprise systems architect is going through a fundamental shift. We are no longer query builders. We are becoming knowledge engineers.
However, becoming a knowledge engineer requires the right foundation. And this is where we encounter the first strategic misstep most organizations make.
Versioning as a strategic decision
Most organizations treat an ERP upgrade to the current release as routine technical maintenance. That is a costly misunderstanding.
Oracle EBS 12.2.14 is not just another patch set. It is a technical layer that opens the door to enterprise AI. The upgraded SOA integration gateway and the stabilized WebLogic layer provide a native REST infrastructure. The system begins to function as a secure data provider for large language models – without disrupting the online patching cycle and without putting the stability of core business processes at risk.
Companies that remain on outdated releases accumulate what I call security debt. It does not just create vulnerabilities; it blocks the path to modern integrations. The decision to upgrade is no longer purely technical. It is a strategic decision about the system’s architectural future.
The problem nobody talks about
Enterprise ERPs store decades of transactional history. Financial transactions, procurement cycles, asset histories – all of it sits inside a relational schema of exceptional complexity. And yet getting a single meaningful answer still requires an experienced analyst, a SQL query, and anywhere from an hour to two days.
The arrival of large language models created an obvious opportunity: let users ask questions in plain language and get answers back immediately. Modern SaaS platforms and low-code ecosystems offer that kind of integration out of the box. But building comparable capabilities into a deeply customized on-premises ERP is a fundamentally different task. There is no ready-made connector here. There is an architectural problem.
A standard language model, when confronted with a real ERP schema, cannot interpret it reliably. It does not understand what is hidden behind faceless technical columns – fields like ATTRIBUTE1 to ATTRIBUTE15, where company-specific business logic has been accumulating for years.
The semantic bridge
The solution is a semantic representation layer – physical views on top of the ERP database that solve two problems at once: they translate technical column names into business terms people actually use, and they dynamically supply the model with the right context before each query.
Metadata translation is not cosmetic. Without it, the model simply cannot interpret the data correctly. It must see “Supplier Rating” instead of ATTRIBUTE11 in the purchase order table – only then does the model understand what it is being asked about.
The context is delivered through a specialized adaptation of the RAG (Retrieval-Augmented Generation) pattern – essentially, Metadata Injection. The system first queries the ERP data dictionary and pulls the active configuration of additional fields for the relevant module – the name of each field and the matching database column. That information is then formatted and passed to the model in the system instructions as a mapping: “Supplier Rating” is stored in ATTRIBUTE3. Only after that does the model receive the user’s question. This makes it possible to avoid manually building hundreds of static views. The system identifies for itself what it needs to know for a specific query.
The semantic bridge solves the comprehension problem. But comprehension is only half the job.
Determinism versus probability
Language models are probabilistic by nature. In most contexts, that is acceptable. In financial reporting, it is not. An error in a supplier balance calculation or an asset cost figure is not an inconvenience. It is an audit risk. And this is exactly where most AI integration projects in financial systems go off the rails.
The architecture enforces a strict separation of responsibilities. The model does only one thing: it interprets the user’s intent and, through a function-calling mechanism, produces a structured request – a function name and a set of parameters. The system intercepts that request and executes deterministic business logic through trusted APIs. The model never has direct access to transactional tables. It never performs calculations itself. It only queries.
In practice, it looks like this: the model identifies the user’s intent – for example, to retrieve the outstanding balance for a specific supplier in a specific operating unit – and produces a structured JSON call with the name of the required function and the relevant parameters. A backend dispatcher intercepts it and routes it to the appropriate system API. The model receives back only the raw result – a number or a status – and uses that to formulate the response. Throughout, the data remains inside a controlled environment. No direct SQL. No access to transactional tables.
Probabilistic intelligence for understanding meaning; deterministic logic for producing the result. I call this the principle of deterministic execution.
Identity management at the boundary between two eras
Integrating a legacy ERP with cloud AI creates another problem that is easy to underestimate. The enterprise ERP runs on its own sessions and access-control mechanisms. Cloud AI requires OAuth2 and JWT authorization tokens. Those two worlds have to be connected without compromising security.
The architecture creates an explicit bridge. The system captures the ERP session identifier and verifies it through a server-side call. Based on that verification, it generates a short-lived token tied to a specific user. Before any tool is executed, the dispatcher initializes the application context on behalf of that user – with all of that user’s organizational and role-based restrictions. Access rights are enforced directly at the database level, not at the interface level. The security model is not duplicated; it is inherited from the system’s existing structure.
The economics of the question
A typical analytical request under the traditional model – framing the problem, writing SQL, formatting the result – takes anywhere from one to two hours and costs $120 to $180 once the specialist’s time is factored in. Under the AI-driven model, the same request is completed in seconds at a cost of about $1.50 in tokens and compute. At a scale of a thousand users, that adds up to hundreds of thousands of dollars a year. Moving to the current system release also reduces integration maintenance costs by roughly 40%, thanks to built-in REST services replacing custom Java bridges.
Practical constraints
Context limits are the most immediate technical constraint. Passing the full metadata dictionary of a deeply customized module to the model would exhaust the available context window. The architecture requires intelligent routing – only the metadata strictly relevant to a given session is passed in.
Latency is the other factor. The secure execution path adds three to eight seconds to the full cycle. For users accustomed to instant responses in standard forms, that feels unfamiliar. But a few seconds of waiting from a system that eliminates hours of manual work is a reasonable tradeoff. That tradeoff needs to be explained before rollout, not after.
The evolving role of the ERP architect
For years, I believed that deep platform knowledge was the definition of expertise: knowing the schema, being able to optimize a query, understanding how a module behaves under load. All of that still matters. But it is no longer enough.
An architect embedding AI into enterprise systems has to be able to formalize knowledge – to turn implicit business logic, accumulated in custom fields and procedures, into a structure a model can use. That is work at the level of semantics, not syntax. A skill of a fundamentally different order.
Legacy systems are often seen as a constraint. My experience suggests the opposite: with the right architecture, they become the foundation on which you can build what modern platforms are still only promising.
Dmitry Borisov is a Senior Enterprise Systems Architect with over 20 years of experience modernizing complex Oracle ERP environments for industrial and financial organizations. Recognized for his original contributions to enterprise IT architecture, his work focuses on developing secure, proprietary architectural patterns for strictly regulated industries.