Enterprise Architecture in the Age of AI

Every technology decision your organization makes is made on the basis of what your architects know. Which systems share a database. Which integration is a workaround that was never replaced. Which platform is three years past its planned retirement.

That knowledge lives in the heads of the people who have been around long enough to accumulate it, in documents that were accurate on the day they were written, and in meeting notes no one can find. When those people leave — or when a decision needs to be made quickly — that knowledge is either gone or inaccessible.

1. Governance decisions in days, not weeks

   When context is assembled before the meeting, the architecture review board makes better decisions faster. They work from prepared context, not assembling it on the fly.

2. You stop betting on the people still here

   Making architecture knowledge explicit and machine-readable means the next person who joins can understand the landscape immediately. Key-person risk becomes a recoverable condition.

3. Compliance becomes a byproduct

   NIS2 is enforceable across the EU. The EU AI Act's high-risk provisions apply from August 2026. With a continuously maintained catalog mapped to regulatory obligations, compliance is a query, not a project.

4. Strategic decisions reflect reality

   M&A due diligence, cloud migration, platform consolidation — all depend on knowing what you have. The catalog makes that discovery something you do before committing, with real data.

1. Principles in the past

   Governance documents last updated in 2019. Standards are verbal agreements between architects who have since left.

2. Decisions without records

   Technology decisions made in meetings that weren't documented, or documented in a format no one can locate.

3. Drifting diagrams

   The architecture repository holds diagrams that were accurate at some point and have drifted steadily since. Systems get modified; the diagram stays as it was.

1. Catalog — the current picture

   Systems, data, integrations, infrastructure — all connected. Questions that would otherwise require a senior architect become queries.

2. Guidance — the intended direction

   Principles, standards, reference architectures, and a technology radar. A system can be assessed against approved standards.

3. Governance — the historical record

   Decision records, architecture decision records, review outcomes. The answer to 'why was this built this way?' lives here.

A governance decision can fail because it is too slow (queued behind an ARB that meets monthly) or too fast (made without knowing which principles applied, what depended on the system, or what was decided before).

1. A decision that stays with the team

   Low scope, reversible, within the team's authority. The agent confirms approval, checks no dependency, finds a precedent. Decision recorded in two sentences. Total time: under an hour.

2. A decision that needs ARB approval

   Cross-domain impact, irreversible without significant rework, sets a new standard. The ARB receives a prepared brief — blast radius mapped, GDPR implications flagged, two previous decisions surfaced. The ARB session takes 40 minutes instead of two hours.

The catalog, guidance layer, governance records, and playbooks are YAML and markdown files in a git repository. Any AI agent can read them. Any architect can edit them. It runs in the tools the organization already uses.

When the engagement ends, everything stays with the client. No ongoing vendor relationship required to access their own architecture knowledge.