⏱ 5 min read
Recommended Reading
Executive summary
Agile delivery amplifies the cost of uncontrolled architecture drift—but it also punishes heavyweight, document-centric governance. Operationalizing TOGAF governance in agile environments therefore means redesigning governance as fast feedback with clear guardrails. TOGAF includes a formal architecture compliance review process and recognizes architecture boards as executive-level bodies responsible for maintaining strategic architecture, which provides a governance structure that can be adapted to agile cadence (e.g., timeboxed reviews, risk-based exceptions).
Scaled agile guidance explicitly discusses agile architecture principles such as collaboration, design simplicity, and balancing intentional and emergent design—principles that align well with “govern by guardrails, review exceptions.”
A practical implementation uses ADRs to capture architectural decisions with context and consequences, and then ties those decisions to model repositories (e.g., Sparx EA) to ensure traceability, baselined approvals, and auditability as needed. Sparx EA performance optimization
- Designing “thin” TOGAF governance (guardrails + exceptions)
- Cadence alignment: PI planning, iteration reviews, release gates
- Decision capture: ADR integrated with reviews
- Tooling: EA baselines/audits/model reviews as evidence
- TOGAF compliance review process.
- Architecture Board definition.
- Agile architecture guidance (SAFe).
- ADR practice.
- Baselines definition.
- Auditing (accountability).
- Model reviews (formal assessment).
The governance cadence: aligning TOGAF with agile rhythms
The fundamental tension between TOGAF and agile is cadence. TOGAF's ADM assumes architecture is developed in phases over weeks or months. Agile delivers in two-week sprints. The solution is not to choose one — it is to align architecture activities to agile ceremonies at multiple time horizons. TOGAF certified training
Sprint level (every 2 weeks): Architecture runway review. The embedded architect ensures upcoming sprint work aligns with the architecture runway — the set of enablers that must be in place for feature delivery.
PI level (every 10 weeks): Architecture vision alignment. At PI Planning, the architect presents the architecture vision for the next PI. This is TOGAF Phase A in miniature — a lightweight vision that guides the PI's technical direction. New enabler epics are identified alongside business features.
Weekly: Architecture sync — a 30-minute standup where architects from different teams identify cross-team dependencies. Replaces heavy cross-domain reviews with lightweight coordination.
Monthly: Governance review. The review board meets for significant changes (new technology adoption, API contract changes, security updates). Uses model-based impact analysis from Sparx EA. Target: complete 80% of reviews in a single session.
Quarterly: ADM iteration. A compressed TOGAF cycle (1–2 weeks) refreshes the target architecture, updates the capability roadmap, and recalibrates standards.
Architecture runway: the bridge between TOGAF and delivery
The architecture runway is the set of existing infrastructure, components, and enablers that allow features to be delivered without blocking architectural work. In TOGAF terms, the runway is the realized portion of the target architecture. In agile terms, it is the technical foundation that keeps teams productive. ArchiMate in TOGAF ADM
Model the runway in ArchiMate: each element is an Application Component or Technology Service tagged with Runway_Status (Ready / In Progress / Planned) and Consuming_Teams. When upcoming features require a runway element not yet ready, an enabler epic is created — architecture work becomes visible and prioritizable alongside business features.
Tailoring TOGAF for practical results
TOGAF's strength is its comprehensiveness. Its weakness is also its comprehensiveness — organizations that try to implement every phase, every deliverable, and every governance mechanism simultaneously create a process that is too heavy to sustain. The most successful TOGAF implementations start small and expand based on demonstrated value.
Begin with Phase A (Architecture Vision) and Phase G (Architecture Governance). Vision ensures that architecture work is aligned with business strategy. Governance ensures that architecture decisions are reviewed, recorded, and enforced. These two phases provide immediate value: stakeholders see architecture alignment with their goals, and delivery teams see clear standards to follow.
Add Phases B through D incrementally as the architecture practice matures. Phase B (Business Architecture) adds capability maps and value stream models. Phase C (Information Systems Architecture) adds application portfolio views and data architecture. Phase D (Technology Architecture) adds infrastructure topology and platform design. Each phase produces ArchiMate views in the repository — not documents in a folder. ArchiMate relationship types
Skip Phases E and F (Opportunities and Migration Planning) initially. Replace them with ArchiMate Migration views that show plateaus (stable architecture states) and work packages (projects that move from one plateau to the next). This achieves the same outcome with less process overhead. ArchiMate best practices
If you'd like hands-on training tailored to your team (Sparx Enterprise Architect, ArchiMate, TOGAF, BPMN, SysML, Apache Kafka, or the Archi tool), you can reach us via our contact page.
Frequently Asked Questions
What is TOGAF used for?
TOGAF (The Open Group Architecture Framework) is used to structure and manage enterprise architecture programmes. It provides the Architecture Development Method (ADM) for creating architecture, a content framework for deliverables, and an enterprise continuum for reuse.
How does ArchiMate relate to TOGAF?
ArchiMate and TOGAF are complementary. TOGAF provides the process framework (ADM phases, governance, deliverables) while ArchiMate provides the notation for creating the architecture content. Many organisations use TOGAF as their EA method and ArchiMate as the modeling language within each ADM phase.
What is the TOGAF Architecture Development Method (ADM)?
The ADM is a step-by-step process for developing enterprise architecture. It consists of a Preliminary phase and phases A through H: Architecture Vision, Business Architecture, Information Systems Architecture, Technology Architecture, Opportunities and Solutions, Migration Planning, Implementation Governance, and Architecture Change Management.