Architecture Content Framework: What an Enterprise Architect Actually Produces

Framework: Architecture Content Framework Perspective: Enterprise Architect

"What does an EA actually deliver?" is the question that ends careers and kills programmes. The Architecture Content Framework gives you the answer — and the professional structure to back it up.

Key Inputs

ADM phase requirements for deliverables
Stakeholder communication needs
Governance and audit requirements
Existing documentation and repositories
Project and programme demands
Regulatory compliance needs

The Process

Map required artefacts to ADM phases
Distinguish deliverables, artefacts, and building blocks
Produce catalogues, matrices, and diagrams per phase
Maintain Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs)
Populate and maintain Architecture Repository
Version-control and baseline artefacts at milestones

Deliverables

Catalogues (e.g. Application Portfolio, Data Entity Catalogue)
Matrices (e.g. Application-Function Matrix, Data-Application Matrix)
Diagrams (context, conceptual, logical, physical)
Architecture Definition Document
Architecture Requirements Specification
Populated Architecture Repository

Practitioner Perspective

The Architecture Content Framework provides a taxonomy for architecture work — a common language for what architects produce and why. Understanding this framework is what separates architects who document from architects who communicate.

The three primary artefact types serve different purposes:

Catalogues answer the question "what do we have?" — lists of things: applications, data entities, technology components, business capabilities, actors, roles
Matrices answer "how do things relate?" — cross-referencing two catalogues reveals relationships, gaps, and redundancies invisible in either alone
Diagrams answer "what does this look like?" — visual representations tailored to the concerns of specific stakeholder groups

The relationships between artefacts are where the real power lies. A business capability mapped to the applications that support it, mapped to the data those applications own, mapped to the technology those systems run on — this traceability chain is the foundation of impact analysis, investment decisions, and architecture governance.

The most common mistake: Producing artefacts for completeness rather than for communication. Every artefact should have a named audience and a specific decision or conversation it enables. If you cannot name both, reconsider whether the artefact is worth producing.

Practical tips:

Use the Content Framework matrix to plan your artefact production by ADM phase — not everything needs to be produced in every engagement; tailor to scope and audience
Distinguish clearly between Architecture Building Blocks (ABBs) — what capability is needed — and Solution Building Blocks (SBBs) — what specific product or component provides it. ABBs define requirements; SBBs define solutions
Version your artefacts and baseline them at the end of each ADM phase — you need to know what was decided and when, especially when projects challenge architecture decisions months later
Invest in tooling early: a proper architecture repository tool (even a structured SharePoint with enforced naming conventions) is significantly better than a shared drive of unlinked Visio files

Part of a series: TOGAF from an Enterprise Architect's Perspective