2.2 Preliminary Phase: Scope, Principles, and Architecture Capability Setup
Key Takeaways
- The Preliminary Phase prepares the organization to undertake enterprise architecture projects by defining 'where, why, who, and how' architecture is built.
- Establishing enterprise scope requires clarifying organizational boundaries, governance frameworks, vertical levels, and time horizons.
- TOGAF's Architecture Principle template has four components — Name, Statement, Rationale, and Implications — and a good principle satisfies five quality criteria: Understandable, Robust, Complete, Consistent, and Stable.
- Setting up an Architecture Capability involves establishing the Architecture Board, defining governance frameworks, and selecting appropriate EA tools and repositories.
- Key outputs of the Preliminary Phase include the Organizational Model for Enterprise Architecture, Architecture Principles, and Tailored Architecture Framework.
2.2 Preliminary Phase: Scope, Principles, and Architecture Capability Setup
The Preliminary Phase is the foundational preparation phase of the TOGAF Architecture Development Method (ADM). Before an enterprise can initiate specific architecture development cycles, it must establish its architecture capability, define its organizational scope, select supporting tools, and establish enduring governance principles.
The primary goal of the Preliminary Phase is to answer the fundamental operational questions: Where, why, who, and how will Enterprise Architecture (EA) be conducted within the organization?
Objectives of the Preliminary Phase
The Preliminary Phase creates the environment required for sustainable EA delivery. Its primary objectives include:
- Defining the Enterprise Scope: Determining the boundaries of the enterprise to be architected.
- Establishing Architecture Principles: Crafting enduring rules and guidelines that govern architectural decision-making.
- Establishing the Architecture Capability: Setting up the organizational structures, roles, and responsibilities, including the Architecture Board.
- Tailoring TOGAF and Frameworks: Customizing the ADM process, metamodel, and terminology to fit organizational culture and existing frameworks (e.g., ITIL, COBIT, SAFe).
- Setting Up Architecture Governance & Tools: Selecting modeling tools, repository structures, and governance procedures.
Determining Enterprise Scope & Boundaries
In TOGAF, an "enterprise" is defined as any collection of organizations that has a common set of goals. An enterprise can be a complete corporation, a government agency, a single division, an enterprise business unit, or a network of extended partner organizations.
During the Preliminary Phase, enterprise architects must explicitly define four dimensions of scope:
| Scope Dimension | Description & Key Considerations |
|---|---|
| Organizational Extent | Which business units, subsidiaries, divisions, or external partner networks are included in or excluded from the EA effort? |
| Architecture Domains | Which of the four BDAT domains (Business, Data, Application, Technology) will be emphasized or covered? |
| Vertical Scope / Depth | At what level of detail will the architecture be built (e.g., Strategic, Segment, or Capability level)? |
| Time Horizon | What is the planning horizon for baseline, target, and transition architectures (e.g., 1-year tactical vs. 5-year strategic)? |
Failing to establish clear scope boundaries during the Preliminary Phase leads to "scope creep," unmanageable complexity, and alignment failures with business stakeholders.
Establishing Architecture Principles
Architecture Principles are enduring qualitative guidelines and rules that govern the development, maintenance, and implementation of all enterprise architectures across the organization. They reflect a consensus across business and IT leadership regarding how technology decisions will support enterprise strategy.
The Four Standard Components of an Architecture Principle
TOGAF specifies a standard, structured format for defining every architecture principle. The TOGAF template has exactly four components — Name, Statement, Rationale, and Implications. Many organizations add local metadata such as an identifier, category, or priority, but that metadata is a local extension, not part of the TOGAF template. Exam questions on this topic reward the four-component answer:
- Name: A short, memorable, and clear title that captures the essence of the principle (e.g., Data is an Asset).
- Statement: A concise, unambiguous statement of the rule or guidance. It must be written in definitive language (e.g., Data is an asset that has value to the enterprise and is managed accordingly).
- Rationale: A compelling business justification that explains why the principle is necessary and how it supports business goals or mitigates enterprise risk.
- Implications: The concrete operational, financial, technical, and cultural consequences of enforcing the principle. This section highlights required investments, trade-offs, and behavioral changes.
(Optional local extension: an identifier, category, or governance priority. Useful in a large principle set, but not one of the four TOGAF components.)
What Makes a Good Architecture Principle?
Writing principles is easy; writing good ones is not. TOGAF sets out five quality criteria that a principle must satisfy, and candidates are expected to recognise all five by name:
| Criterion | What it Demands | Failure Symptom |
|---|---|---|
| Understandable | The intention is clear and unambiguous so that it can be applied consistently by people who were not in the room when it was written. | Two teams read the same principle and reach opposite design decisions. |
| Robust | Precise enough to support good-quality decisions and enforceable policy, even in contested or novel situations. | The principle is quoted by both sides of an architecture dispute. |
| Complete | Every situation the principle is meant to govern is covered, as far as can be foreseen. | Cloud workloads are exempt "because the principle predates cloud". |
| Consistent | Principles do not contradict one another; where they pull in opposite directions, the trade-off is made explicit. | "Buy before build" collides head-on with "maximise reuse of in-house services". |
| Stable | Enduring, and changed only through a documented change process rather than reactively per project. | The principle set is rewritten every time a new CIO arrives. |
A practical test: read the Implications aloud to the people who will be constrained by them. If nobody objects, the principle is probably too vague to be robust.
Example Architecture Principles Matrix
| Principle Name | Statement | Rationale | Implications |
|---|---|---|---|
| Data is an Asset | Data is a valuable enterprise asset managed centrally across all business domains. | Accurate data is required for strategic decision-making; silos create data duplication and compliance risks. | Shared data ownership must be established; business data stewards must be appointed; legacy applications must expose data interfaces. |
| Common Use Applications | Applications used across multiple business units shall be standardized enterprise-wide. | Eliminates redundant software licenses, reduces support overhead, and streamlines business integration. | Individual business units must surrender custom applications in favor of enterprise standard solutions; customization requires Architecture Board approval. |
| Business Continuity | Enterprise services must maintain business operations despite hardware, network, or site failures. | Unplanned downtime leads to direct revenue loss, regulatory penalties, and reputational damage. | Systems must be architected for high availability; multi-region failover and disaster recovery testing become mandatory design requirements. |
| Requirements-Based Change | Architectural and technology changes are made only in response to defined business needs. | Prevents technology-driven scope creep and ensures IT investments directly yield business value. | IT projects cannot introduce new platforms without an approved business case and Architecture Board dispensation. |
Setting Up Architecture Capability & Governance
A core responsibility of the Preliminary Phase is establishing the organizational infrastructure to govern and execute EA.
The Architecture Board
The Preliminary Phase establishes the Architecture Board, a cross-functional governance body comprising executive business sponsors, domain architects, IT leaders, and risk/security officers. The board is responsible for:
- Reviewing and approving target architectures and Statements of Architecture Work.
- Conducting formal architecture compliance reviews.
- Evaluating change requests and granting architectural dispensations (temporary or permanent exceptions to standards).
- Resolving architectural conflicts across business units.
Architecture Repository & Tooling
The Preliminary Phase defines the architecture toolset and initializes the Architecture Repository. The repository stores:
- Architecture Metamodel: The structural taxonomy of artifacts.
- Architecture Landscape: Models of baseline, target, and transition architectures across Strategic, Segment, and Capability levels.
- Standards Information Base (SIB): Approved technology standards, platforms, and building block specifications.
- Governance Log: Records of board decisions, compliance reviews, and granted dispensations.
Key Deliverables of the Preliminary Phase
Upon completion, the Preliminary Phase produces several foundational outputs:
- Organizational Model for Enterprise Architecture: Defines roles, skills, reporting structures, and governance bodies.
- Tailored Architecture Framework: Customized ADM, tailored metamodel, and adapted guidelines.
- Architecture Principles: Formally approved list of business, data, application, and technology principles.
- Restructured Architecture Repository: Operational repository environment configured with access controls and metamodels.
Which of the following represents the primary structural components of a standard TOGAF Architecture Principle?
What is a primary responsibility of the Architecture Board established during the Preliminary Phase?
Why must enterprise scope be explicitly defined during the Preliminary Phase?
An enterprise publishes a principle whose wording is so general that two delivery teams applied it to reach opposite integration decisions. Which TOGAF quality criterion for a good Architecture Principle has this principle failed?