2.3 The TOGAF Content Framework & Enterprise Metamodel
Key Takeaways
- A deliverable is contractually specified and formally reviewed, approved, and signed off by stakeholders, while an artifact describes an aspect of the architecture.
- Artifacts are generally classified as catalogs (lists of things), matrices (relationships between things), and diagrams (pictures of things).
- The TOGAF Content Framework drives consistency, provides a checklist of possible outputs, and reduces the risk of gaps in the deliverable set.
- The Enterprise Metamodel defines the types of entity in the enterprise and their relationships, supporting consistency, completeness, and traceability.
- The TOGAF Standard does not constrain an enterprise's selection of artifacts or modeling notation such as ArchiMate, BPMN, or UML.
2.3 The TOGAF Content Framework & Enterprise Metamodel
Learning Unit 1 asks you to briefly explain the TOGAF Content Framework and Enterprise Metamodel. The short version: the Content Framework is a categorization framework for structuring architecture descriptions and work products, and the Enterprise Metamodel is a formal model of the types of entities in the enterprise and the relationships between them.
Why an Enterprise Needs Both
The TOGAF Standard, 10th Edition explains that an essential task when establishing the enterprise-specific EA Capability in the Preliminary Phase is to define:
- A categorization framework to structure the Architecture Descriptions, the work products used to express an architecture, and the collection of models that describe it — the Content Framework
- An understanding of the types of entities within the enterprise and the relationships between them that need to be captured, stored, and analyzed — the Enterprise Metamodel
- The specific artifacts to be developed
The Content Framework chosen is likely to be influenced by the architecture framework selected as the basis for the EA Capability and by the software tool used to support it.
Deliverables, Artifacts, and Building Blocks
The Content Framework uses three categories to describe architectural work products:
| Category | TOGAF description | Example |
|---|---|---|
| Deliverable | A work product that is contractually specified and in turn formally reviewed, approved, and signed off by the stakeholders. Deliverables represent the output of projects; documentation deliverables are typically archived at project completion or transitioned into an Architecture Repository as a reference model, standard, or snapshot of the Architecture Landscape | Architecture Definition Document |
| Artifact | An architectural work product that describes an aspect of the architecture. Artifacts are generally classified as catalogs (lists of things), matrices (showing relationships between things), and diagrams (pictures of things). A deliverable may contain one or more artifacts, and artifacts form the content of the Architecture Repository | Requirements catalog, application interaction matrix, value chain diagram |
| Building block | A potentially re-usable component that can be combined with other building blocks to deliver architectures and solutions. Architecture Building Blocks (ABBs) typically describe required capability; Solution Building Blocks (SBBs) represent components used to implement it | A customer services capability (ABB) supported by processes, data, and application software (SBBs) |
The standard's example ties them together: an Architecture Definition Document (deliverable) documents an Architecture Description and contains artifacts that are views of relevant building blocks — for instance, a process flow diagram (artifact) describing the target call-handling process (building block), which may also show the actors involved, such as a Customer Services Representative.
The TOGAF Content Framework
There are many alternative content frameworks — the TOGAF Content Framework, the Zachman Framework, DoDAF, NAF, and others. Selecting a content framework is essential, even though the choice of which one is less important, and the final framework is usually adapted to fit specific organization needs.
The TOGAF Content Framework is intended to:
- Provide a detailed model of architectural work products
- Drive consistency in the outputs created when following the ADM
- Provide a comprehensive checklist of architecture output that could be created
- Reduce the risk of gaps within the final architecture deliverable set
- Help an enterprise mandate standard architecture concepts, terms, and deliverables
At the highest level, the Content Framework is structured in line with the phases of the ADM:
| Content area | What it captures |
|---|---|
| Architecture Principles, Vision, Motivation, and Requirements | The surrounding context of formal architecture models: principles, strategic context, and requirements; typically investigated and recorded in the Preliminary and Architecture Vision phases |
| Business Architecture | Models of the business, looking at the factors that motivate the enterprise, its structure, and its capabilities |
| Information Systems Architecture | Models of IT systems, looking at applications and data |
| Technology Architecture | Technology assets used to implement and realize information system solutions |
| Architecture Realization/Transformation | Change roadmaps showing transitions between architecture states, and binding statements used to steer and govern implementation |
| Architecture Change Management | Value realization management events that impact the EA and generate requirements for action |
The Enterprise Metamodel
The TOGAF Standard encourages development of an Enterprise Metamodel, which defines the types of entity that appear in models describing the enterprise, together with the relationships between those entities. The glossary defines a metamodel as "a model that describes the entities used in building an Architecture Description, their characteristics, and the key relationships between those entities."
The standard's example: one entity type might be Role; the Business Architecture models might then contain instances such as Teller, Pilot, Manager, Volunteer, Customer, or Firefighter.
An Enterprise Metamodel provides value because it:
- Gives architects a starter set of the types of things to investigate and model
- Provides a completeness check for any modeling language or metamodel proposed for use
- Helps ensure consistency, completeness, and traceability
The standard does not aim to constrain an enterprise's selection of artifacts or modeling notation; ArchiMate®, BPMN™, UML®, entity-relationship diagramming, flowcharting, or other notations can express TOGAF ideas. Entity types and relationships are specific to each enterprise, so developing a high-quality metamodel is an important part of establishing the EA Capability.
The Core Enterprise Metamodel
To help, TOGAF provides a Foundation-level Core Enterprise Metamodel (detailed in the Architecture Content document). Its entities are grouped as follows:
| Group | Example entity types |
|---|---|
| Architecture Principles, Vision, and Requirements | Architecture Principles; Business Strategy; Technology Strategy; Business Principles, Objectives, and Drivers; Architecture Vision; Stakeholders; Requirements; Constraints; Assumptions; Gaps; Locations |
| Motivation | Drivers, Goals, Objectives, Measures |
| Business Architecture | Value Streams, Business Capabilities, Courses of Action, Business Services, Contracts, Service Qualities, Business Information, Products, Processes, Events, Controls, Functions, Organization Units, Actors, Roles |
| Information Systems Architecture | Data Entities, Logical Data Components, Physical Data Components; Application Services, Logical Application Components, Physical Application Components |
| Technology Architecture | Technology Services, Logical Technology Components, Physical Technology Components |
| Architecture Realization | Capabilities, Work Packages, Architecture Contracts, Standards, Guidelines, Specifications |
Notice the pattern of logical versus physical components in each Information Systems and Technology area — it mirrors the logical and physical abstraction levels from Section 1.3.
Common Exam Pitfalls
- Swapping the two concepts. The Content Framework categorizes work products; the Enterprise Metamodel defines entity types and relationships.
- Mis-classifying artifacts. Catalogs list things, matrices show relationships between things, diagrams are pictures of things.
- Thinking TOGAF mandates a notation. The metamodel does not constrain artifact selection or modeling notation.
- Treating every artifact as a deliverable. Whether an artifact is a deliverable depends on the contractual specification.
Which statement correctly distinguishes a deliverable from an artifact in the TOGAF Content Framework?
An architect produces a grid showing which organization units use which applications. How is this artifact classified?
Which of the following is a stated benefit of an Enterprise Metamodel in the TOGAF Standard?
According to the TOGAF Standard, what is true about choosing a content framework?