Before an organization can begin the journey of designing its future state, it must first build the foundation that allows it to do so. In the TOGAF Architecture Development Method (ADM), this critical groundwork is known as the Preliminary Phase. Often overlooked, this phase is the bedrock of successful enterprise architecture. It transforms an organization from a group of disparate departments into a cohesive entity ready to execute complex architectural initiatives.
This tutorial explores the anatomy of the Preliminary Phase, breaking down the five key pillars required to establish architecture capability, defining the scope, setting principles, and structuring the governance necessary for success.
The Core Objective: Establishing Architecture Capability
The primary goal of the Preliminary Phase is to define the organization’s Architecture Capability. This is not merely about hiring a few architects; it is about creating a structured environment where architecture work can be conducted effectively. Think of this phase as setting up the laboratory before attempting the experiment.
To achieve this, the organization must address five specific areas, often visualized as the central hub of the architecture process:
- Define Capability: Assessing the current state and planning the future.
- Set Principles: Establishing the rules of engagement.
- Establish Governance: Creating the oversight bodies.
- Tailor the ADM: Adapting the method to fit the organization.
- Set Scope, Roles & Tools: Defining the boundaries and the team.
Step 1: Defining the Scope
The first practical step is determining where architecture will be applied. Architecture is not a “one size fits all” activity; it must be scoped correctly to be manageable yet impactful.
Levels of Scope
Depending on the organization’s needs, the scope of the Preliminary Phase can vary:
- Enterprise: The entire organization, covering all business units and technologies.
- Business Unit: A specific division or department (e.g., HR, Finance).
- Region: A specific geographic location or market.
- Product Line: A specific suite of products or services.
- Program: A specific transformation program or major initiative.
- Domain: A specific capability, such as Data, Security, or Infrastructure.
Key Insight: The scope must be broad enough to address dependencies between different parts of the business but narrow enough to remain manageable. If the scope is too broad, the architecture effort can become paralyzed by complexity. If it is too narrow, it may miss critical integration points.
Step 2: Establishing Architecture Principles
Once the scope is defined, the organization needs a compass to guide decision-making. These are the Architecture Principles. They are statements that describe the organization’s beliefs regarding how it will achieve its business goals.
Examples of Standard Principles
Effective principles are typically:
- Business continuity is essential: Systems must remain available and resilient.
- Security is designed into solutions: Security is not an afterthought but a foundational element.
- Data is treated as a strategic asset: Data quality and management are critical to success.
- Reuse is preferred over duplication: Solutions should be shared where possible to reduce cost and complexity.
- Standards are preferred over proprietary dependencies: Open standards ensure long-term flexibility.
- Technology decisions must support business outcomes: IT exists to enable business, not the other way around.
Structure of a Principle
A robust principle document usually contains three components:
- Name: A concise title (e.g., “Data Reuse”).
- Statement: A clear directive (e.g., “Shared data services are to be used wherever possible”).
- Rationale & Implications: The “Why” and the “So What.” Why is this important, and how does it impact daily operations?
Step 3: Establishing Governance
Principles are useless without enforcement. The Governance Framework defines how architecture decisions are made, approved, and monitored. This structure ensures that the architecture remains aligned with business strategy.
Key Governance Functions
- Approve Decisions: Who has the authority to sign off on major architectural changes?
- Resolve Conflicts: How are disputes between business units or technical teams resolved?
- Grant Exceptions: What happens when a strict principle cannot be met due to business urgency?
- Monitor Compliance: How do we ensure projects are actually adhering to the architecture?
- Manage Standards: Who maintains the catalog of approved technologies?
This governance is often executed through an Architecture Board (or Review Forums), which may include representatives from security, data, and portfolio management.
Step 4: Establishing the Architecture Team
Architecture is a team sport. The Preliminary Phase requires identifying the right talent and roles to execute the work. A typical architecture team is multidisciplinary:
- Chief or Lead Architect: Provides overall vision and leadership.
- Business Architect: Focuses on business strategy, processes, and capabilities.
- Data Architect: Manages data structure, governance, and flows.
- Application Architect: Oversees the application portfolio and integration.
- Technology Architect: Focuses on infrastructure, platforms, and hardware.
- Security Architect: Ensures security requirements are met across all layers.
- Program & Project Representatives: Ensures alignment with delivery teams.
Step 5: Selecting Tools and Repositories
Finally, the organization needs the infrastructure to store and model its architecture. This involves selecting the right Architecture Repositories and modeling tools.
Essential Repository Contents
- Architecture Modeling Tools: Software to create diagrams and models.
- Standards Catalogs: A list of approved technologies and standards.
- Reference Architectures: Blueprints for common solutions.
- Application & Technology Inventories: A detailed list of existing assets.
- Principles Repositories: A central place to manage principles.
- Architecture Decision Records (ADRs): Documentation of why specific decisions were made.
- Roadmap & Dependency Management: Tools to plan future states and track relationships.
Recommended Tooling for the ADM
Executing the Preliminary Phase and the subsequent ADM cycles requires robust software to manage complex models, maintain repositories, and facilitate collaboration. For organizations looking to implement this framework efficiently, the Visual Paradigm TOGAF ADM Tool is the recommended solution. This tool provides comprehensive support for the entire ADM lifecycle, offering features such as:
- Automated Repository Management: Easily store and version control architecture artifacts.
- Integrated Modeling: Create data flow diagrams, architecture views, and roadmaps within a unified environment.
- Collaboration: Enable teams to work together on the architecture capability.
- Compliance Tracking: Monitor adherence to principles and governance rules.
Conclusion
The Preliminary Phase is the launchpad for the entire TOGAF journey. By carefully defining the scope, setting clear principles, establishing governance, building a skilled team, and selecting the right tools, an organization creates a sustainable architecture capability. With a solid foundation in place, the organization is ready to move forward to Phase A: Architecture Vision, confident that it has the structures and rules necessary to succeed.
