An Architecture Contract is a joint agreement in which development partners and sponsors settle what an architecture will deliver, its quality and its fitness-for-purpose. Its success depends on effective architecture governance.
Why use them
A governed approach to contracts provides:
- continuous monitoring of integrity, changes, decisions and audit of architecture activity;
- adherence to principles, standards and requirements;
- identification of development and operational risks, supporting a resilient environment;
- processes that ensure accountability, responsibility and discipline;
- a formal understanding of the governing body, its authority and its scope.
The aim is an enterprise architecture that can evolve with technology and business drivers without being needlessly constrained; the contract is the key to governing its implementation. Traditionally contracts sat between a sponsor and the architecture function or IS department; today many parties (systems integrators, application and service providers) are often involved, so contracts are joint agreements among all of them. Figure 12.1 shows where contracts occur in the ADM and who signs each.
Where contracts occur in the ADM
| When | Between whom | Notes |
|---|---|---|
| Phase A | Architecting organisation and sponsor (or IT governance) | The Statement of Architecture Work is effectively a contract |
| When domain development or oversight is outsourced | Architecture function and the external partner | Covers outsourced architecture work |
| Start of Phase G | Architecture function and the implementing function, whether in-house development or a major contractor | The thing being implemented is the overall EA (enterprise-wide or strategic infrastructure, applications and data), not non-strategic business-unit applications added on top later; a large programme may need a separate contract for each implementation team |
| After Phase F (finalised ADD and agreed Implementation and Migration Plan) | Architecting function and business users who will build and deploy in the architected environment | This contract also supports managing changes to the EA during Phase H |
The three types
| Type | Purpose |
|---|---|
| Statement of Architecture Work | Agreement between the architecting organisation and the sponsor on the scope and approach of the architecture work |
| Contract between Architecture Design and Development Partners | A signed statement of intent from the partners who design and develop, such as systems integrators and application and service providers |
| Contract between Architecting Function and Business Stakeholders | Agreement with the business users who will build and deploy within the architected environment |
Common trap: Thinking an Architecture Contract only appears in Phase G - the Statement of Architecture Work in Phase A is effectively a contract, and contracts also arise when work is outsourced and after Phase F with business stakeholders.