From documentation to decisions: enterprise architecture in the age of AI
How we built a connected enterprise model to support ownership, cost and AI governance decisions.
For the past 5 years, I have been changing how enterprise architecture works inside a large organisation.
We needed to help people make decisions. Our documents described the organisation, but they did not give teams enough evidence to act. An internal audit found unclear ownership across parts of the technology estate. A cost programme needed a consistent view of applications and capabilities. The growth of generative AI created another need: reviewers had to understand how each proposal connected to systems, data and accountable owners.
We built a connected enterprise model to address these problems. It now supports decisions about ownership, investment and AI risk.
As AI tools begin to reason and act across systems, they will also need this context in a form they can interpret.
I discussed this approach in an on-demand Ardoq webinar with enterprise architecture leaders from ITV and Funding Circle. We covered AI governance and business agility in complex organisations.
Clear ownership improved cost decisions
The internal audit found that ownership information was fragmented and inconsistent. Some applications had no accountable owner. Teams judged legacy status from experience rather than agreed evidence.
We created a model that linked each application to a business capability and a named owner. We agreed common definitions and gave teams a place to maintain the information.
The model exposed duplicate applications and gaps in accountability. It also changed cost discussions. Teams could examine evidence about business fit, technical condition and ownership before recommending investment.
A later cost programme used the same model for TIME analysis: tolerate, invest, migrate or eliminate. We could connect cost information to applications and capabilities instead of assembling another set of spreadsheets.
Finance and procurement teams still work in Excel, so we designed around that reality. We accepted spreadsheet imports and incomplete records while the model matured. This introduced modelling debt, but it allowed people to use the model before every field was perfect.
AI governance needs connected context
Generative AI increased the number and range of proposals that governance teams had to review. Narrative submissions made those reviews slow and inconsistent. Reviewers had to extract the relevant applications, data and business purpose from free text.
We replaced part of that process with a structured workflow. People submitting a proposal select the relevant applications, data and business capabilities from the enterprise model. The workflow checks the proposal against policy constraints and presents the result to a human reviewer.
The reviewer remains accountable for the decision. The workflow gives them consistent context and a record of the evidence they considered.
Linking each proposal to the enterprise model also gives us a broader view of AI use. We can see which capabilities depend on AI, which systems process sensitive data and who owns the associated risk.
AI systems need a machine-readable enterprise
Architecture teams have stored much of their knowledge in documents and slide decks. Those formats help people discuss a design, but software cannot rely on them as a consistent source of context.
AI-enabled automation needs defined relationships across the organisation. It needs to know:
- which business capabilities a system supports
- who owns the system and its data
- which sensitivity classifications apply
- which policies limit an action
- which other systems depend on the outcome
An application inventory cannot provide all of this. Teams need a shared model of business, technology, data and policy. The definitions must be consistent, and named people must own them.
A connected model can provide the basis for a knowledge graph. AI tools can use that graph to find relevant context, check boundaries and explain which information informed an action.
We are still developing this model. Agreeing definitions takes time, and ownership creates work for teams across the organisation. The technical platform is the easier part.
Architects must design decision context
This work changes the architect’s role. Architects still need modelling skills, but the quality of a diagram is not the main measure of value.
Architects need to understand the decision, the people responsible for it and the evidence they need. They must connect the enterprise model to operational data and bring that context into the workflow where the decision happens.
AI governance also requires architects to work with privacy, cyber security, legal, finance and procurement teams. Together, these teams define the boundaries that an automated system must respect.
For our practice, the main lessons have been:
- start with a decision that the organisation needs to make
- assign an accountable owner to each important record
- accept modelling debt when it helps people start using the model
- connect the model to operational workflows and source systems
- keep people accountable for decisions supported by AI
The next step
Our enterprise model began as a response to an audit. It now supports cost analysis and AI governance because teams can reuse the same ownership, capability and system relationships.
The next step is to make more of that context available to automation. We need to do this without weakening human accountability or exposing data beyond its agreed boundaries.
Enterprise architecture can provide the governed context for that work. Its value will come from the decisions people make with it and the actions they can explain afterwards.