Key takeaways
- The category depends on the context of use, not on form alone.
- Deliverable ⊃ artifacts ⊃ views of building blocks.
- An artifact is a deliverable only if the contract says so.
- Artifacts form the content of the Repository.
- A closed deliverable is archived or re-used through the Repository.
- Architecture Definition Document
- Describes the architecture, such as applications and their relationships. It contains artifacts such as a diagram.
- Architecture Requirements Specification
- Specifies verifiable conditions, such as the service responding within two seconds under agreed conditions.
- Architecture Roadmap
- Sequences work packages and transitions over time to reach the target.
Illustrative example: names, measures and decisions depend on the context. An artifact describes an aspect; a deliverable formalizes a result subject to review and approval.
Three categories defined by use
The Content Framework classifies a work product by the role it plays. A deliverable is specified in a contract, then reviewed, approved, and signed off by stakeholders. An artifact describes a specific aspect of the architecture. A building block is a potentially re-usable component that, combined with others, delivers architectures and solutions.
The same object can therefore change category with the context: a matrix remains an artifact, but it also becomes a deliverable if the contract names it explicitly.
- Deliverable: contractual commitment, formally approved
- Artifact: catalog, matrix, or diagram describing an aspect
- Building block: re-usable element described by artifacts
The nesting chain
Take an Architecture Definition Document: it is a deliverable that documents an Architecture Description. It contains complementary artifacts, for instance a flow diagram of the target call handling process. That process is a building block; the same diagram also shows another building block, the "customer services representative" actor.
One artifact can thus describe several building blocks, and a deliverable usually contains several artifacts. Artifacts make up the content of the Architecture Repository.
What happens to products after the project
Deliverables represent the output of projects. At closure, those in document form are either archived or moved into the Architecture Repository as a reference model, as a standard, or as a snapshot of the Architecture Landscape at a given time.
Building blocks, for their part, gain detail as work progresses: just a name at first, then a decomposition into supporting blocks with a full specification. They come as Architecture Building Blocks and Solution Building Blocks.
- Archiving of the document deliverable
- Or transition into the Repository: reference model, standard, Landscape snapshot
Common traps
Three confusions come up often. The first assumes a deliverable must be a large document: what counts is its contractual status and its approval. The second treats artifact and building block as the same; yet the artifact describes, while the building block is the thing described. The third forgets that the catalog, matrix, diagram classification applies to artifacts, not to deliverables.
To decide, ask three questions: is the product required and signed off by contract? Does it describe an aspect of the architecture? Does it represent a re-usable thing that domain experts recognize?
TERMS TO KNOW
The terms, in context.
- Deliverable
- Work product specified by contract, reviewed, approved, and signed off by stakeholders.
- Artifact
- Product describing one aspect of the architecture, as a catalog, matrix, or diagram.
- Building block
- Potentially re-usable component that can be combined with others to deliver architectures and solutions.
- Architecture Description
- Set of views and models documenting an architecture; the ADD is its vehicle.