Key takeaways
- ADD = qualitative view, intent; ARS = quantitative view, measurable criteria.
- ADD: created in A, enriched in B, C, D, Transition Architectures added in E.
- ARS: tied to Requirements Management and to Phases B, C, D.
- Phase B provides the first technical requirements that drive what follows.
- Phase C flags induced business changes and constrains Phase D.
- 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.
Two complementary deliverables
The Architecture Definition Document is the container for a project's architecture artifacts. It covers the four domains and every useful state: Baseline, Transition, and Target. It gives a qualitative view of the solution and communicates the architects' intent.
The Architecture Requirements Specification provides the quantitative view: measurable statements an implementation project must meet to comply. It often forms a significant part of an implementation contract or of a contract for more detailed definition.
Lifecycle and content of the Architecture Definition Document
It is created in Phase A with the artifacts supporting the vision, enriched in B, C, and D with each domain's material, then completed in Phase E with one or more Transition Architectures if the Target must be reached in steps.
Each domain adds its Baseline where relevant, its Target, and views matching the chosen viewpoints. Business: organization structure and locations, goals, functions decomposed into sub-functions, capabilities, services, products, processes, roles, business data model, organization/function matrix. Data: business and logical data models, data management processes, entity/function matrix. Technology: components and platforms, environments and locations, load and distribution, physical communications, hardware and network specifications.
- Scope; goals and constraints; Architecture Principles
- Baseline; domain models for each state
- Rationale for the approach; Repository mapping (Landscape, reference models, standards, re-use)
- Gap analysis; impact assessment; Transition Architecture
Content of the Architecture Requirements Specification
Phase B adds gap analysis results, updated business requirements, and an initial batch of technical requirements that steer what follows and prioritize implications for the other domains. Phase C adds data and application interoperability requirements, areas where the Business Architecture must change, and constraints for the Technology Architecture to be designed. Phase D adds its gap analysis results and updated technology requirements. Interoperability is addressed throughout the cycle.
- Success measures; architecture requirements
- Business and application service contracts
- Implementation guidelines, specifications, and standards
- Interoperability; IT service management; constraints; assumptions
TERMS TO KNOW
The terms, in context.
- Architecture Definition Document (ADD)
- Container of architecture artifacts, covering domains and states; qualitative view.
- Architecture Requirements Specification (ARS)
- Quantitative statements a project must meet to comply with the architecture.
- Technical requirements (Phase B)
- First batch of requirements from the Business Architecture, driving the following phases.
- Repository mapping
- ADD section linking the architecture to the Landscape, reference models, standards, and re-use.