TOGAF with BIZBOK

The Business Architecture Guild positions BIZBOK as a guide to the business architecture body of knowledge. That already tells you something important about scope. Its centre of gravity is business architecture: how an enterprise describes, structures, and analyses its business layer. TOGAF, by contrast, is a broader enterprise-architecture standard spanning business, data, application, technology, governance, capability, and change method.

That means the comparison is not between two identical kinds of thing. It is a comparison between a business-architecture body of knowledge and a fuller enterprise-architecture method and governance structure. Getting this framing wrong is the single most common source of confused comparison.

BIZBOK is maintained by the Business Architecture Guild, a member-based professional organisation. TOGAF is maintained by The Open Group, a global technology standards consortium. Both are serious bodies of knowledge with real practitioner communities. The question is not which is better but what each is designed to do.

Why the scope difference matters

If you assume both are full enterprise-architecture methods, you will compare them on axes where one of them was never trying to compete. BIZBOK does not claim to provide an end-to-end architecture development method, governance model, migration planning logic, or repository stewardship framework. It claims to provide depth, vocabulary, and analytical rigour for the business layer specifically.

TOGAF does claim to provide all of those things, but its business-architecture treatment in Phase B and the supporting Series Guides (G211 on capabilities, G178 on value streams) is necessarily less specialised than a body of knowledge that puts business architecture at the centre of everything it does.

Honest comparison requires choosing the right axes. A comparison that tests both standards against enterprise-wide governance is unfair to BIZBOK. A comparison that tests both against business-architecture analytical depth is unfair to TOGAF. The fairest approach is to identify what each one optimises and then ask where overlap, complementarity, and genuine gaps exist.

Centre of gravity

BIZBOK is business-architecture first. Everything it teaches, from capability mapping through value-stream analysis, information mapping, stakeholder alignment, and business model design, treats the business layer as the primary frame of reference. TOGAF is enterprise-architecture wide, with business architecture as one major domain rather than the whole frame.

Depth versus breadth

BIZBOK is most useful where the enterprise needs sharper business-architecture practice: better capability definitions, cleaner value-stream models, stronger alignment between business strategy and architecture decisions. TOGAF is most useful where business, information, applications, technology, governance, and transition planning all have to be held together in a single coherent method.

Method and governance reach

TOGAF gives a more explicit end-to-end architecture method, governance model, and migration logic. It defines how architecture work is scoped, how Architecture Boards operate, how exceptions are handled, how compliance reviews work, and how the architecture repository is maintained. BIZBOK is not trying to be a full ADM equivalent. It contributes analytical depth to the business layer, not a process backbone for the whole enterprise.

Expected outputs

BIZBOK-style work often sharpens business concepts and analysis: capability maps with well-defined levels, value-stream stages with measurable outcomes, business models that connect strategy to operational structure. TOGAF work must also carry those outputs into cross-domain architecture, roadmap sequencing, and governance decisions. The outputs serve different purposes because the methods serve different scopes.

Practitioner community

BIZBOK practitioners tend to identify as business architects. TOGAF practitioners tend to identify as enterprise architects. This is not a trivial distinction. It shapes how they see their role, what they consider in scope, and where they expect their work to land. A business architect cares deeply about the quality of the capability map. An enterprise architect cares about whether that capability map connects to information architecture, technology decisions, and governed delivery.

The strongest argument for BIZBOK-style depth is that it prevents the rest of the architecture from being built on fuzzy business assumptions. If the business layer is thin, everything built on top of it inherits that weakness.

Capability mapping with real precision

BIZBOK gives detailed guidance on building capability maps that go beyond vague labels. It distinguishes between capability levels, defines how capabilities relate to value streams, and provides patterns for assessing capability maturity. TOGAF's G211 guide covers capability planning, but a business-architecture-first body of knowledge naturally goes deeper into the analytical techniques for getting the business layer right.

Value-stream analysis

BIZBOK treats value streams as a primary organising concept. It provides techniques for identifying value-stream stages, mapping enabling capabilities to each stage, and measuring where value is created or lost. TOGAF's G178 guide covers value streams, but BIZBOK-style practice gives the concept more analytical weight because business architecture is the central lens rather than one phase in a broader cycle.

Business vocabulary and alignment

