In the TOGAF Architecture Development Method (ADM), the Preliminary Phase is often misunderstood as mere "setup" or "administrative overhead." However, it is arguably the most critical phase for long-term success. It defines how architecture will be done in your organization. Without a solid foundation here, subsequent phases risk producing architectures that are ignored, unenforceable, or misaligned with business reality.
This guide zooms in exclusively on the six key deliverables of the Preliminary Phase. Using our ongoing case study of GlobalFin Corp, we will explore what each deliverable is, why it matters, and exactly what it looks like in practice.
Architecture Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission. They provide a framework for making architecture decisions.
Principles prevent "architecture by accident." They ensure that when two teams disagree on a technical approach, they have a pre-agreed set of values to refer to. They reduce decision fatigue and increase consistency.
Principle Name: "Buy Before Build"
Statement: Commercial off-the-shelf (COTS) solutions should be preferred over custom development unless a unique competitive advantage is gained.
Rationale: Reduces maintenance burden, accelerates time-to-market, and leverages vendor security updates.
Implications: All new project proposals must include a market analysis of existing COTS solutions. Custom code requires CIO approval.
Principle Name: "API-First Design"
Statement: All new capabilities must be exposed via well-documented, versioned APIs before any user interface is developed.
Rationale: Enables omnichannel experiences (mobile, web, partner integrations) and decouples frontend from backend.
Implications: No direct database access from frontends. API contracts must be published in the central repository.
The Architecture Repository is a physical or virtual storage location for all architecture-related assets. It includes the Architecture Metamodel, Architecture Capability, Architecture Landscape, Standards Information Base, Reference Library, and Governance Log.
Without a centralized repository, architecture knowledge becomes siloed in individual laptops or emails. The repository ensures reusability, traceability, and single source of truth.
Structure:
Platform: Confluence integrated with ArchiMate and AWS CloudFormation templates.
Folder Structure:
/01_Principles: PDFs of approved principles.
/02_Standards: JSON schemas for API standards, Java version policies.
/03_Reference_Models: Industry-standard banking data models (e.g., BIAN).
/04_Architecture_Landscape: Current state diagrams of all active systems.
/05_Governance_Log: Minutes from Architecture Review Board (ARB) meetings.
Access Control: Read-only for all engineers; Write access for Certified Architects only.
This deliverable defines the structure, roles, responsibilities, and skills required for the architecture function within the organization. It answers: Who does what?
Clarifies accountability. Prevents the "ivory tower" perception by defining how architects engage with project teams. Ensures the right skills are present.
Roles Defined:
Chief Enterprise Architect (Sarah Chen): Accountable for overall strategy and ARB chair.
Domain Architects (3): Responsible for Business, Data, and Technology domains respectively.
Solution Architects (Embedded): Assigned to specific projects (e.g., Mobile App Team). Responsible for day-to-day design compliance.
Architecture Governance Officer: Part-time role ensuring processes are followed.
Engagement Model:
Strategic Level: Quarterly reviews with C-suite.
Tactical Level: Weekly ARB meetings for project approvals >$50k.
Operational Level: Slack channel #arch-help for real-time developer questions.
TOGAF is generic. This deliverable documents how TOGAF has been customized to fit the organization’s size, culture, industry, and maturity. It may involve skipping certain steps, adding specific artifacts, or integrating with other frameworks (e.g., Agile, ITIL).
A rigid, one-size-fits-all TOGAF implementation fails. Tailoring ensures the framework is lightweight enough to be adopted but rigorous enough to add value.
Tailoring Decisions:
Agile Integration: Instead of waiting for full Phase B/C/D completion before coding, GlobalFin adopts "Just Enough Architecture." High-level ADM phases define boundaries, but detailed design happens in Sprint 0 of Agile projects.
Simplified Documentation: For internal tools, only the "Architecture Definition Document" summary page is required. For customer-facing systems, full artifact suite is mandatory.
Terminology Adjustment: Replaced TOGAF term "Building Block" with "Service Component" to align with DevOps terminology.
While Architecture Principles (Deliverable #1) guide technical decisions, this deliverable captures the business context. It links architecture work to strategic business objectives.
Ensures architecture is not doing technology for technology’s sake. Every architectural decision can be traced back to a business goal.
Business Driver: Regulatory Compliance (PSD2/Open Banking)
Impact: Must expose customer account data to third-party providers securely.
Architecture Implication: Need for robust API Gateway with OAuth2.0 and strong customer authentication (SCA).
Business Goal: Increase Cross-Sell Ratio by 15%
Impact: Need a unified view of customer holdings across savings, loans, and investments.
Architecture Implication: Break down data silos; implement a Customer 360 Data Lake.
Business Principle: Customer Centricity
Statement: All digital interactions must be completed in under 3 clicks.
Architecture Implication: Frontend services must aggregate data from multiple backends to reduce user steps.
A formal document initiated by senior management or a business unit that triggers the start of a new architecture cycle. It defines the problem, scope, constraints, and expected outcomes.
It acts as the "contract" that authorizes the architecture team to spend resources. It prevents scope creep and ensures stakeholders are committed.
Document Title: Request for Architecture Work – Digital Lending Platform
Initiator: Head of Retail Banking
Problem Statement: Current loan approval process takes 5 days manually. Competitors offer instant approvals.
Scope: End-to-end personal loan journey from application to disbursement. Excludes mortgage loans.
Constraints: Must integrate with existing Core Banking System (CBS). Budget cap: $2M for implementation.
Expected Deliverables: Target Architecture for Lending Module, Migration Plan, ROI Analysis.
Approval: Signed by CIO and CFO. Date: Jan 15, 2024.
The Preliminary Phase deliverables are not just paperwork; they are the operating system for your enterprise architecture practice.
Principles provide the compass.
Repository provides the memory.
Organization Model provides the hands.
Tailored Framework provides the map.
Business Context provides the destination.
Request for Work provides the fuel.
Investing time in getting these six deliverables right ensures that when you move into Phase A (Architecture Vision) and beyond, you are building on solid ground. For GlobalFin Corp, this clarity allowed them to navigate their complex digital transformation with confidence, avoiding common pitfalls of ambiguity and misalignment.
Next Steps: Once these deliverables are signed off, the architecture team is ready to issue the Statement of Architecture Work and begin Phase A: Architecture Vision.
