The Agile Architect: TOGAF Meets High-Velocity Delivery

Moving from "Ivory Tower" Governance to "Just-in-Time" Strategic Alignment

Quick Summary

Speed is critical in today’s race for digital transformation. But speed without direction is dangerous. Many organizations rush to deliver, only to find themselves tangled in technical debt, fragmented systems, and missed opportunities.

The problem isn’t ambition; it’s alignment. Leadership often sees Enterprise Architecture (EA) as a “braking system” that slows down Agile teams, while Agile is viewed as the “accelerator” that drives delivery. This false dichotomy creates friction, with architects seen as gatekeepers and Agile teams as rule-breakers.

But EA isn’t a brake, and Agile isn’t a free-for-all. EA is the GPS; it ensures the car is driving toward the right destination at high speed without hitting a dead end. Agile is the engine that powers the journey.

When TOGAF’s structure is harmonized with Agile’s velocity, organizations can deliver value faster while avoiding the chaos of uncoordinated execution.

The False Dichotomy: Why Speed Alone Isn’t Enough

Digital transformation demands speed, but unguided speed leads to what I call “Technical Debt Bankruptcy.” This happens when teams prioritize short-term wins over long-term sustainability, creating a patchwork of systems that are expensive to maintain and difficult to scale.

Traditional approaches like “Big Up-Front Design” (BUFD) make this worse. Spending months designing a perfect architecture before taking any action is no longer viable in today’s fast-paced markets.

But swinging too far in the other direction (e.g., embracing Agile without guardrails) creates its own problems. Teams move quickly but in different directions, building disconnected features, duplicating efforts, and creating integration nightmares.

The solution isn’t to choose between TOGAF and Agile. It’s to combine them. TOGAF provides the guardrails (the what and why), while Agile provides the engine (the how). Together, they create a system that balances speed with strategic alignment.

Shifting the Architecture Mindset: From “Police” to “Platform”

Rethinking the role of Enterprise Architecture is necessary for this to work. Instead of acting as a gatekeeper, EA should function as a platform that enables teams to move quickly and safely.

Minimum Viable Architecture (MVA)

Borrowing from the Minimum Viable Product (MVP) concept, MVA focuses on defining the minimum architecture required to begin working safely. This means identifying the non-negotiables (like security standards, data models, and integration points) while leaving room for teams to innovate within those boundaries.

Decentralizing Decisions

Instead of relying on monthly Architecture Review Boards (ARBs), embed architects directly into Agile teams. This enables real-time decision-making, reducing bottlenecks and ensuring alignment without slowing delivery.

The 80/20 Rule

Eighty percent of architectural decisions should occur within the Scrum team, while twenty percent (cross-cutting concerns such as security, data standards, and integration) remain with the Enterprise Architect. This balance ensures teams have the autonomy to move quickly, while maintaining enterprise-wide consistency.

Adapting the TOGAF ADM for Sprints

The TOGAF Architecture Development Method (ADM) is often perceived as a linear, waterfall process. However, in an Agile environment, the ADM can be compressed and run in parallel with delivery, ensuring that architecture evolves alongside development rather than being locked in upfront.

This adaptation bridges the gap between strategy and execution, enabling organizations to deliver value faster while maintaining alignment with enterprise goals. Here’s how the ADM lifecycle adapts to Agile sprints:

Preliminary Phase: Establishing the Agile Foundation

The Preliminary Phase in Agile focuses on setting up foundational elements for iterative delivery. Key activities include:

• Defining Architectural Principles: Establishing core principles to guide all architectural decisions (e.g., “APIs must be RESTful,” “Data must be encrypted at rest and in transit”).

• Building the Architecture Capability: Ensuring the organization has the tools, processes, and skills to support Agile architecture.

• Creating a Governance Framework: Designing lightweight governance processes that integrate seamlessly with Agile workflows, such as peer reviews and automated compliance checks.

Measuring Success: Use metrics like time-to-decision, compliance rates, and the percentage of automated governance checks to evaluate the effectiveness of this phase.

This phase ensures the organization is ready to execute architecture in an Agile way, with clear guardrails and capabilities in place.

Phase A (Vision): The North Star

The Vision phase aligns with Strategic Planning or Program Increment (PI) Planning. The process avoids lengthy Vision Documents. The final output is a concise “Fixed vs. Flexible” Manifesto. It defines:

• Non-Negotiables: Core principles and constraints that cannot be compromised (e.g., security, compliance, scalability).

• Flexible Areas: Aspects where teams have the freedom to innovate and adapt based on evolving needs.

Example: A retail organization might define “real-time inventory visibility” as a non-negotiable, while allowing teams to choose the specific tools and methods to achieve it.

This phase provides a clear North Star for all teams, ensuring alignment with enterprise goals while allowing for agility in execution.

Phases B, C, D (Business, Information, Technology): Just-in-Time Design

Teams do not design the entire system upfront. These phases occur one to two sprints ahead of delivery teams. This approach is Architectural Runway Management. It ensures architecture evolves incrementally. The design remains relevant to immediate delivery needs.

• Business Architecture (Phase B):

  • Define the user journey and capability map for the upcoming Agile epic.

  • Ensure business goals are clearly translated into technical requirements.

• Information Systems Architecture (Phase C):

  • Focus on contract-first APIs, data entities, and data flows needed for the next set of features.

  • Ensure data is consistent, accessible, and secure across the enterprise.

• Technology Architecture (Phase D):

  • Select and validate the technology stack for upcoming features.

  • Ensure technology choices made by one team don’t create integration challenges for others.

