3.2 Terms for Work Products, Models, Requirements & Change
Key Takeaways
- TOGAF defines a Requirement as a statement of need that is unambiguous, testable or measurable, and necessary for acceptability.
- A Metamodel is a model that describes the entities used in building an Architecture Description, their characteristics, and the key relationships between them.
- A Work Package is a set of actions to achieve one or more business objectives and can be part of a project, a complete project, or a program.
- A Gap is a statement of difference between two states, used in gap analysis to identify the difference between the Baseline and Target Architectures.
- TOGAF defines a Stakeholder as an individual, team, organization, or class thereof, having an interest in a system.
3.2 Terms for Work Products, Models, Requirements & Change
This section completes the Learning Unit 2 terminology. It covers the words TOGAF uses for what architects produce (artifacts, deliverables, models), how they describe things (metamodel, modeling, business model), who and what they deal with (stakeholder, role, requirement), and how change is packaged (gap, work package).
Work Products
| Term | TOGAF definition | Plain-language meaning |
|---|---|---|
| Deliverable | An architectural work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders | A formal, signed-off output, such as a Statement of Architecture Work or Architecture Definition Document |
| Artifact | An architectural work product that describes an aspect of the architecture | A catalog, matrix, or diagram describing part of the architecture |
The note on Deliverable adds that 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.
Key distinction: every deliverable is formally agreed and signed off; an artifact may or may not be a deliverable, depending on the contractual specification, and a deliverable usually contains several artifacts.
Models and Modeling
| Term | TOGAF definition | Plain-language meaning |
|---|---|---|
| Architecture Model | A representation of a subject of interest. An architecture model provides a smaller scale, simplified, and/or abstract representation of the subject matter | A simplified picture or structure that stands in for the real thing |
| Metamodel | A model that describes the entities used in building an Architecture Description, their characteristics, and the key relationships between those entities | A "model of the model" — which entity types and relationships are allowed |
| Modeling | A technique through construction of models which enables a subject to be represented in a form that enables reasoning, insight, and clarity concerning the essence of the subject matter | The act of building models so people can reason about something |
| Business Model | A model describing the rationale for how an enterprise creates, delivers, and captures value | How the enterprise makes or delivers value, for example as described with a Business Model Canvas |
How These Fit Together
- The metamodel says a model may contain entity types such as Actor, Role, Process, and Application Component, and how they may relate.
- Modeling is the technique of building architecture models that use those entity types.
- A business model is one particular kind of model — about value creation, delivery, and capture — used mainly in Business Architecture.
- Related glossary terms: an Architecture View is a representation of a system from the perspective of a related set of concerns, and a Model Kind is the conventions for a type of modeling; a viewpoint references model kinds and a view incorporates models.
Stakeholders, Roles, and Requirements
| Term | TOGAF definition | Plain-language meaning |
|---|---|---|
| Stakeholder | An individual, team, organization, or class thereof, having an interest in a system | Anyone with an interest in the system or the architecture |
| Role | (1) The usual or expected behavior of an actor, or the part somebody or something plays in a particular process or event; an actor may have a number of roles. (2) The part an individual plays in an organization and the contribution they make through the application of their skills, knowledge, experience, and abilities | A part played by an actor, not the actor itself |
| Requirement | A statement of need, which is unambiguous, testable or measurable, and necessary for acceptability | A need precise enough to test and important enough that the result is unacceptable without it |
Actor Versus Role
The glossary defines an Actor as "a person, organization, or system that has one or more roles that initiates or interacts with activities." One actor can hold several roles: a single employee (actor) might play the roles of claims approver and fraud reviewer.
What Makes a Good Requirement
A TOGAF requirement has three qualities built into the definition:
- Unambiguous — only one reasonable interpretation
- Testable or measurable — you can verify whether it is met
- Necessary for acceptability — without it, the solution would not be acceptable
Compare: "the portal should be fast" fails the test; "the portal shall return account balances within two seconds for 95% of requests" passes it.
Gaps and Work Packages
| Term | TOGAF definition | Plain-language meaning |
|---|---|---|
| Gap | A statement of difference between two states. Used in the context of gap analysis, where the difference between the Baseline and Target Architecture is identified | What must change to get from one state to another |
| Work Package | A set of actions identified to achieve one or more objectives for the business. A work package can be a part of a project, a complete project, or a program | A bundle of change activity that closes gaps |
Gaps are identified in Phases B, C, and D, consolidated in Phase E, and addressed by work packages, which are sequenced on the Architecture Roadmap and scheduled in the Implementation and Migration Plan. Note the flexibility in the Work Package definition: it can be part of a project, a complete project, or a program.
Worked Example: An Insurance Claims Initiative
| Term | Example in the initiative |
|---|---|
| Stakeholder | Head of Claims, Chief Risk Officer, claims handlers, regulators |
| Role | Claims Approver; Fraud Reviewer (both played by senior handlers) |
| Requirement | "Claims under USD 1,000 shall be settled within 24 hours for 90% of cases" |
| Architecture Model | A process model of the target claims journey |
| Metamodel | The enterprise's rule that a Process is performed by a Role and supported by an Application Component |
| Business Model | How the insurer creates value through faster, lower-cost claims handling |
| Artifact | Application/Organization matrix showing which teams use which claims systems |
| Deliverable | The signed-off Architecture Definition Document for claims |
| Gap | Baseline has no automated fraud scoring; target does |
| Work Package | "Automated fraud scoring," delivered as one project within the claims program |
Common Exam Pitfalls
- Calling an artifact a deliverable. Only work products that are contractually specified and signed off are deliverables.
- Confusing Metamodel with Architecture Model. A metamodel describes the entities and relationships used to build architecture descriptions; an architecture model represents a subject of interest.
- Treating a Role as a person. A role is the part an actor plays; the actor is the person, organization, or system.
- Forgetting the three qualities of a Requirement. Unambiguous, testable or measurable, and necessary for acceptability.
- Assuming a Work Package is always a single project. It can be part of a project, a whole project, or a program.
Which set of qualities is part of the TOGAF definition of a Requirement?
How does the TOGAF Standard define a Work Package?
What is the difference between a Metamodel and an Architecture Model?
A single operations manager acts as both "incident approver" and "change reviewer" in the architecture models. In TOGAF terms, what are "incident approver" and "change reviewer"?