As applications go headless and intelligence moves into the context layer above them, most of the decisions that matter are getting no attention at all.
For thirty years enterprise architecture was organized around applications. Finance lived in the ERP. Sales lived in the CRM. People lived in the HR platform. Each system owned its data, its processes and its business logic, and employees learned how the company worked by learning where each function lived.
That will inevitably invert, at a different pace for every company. Work is starting to be organized around outcomes rather than systems, with agents working out what has to happen, which systems hold the information, which rules apply and which transactions get executed. The applications do not disappear. They become less visible and less important.
Executive teams are being pulled into this, and the question they usually get handed is which model to standardize on. It is the wrong question, and it is expensive, because it absorbs the attention that belongs somewhere else. When capability turns over every few quarters, the only choices worth agonizing over are the ones that are costly to reverse. Almost none of the decisions getting management’s attention are in that category. Almost all of the ones getting no attention are.
Apps Will Become Headless.
The application-centric company assumed that business logic and user experience belonged together, inside the system that owned the data. That bundle is coming apart.
Systems of record contain the record. They do not contain the reasoning. A CRM holds the stage and the number. What actually determines whether a deal renews sits in email, calendar, chat and documents, and salespeople rarely enter it. Anything that wants to act rather than report has to reach that context, and the context was never inside the system of record. That is what pulls intelligence into a layer above the applications.
The consequence is direct. Once orchestration, context, memory and policy live above the applications, the applications become infrastructure: necessary, expensive, and not where you differentiate. A company that owns a best-in-class core platform and does not own the layer above it has bought a very good database. Every major platform vendor understands this, which is why every one of them is now building its own agentic front end rather than conceding that layer. They are not confused about where the value is going.
Being an excellent system of record is a legitimate position. It is just not a competitive one for the company that bought it. And that layer above the applications is where the real decisions now sit, which raises the question of how to tell which of them deserve real deliberation and which do not.
The Doors That Close Behind You.
Jeff Bezos split business decisions into two kinds: one-way doors, which you cannot walk back through once you have gone through them, and two-way doors, which you can. Almost every enterprise architecture choice in the layer above the applications falls into one or the other, and the two kinds deserve completely different amounts of attention. Sort every decision by how expensive it is to reverse, then spend deliberation in proportion. This sounds like a truism until you look at what falls on each side.
The doors that close are consistent across companies that have done this work: the data layer, the knowledge and semantic layer, identity and entitlements, the register of what agents exist, and above all the enterprise ontology, the shared definition of what your business objects and relationships actually are. The ontology takes years because it is a business artifact rather than a technical one and cannot be bought or accelerated. You will live with these choices. They deserve slow, senior attention.
The doors that stay open are models, agent frameworks, coding assistants and user interfaces. Replace these on a short cycle and do not get attached to any of them.
Most companies have this backwards. They will run a six-month evaluation to standardize on a model, a two-way door they will reopen inside a year, while the entitlement model and the ontology accumulate by default through a hundred uncoordinated project decisions that nobody ever convened to make.
The same pattern shows up in orchestration, which is where control actually concentrates. Orchestration decides which agents exist, what they can reach, which policies bind them and who answers when an outcome is wrong. The common failure is not a bad choice. It is the absence of one. Your ERP vendor ships an orchestration layer, your CRM vendor ships one, your collaboration suite ships one, and your engineering group builds one. No single decision was wrong, and nobody ever decided the company would run four. It accumulated the way integration middleware accumulated in the last era, and it will be unwound at the same cost.
Build So You Can Be Overtaken.
Capability in this environment perishes fast, and the case for waiting deserves a fair hearing. A company can staff a team, build a capability, and find eighteen months later that a general-purpose product does it better and cheaper. The platform vendors are well funded and competent, and they will eventually ship a strong bundled experience.
That is an argument about how to build rather than whether to. Being overtaken by a vendor is cheap if what you built was a two-way door, because you unplug it and buy the better version. It is expensive only when the thing you throw away has your data model, your entitlements and your definitions welded into it, because now you are not replacing a capability, you are unpicking the layer underneath it. Most of the write-offs people point to as evidence for waiting were one-way doors that nobody recognized as one-way doors at the time. Build what you need now and keep the seams clean enough that being overtaken costs you a migration rather than a rebuild.
What You Should Actually Ask.
Which of the decisions in front of us this year cannot be undone, and are we giving those proportionally more time than the ones we will revisit anyway? Do we own the seams between the capabilities we buy, rather than only the capabilities themselves, so that if a provider supplies three things we can unplug any one of them without renegotiating the other two? And which doors have already closed behind us without anyone deciding to close them, in the ontology, the entitlement model and the orchestration layers we now run four of?
The one-way doors in your architecture will be walked through over the next two years either way. Some of them you will choose. The rest will be chosen for you by whoever happened to be building that week.
This article was originally published onForbes.com
