How AI is applied across API Evangelist and APIs.io. Read my AI disclosure →
API Evangelist API Evangelist
Discovery
Learnings
Guidance
Toolbox
Alignment
API Evangelist LLC

Turbo EA Reference Catalog

The Turbo EA Reference Catalog is an open, MIT-licensed reference model for business architecture, covering three orthogonal artefacts — business capabilities (what the enterprise does), business processes (how it does it), and value streams (how value gets delivered end to end). It ships as YAML validated by JSON Schema, published as a JSON API and a Python package, and it is deliberately tool-agnostic: usable in LeanIX, Ardoq, Turbo EA, or a spreadsheet. It gives an architecture team a governed, machine-readable vocabulary for the demand side of the enterprise — the same vocabulary APIs should be mapped against.

The Turbo EA Reference Catalog is an open, MIT-licensed business architecture reference model published by Turbo EA, browsable at catalog.turbo-ea.org and maintained as YAML in a public GitHub repository. It is a curated, opinionated baseline for teams standing up an enterprise architecture function — a starting taxonomy of what businesses in a given industry must be able to do, rather than a modeling notation like ArchiMate or a method like TOGAF. It is explicitly tool-agnostic, and exports into LeanIX, Ardoq, or any other EA management solution.

  • Three orthogonal artefacts - Business capabilities (what the enterprise does), business processes (how the work gets done), and value streams (trigger to outcome), each governed separately and linked at the stage level rather than collapsed into one tree.
  • Real scale, by industry - 9,697 capabilities across four levels (333 L1, 2,068 L2, 7,296 L3) spanning 28 industries — banking, insurance, telecom, healthcare, utilities, mining, air traffic control, agriculture and more — on top of a 41-capability Cross-Industry baseline every enterprise shares.
  • Processes and value streams too - 1,321 business processes organized into 54 top-level categories, 65 value streams whose stages point at the capabilities and processes that participate, and an optional nine-item macro-capability overlay for executive navigation.
  • Governed, not just published - A written governance model defines the TOGAF-aligned definition of a capability, MECE decomposition rules, noun-phrase naming, sparse BC- / BP- / VS- / MC- identifier allocation, mandatory metadata, deprecation with successors, and a lint-on-pull-request workflow.
  • Machine-readable end to end - YAML source of truth validated by JSON Schema 2020-12, built into a JSON API (capabilities.json, tree.json, value-streams.json, business-processes.json, per-capability subtrees) plus a turbo-ea-capabilities Python package that bundles the whole catalogue offline, with translation sidecars in seven languages.
  • Anchored to the existing bodies of work - The upper levels are built against APQC’s Process Classification Framework, TOGAF, DAMA-DMBOK, ITIL, ISO 9001/14001/22301/27001/55000, ISA-95, and dozens of industry-specific regimes, with divergence reserved for where an enterprise actually differentiates.

The catalogue exists because of a gap on the tooling side. Vincent Verdet, the Swiss enterprise architect who maintains it, built it as a by-product of Turbo EA — his source-available enterprise architecture management platform, aimed at the small and mid-sized companies that cannot justify a six-figure EAM license. Since those companies may already own an EAM or prefer a commercial one, he split the catalogue out and released it separately under MIT, on the reasoning that a blank capability model is the single sharpest pain point when a team is standing up an EA function from scratch. There is no grand roadmap — new industries get added when a need for them appears. Source lives at vincentmakes/turbo-ea-capabilities, where the YAML, the schemas, and the governance model are the deliverable rather than a rendered PDF.

For API operations this belongs on the demand side of the ledger. Almost every API catalog — including my own — organizes the world by supply: providers, tags, specs, endpoints. A capability model organizes it by what the business must be able to do, and that is the missing join. When an L3 capability like Identity Verification or Meter Data Collection has a stable identifier and a machine-readable definition, you can map the APIs that realize it, see which capabilities are covered by an internal API, a vendor API, or nothing at all, and turn “we have 400 APIs” into “here is the 12% of what we do that no interface touches.” That is the coverage conversation architecture teams keep trying to have without a shared vocabulary on both sides.

The agentic turn raises the stakes on that join. An agent handed a pile of OpenAPI contracts knows what calls it can make, not what the business is trying to accomplish; a capability and value-stream model is exactly the context that tells it which operations serve which outcome, and in what order. A reference catalogue that is MIT-licensed, versioned, schema-validated, and served as JSON is the rare enterprise architecture artifact an agent can actually consume — which makes it far more interesting than the PowerPoint capability maps most organizations still keep their business architecture in.