When an enterprise needs stronger business vocabulary, clearer alignment between strategy and operational structure, and more deliberate treatment of how business concepts connect to one another, BIZBOK-style depth helps. It forces practitioners to define what they mean by each business concept rather than leaving terms vague.

When the business layer is the weakest link

• When capability maps have vague labels that nobody can walk through concretely.
• When value streams exist on paper but nobody can explain where value is actually created or where it breaks down.
• When business models do not connect to delivery choices, and technology decisions are made without clear business rationale.
• When the organisation needs to strengthen the quality of its business architecture before it expands into broader cross-domain governance.

Even in an enterprise that has invested heavily in BIZBOK-style business architecture, TOGAF contributes capabilities that a business-architecture body of knowledge is not designed to provide.

End-to-end architecture method

The ADM provides a structured method for moving from preliminary framing through business, information systems, technology, opportunities and solutions, migration planning, implementation governance, and change management. BIZBOK does not attempt to provide this kind of end-to-end process backbone. It assumes either that the enterprise already has one or that business architecture can be practised without one.

Cross-domain integration

TOGAF explicitly connects business architecture to information systems architecture,technology architecture, and transition planning. It defines how business decisions flow into data architecture, application architecture, and technology selection. That cross-domain integration is what turns business-layer thinking into enterprise-wide architecture rather than a specialist island.

Governance and decision rights

TOGAF provides explicit guidance on governance structures: how Architecture Boards operate, how architecture contracts bind delivery to architecture decisions, how compliance reviews work, and how exceptions are handled. These governance mechanisms are what keep architecture connected to real enterprise decisions rather than existing as advisory documents that delivery teams can ignore.

Migration and transition logic

Phase E and Phase F provide explicit guidance on identifying work packages, sequencing transition states, and building an architecture roadmap that connects to delivery planning. BIZBOK does not provide this kind of migration discipline because its scope is the business layer, not the full delivery lifecycle.

Repository stewardship

TOGAF provides guidance on how the architecture repository should be structured, maintained, and governed. This includes the Enterprise Continuum classification, reference architectures, and the relationship between Architecture Building Blocks andSolution Building Blocks. Business-architecture artefacts need to live somewhere that connects them to the wider enterprise. TOGAF provides that structure.

Several core concepts appear in both BIZBOK and TOGAF. Understanding how they overlap and where they diverge is essential for any organisation that uses both.

Capabilities

Both BIZBOK and TOGAF treat capabilities as a fundamental concept. TOGAF defines capabilities in the content metamodel and provides the G211 Series Guide on business capabilities. BIZBOK places capabilities at the centre of its analytical framework and provides more detailed guidance on capability decomposition, levelling, and maturity assessment. The concepts are compatible but the depth of treatment differs.

Value streams

Both standards recognise value streams. TOGAF provides the G178 Series Guide specifically on value streams. BIZBOK treats value streams as a primary organising concept and provides more extensive analytical techniques for value-stream mapping, stage identification, and capability-to-value-stream alignment. Again, compatible but different in emphasis.

Information mapping

BIZBOK includes information mapping as part of its business-architecture toolkit. TOGAF addresses information architecture through Phase C and the data architecture content. The difference is that BIZBOK's information mapping stays at the business level (what information does the business need and where does it flow?), while TOGAF's Phase C extends into data domains, metadata, application architecture, and the technical infrastructure that supports data management.

Organisation mapping

BIZBOK includes organisation mapping as part of understanding how business capabilities are distributed across organisational units. TOGAF addresses organisation through stakeholder analysis, the content metamodel's Organisation Unit entity, and Phase B business architecture. The overlap is real but BIZBOK gives the organisation-to-capability relationship more analytical weight.

Where BIZBOK goes further

• Business model decomposition and alignment to strategy.
• Detailed capability maturity assessment techniques.
• Cross-mapping between capabilities, value streams, information, and organisation as an integrated analytical framework.
• Business-architecture-specific communication and stakeholder engagement patterns.

Where TOGAF goes further

• Cross-domain architecture development from business through technology.
• Explicit governance, compliance, and exception handling.
• Migration planning, transition states, and work-package sequencing.
• Repository stewardship and the Enterprise Continuum classification.
• Architecture principles that constrain decisions across all domains.

