Enterprise Architecture
The New Leg Problem
Avoid creating an app for every gap if there is a feature missing in a core system, by
Understanding the consequences
Identifying the missing feature(s) in the context of the value chain
Choosing the governed path to solve it sustainably
THE REFLEX
The constraint that used to protect your architecture is gone.
For decades, building an enterprise application was expensive enough that someone senior had to say yes. The cost forced a conversation: is this worth it, who will own it, where should it live? That conversation was never really about money. It was about fit — whether the new thing belonged inside the architecture that runs the business.
AI removed the constraint. A capable team with a prompt can now stand up an application in days — real infrastructure, real database, real users — without asking anyone; sometimes on a corporate card, sometimes inside the generous defaults of a platform the enterprise already sanctions. And when a core application is missing a feature or a report, that is exactly what happens: the gap gets an app.
The reflex is not new. Every enterprise already runs on spreadsheets and departmental databases that were satellites before anyone used the word — the effort barrier never stopped them. What is new is the grade of the artifact: the workaround now arrives as a real application, at the speed the spreadsheet used to.
It feels like progress, because locally it is. The feature works and the team is unblocked. The problem is what it does globally: an application estate that grows a new satellite for every gap, each one integrating data out of the core, each one carrying its own stack, its own security model, and its own version of the numbers.
The effort barrier was never just a cost. It was the moment somebody asked: “Where does this belong?”
THE METAPHOR
The reflex has a shape, and medicine named it first.
A patient walks into a clinic with a knee problem. The doctor examines it, agrees that the knee is bad — and instead of treating it, builds the patient a whole new leg. The new leg is excellent: modern materials, quick to fit, works on day one. The patient walks out relieved — with a knee that was never fixed, a leg that must be maintained for life, and a gait that two limbs will have to negotiate forever.
It sounds absurd in medicine and completely normal in enterprise technology. The quoting screen in the CRM is clumsy, so sales gets a quoting app. The vendor report in the ERP is slow, so procurement gets a payment tracker. The knee — the core application that carries the process — is never treated. It stays clumsy, and now it walks beside something newer that it must stay synchronized with for the rest of its life.
The patient’s problem was never a missing leg. It was a knee that needed a surgeon who understands how the patient walks.
FIX THE KNEE
Treat the core in its context — the surgeon knows how the patient walks.
BUILD A LEG
A second limb to maintain, synchronize, and explain — for the rest of its life.
THE NEW-LEG PROBLEM, STATED
A satellite application is a new leg: locally superior, globally destabilizing. Fix the knee instead.
seeing a missing feature and reflexively building a new application
the AI-built side applications orbiting the core systems
the recurring cost of making satellite numbers tie out with ERP, CRM, and PPM
the nine end-to-end processes every enterprise runs on
improve the core in its context instead of building around it
THE SATELLITE
The feature is the smallest thing that ships.
Ask what actually goes to production when a team closes a gap with an AI-built application. The feature, yes. And around the feature, an estate in miniature:
A runtime and its infrastructure — provisioned in minutes, owned by no one in particular
A data pipeline extracting from the core — one more consumer the core team cannot see
A second identity and security model — new accounts, new access rules, new offboarding to forget
Reports of its own — numbers produced beside ERP, CRM, and PPM, not inside them
A dependency tree — frameworks, libraries, and APIs, each on its own upgrade clock
The gap-to-app reflex
THE GAP
a missing feature in a core app
1
THE SATELLITE APP
AI-built in days · beside the core
2
A NEW STACK
runtime · pipelines · dependencies
3
A NEW SECURITY MODEL
own identities · own access rules
4
NEW REPORTS
numbers beside the masters
5
THE TIE-OUT
reconcile with ERP · CRM · PPM
6
THE NEXT GAP
the workaround becomes core
7
One gap forks into three new liabilities that all converge on the tie-out.
Read the walkthrough
AN ARCHETYPE, START TO FINISH
Sales operations is missing flexible discount approval in the CRM, so an AI-assisted team ships a quoting app in a sprint. It pulls customer and price data from the CRM and the ERP, applies its own approval logic, and writes agreed discounts back by upload. It works — the pipeline moves faster, and everyone involved is right to be pleased.
At quarter close, finance discovers that the revenue picture in the quoting app and the bookings in the ERP disagree, and nobody can say which is right. A reconciliation spreadsheet appears. Within a year the spreadsheet is load-bearing: the fastest-moving part of Deal-to-Dollar now runs through an application the architecture never planned for, reconciled by hand, owned by a team that has already moved on. And because the satellite is now load-bearing, its own gaps are next in line for an app of their own. The reflex compounds.
THE COSTS
The costs do not arrive with the app. They arrive on its anniversaries.
2
Upgrade and dependency debt
Core platforms move on the vendor’s schedule; every satellite adds a dependency tree on clocks of its own. When the core upgrades, every satellite integration becomes a regression test. When a framework is deprecated, the business asks why the quoting app needs a rebuild.
3
Security-model proliferation
Sprawling security models do get brought under control — eventually — but controlling many costs far more than controlling one. An access review that was one afternoon in the core now spans a dozen user stores. Most days the audit does not fail — it just costs more than it should. When it does, the finding traces to a satellite nobody governs.
Beneath all three sits the quiet cost: every satellite produces numbers, and numbers must eventually agree with the masters. Reports that tie out with the ERP, the CRM, and the PPM system are not an accounting nicety — they are how an enterprise knows what is true. Every satellite adds a report line that has to be explained at close.
The satellite estate
+ A STACK
to patch and upgrade
CRM
the customer master
Quoting app · own login
Discount tracker · own data
+ A SECURITY MODEL
to govern
ERP
finance and operations
Vendor payment tracker
Margin dashboard · extracts
+ A REPORT LINE
to reconcile
PPM
projects and portfolios
Intake tracker · own board
Status roll-up builder
+ AN OWNER
to find, later
HRIS
the people master
Onboarding tracker
Contractor portal · own IDs
ONE ENTERPRISE
every satellite number must still tie out with the master systems
Four core systems, each orbited by AI-built satellites; every satellite adds a recurring cost.
Read the walkthrough
PROCURE-TO-PAY
A departmental payment tracker re-implements approval logic that already lives in the ERP. Two approval truths now exist for one process, and the duplicate-payment exposure surfaces later — in Record-to-Report, as a control exception with no system of record to trace it to.
HIRE-TO-RETIRE
An onboarding tracker built beside the HRIS keeps its own user store. Contractor accounts outlive contracts, because offboarding lives in the HRIS — the system the tracker deliberately went around. The finding lands in the next access audit, and the quick app owns it.
The examples in this article are illustrative archetypes — composites of common patterns, not client engagements or measured outcomes.
THE BLIND SPOT
The code is the smallest part of an enterprise application.
None of this happens because AI writes bad code. Mostly, it writes remarkably good code. It happens because code is the smallest part of an enterprise application. The larger part is context: why the core system is configured the way it is, which regulation shaped that workflow, which outage a decade ago made finance insist on that reconciliation step, which acquisition left two customer masters that still have not fully merged.
That context lives in the organization — in its history, its scars, and its constraints — and almost none of it is written down where a model could read it. A prompt describes the feature. It cannot describe what the feature must fit into:
Security posture — the model the enterprise runs, and the price of every model it adds
Financial reality — what the estate already costs, and what every addition will
Scalable data requirements — lineage, mastering, and one version of the truth
Legal and compliance risk — the regulations that shaped the core, invisibly
Business evolution — where the organization is going, not only what it does today
Some of that context can be written down, and should be — every page of it shrinks the blind spot. But a model can only answer for the context it is given. Someone still has to answer for the whole.
WHAT THE PROMPT CARRIES
the feature
WHAT THE ENTERPRISE KNOWS
evolution · security · compliance · data lineage · financial reality · history
AI answers the prompt. Enterprise architecture is responsible for all the context the prompt was created in. AI doesn’t know the full organizational context, unless the company itself is entirely run by AI.
THE PROCESS SPINE
Applications execute the processes from input to reporting.
Underneath every application estate, an enterprise runs on a small set of end-to-end processes — value chains that cross departments, systems, and years. None of them belongs to a single application; every one of them crosses several. This is the spine a specialist reasons along, and the context a satellite app never sees:
Nine processes, one enterprise
OPERATIONS AND FINANCE
from plan to audited truth
Risk-to-Compliance · controls
Record-to-Report · the ledger
Plan-to-Fulfill · supply chain
CUSTOMERS AND PRODUCTS
from idea to loyal customer
Issue-to-Resolution · support
Deal-to-Dollar · order to cash
Idea-to-Market · new offerings
PEOPLE AND SUPPLIERS
the workforce and the vendors
Procure-to-Pay · buy and settle
Source-to-Contract · suppliers
Hire-to-Retire · the workforce
THE CORE SYSTEMS
ERP · CRM · PPM · HRIS · SCM · every process crosses several of them
SECURITY AND COMPLIANCE
one model · one audit
ENTERPRISE ARCHITECTURE
one connected blueprint
BUSINESS CONTEXT
history and reasoning
The process spine in three groups over the core-system bed, kept whole by context, architecture, and one security model.
Record-to-Report
collecting, processing and communicating financial data — ledgers, balance sheets, regulatory reports
Procure-to-Pay
requisition, purchasing, vendor management, receiving, invoice approval and payment
Deal-to-Dollar
also known as Order-to-Cash — customer acquisition, contracting, orders, delivery, invoicing, collection
Issue-to-Resolution
complaints, support requests, service tickets, and troubleshooting paths
Source-to-Contract
supplier identification, bid evaluation, negotiation, and contract execution
Idea-to-Market
research, product development, engineering, testing, and commercial launch
Risk-to-Compliance
risk identification, internal controls, audits, and regulatory obligations
Plan-to-Fulfill
forecasting, demand planning, manufacturing schedules, inventory, and logistics
Hire-to-Retire
the complete workforce journey — recruitment, onboarding, payroll, development, exit and retirement
Count them differently if your taxonomy insists — eight, ten, twelve. The argument does not move: the list is short, the chains are end-to-end, and no application owns one outright.
Look back at the satellites through this lens and the problem sharpens. The quoting app did not extend an application; it cut across Deal-to-Dollar. The onboarding tracker cut across Hire-to-Retire. The payment tracker forked Procure-to-Pay and left the debris in Record-to-Report. A gap in a core application is never an application problem. It is a process problem presenting as an application problem.
THE PRESCRIPTION
The answer is not less AI. It is embedding AI controlled into the enterprise architecture.
The prescription is organizational before it is technical. Put people who understand the core processes — advisors and specialists in Hire-to-Retire, Deal-to-Dollar, Procure-to-Pay and their peers — between the gap and the build. Their job is not to say no. It is to ask: where does this belong? Then assess in order:
1
Configure the core
A surprising share of missing features are not missing — they are unconfigured. The cheapest application is the one you already own, doing what it already does.
2
Extend the core
Build the feature on the platform the core runs on, inheriting its identity, its data model, and its upgrade path.
3
Integrate on sanctioned rails
When it must live separately, put it on the integration and identity rails the architecture already governs — one login, one lineage, one place to look.
4
Build new — inside the architecture
Sometimes a new application is the right answer. Built inside the architecture — AI-accelerated, security-inherited, reporting into the masters — it becomes an asset instead of a liability.
The ladder is not a wall. There are honest reasons to land on the fourth rung — a capability no core system claims, an experiment that needs a decision date rather than a data center. And when the core genuinely cannot move — a vendor backlog, a frozen release calendar — the ladder still answers: that is what the third and fourth rungs are for. Keeping the core stable and innovating at the edges is a respectable strategy; the satellite estate is that strategy minus the decision.
None of it works as a toll booth. Teams that can ship in days will not queue for weeks, so the governed path has to be the fast path: advisors who answer in days, sanctioned rails quicker than the workaround, and enough visibility into the estate that a satellite surfaces long before its first anniversary.
The governed path
3
THE ARCHITECTURE REVIEW
security · data · compliance · cost
2
THE PROCESS ADVISOR
context · history · constraints
1
THE SAME GAP
a missing feature in a core app
4
CONFIGURE THE CORE
the feature often already exists
5
EXTEND THE CORE
build on the platform you own
7
BUILD INSIDE
AI-accelerated · governed
6
INTEGRATE
sanctioned platform · one identity
ONE ARCHITECTURE
one security model · one truth
The same gap, routed through context and an architecture review, down a four-rung ladder to one architecture.
AI belongs at every rung: reading configurations, drafting extensions, generating integration code, accelerating the governed build. Used this way, it compounds the architecture instead of fragmenting it. The organizations that win with AI will not be the ones that build the most applications. They will be the ones that keep the fewest — and improve them the fastest.
CONTINUITY
Business continuity is the argument that survives every counterargument.
Satellites are tolerable while their builders are in the room. But applications outlive teams, vendors, and org charts — and eventually someone must control and understand the full process: how an order becomes cash, how a hire becomes a payslip, how a risk becomes a control. The more the estate fragments, the fewer people can hold it, until the honest answer to “who understands this end to end?” is nobody.
Transformation is not a project with an end date. It is a loop — assess, modernise, optimise, repeat — and an architecture improved in context keeps every gap inside the loop: examined against the business it serves, the security it must inherit, the compliance it must satisfy, the data it must keep true, and the money it must be worth.
AI has made it effortless to step outside the loop. That is precisely why the loop now matters more than it ever has.
MODERNISE
→
OPTIMISE
→
ASSESS
→
REPEAT
Eventually, someone has to understand the whole. Organizations that thrive will be the ones that decided early on the people that own and coordinate core systems of the value-chain processes.
CONCLUSION
AI did not create the temptation to build around the core — it industrialized it. The gap-to-app reflex now operates at the speed of a prompt, and every satellite it produces adds a stack to maintain, a security model to govern, and a report line to reconcile against the masters.
The alternative is not slower delivery. It is delivery with a diagnosis: process advisors who know how the enterprise actually walks, an architecture review that asks where the feature belongs, and a short ladder — configure, extend, integrate, build inside — that turns AI from an architecture risk into an architecture accelerant.
A patient with a knee problem does not need a new leg — just a doctor who treats the knee, and knows the whole patient.
THE ARGUMENT, IN FIVE LINES
AI removed the effort barrier — and with it, the question of where new software belongs.
Every gap that gets an app adds a stack, a security model, and a report line to reconcile.
AI cannot see the context that shaped the core: the history, the regulation, the constraints.
The enterprise runs on nine end-to-end processes, and every satellite cuts across at least one.
Specialists who know those processes — plus a short decision ladder — turn AI into an architecture accelerant.
Bring the whole patient
A discovery call walks your application estate: where the satellites are, what they cost, and which of the nine processes they cut across.
OPTIMIZE · AUTOMATE · INNOVATE
Book a discovery call
ABOUT INNOVATIONS24
Innovations24 is an enterprise architecture and AI transformation consultancy. We help enterprises modernize across AI, data, applications, infrastructure, and cloud — and keep them moving.
Jakub Marciniak · Founder & Principal Advisor