Example: A financial services company might prioritize designing APIs for customer account data in Phase C, ensuring seamless integration with mobile apps in Phase D.

This iterative approach prevents overdesign while ensuring that architecture supports both immediate and long-term needs.

Phase E (Opportunities and Solutions): Prioritizing Architectural Enablers

Phase E focuses on architectural enablers. These enablers support both business goals and technical delivery. The Product Backlog includes these enablers. They remain alongside customer-facing features.

• Architectural Epics: Large-scale initiatives, such as implementing a new microservices framework or upgrading a legacy system, are broken down into smaller, actionable stories.

• Cost-Benefit Analysis: Evaluate trade-offs between short-term delivery speed and long-term architectural integrity.

Example: A logistics company might prioritize an architectural epic to standardize data formats across systems, enabling faster onboarding of new partners.

This phase ensures that architecture is not treated as a separate initiative but is fully integrated into the Agile delivery process.

Phase F (Migration Planning): Sequencing the Roadmap

Agile Migration Planning is an ongoing activity. It is not a one-time event. This process involves a rolling-wave roadmap. The roadmap evolves with each sprint or Program Increment. Key activities include:

• Dependency Mapping: Identifying dependencies between teams, systems, and features to avoid bottlenecks.

• Incremental Delivery: Breaking down large-scale migrations into smaller, manageable phases that deliver value incrementally.

• Risk Mitigation: Proactively addressing risks associated with system migrations, such as downtime or data loss.

Example: A healthcare provider migrating to a new patient management system might prioritize migrating high-traffic clinics first, using lessons learned to refine the process for smaller locations.

This phase ensures that migration efforts are aligned with delivery priorities and minimize disruption to the business.

Phase G (Implementation Governance): Automated Compliance

Traditional TOGAF governance is a manual process. This process often slows down delivery. Agile governance resides within the CI/CD pipeline. This integration increases speed and effectiveness.

• Policy as Code: Use automated tools to enforce architectural standards, such as linting, security scans, and performance tests.

• Definition of Done (DoD): Architectural compliance is baked into the Scrum team’s DoD. If a feature doesn’t meet the defined standards, it’s not considered complete.

Example: A retail company might use automated tools to ensure all APIs meet security standards before deployment.

This approach ensures that governance is proactive and continuous, preventing issues before they arise.

Phase H (Architecture Change Management): Continuous Evolution

Agile teams learn by doing, and Phase H ensures that these learnings are incorporated into the enterprise architecture. This phase creates a feedback loop that keeps the architecture relevant and up to date.

• Retrospectives: Use sprint retrospectives to identify architectural improvements and update standards accordingly.

• Continuous Improvement: Treat the architecture as a living document that evolves with the organization’s needs.

• Innovation Integration: Ensure that innovations discovered at the team level are shared and adopted across the enterprise.

Example: A software company might adopt a new data caching strategy discovered by one team and scale it across all teams.

This phase ensures that the architecture remains dynamic and responsive to change, rather than becoming a static artifact.

Practical Strategies for the Agile-TOGAF Hybrid

Traditional TOGAF

• Rigid 12-month Roadmaps

• Architecture Review Boards

• Comprehensive Documentation

• Governance Gates

Agile-Integrated TOGAF

• Rolling-wave Roadmaps (updated every Program Increment)

• Peer-based Architecture Guilds

• Architecture Decision Records (ADRs)

• Automated Guardrails & Compliance-as-Code

Why This Matters

Agile environments require an adapted TOGAF ADM. Architecture ceases to be a bottleneck. It transforms into a strategic enabler. Organizations embed architecture into the Agile delivery process. This integration achieves several key outcomes:

• Faster Delivery: Architecture evolves alongside development, eliminating delays caused by upfront design.

• Reduced Risk: Automated compliance and just-in-time design prevent costly rework and technical debt.

• Enterprise Alignment: Every sprint contributes to enterprise-level outcomes, not just isolated team goals.

Rethinking the ADM lifecycle is a critical step. It aligns TOGAF’s structure with Agile’s velocity. This alignment speeds up value delivery. Organizations achieve higher effectiveness.

Managing the Architectural Runway

The Architectural Runway is the foundation that allows Agile teams to deliver features quickly without creating technical debt.

Enabler Stories

Architectural work is prioritized in the Product Backlog alongside customer features. For example, if a new microservices framework is needed, it’s written as an Enabler Story and prioritized by the Product Owner.

Avoiding Agile Spaghetti

Without EA, Agile teams can create fragmented data silos and disconnected systems. The Architectural Runway ensures that all teams are building toward a cohesive enterprise vision.

The Bottom Line

Harmonizing TOGAF with Agile delivery isn’t just about process; it’s about results. Here’s what leadership can expect:

• Reduced Rework: Catching misalignments early saves 10x in downstream costs.

• Interoperability: Ensuring that new digital products integrate seamlessly with legacy systems.

• Talent Retention: High-performing developers thrive when they have clear boundaries and don’t have to navigate vague infrastructure.

The Architecture of Flow

Digital transformation is a marathon run at a sprinter’s pace. To succeed, organizations need both speed and direction.

Enterprise Architecture, when integrated with Agile delivery, provides the map that ensures teams are driving toward the right destination at high speed without hitting a dead end.

The role of leadership is to empower architects to be servant leaders, guiding teams with just-in-time alignment, while removing obstacles to delivery.

By harmonizing TOGAF with Agile, organizations can achieve the holy grail of digital transformation: speed, alignment, and sustainable value.

Are you ready to make the shift?​​