The clean combination is to let deeper business-architecture practice strengthen the business layer while TOGAF carries the wider enterprise method. That means capability and value-stream work remain business-led, but they still flow into information architecture, technology choices, work packages, and governance.

The integration design pattern

1. Single vocabulary for shared concepts. Where both standards use the same concept (capability, value stream, organisation), agree on one definition and one naming convention. Do not maintain parallel glossaries.
2. Business-architecture depth feeds Phase B. Use BIZBOK-style analytical techniques to produce richer business-architecture artefacts. Those artefacts become the inputs to Phase B and flow through the rest of the ADM.
3. TOGAF carries the cross-domain method. The ADM provides the process for connecting business architecture to information systems architecture, technology architecture, migration planning, and governance. Business-architecture artefacts are not endpoints; they are inputs to a wider enterprise method.
4. One repository, not two. Business-architecture artefacts should live in the same architecture repository as the rest of the enterprise architecture. A separate business-architecture repository creates traceability gaps.
5. Governance covers the boundary. The Architecture Board or equivalent governance body should review how business-architecture decisions flow into cross-domain architecture decisions. This prevents the business layer from becoming a specialist island.

The poor combination

The poor combination is to run business architecture in one language, run enterprise architecture in another, and never reconcile the artefacts. That creates duplication and weak traceability rather than complementary practice. Specific failure patterns include:

• Parallel capability maps with different decomposition levels and no reconciliation.
• Business-architecture deliverables that sit in a separate repository and are never referenced during Phase C, Phase D, or migration planning.
• Two governance bodies reviewing business architecture separately from enterprise architecture with no handoff protocol.
• Business architects and enterprise architects disagreeing about definitions because nobody designed the integration boundary.

A business leader looking at this comparison does not care about framework taxonomy. They care about whether the architecture practice delivers clear business outcomes. The honest answer from this comparison is that both bodies of knowledge serve different needs, and the business leader should expect the architecture team to explain the boundary.

If the business leader asks "why are we doing business architecture?" the answer should come from BIZBOK-style thinking: to build better capability maps, clearer value streams, and stronger alignment between strategy and operational structure.

If the business leader asks "how does business architecture connect to our technology decisions, roadmap, and governance?" the answer should come from TOGAF-style thinking: through a structured method that carries business-layer decisions into cross-domain architecture, transition planning, and governed delivery.

A business leader who hears both answers and sees a connected practice is looking at a mature architecture function. A business leader who hears neither answer, or who hears both but sees two disconnected streams of work, is looking at a problem.

The London case makes the complementarity easy to see. Stage 3 already showed why capability, organisation, and value-stream work matter in a regulated distributor. A business-architecture-first guide could deepen that layer further: sharper capability decomposition, better-defined value-stream stages, clearer alignment between business capabilities and the operational structure of a distribution network operator.

But London also needs cross-domain method, transition logic, compliance, repository stewardship, and delivery governance. That is where TOGAF remains essential. It connects the business layer to the rest of the enterprise architecture instead of leaving it as a specialist island.

Where BIZBOK-style depth would add value in the London case

• Capability decomposition. London's capability map could benefit from more rigorous decomposition using BIZBOK-style levelling techniques, particularly for capabilities like network asset management and connections delivery.
• Value-stream analysis. The new-connections value stream could be analysed at greater depth, identifying exactly where value is created, where delays accumulate, and where capability gaps cause the most damage.
• Business model alignment. The relationship between London's regulatory obligations, stakeholder expectations, and operational capabilities could be made more explicit through BIZBOK-style business-model decomposition.

Where TOGAF remains essential in the London case

• Cross-domain architecture. Business-architecture decisions must flow into information authority design, application portfolio choices, technology selection, and OT/IT integration patterns.
• Transition planning. London's multi-year roadmap requires explicit transition states, gap analysis, and work-package sequencing that BIZBOK does not attempt to provide.
• Governance and compliance. Regulatory obligations, Ofgem reporting, NIS Regulations compliance, and Cyber Assessment Framework alignment all require governed architecture practice with explicit exception handling.
• Repository stewardship. All London artefacts, including business-architecture artefacts, need to live in one traceable repository structure.

For London, BIZBOK-style depth would enrich business architecture. TOGAF still holds the whole enterprise change system together. The honest comparison is depth in one domain versus breadth across the enterprise. Both are needed.