Enterprise ArchitEcture
Found this helpful? Share it with peers.
Introduction
AI has become one of the few investments a company can make where the biggest risk and the biggest opportunity sit in the same place. Used well, it lifts the performance of core business processes. Used without oversight, it can breach a regulation or expose data the organization is accountable for, often before anyone notices it is in use. The upside and the exposure grow together, and both depend on the same thing: knowing where AI sits in the business and what it touches.
That single requirement splits into two demands, and they usually come from different parts of the organization:
- Where does AI create the most business value, and where should investment go next?
- How can AI be used responsibly and transparently, within internal policy and external regulation?
These map onto two disciplines, AI strategy and AI governance. They pursue different goals, but both start from the same foundation. Each needs to know where AI is used and how it connects to the business processes, applications, data, and people around it.
Most organizations reach for discovery tools first, and those tools do real work, scanning the environment and surfacing the AI services and integrations already running inside it. What comes back is an accurate list of what exists, and it is also where the picture stops. The list cannot show which business function a system serves, what it depends on, or which rules govern it. Enterprise Architecture is what carries the picture the rest of the way, placing each AI system in relation to the processes, applications, and controls around it, and giving AI strategy and AI governance the shared foundation they both build on.
Technical Discovery Is Only the Beginning
Modern discovery tools can identify AI services, foundation models, APIs, cloud resources, AI-enabled applications, and other technical AI artefacts. This technical visibility is an important first step towards understanding the AI landscape.
However, discovering AI is not the same as understanding AI.
Finding an AI agent in Azure AI Foundry or discovering a Copilot integration in Microsoft 365 does not answer questions such as:
- Why does this AI exist?
- Which business capability does it support?
- Which business process depends on it?
- Who is responsible for it?
- Which business data does it process?
- Which governance controls apply?
- What would be affected if it changed?
Technical discovery tells you what exists. Enterprise Architecture explains why it exists, how it is used, and what it affects.
AI Spans the Enterprise (Architecture)
It’s easy to assume AI belongs exclusively to technology architecture, since it depends on foundation models, cloud services, and inference platforms.
In fact, AI extends across the entire enterprise architecture:
- Within the context of Business Architecture, AI supports business capabilities, enables business processes, and assists employees in their daily work.
- Within Application Architecture, AI appears as AI agents, AI enabled applications, and integrations with enterprise systems.
- Within Data Architecture, AI consumes and produces business data, uses knowledge bases, accesses retrieval sources, and depends on strong data governance.
- Within Technology Architecture, AI relies on foundation models, cloud platforms, vector databases, and supporting infrastructure.
Looking at just one of these aspects gives an incomplete picture. Enterprise architecture brings them together into a single, coherent overall view.
EA frameworks such as ArchiMate provide a common language for describing these architectural domains and the relationships between them. Rather than treating AI as a separate architectural discipline, ArchiMate enables organizations to model AI as an integral part of their existing enterprise architecture.
AI is not a separate architecture domain. It spans the existing Strategy, Motivation, Business, Application, Data, Technology, Physical, and Implementation & Migration perspectives.
AI does not belong to a single architecture layer. It spans the enterprise. Enterprise Architecture provides the integrated view needed to understand, govern, and evolve it.
Relationships Create Architectural Context
An inventory can place every AI system correctly within its business, application, data, or technology domain and still leave the question that matters most unanswered. What happens elsewhere if any single one of them changes?
Apollo 13 wasn’t saved because engineers knew every individual component. It was saved because they understood how the entire system worked together. The same principle applies to AI in the enterprise. Knowing which systems exist is only the beginning, and the harder work is understanding how each one connects to the business processes, applications, data, and technology around it, with governance running across all of them.
That understanding rests on a specific set of questions:
- Which business capabilities does this AI support?
- Which business processes use it?
- Which business roles interact with it?
- Which applications provide or consume it?
- Which business data does it process?
- Which foundation models does it use?
- Which governance controls apply?
- Who is responsible for it?
- What systems depend on it?
- What is affected if the AI system or foundation model changes?
Enterprise Architecture is what makes these questions answerable. A modeling language like ArchiMate gives architects a standardized way to connect an AI system to the business capabilities and processes it supports, then carry those same connections through to the applications and data it depends on and the governance controls that apply. The relationships stop being scattered notes and become part of a model that can be queried and traced.
Relationships transform an AI inventory into an architecture model of AI.
Hint: Learn how to build a governed AI inventory with ArchiMate and ADOIT.
Take an AI agent that supports customer service representatives. EA identifies the customer service processes it supports and the application that implements it, along with the customer data it accesses and the model it relies on. It also shows who is responsible for the agent’s operation and which governance controls apply. If the underlying model or the business process changes, architects can see the impact across the enterprise immediately.
This screenshot from ADOIT illustrates the difference between an AI inventory and an EA repository. An inventory confirms that the AI agent exists. The architecture shows how it contributes to the business and what depends on it.
These relationships let architects trace dependencies and see the impact of a change before it happens. They also make it possible to spot governance gaps and plan with the rest of the enterprise in view. AI lives in the same repository as the applications, data, and technology it connects to, giving business, IT, and governance teams one shared source to work from.
Enterprise Architecture Supports AI Strategy and AI Governance
Enterprise Architecture does not replace AI Strategy or AI Governance. Instead, it provides the architectural context both disciplines depend on.
AI Strategy defines how AI creates business value. It helps organizations decide where AI should be introduced, which initiatives deserve investment, and how AI supports strategic objectives. It provides answers to questions such as:
- Which business capabilities have the greatest potential for AI?
- Which AI initiatives support strategic priorities?
- Where are similar AI initiatives being developed independently?
- Which applications should be AI enabled first?
- Which dependencies influence implementation and investment decisions?
This enables organizations to prioritize investments, reuse existing capabilities, and align AI initiatives with business strategy.
AI Governance ensures that AI is deployed responsibly, transparently, and in accordance with internal policies and external regulations. Effective governance is not about slowing innovation or policing AI adoption. It is about providing transparency, accountability, and architectural guidance so organizations can scale AI confidently and consistently.
When AI is modelled within the EA, architects can answer questions such as:
- Which AI systems process sensitive business data?
- Which AI systems are classified as High Risk under the EU AI Act?
- Which business capabilities and processes rely on AI?
- Which applications use a particular foundation model or AI service?
- Which AI systems require human oversight?
- Which governance controls apply to each AI system, and which have already been assessed?
- Who is responsible for each AI system from a business and technical perspective?
- Which AI systems would be affected if a foundation model or supporting application changes?
These insights enable organizations to manage risk, support compliance, and establish trustworthy AI without slowing innovation.
From AI Repository to Architecture Intelligence
As an integral part of the Enterprise Architecture, AI becomes a foundation for analysis, planning, governance, and informed decision making across the enterprise.
Organizations can:
- identify duplicate AI initiatives,
- discover opportunities to reuse existing AI capabilities,
- understand dependencies before introducing change,
- prioritize AI investments based on business value,
- identify ownership and governance gaps,
- assess architectural impact before deploying new AI services,
- plan the evolution of AI across the enterprise.
The objective is not simply to document AI, but to understand how it contributes to the enterprise and how it should evolve.
How ADOIT Helps Build a Connected AI Architecture View
ADOIT extends Enterprise Architecture to include AI as a first-class architectural concern. Instead of maintaining separate AI inventories, governance spreadsheets, and discovery results, organizations can document AI where it belongs: within the Enterprise Architecture repository.
ADOIT Connect imports and synchronizes AI-related information from external sources such as Microsoft Entra, Azure AI Foundry, ServiceNow, cloud platforms, and other enterprise systems. Rather than replacing technical discovery, it establishes the foundation for a continuously evolving AI repository by consolidating AI-related information from across the organization.
ADOIT Forms enrich discovered AI systems with the business and architectural context that discovery alone cannot provide. Architects can document supported business capabilities, business processes, ownership, business data, governance information, foundation models, and relationships to enterprise applications in a structured and governed way.
Workspaces transform this connected architecture into informed decisions. Whether identifying business capabilities with the highest AI potential, prioritizing AI investments, evaluating governance and compliance, assessing architectural impacts, or planning future target architectures, guided Enterprise Architecture workflows help organizations turn architectural insight into action.
Reports and dashboards provide transparency into AI adoption, ownership, governance status, documentation coverage, high-risk AI systems, and other decision-relevant information.
The result is a living EA repository that enables organizations to understand where AI creates value, assess the impact of change, govern AI consistently, and make better strategic investment decisions across the enterprise.
Already got our weekly updates?
