11.3 Architecture Contracts
Key Takeaways
- Architecture Contracts are joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture, delivered through effective Architecture Governance.
- The Statement of Architecture Work created in Phase A is effectively an Architecture Contract between the architecting organization and the sponsor.
- An Architecture Contract with the function implementing the architecture is agreed at the beginning of Phase G, and the signed contract is a Phase G output.
- A business users' Architecture Contract is normally drawn up at the end of Phase F and is also used to manage changes to the Enterprise Architecture in Phase H.
- TOGAF says the Architecture Contract is crucial to enabling a dynamic Enterprise Architecture and is often used as a means of driving architecture change.
11.3 Architecture Contracts
The Foundation syllabus asks you to briefly explain the role of Architecture Contracts. They turn agreements about architecture into explicit commitments that governance can monitor — between the architecture function and its sponsor, the partners who help develop the architecture, the teams who implement it, and the business users who build on it.
Definition and Role
Architecture Contracts are the joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture. Successful implementation of these agreements is delivered through effective Architecture Governance (Section 11.1).
By implementing a governed approach to the management of contracts, the TOGAF Standard says an organization ensures:
- A system of continuous monitoring to check integrity, changes, decision-making, and audit of all architecture-related activities within the organization
- Adherence to the principles, standards, and requirements of the existing or developing architectures
- Identification of risks in all aspects of developing and implementing the architecture — both internal development against accepted standards, policies, technologies, and products, and the operational aspects, so the organization can continue its business within a resilient environment
- A set of processes and practices that ensure accountability, responsibility, and discipline in the development and usage of all architectural artifacts
- A formal understanding of the governance organization responsible for the contract, its level of authority, and the scope of the architecture under its governance
Why Contracts Are Needed
The traditional Architecture Contract is an agreement between the sponsor and the architecture function or Information Systems (IS) department. Increasingly, however, services are provided by systems integrators, applications providers, and service providers, co-ordinated through the architecture function or IS department. Architecture Contracts are therefore needed to establish joint agreements between all parties involved in architecture development and delivery.
Where Architecture Contracts Occur in the ADM
| Occasion | Parties | When |
|---|---|---|
| Statement of Architecture Work — effectively an Architecture Contract | The architecting organization and the sponsor of the Enterprise Architecture (or the IT governance function, on behalf of the enterprise) | Created as a deliverable of Phase A |
| Contracted-out architecture development | The architecture function and systems integrators, applications providers, or service providers developing one or more architecture domains (and occasionally overseeing the whole Enterprise Architecture) | At the stage of the ADM that suits the contracted work; the contract template is normally defined in the Preliminary Phase |
| Implementation of the architecture | The architecture function and the function responsible for implementing the architecture — typically the in-house systems development function or a major contractor | At the beginning of Phase G; a large program may have one contract per implementation team |
| Adoption by business users | The architecting function and the business users or stakeholders who will build and deploy application systems or business solutions in the architected environment | When the finalized architecture and the Implementation and Migration Plan are agreed at the end of Phase F |
What is "implemented" in Phase G is the overall Enterprise Architecture: typically the technology infrastructure from Phase D, plus the enterprise applications and data management capabilities from Phase C that are enterprise-wide or strategic. Non-strategic business applications, which business units later deploy on that infrastructure, are typically not included.
TOGAF stresses that the ultimate goal is not just an Enterprise Architecture but a dynamic one that can evolve flexibly as technology and business drivers change. The Architecture Contract is crucial to enabling a dynamic Enterprise Architecture and key to governing its implementation.
Typical Contents
The Statement of Architecture Work has the contents described in Section 12.3. The other two kinds of contract compare as follows:
| Architecture Design and Development Contract | Business Users' Architecture Contract |
|---|---|
| Introduction and background | Introduction and background |
| The nature of the agreement | The nature of the agreement |
| Scope of the architecture | Scope |
| Architecture and strategic principles and requirements | Strategic requirements |
| Conformance requirements | Conformance requirements |
| Architecture development and management process and roles | Architecture adopters |
| Target Architecture measures | Time window |
| Defined phases of deliverables | Architecture business metrics |
| Prioritized joint workplan | Service architecture, including the Service-Level Agreement (SLA) |
| Time window(s) | |
| Architecture delivery and business metrics |
The design and development contract is a signed statement of intent from partner organizations on designing and developing the Enterprise Architecture, or significant parts of it. The EA Capability and Governance document calls the second contract one between the architecting function and business stakeholders, and also lists architecture deliverables that meet the business requirements. That contract is also used to manage changes to the Enterprise Architecture in Phase H.
Architecture Contracts in Phases G and H
| Point in the ADM | Contract activity |
|---|---|
| Phase G input | A standard Architecture Contract |
| Phase G step "Guide Development of Solutions Deployment" | Document the Architecture Contract and obtain signatures from all developing organizations and the sponsoring organization |
| Phase G output | Architecture Contract (signed) |
| Phase H input | The signed Architecture Contract |
| Phase H output | Architecture Contract, updated if necessary |
TOGAF describes Phase G as establishing the connection between architecture and the implementation organization through the Architecture Contract. In Phase H, architecture change management is closely related to Architecture Governance and to managing the Architecture Contract between the architecture function and the business users.
Relationship to Architecture Governance
The Architecture Contract produced in Phase G figures prominently in Architecture Governance, where it is often used as a means of driving architecture change. To make the contract effective and efficient, these aspects of the governance framework may need to be introduced into Phase G:
- Simple processes
- People-centered authority
- Strong communication
- Timely responses and an effective escalation process
- Supporting organizational structures
- Status tracking of architecture implementation
The Architecture Board identifies divergence from the contract and plans realignment through dispensations or policy updates. It also ensures that information relevant to implementing the contract is published under controlled conditions to authorized parties, and requests for change are made within the authority levels and parameters the contract defines. Compliance reviews (Section 11.4) check the work against the contract; Compliance Assessments and decisions such as standards deviations are recorded in the Governance Repository.
Scenario: Contracts Across a Health Authority's ADM Cycle
A health authority is building a shared patient-record platform:
- In Phase A, the chief architect and the sponsoring executive approve a Statement of Architecture Work.
- The authority lacks data specialists, so it contracts a consultancy to develop the Data Architecture under an Architecture Design and Development Contract based on the template agreed in the Preliminary Phase, with conformance requirements and a prioritized joint workplan.
- At the end of Phase F, the regional clinics that will deploy local applications on the shared platform sign a business users' contract covering conformance requirements, business metrics, and SLAs.
- At the beginning of Phase G, the architecture function and the systems integrator building the shared identity and integration services sign the implementation contract.
When the integrator later proposes a non-standard messaging product, the contract's conformance requirements frame the compliance review, and the Architecture Board decides whether to grant a time-limited dispensation or require realignment.
Common Exam Pitfalls
- Treating Architecture Contracts as commercial purchase orders. They are joint agreements on deliverables, quality, and fitness-for-purpose, delivered through Architecture Governance.
- Forgetting the Statement of Architecture Work. It is effectively an Architecture Contract between the architecting organization and the sponsor, created in Phase A.
- Putting every contract in Phase G. The implementation contract is agreed at the beginning of Phase G and the signed contract is a Phase G output, but design and development contracts arise whenever architecture work is contracted out, and the business users' contract is drawn up at the end of Phase F.
- Mixing up the two content lists. Process and roles, defined phases of deliverables, and a prioritized joint workplan belong to the design and development contract; architecture adopters and the SLA belong to the business users' contract.
How does the TOGAF Standard describe Architecture Contracts?
Which deliverable, created in Phase A, is effectively an Architecture Contract between the architecting organization and the sponsor of the Enterprise Architecture?
Which of the following is a typical section of an Architecture Design and Development Contract?
According to the TOGAF Standard, when is an Architecture Contract normally agreed between the architecture function and the function responsible for implementing the Enterprise Architecture?
Which of the following is an aspect of the governance framework that TOGAF says may need to be introduced into Phase G so the Architecture Contract is effective and efficient?