Enterprise Architecture: From Automation to Autonomy

It's a bold question: Why do we have applications at all when we can interact directly with intelligent, personalised agents? These agents handle every task needed—they just require data, knowledge, and support from other specialized agents.

Consider what today's applications actually are: a user interface, business logic, data access, and integration points — bundled into a package. Now consider what an agent does: it communicates in natural language, reasons about business logic dynamically, accesses data through tools and APIs, and orchestrates across systems natively.

But this is a future direction, not our current reality. Legacy systems will persist for decades. New applications will still be built. And for tasks that need to be done efficiently, at high volume, and consistently—applications might still hold their ground. Yet, the architectural focus is shifting: from applications as the main execution layer to agents as the primary orchestration layer.

That's why we've merged them into one domain: Agents & Applications. Today, agents and applications still differ in how they are built, integrated, and managed. But agents are already calling and embedding applications - and beginning to generate their own application logic. The two may soon be indistinguishable. 

Data has transitioned from a supporting role to taking centre stage. For years, it was merely a component of applications—stored in databases, shaped by application logic, and managed by application teams. Its rise as a distinct architectural domain marks a significant journey: from data warehousing to master data management, and now to data mesh and data products.

Agents are transforming this landscape further: Because they don't just query databases — they consume unstructured information and knowledge to reason, plan, and act. A policy document, an email thread, a process description — these become direct inputs for agent behaviour. It is no longer enough to make knowledge available to humans in documents. We must explicitly manage, curate, and structure it so that agents can read, retrieve, and correctly interpret it — for RAG (Retrieval-Augmented Generation), for context, for autonomous decision-making.

This calls for new architectural concepts:

• Knowledge graphs and ontologies that provide agents with semantic understanding. 
• Retrieval augmented generation (RAG) architectures that ground agent responses in organisational knowledge
• Agent memory and context stores that enable agents to maintain state across interactions
• Embeddings and vector databases that make unstructured knowledge searchable
• Metadata — process descriptions, business rules, data lineage — that agents need to operate effectively 

This is why we renamed the domain from Data Architecture to Data & Knowledge. It's not just about storing and modelling data anymore. It's about curating the metadata and the knowledge fabric that agents reason on.

This is less about Agentic AI and more about trends that have been building for years: cloud, virtualisation, everything-as-a-service, zero trust.

When infrastructure is consumed as a service — the architectural significance of modelling systems, networks, and virtualisation separately diminishes. With zero trust, even the network perimeter loses its relevance — security is no longer a function of topology, but of identity and policy.

Here's what this means for you: Technology capabilities — system, network, and virtualisation architecture — are increasingly absorbed into platform choices, cloud configuration, and security policy. They don't vanish, but their strategic importance as a separate architectural domain decreases. Enterprise architecture creates the most strategic value today in the design of business capabilities, agents & applications, and the data & knowledge that powers them.

Consider these examples:

• A development team can now access compute, storage, and networking with a single API call - or choose to go serverless. There's no need for server architecture.
• A company migrates to a cloud platform that bundles infrastructure, security and compliance out of the box — what was once a complex technology architecture decision becomes a configuration choice.

A capability model defines what we architect. Yet, an enterprise also requires capabilities for managing Enterprise Architecture, maintaining the Enterprise Architecture repository, and ensuring governance.

While Enterprise Architecture management and the repository remain consistent in an agentic world, governance transforms. When agents act autonomously, new questions arise: Who owns an agent? Who is responsible for its decisions? How do we ensure compliance?

Two critical additions to the governance model:

• Guardrails: These are machine-enforceable boundaries that limit agent behaviour in real-time—a key governance concept.
• Agent & Data Governance: This addresses accountability, ownership, and compliance for autonomous agents and the data they use.

We intentionally leave two questions open: How should governance adapt for autonomous agents? And how will architecture roles evolve? These are topics for another blog post.