Applications Are Becoming Execution Resources

Applications have been the centre of Enterprise Architecture for decades. Business capabilities are mapped to applications. Projects replace applications. Roadmaps modernise applications. Entire architecture landscapes are drawn around application boundaries. Even today, most architecture discussions begin with a familiar question.

Which application should own this capability?

It is a sensible question in a world where applications are the primary mechanism through which work gets done. Artificial intelligence is changing that assumption, not because applications are disappearing, but because they are no longer the only way work can be executed.

Every technological revolution changes what becomes important

Architecture has always reflected the dominant technology of its time. Mainframes organised computing around central systems. Client-server architectures distributed functionality across machines. Service-Oriented Architecture separated responsibilities into reusable services. Microservices broke those services into smaller, independently deployable units. Cloud platforms shifted attention towards infrastructure, elasticity and continuous delivery.

Each generation introduced a different way of thinking about software. Yet throughout all those changes, applications remained the organising principle. Business capabilities belonged to applications. Teams owned applications. Budgets funded applications. Applications became the lens through which organisations viewed their technology landscape.

That made perfect sense because applications were also where work happened. Today that relationship is beginning to change.

Work no longer belongs to one application

Imagine a customer onboarding process. Traditionally, the CRM manages customer information. An identity platform verifies identity. A document management system stores evidence. An ERP creates the customer account. Employees review exceptions and approve high-risk cases. Each application owns part of the process.

Now introduce AI. An AI agent retrieves customer information, validates documentation, performs risk checks, communicates with the customer, coordinates approvals and triggers actions across multiple systems. None of the underlying applications has disappeared. Yet none of them can honestly claim ownership of the onboarding process anymore.

The work has become distributed. The applications have become execution resources.

Execution becomes the architectural concern

This distinction is subtle, yet important. When we describe an application as owning a business capability, we implicitly assume that the application is the permanent home of the business logic. That assumption becomes increasingly fragile.

A task performed by SAP today may move tomorrow to an AI agent that coordinates SAP, Salesforce and several specialist services. Two years later, the same task may become fully autonomous or move back to a person because regulations have changed. The work has not changed. The executor has.

If Enterprise Architecture continues to treat applications as the primary architectural building block, every change in execution appears as a redesign of the architecture. If we instead model the work independently, applications simply become one possible way of executing that work.

Applications become interchangeable

This changes the role of software significantly. An application is no longer the centre of the enterprise. It becomes one of several execution resources available to perform a task.

Others include:

people
AI agents
software services
external SaaS platforms
robotic process automation
partner organisations

Each has strengths and weaknesses. Humans provide judgement, empathy and accountability. Applications provide stability and transactional consistency. AI agents contribute reasoning, interpretation and coordination. Services provide specialised capabilities.

The architectural question therefore changes. Instead of asking which application owns a capability, we ask which execution resource is best suited to perform this task under these circumstances. The answer may change over time without changing the work itself.

This is why AI is different

Previous technology waves changed software. AI changes execution. That distinction is easy to overlook.

Cloud computing did not fundamentally alter who performed the work. It changed where software ran. Microservices changed how software was structured. Containers changed deployment. APIs changed integration.

AI introduces a new executor. For the first time, an organisation can legitimately choose between a person, an application or an autonomous agent to perform exactly the same task. That is not another technology upgrade. It is a change to the architecture of work.

Enterprise Architecture becomes more stable

Ironically, separating work from applications makes architecture more stable, not less. Applications evolve rapidly. Vendors change. Platforms are replaced. AI models improve. Costs fluctuate. New regulations appear.

If work is embedded inside applications, every technological change forces the architecture to change with it. If work is modelled independently, execution can evolve continuously while the underlying architecture remains coherent.

Customer onboarding remains customer onboarding. Identity verification remains identity verification. Fraud detection remains fraud detection. Only the way those activities are executed changes.

That is exactly what Enterprise Architecture has always tried to achieve: loose coupling. AI simply extends that principle beyond software into work itself.

Preparing for continuous evolution

This does not mean organisations should replace their application landscape. Quite the opposite. Most existing applications will continue providing enormous value for years. ERP systems, CRM platforms and industry-specific solutions contain decades of business knowledge that should not be discarded.

Their role, however, is beginning to change. Instead of becoming the centre of the architecture, they become valuable execution resources within a larger execution landscape.

Some tasks will continue running inside existing applications. Others will move to AI-assisted workflows or become autonomous. Some may return to people because judgement, ethics or regulation demand it.

The architecture should accommodate all of these possibilities without requiring a fundamental redesign every time execution changes.

The next generation of Enterprise Architecture

The past fifty years taught us how to design software. The next fifty may teach us how to design work.

Applications are not disappearing. They are becoming part of something larger. Just as services became building blocks for applications, applications are becoming building blocks for execution.

That changes the architect's perspective. The enterprise is no longer organised around software. It is organised around work. Applications, people and AI agents simply become different ways of accomplishing it.

That is perhaps the most significant architectural shift AI has introduced: not because it changes our technology, but because it changes what sits at the centre of the enterprise.

About NativeWork

NativeWork™ is an AI-native Enterprise Architecture standard and method developed by Centipod. It places work at the centre of enterprise design and provides an architectural foundation for Continuous Enterprise Evolution.

WorkML™ is the accompanying language for expressing NativeWork architectures in a form designed for both people and intelligent systems.

Learn more at nativework.org.

NativeWork™ and WorkML™ are trademarks of Centipod. Trademark applications are pending.

This article was created by people. We have used artificial intelligence (AI) to help articulate our message and refine the text. AI was employed as a tool to assist with structuring, identifying grammatical and spelling errors, and improving readability. The final document has been carefully reviewed and approved by our team.