Architecture Contracts
Role |
Contents |
Relationship to Architecture Governance
This chapter provides guidelines for defining and using Architecture Contracts.
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 will be delivered through effective
architecture governance (see Architecture Governance). By implementing a governed approach
to the management of contracts, the following will be ensured:
- 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 the development and implementation of the architecture(s) covering the internal
development against accepted standards, policies, technologies, and products as well as the operational aspects of the
architectures such that the organization can continue its business within a resilient environment
- A set of processes and practices that ensure accountability, responsibility, and discipline with regard to the development and
usage of all architectural artefacts.
The traditional Architecture Contract is an agreement between the sponsor and the architecture function or IS department.
However, increasingly more services are being provided by systems integrators, applications providers, and service providers,
co-ordinated through the architecture function or IS department. There is therefore a need for an Architecture Contract to
establish joint agreements between all parties involved in the architecture development and delivery.
Architecture Contracts may occur at various stages of the Architecture Development Method (ADM); for example:
- The Statement of Work created in Phase A of Part II: Architecture Development Method (ADM) is
effectively an Architecture Contract between the architecting organization and the sponsor of the enterprise architecture (or the
IT governance function).
- The development of one or more architecture domains (Business, Data, Applications, Technology), and in some cases the oversight
of the overall enterprise architecture, may be contracted out to systems integrators, applications providers, and/or service
providers. Each of these arrangements will normally be governed by an Architecture Contract that defines the deliverables, quality,
and fitness-for-purpose of the developed architecture, and the processes by which the partners in the architecture development will
work together.
- At the beginning of Phase G (the implementation governance phase), between the architecture function and the function
responsible for implementing the enterprise architecture defined in the preceding ADM phases. Typically, this will be either the
in-house systems development function, or a major contractor to whom the work is outsourced.
- What is being "implemented" in Phase G of the ADM is the overall enterprise architecture. This will typically include the
technology infrastructure (from Phase D), and also those enterprise applications and data management capabilities that have been
defined in the Applications Architecture and Data Architecture (from Phase C), either because they are enterprise-wide in scope, or
because they are strategic in business terms, and therefore of enterprise-wide importance and visibility. However, it will
typically not include non-strategic business applications, which business units will subsequently deploy on top of the technology
infrastructure that is implemented as part of the enterprise architecture.
- In larger-scale implementations, there may well be one Architecture Contract per implementation team in a program of
implementation projects.
- When the enterprise architecture has been implemented (at the end of Phase G), the ADM defines an Architecture Contract between
the architecting function (or the IT governance function, subsuming the architecting function) and the business users who will
subsequently build and deploy business unit-specific application systems in conformance with the architected environment.
It is important to bear in mind in all these cases that the ultimate goal is not just an enterprise architecture, but a dynamic
enterprise architecture; i.e., one that allows for flexible evolution in response to changing technology and business drivers,
without unnecessary constraints. The Architecture Contract is crucial to enabling a dynamic enterprise architecture.
Typical contents of these three kinds of Architecture Contract are explained below.
Contents
Statement of Architecture Work
The Statement of Architecture Work is created as a deliverable of Phase A, and is effectively an Architecture Contract between
the architecting organization and the sponsor of the enterprise architecture (or the IT governance function, on behalf of the
enterprise).
Typical contents of a Statement of Architecture Work are:
- Statement of work title
- Project request and background
- Project description and scope
- Architecture vision
- Managerial approach
- Change of scope procedures
- Responsibilities and deliverables
- Acceptance criteria and procedures
- Project plan and schedule
- Support of the Enterprise Continuum
- Signature approvals
Contract between Architecture Design and Development Partners
This is a signed statement of intent on designing and developing the enterprise architecture, or significant parts of it, from
partner organizations, including systems integrators, applications providers, and service providers.
Increasingly the development of one or more architecture domains (Business, Data, Applications, Technology) may be contracted
out, with the enterprise's architecture function providing oversight of the overall enterprise architecture, and co-ordination and
control of the overall effort. In some cases even this oversight role may be contracted out, although most enterprises prefer to
retain that core responsibility in-house.
Whatever the specifics of the contracting-out arrangements, the arrangements themselves will normally be governed by an
Architecture Contract that defines the deliverables, quality, and fitness-for-purpose of the developed architecture, and the
processes by which the partners in the architecture development will work together.
Typical contents of an Architecture Design and Development Contract are:
- Introduction and background
- The nature of the agreement
- Scope of the architecture
- Architecture and strategic principles and requirements
- Conformance requirements
- Architecture development and management process and roles
- Target architecture measures
- Defined phases of deliverables
- Prioritized joint workplan
- Time window(s)
- Architecture delivery and business metrics
The template for this contract will normally be defined as part of the Preliminary Phase of the ADM, if not existing already,
and the specific contract will be defined at the appropriate stage of the ADM, depending on the particular work that is being
contracted out.
Contract between Architecting Function and Business Users
This is a signed statement of intent to conform with the enterprise architecture, issued by enterprise business users. When the
enterprise architecture has been implemented (at the end of Phase G), an Architecture Contract will normally be drawn up between
the architecting function (or the IT governance function, subsuming the architecting function) and the business users who will
subsequently be building and deploying application systems in the architected environment.
Typical contents of a Business Users' Architecture Contract are:
- Introduction and background
- The nature of the agreement
- Scope
- Strategic requirements
- Architecture deliverables that meet the business requirements
- Conformance requirements
- Architecture adopters
- Time window
- Architecture business metrics
- Service architecture (includes Service Level Agreement (SLA))
This contract is also used to manage changes to the enterprise architecture in Phase H.
Relationship to Architecture Governance
The Architecture Contract document produced in Phase G of the ADM figures prominently in the area of architecture governance, as
explained in Part IV: Resource Base , Architecture Governance
.
In the context of architecture governance, the Architecture Contract is often used as a means of driving architecture
change.
In order to ensure that the Architecture Contract is effective and efficient, the following 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
return to top of page
Navigation
The TOGAF document set is designed for use with frames. To navigate around the document:
- In the main Contents frame at the top of the page, click the relevant hyperlink (Part I, Part II, etc.) to load the Contents
List for that Part of the TOGAF document into the Secondary Index frame in the left margin.
- Then click in that Contents List to load a page into this main frame.
return to top of page
Downloads
Downloads of the TOGAF documentation, are available under license from the TOGAF information web site . The license is free to any
organization wishing to use TOGAF entirely for internal purposes (for example, to develop an information system architecture for
use within that organization). A hardcopy book is also available from The Open Group Bookstore as document G063 .
Copyright © 1999-2006 The Open Group, All Rights Reserved
TOGAF is a trademark of The Open Group