I normally don’t post much from an AI if I can help it, but this was a special case… on a whim, I prompted chatGPT with “I’m curious about how you would compare TOGAF and BTABoK concepts in places where they overlap, like Roadmaps. And if possible, show how they are different.” To be honest, I have made my own comparison of some of these and have had many of the same reactions and statements made. We get asked by
organizations ALL the time to come help them fix their Architecture Practice and it often involves conversations about things not working from TOGAF.
I was extremely pleased when OpenAI came back with the following. I did add one extra prompt, which was, “Interesting comparison, but how does that apply to different types of architects where the BTABoK focuses?” and I got the below… I’m very proud that the BTABoK is interpreted this way by an AI, since most of this was intentional!
When creating or teaching architectural roadmaps, it’s common to reference TOGAF’s framework — but increasingly, architects are turning to the BTABoK (Business Technology Architecture Body of Knowledge) for a more value-based, scope-aware, and people-centric model.
Both frameworks define and use roadmaps, but in notably different ways.
This article compares how TOGAF and the BTABoK define roadmaps — especially in terms of transitions, value, and strategic alignment — and explains why the BTABoK is gaining adoption across a wider range of architectural roles.
TOGAF: Transition-Focused Architecture Roadmaps
TOGAF (The Open Group Architecture Framework) treats a roadmap as a time-based implementation plan, produced as part of the ADM (Architecture Development Method).
TOGAF Roadmap Summary:
- Purpose: Communicate how to move from baseline to target architecture.
- Scope: Technical capabilities, systems, business functions.
- Driven by: Gap analysis and capability assessments.
- Primary Role: Bridge between architecture vision and solution implementation.
- Audience: Program managers, IT project leaders.
Common Output:
- Work packages with sequencing
- Technical transitions and dependencies
- Gantt-style views
In TOGAF, the roadmap is a delivery-focused artifact, grounded in system-level transitions and aligned to phases E and F of the ADM.
BTABoK: Strategic and Capability-Based Roadmaps
BTABoK also defines roadmaps — but with a broader scope. In the BTABoK, a roadmap is a decision-making and communication tool used to align architecture with stakeholder intent, capability evolution, and value delivery.
BTABoK Roadmap Summary:
- Purpose: Align decisions, stakeholders, and capabilities over time.
- Scope: People, decisions, skills, systems, and business value.
- Driven by: Value streams, decision records, and stakeholder engagement.
- Primary Role: Strategic alignment, capability growth, and transparent decision communication.
- Audience: Architects, business leaders, capability owners, teams.
What’s Included:
- Transitions in capability maturity
- Decision points and architecture options
- Stakeholder and skill readiness
- Value realization milestones
- Communication and negotiation checkpoints
Do BTABoK Roadmaps Include Transitions?
Yes — but not in the limited TOGAF sense of technical or system transitions.
BTABoK includes transitions in a richer, more multi-dimensional way:
Type of Transition Included in BTABoK? Notes Systems/architecture migrations ✅ As a consequence of decisions Capability maturity evolution ✅ Central to BTABoK Decision progressions ✅ Decisions are tracked over time Stakeholder readiness ✅ Part of the engagement model Skills/team capability growth ✅ Often charted as part of roadmap milestones Value checkpoints ✅ Justify transitions with outcomes
So yes, BTABoK includes transitions — but as part of a living, strategic artifact rather than a static project plan.
BTABoK Serves Practicing Architects in Other Roles
One of the key differentiators of BTABoK is that it’s designed to support multiple architectural roles — not just enterprise architecture.
Who Uses BTABoK Roadmaps?
Role BTABoK Value Solution Architects Use roadmaps to align solution decisions with business goals and capability targets Business Architects Track the evolution of processes, capabilities, and stakeholder influence Software Architects Visualize architectural decision records and their effect over time to prioritize backlogs Infrastructure/Cloud Architects Map technical capability maturity and stakeholder engagement across technical transitions Enterprise Architects Use the roadmap as a strategic alignment and mentoring tool, not just a project tracker
BTABoK democratizes the roadmap. Rather than being a document created by enterprise architects for enterprise programs, it’s a shared, evolving artifact that all architects contribute to and use to align decisions with value.
TOGAF vs. BTABoK Roadmaps: Summary Table
Attribute TOGAF BTABoK Orientation Delivery/execution Strategic alignment and communication Focus Technical state transitions Value, decisions, people, capabilities Scope Systems, business functions Skills, decisions, stakeholders, systems Use of transitions Core focus Included, but broader and value-driven Update cycle Project-based, periodic Iterative, collaborative, living Visual format Gantt-style, project plans Capability + decision timelines, intent maps Audience EA and program teams All architects, plus stakeholders
Conclusion
TOGAF and BTABoK both value roadmaps — but for different reasons.
- Use TOGAF roadmaps to guide system and capability implementation over time.
- Use BTABoK roadmaps to connect people, decisions, capabilities, and value in an evolving narrative.
In practice? The best approach is often to blend both:
- Use BTABoK to shape strategic engagement and intent
- Use TOGAF to plan technical execution
BTABoK’s real strength lies in its flexibility and role-inclusiveness, making it well-suited for cross-functional architecture teams in complex enterprises.