# Business Capability Map: [Organisation or business unit]

> Business capability map and heatmap for one organisation or business
> unit: modelling principles, an L1 to L3 capability hierarchy, a
> definitions catalogue with stable IDs, maturity and strategic importance
> scoring, a heatmap, mappings to value streams and applications, and the
> investment recommendations that follow. The structure is aligned with the
> concepts of the TOGAF Series Guide: Business Capabilities, Version 2
> (G211, April 2022), part of the TOGAF Standard, 10th Edition. Replace
> every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Work in this order: 2 (agree the modelling rules) -> 3 (draft the L1
  and L2 levels with business leaders) -> 4 (define every capability) ->
  5 and 6 (score and heatmap) -> 7 and 8 (map value streams and
  applications) -> 9 (recommend investments) -> 10 (agree how the map is
  kept current).
- A capability describes WHAT the business does, never HOW, WHO or WITH
  WHICH SYSTEM. If a box names a department, a product or an application,
  rename it.
- The worked examples describe a fictional mid-sized insurer. Delete them
  once your own rows exist.
-->

## Document control

<!-- Guidance: Identify the map itself and the planning cycle it supports. A capability map without an owner and a refresh date decays within a year. -->

| Field | Value |
|---|---|
| Document ID | [BCM-ORG-001] |
| Organisation or scope | [Organisation, business unit or domain] |
| Planning cycle supported | [FY YYYY strategy / portfolio review YYYY-QN] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@business-architect] |
| Business sponsor | [@executive-sponsor] |
| Approvers / reviewers | [@cio, @coo, @strategy-lead] |
| Last updated | YYYY-MM-DD |
| Next scheduled refresh | YYYY-MM-DD |
| Classification | [Internal / Confidential] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Business sponsor | [@name] | [Approved / Approved with comments / Rejected] | YYYY-MM-DD |
| Chief architect | [@name] | [Decision] | YYYY-MM-DD |
| Head of strategy or portfolio office | [@name] | [Decision] | YYYY-MM-DD |
| Capability owners (L1) | [@names] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record structural changes (capabilities added, split, merged or retired) separately from scoring changes, so that trend comparisons stay honest. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Initial L1 and L2 model from leadership workshops |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Added L3 for Claims Management; first maturity scoring |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Baseline approved for the FY portfolio review |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Introduction](#1-introduction)
2. [Capability modelling principles](#2-capability-modelling-principles)
3. [Capability hierarchy](#3-capability-hierarchy)
4. [Capability definitions catalogue](#4-capability-definitions-catalogue)
5. [Assessment method](#5-assessment-method)
6. [Capability heatmap](#6-capability-heatmap)
7. [Capability to value stream mapping](#7-capability-to-value-stream-mapping)
8. [Capability to application mapping](#8-capability-to-application-mapping)
9. [Investment recommendations](#9-investment-recommendations)
10. [Governance and refresh](#10-governance-and-refresh)
11. [Glossary and references](#11-glossary-and-references)

## 1. Introduction

<!-- Guidance: State the decisions this map will inform. A map built "for completeness" rarely gets used; a map built to steer next year's investment does. -->

### 1.1 Purpose

This capability map gives [Organisation] a single, stable description of
what the business must be able to do to deliver its strategy, independent
of the current organisation chart, processes and systems. It is used to
[prioritise the FY YYYY change portfolio, locate duplicated applications,
scope the target architecture, assign capability ownership].

### 1.2 Scope

- **In scope**: [all customer-facing and supporting capabilities of the
  retail insurance business unit].
- **Out of scope**: [group-level treasury, which has its own map].
- **Depth**: L1 and L2 for the whole scope; L3 only where an investment
  decision needs it (currently [Claims Management, Customer Management]).
- **Time frame**: current state as of YYYY-MM-DD, target maturity for
  YYYY-MM-DD.

### 1.3 Questions this map answers

1. Which capabilities differentiate us and which only need to be
   reliable at reasonable cost?
2. Where is the gap between current and target maturity largest for the
   capabilities that matter most?
3. Which capabilities are supported by several overlapping applications,
   and which by none?
4. Where should the next planning cycle invest, sustain or reduce spend?

### 1.4 Related documents

| ID | Document | Relationship |
|---|---|---|
| REF-01 | [Business strategy YYYY to YYYY] | Source of strategic importance ratings |
| REF-02 | Architecture Principles Catalogue (`architecture/architecture-principles`) | Constraints on target state |
| REF-03 | Application Portfolio Rationalization (`architecture/application-portfolio-rationalization`) | Uses the capability IDs in section 8 |
| REF-04 | OKRs (`business/okr`) | Key results that capability investments support |
| REF-05 | TOGAF Architecture Vision (`architecture/togaf-architecture-vision`) | Consumes the heatmap for scope and priorities |

## 2. Capability modelling principles

<!-- Guidance: Agree these rules before drawing a single box. Most capability maps fail because each workshop group used different rules, producing a mix of processes, departments and systems. -->

The following rules apply to every capability in this map. Reviewers
reject a capability that breaks a rule unless a recorded exception exists.

| ID | Principle | Test a reviewer applies |
|---|---|---|
| CMP-01 | **Outcome-named**: name capabilities as nouns describing an ability, for example "Claims Assessment", not "Assess claims in system X" | Does the name survive a reorganisation and a system replacement? |
| CMP-02 | **Stable**: a capability changes only when the business model changes, not when processes, teams or tools change | Would this capability have existed five years ago, and will it in five years? |
| CMP-03 | **Non-overlapping**: each capability has one parent and no two capabilities at the same level describe the same ability | Can any piece of work be placed in exactly one L2? |
| CMP-04 | **Complete at each level**: the children of a capability together cover all of the parent | Is anything the parent does missing from its children? |
| CMP-05 | **Organisation-neutral**: no department names, roles or locations in capability names | Could the same capability be performed by a partner? |
| CMP-06 | **Technology-neutral**: no application, vendor or channel names | Would the name still fit if the work were manual? |
| CMP-07 | **Business vocabulary**: use terms business leaders recognise; record synonyms in the catalogue | Did a business owner, not only an architect, approve the name? |
| CMP-08 | **Bounded depth**: three levels by default; a fourth only where a decision requires it | Is the extra level tied to a named decision? |

### 2.1 Capability categories

Group L1 capabilities into three bands so that leaders read the map at a
glance:

- **Strategic** (direction-setting): capabilities that set goals, govern
  and plan, such as Strategy Management and Risk Management.
- **Core** (customer-facing value delivery): capabilities that create and
  deliver the value customers pay for, such as Product Management, Policy
  Administration and Claims Management.
- **Supporting** (enabling): capabilities every organisation needs but
  which rarely differentiate, such as Finance, People and Facilities.

### 2.2 Capability versus process versus value stream

A capability is an ability; a process is the sequence of activities that
exercises it; a value stream is the end-to-end set of stages that deliver
a result to a stakeholder. One capability is used by many processes and
many value stream stages. Keep processes in the process catalogue and
value streams in section 7; link them to capabilities by ID instead of
copying them into the map.

## 3. Capability hierarchy

<!-- Guidance: Draw L1 and L2 for the full scope first and get it approved before adding L3. Aim for roughly 8 to 15 L1 capabilities and 3 to 10 children per parent; much more suggests processes have crept in. -->

### 3.1 L1 and L2 overview

The mindmap shows the three bands from section 2.1, the L1 capabilities and their L2 children. Regenerate it from the catalogue in section 4 whenever the structure changes.

```mermaid
mindmap
  root((Organisation))
    Strategic
      CAP-01 Strategy Management
        CAP-01.01 Strategic Planning
        CAP-01.02 Performance Management
      CAP-02 Risk and Compliance Management
        CAP-02.01 Enterprise Risk Management
        CAP-02.02 Regulatory Compliance
    Core
      CAP-03 Customer Management
        CAP-03.01 Customer Onboarding
        CAP-03.02 Customer Information Management
        CAP-03.03 Customer Service
      CAP-04 Product Management
        CAP-04.01 Product Design
        CAP-04.02 Pricing
      CAP-05 Policy Administration
        CAP-05.01 Underwriting
        CAP-05.02 Policy Servicing
      CAP-06 Claims Management
        CAP-06.01 Claims Intake
        CAP-06.02 Claims Assessment
        CAP-06.03 Claims Settlement
    Supporting
      CAP-07 Finance Management
      CAP-08 People Management
      CAP-09 Technology Management
```

### 3.2 L3 decomposition where required

L3 is maintained only for capabilities selected for investment analysis.
The table is the source of truth; the diagram above is a view of it.

| L1 | L2 | L3 ID | L3 capability |
|---|---|---|---|
| CAP-06 Claims Management | CAP-06.01 Claims Intake | CAP-06.01.01 *(Example)* | First Notice of Loss Capture |
| CAP-06 Claims Management | CAP-06.01 Claims Intake | CAP-06.01.02 *(Example)* | Claim Triage |
| CAP-06 Claims Management | CAP-06.02 Claims Assessment | CAP-06.02.01 *(Example)* | Coverage Verification |
| CAP-06 Claims Management | CAP-06.02 Claims Assessment | CAP-06.02.02 *(Example)* | Fraud Detection |
| CAP-06 Claims Management | CAP-06.02 Claims Assessment | CAP-06.02.03 *(Example)* | Loss Estimation |
| CAP-06 Claims Management | CAP-06.03 Claims Settlement | CAP-06.03.01 *(Example)* | Payment Authorisation |
| CAP-06 Claims Management | CAP-06.03 Claims Settlement | CAP-06.03.02 *(Example)* | Recovery and Subrogation |
| [CAP-nn] | [CAP-nn.nn] | [CAP-nn.nn.nn] | [L3 capability] |

### 3.3 ID convention

- L1: `CAP-NN`, L2: `CAP-NN.NN`, L3: `CAP-NN.NN.NN`.
- IDs are never reused. A retired capability keeps its ID with status
  "Retired" so that historical heatmaps still resolve.
- When a capability is split, the original ID is retired and the parts
  receive new IDs; record the lineage in the catalogue.

## 4. Capability definitions catalogue

<!-- Guidance: Every box on the map needs a one-sentence definition, an owner and boundaries. Without definitions, two teams will score the same box against different meanings. -->

Each definition states the ability, the business object it acts on and
the outcome it produces. Owners are accountable business leaders, not
system owners.

| ID | Capability | Definition | Key business objects | Owner | Boundary notes | Status |
|---|---|---|---|---|---|---|
| CAP-03.01 *(Example)* | Customer Onboarding | Ability to establish a verified new customer relationship ready for sale or service | Customer, identity evidence | [@head-of-distribution] | Excludes credit checks, which sit in CAP-05.01 | Active |
| CAP-04.02 *(Example)* | Pricing | Ability to set and adjust the price of products based on risk, cost and market | Rate table, price | [@chief-actuary] | Excludes discounts at point of sale (CAP-03.03) | Active |
| CAP-06.01 *(Example)* | Claims Intake | Ability to receive, register and route a claim from any channel | Claim, loss event | [@head-of-claims] | Ends when a claim is assigned for assessment | Active |
| CAP-06.02 *(Example)* | Claims Assessment | Ability to decide whether and how much a claim is payable | Claim, policy, evidence | [@head-of-claims] | Includes fraud detection at L3 | Active |
| CAP-06.03 *(Example)* | Claims Settlement | Ability to pay, close and recover claims accurately | Payment, recovery | [@head-of-claims] | Payment execution sits in CAP-07 | Active |
| [CAP-nn.nn] | [Name] | [Definition] | [Objects] | [@owner] | [What it excludes and where that lives] | [Active / Proposed / Retired] |

### 4.1 Synonyms and lineage

| ID | Synonyms used in the business | Previous IDs or names | Reason for change |
|---|---|---|---|
| CAP-06.01 *(Example)* | First notice of loss, claim lodgement | CAP-06.04 "Claims Registration" (retired) | Merged into intake to remove overlap |
| [CAP-nn.nn] | [Synonyms] | [Lineage] | [Reason] |

## 5. Assessment method

<!-- Guidance: Define the scales before anyone scores. Calibrate by scoring two capabilities together as a group first. Common pitfall: scoring maturity of the supporting application instead of the business capability. -->

### 5.1 Maturity scale

Maturity describes how well the organisation performs the capability
today, across people, process, information and resources (tools and
assets). Score the weakest of the four dimensions, not the average, when
they differ by two or more levels.

| Level | Label | Description |
|---|---|---|
| 1 | Initial | Performed ad hoc, depends on individuals, outcomes unpredictable |
| 2 | Repeatable | Performed consistently in some areas, little measurement |
| 3 | Defined | Documented and consistent across the organisation, basic measures |
| 4 | Managed | Measured against targets, variations understood and controlled |
| 5 | Optimised | Continuously improved, benchmarked, adapts quickly to change |

### 5.2 Strategic importance scale

Strategic importance describes how much the capability contributes to
the strategy in REF-01. Derive it from the strategy, not from current
spend.

| Score | Label | Meaning |
|---|---|---|
| 3 | Differentiating | Source of competitive advantage named in the strategy |
| 2 | Core | Must be performed well for the business model to work, but not a differentiator |
| 1 | Commodity | Needed at acceptable cost and risk; standard market solutions fit |

### 5.3 Additional assessment dimensions

| Dimension | Scale | Source of evidence |
|---|---|---|
| Target maturity | 1 to 5, set by the capability owner for the target date | Strategy, regulatory demands |
| Maturity gap | Target minus current | Derived |
| Business risk | Low / Medium / High | Risk register, audit findings |
| Technology support | Adequate / Partial / Poor / None | Section 8 and application health scores |
| Annual run cost | Currency amount | Finance cost allocation |

### 5.4 Priority rule

Investment priority is the strategic importance multiplied by the
maturity gap. With importance 1 to 3 and a gap of 0 to 4, the result
ranges from 0 to 12. Treat 6 and above as "Invest", 3 to 5 as "Improve
selectively", and below 3 as "Sustain or reduce". Adjust these bands only
by a recorded decision of the governance forum in section 10.

### 5.5 Assessment evidence

Record for every score who scored it, when, and on what evidence
(metrics, audit reports, interviews). A score without evidence is marked
"Provisional" and is not used for funding decisions.

## 6. Capability heatmap

<!-- Guidance: The heatmap is the page executives will look at. Keep it to L2, use a legend, and show the reasons behind red cells in the notes column. -->

### 6.1 Heatmap table

Legend for the "Heat" column: **Red** priority 6 or more, **Amber** 3 to
5, **Green** below 3. Add a cross mark in the "Risk" column for any
capability rated High business risk regardless of colour.

| ID | Capability | Importance | Current | Target | Gap | Priority | Heat | Risk | Notes |
|---|---|---|---|---|---|---|---|---|---|
| CAP-03.01 *(Example)* | Customer Onboarding | 3 | 2 | 4 | 2 | 6 | Red | | Manual identity checks, high drop-off in digital channel |
| CAP-03.02 *(Example)* | Customer Information Management | 2 | 2 | 4 | 2 | 4 | Amber | X | Four customer masters, data quality issues in audit |
| CAP-04.02 *(Example)* | Pricing | 3 | 3 | 5 | 2 | 6 | Red | | Rate changes take eight weeks; strategy needs weekly |
| CAP-05.01 *(Example)* | Underwriting | 2 | 3 | 3 | 0 | 0 | Green | | Meets current needs |
| CAP-06.01 *(Example)* | Claims Intake | 3 | 2 | 4 | 2 | 6 | Red | | Phone-only intake out of hours |
| CAP-06.02 *(Example)* | Claims Assessment | 3 | 3 | 4 | 1 | 3 | Amber | X | Fraud detection relies on manual rules |
| CAP-06.03 *(Example)* | Claims Settlement | 2 | 3 | 3 | 0 | 0 | Green | | Stable |
| CAP-07 *(Example)* | Finance Management | 1 | 3 | 3 | 0 | 0 | Green | | Candidate for cost reduction |
| [CAP-nn.nn] | [Name] | [1 to 3] | [1 to 5] | [1 to 5] | [Gap] | [Importance x Gap] | [Red / Amber / Green] | [X or blank] | [Evidence summary] |

### 6.2 Heatmap view

The diagram colours each L2 capability by its heat value from table 6.1; keep the two consistent by updating the table first.

```mermaid
flowchart TB
  classDef red fill:#f8d7da,stroke:#b02a37,color:#000
  classDef amber fill:#fff3cd,stroke:#997404,color:#000
  classDef green fill:#d1e7dd,stroke:#146c43,color:#000
  subgraph core [Core capabilities]
    c31[CAP-03.01 Customer Onboarding]:::red
    c32[CAP-03.02 Customer Information]:::amber
    c42[CAP-04.02 Pricing]:::red
    c51[CAP-05.01 Underwriting]:::green
    c61[CAP-06.01 Claims Intake]:::red
    c62[CAP-06.02 Claims Assessment]:::amber
    c63[CAP-06.03 Claims Settlement]:::green
  end
  subgraph support [Supporting capabilities]
    c7[CAP-07 Finance Management]:::green
  end
```

### 6.3 Reading the heatmap

- Red differentiating capabilities are the first candidates for change
  investment.
- Green commodity capabilities with high run cost are candidates for
  standardisation, outsourcing or cost reduction.
- Amber capabilities marked with a risk cross need a risk owner decision
  even if they are not funded for improvement.

## 7. Capability to value stream mapping

<!-- Guidance: Show which capabilities enable each value stream stage. This explains to executives why a capability matters, in terms of the customer outcome it supports. -->

### 7.1 Value streams in scope

| ID | Value stream | Triggering stakeholder | Value delivered |
|---|---|---|---|
| VS-01 *(Example)* | Acquire Insurance Coverage | Prospective customer | Customer is insured |
| VS-02 *(Example)* | Resolve Claim | Policyholder | Claim is settled fairly and quickly |
| [VS-nn] | [Value stream] | [Stakeholder] | [Value] |

### 7.2 Stage to capability cross-map

| Value stream stage | Enabling capabilities | Weakest capability (heat) |
|---|---|---|
| VS-02.1 Report Loss *(Example)* | CAP-06.01, CAP-03.03 | CAP-06.01 (Red) |
| VS-02.2 Assess Claim *(Example)* | CAP-06.02, CAP-05.02 | CAP-06.02 (Amber) |
| VS-02.3 Settle Claim *(Example)* | CAP-06.03, CAP-07 | None red |
| VS-01.1 Get Quote *(Example)* | CAP-04.02, CAP-03.01 | CAP-04.02 (Red) |
| [VS-nn.n Stage] | [CAP IDs] | [CAP ID (heat)] |

A value stream stage is only as strong as its weakest enabling
capability. Use the third column to explain customer-visible problems in
capability terms.

## 8. Capability to application mapping

<!-- Guidance: Map applications to L2 or L3 capabilities. Look for capabilities with many applications (duplication) and capabilities with none (manual work or shadow IT). Feed the result into the application portfolio rationalization. -->

| Capability | Supporting applications | Coverage | Duplication | Technology support |
|---|---|---|---|---|
| CAP-03.02 *(Example)* | APP-012 CRM, APP-031 Policy admin, APP-044 Broker portal, APP-050 Data warehouse | Full | High (four customer masters) | Partial |
| CAP-04.02 *(Example)* | APP-020 Rating engine, spreadsheets | Partial | Low | Poor |
| CAP-06.01 *(Example)* | APP-061 Claims system (agent screens only) | Partial | None | Partial |
| CAP-06.02 *(Example)* | APP-061 Claims system, APP-070 Rules engine | Full | Low | Partial |
| CAP-07 *(Example)* | APP-090 ERP | Full | None | Adequate |
| [CAP-nn.nn] | [APP IDs and names] | [Full / Partial / None] | [None / Low / High] | [Adequate / Partial / Poor / None] |

### 8.1 Findings from the mapping

| ID | Finding | Capabilities | Follow-up |
|---|---|---|---|
| FND-01 *(Example)* | Customer data mastered in four applications | CAP-03.02 | Rationalization review of APP-012, APP-044 |
| FND-02 *(Example)* | Pricing changes depend on spreadsheets outside change control | CAP-04.02 | Technology selection for rating capability |
| [FND-nn] | [Finding] | [CAP IDs] | [Follow-up] |

## 9. Investment recommendations

<!-- Guidance: Turn the heatmap into a short list of recommendations the portfolio board can fund. Each recommendation names the capability, the intended maturity change and how success is measured. -->

| ID | Capability | Recommendation | Type | Maturity change | Indicative cost | Success measure | Owner |
|---|---|---|---|---|---|---|---|
| INV-01 *(Example)* | CAP-06.01 Claims Intake | Add digital and out-of-hours intake with automated triage | Invest | 2 to 4 | [USD range] | Share of claims registered digitally | [@head-of-claims] |
| INV-02 *(Example)* | CAP-04.02 Pricing | Replace spreadsheet rating with a governed rating platform | Invest | 3 to 5 | [USD range] | Lead time for a rate change | [@chief-actuary] |
| INV-03 *(Example)* | CAP-03.02 Customer Information | Consolidate customer masters to one | Improve | 2 to 4 | [USD range] | Duplicate customer rate | [@head-of-data] |
| INV-04 *(Example)* | CAP-07 Finance Management | Standardise on ERP processes; stop customisation | Reduce | 3 to 3 | [Saving] | Run cost per transaction | [@cfo] |
| [INV-nn] | [CAP ID] | [Recommendation] | [Invest / Improve / Sustain / Reduce] | [From to] | [Cost] | [Measure] | [@owner] |

### 9.1 Traceability

| Strategic objective (REF-01) | Capability | Recommendation | Key result (OKR) |
|---|---|---|---|
| *Example:* Settle simple claims within 48 hours | CAP-06.01, CAP-06.02 | INV-01 | [KR ID] |
| *Example:* Launch usage-based products | CAP-04.02 | INV-02 | [KR ID] |
| [Objective] | [CAP IDs] | [INV IDs] | [KR ID] |

## 10. Governance and refresh

<!-- Guidance: Decide who may change the model, how often scores are refreshed, and which decisions must reference the map. Without this, the map becomes a poster. -->

### 10.1 Roles

| Role | Responsibility |
|---|---|
| Map owner | Maintains the model, chairs reviews, keeps IDs and lineage clean |
| Capability owner | Accountable for the definition, the scores and the target maturity of an L1 or L2 |
| Architecture board | Approves structural changes and checks that change initiatives cite capability IDs |
| Portfolio office | Uses the heatmap and recommendations in funding rounds |

### 10.2 Change rules

1. Structural changes (add, split, merge, retire) need a change request
   with rationale and approval from the architecture board.
2. Score changes need evidence and the capability owner's approval.
3. Every funded initiative names the capability IDs it changes and the
   expected maturity change.

### 10.3 Refresh cadence

| Activity | Frequency | Next date |
|---|---|---|
| Structural review of L1 and L2 | Annually, before strategy planning | YYYY-MM-DD |
| Maturity and importance rescoring | Annually, plus after major initiatives | YYYY-MM-DD |
| Application mapping update | Quarterly, from the application inventory | YYYY-MM-DD |
| Heatmap publication | With each portfolio review | YYYY-MM-DD |

## 11. Glossary and references

<!-- Guidance: Define the terms in the way this document uses them; link related templates instead of repeating their content. -->

### 11.1 Glossary

| Term | Meaning in this document |
|---|---|
| Business capability | Something the organisation is able to do to produce an outcome, described without reference to who does it, how or with which system |
| Capability map | A structured, hierarchical model of all capabilities in scope |
| Heatmap | A capability map coloured by an assessment dimension |
| Maturity | How well a capability is performed today across people, process, information and resources |
| Strategic importance | How much a capability contributes to the strategy |
| Value stream | End-to-end stages that deliver a result to a stakeholder |
| Capability owner | Business leader accountable for a capability |

### 11.2 References

- The Open Group, *TOGAF Series Guide: Business Capabilities, Version 2*
  (G211, April 2022), part of the TOGAF Standard, 10th Edition: concepts
  of capability, capability map and heat mapping.
- Business Architecture Guild, *A Guide to the Business Architecture Body
  of Knowledge* (BIZBOK Guide): concepts of capability, value stream and
  their cross-mapping; check the current version at the Guild's site.
- Related templates: Application Portfolio Rationalization
  (`architecture/application-portfolio-rationalization`), Architecture
  Principles Catalogue (`architecture/architecture-principles`),
  Technology Selection (`architecture/technology-selection`), Legacy
  Modernization Assessment (`architecture/modernization-assessment`),
  Architecture Roadmap and Transition Architectures
  (`architecture/architecture-roadmap-transition`).

## Standard and licence note

Structure aligned with the concepts of the TOGAF Series Guide: Business
Capabilities, Version 2 (The Open Group, G211, April 2022), part of the
TOGAF Standard, 10th Edition, and with business architecture concepts
described in the BIZBOK Guide of the Business Architecture Guild. Both
works are copyrighted; this template reproduces no text, definitions,
tables or reference models from them, and all wording, scales and
examples are original. Check the current official versions for their
guidance. TOGAF is a registered trademark of The Open Group; BIZBOK is a
registered trademark of the Business Architecture Guild.
Template licence: MIT.