Business Architecture Framework: What It Contains, the Main Options, and How to Build Your Own
A framework is the set of rules that makes business architecture repeatable: what you model, how the pieces relate, how the work gets done, and who keeps it current.
By Capstera Business Architecture Staff · Updated
11 min read
Two business architects in the same company can produce capability maps that cannot be compared. One decomposes by department, the other by outcome. One calls "Customer Onboarding" a capability, the other calls it a value stream. Both maps are reasonable, and neither connects to the other. A business architecture framework exists to prevent exactly this. A framework is not the architecture itself. The capability map, the value streams and the information concepts are the model. The framework is the rulebook that says which of those things you model, how they relate to each other, how the work is done, and who owns the result once it exists. This article covers what goes into a framework, what the established frameworks contribute, and how to assemble one that fits your organization.
Most organizations do not adopt a single framework whole. They take the domain definitions from BIZBOK, the delivery cycle from TOGAF, a classification habit from Zachman, and an industry reference model as a starting map, then add the governance that none of them can supply for a specific company. That combination is the framework, whether or not anyone writes it down. Writing it down is what makes the architecture consistent across teams and durable across reorganizations.
Key Takeaways
- A business architecture framework has four parts: a metamodel (what you model and how it relates), a method (how the work is done), governance (who owns and approves it), and reference content (a starting point so you are not modeling from a blank page).
- The business capability is the hub of most frameworks. Value stream stages, organization units, information concepts, initiatives and applications all connect to the business through capabilities.
- BIZBOK defines the business architecture domains and their relationships, TOGAF places business architecture inside an enterprise architecture delivery cycle (Phase B of the ADM), and Zachman offers a classification grid, not a method. They answer different questions and are routinely combined.
- Build a framework from the decisions it has to support. Start with the questions leaders will ask, model only the domains needed to answer them, and add domains when a real decision requires one.
- A framework without an owner and an update cadence produces a model that is accurate for one quarter. Governance is part of the framework, not an afterthought to it.
What a Business Architecture Framework Is, and What It Is Not
A business architecture framework is a defined structure for describing an enterprise from the business point of view: its capabilities, the value it delivers, the information it depends on and the organization that does the work.
The word "framework" gets used loosely, so it helps to separate three things that are often run together. The model is the content: your capability map, your value streams, your list of information concepts. The framework is the structure that content must follow: which object types exist, what each one means, how they may be connected and at what level of detail. The tool is the software or spreadsheet that stores the model.
The distinction matters in practice. When two teams disagree about whether something is a capability or a process, they are not arguing about the model. They are discovering that there is no shared framework. When a capability map has to be rebuilt after every reorganization, the framework is missing a rule that capabilities describe what the business does, independent of who does it.
A business architecture framework is also narrower than an enterprise architecture framework. Enterprise architecture spans business, data, applications and technology. Business architecture covers the business layer, and its framework defines how that layer connects to the others, usually through capability-to-application and information-to-data mappings.
| Framework (the rules) | Model (the content) | |
|---|---|---|
| Example | "A capability is a noun phrase describing what the business does, independent of org structure, process and technology" | "Customer Management > Customer Onboarding > Identity Verification" |
| Changes when | The practice matures or the questions it must answer change | The business changes: new products, markets, acquisitions |
| Owned by | The architecture practice lead | Business owners, with architects as stewards |
| Failure mode | Missing or unwritten: every team models differently | Stale: accurate once, never updated |
The Four Parts of a Working Framework
Every business architecture framework that holds up in practice has the same four parts, whether they come from a published standard or were built in-house.
The metamodel defines what you model. It lists the object types (capabilities, value streams, organization units, information concepts and so on), gives each a definition and naming rule, and states which relationships are allowed between them. The metamodel is what makes two architects' work combinable.
The method defines how the work is done: how a capability map is built and validated, how a value stream is scoped, how heat maps are scored, how the architecture is applied to an initiative. A method turns definitions into repeatable steps.
Governance defines who owns each part of the model, who approves changes, and how often the model is reviewed. Without it, the model drifts from reality within a planning cycle or two.
Reference content is the starting point: an industry capability map, a standard set of value streams, a common information model. Reference content is not a substitute for analysis, but it removes weeks of first-draft work and keeps naming consistent with how the industry describes itself.
- Metamodel: object types, definitions, naming rules, allowed relationships, levels of decomposition.
- Method: the steps for building, validating and applying each artifact.
- Governance: ownership, change approval, review cadence and the forums where architecture informs decisions.
- Reference content: industry capability maps, value streams and information models to start from.
The Core Domains and How They Connect
The metamodel is the part of the framework that does the most work. Its domains, and the relationships between them, decide what questions the architecture can answer.
Business capabilities describe what the business does, such as Product Development, Customer Management or Risk Management, stated independently of who does it, how, or with which systems. Because they change slowly, capabilities are the stable reference point that everything else connects to.
Value streams describe how value reaches a stakeholder, end to end: a triggering stakeholder, a sequence of stages, and a value item at the end, such as "Acquire Customer" or "Settle Claim." Each stage is enabled by one or more capabilities. That stage-to-capability link is what lets a capability heat map be read in terms of customer outcomes.
Organization mapping connects capabilities to the business units, roles and partners that perform them. It is the domain that shows duplication, such as three business units each running their own version of the same capability.
Information concepts describe the business objects the enterprise depends on, such as Customer, Policy, Order or Asset, and connect to capabilities as the information each one creates or uses. This is the bridge to data architecture.
Most mature frameworks add strategy (objectives mapped to the capabilities that must improve), initiatives (the projects and programs changing those capabilities), products and services, stakeholders, and policies. Add these when a decision needs them, not by default.
The Established Frameworks and What Each Contributes
BIZBOK, TOGAF and Zachman are often presented as competing choices. They answer different questions, and most practices draw on more than one.
BIZBOK, the Business Architecture Body of Knowledge published by the Business Architecture Guild, is the most complete definition of business architecture as a discipline. It defines the core domains of capabilities, value streams, organization and information, along with extended domains including strategy, initiatives, products, stakeholders and policies, and describes how they relate. It is vendor-neutral and deliberately leaves tooling and day-to-day operating detail to the practitioner. Use it for the metamodel.
TOGAF, from The Open Group, is an enterprise architecture framework. Its Architecture Development Method (ADM) is a cycle of phases, and business architecture is Phase B, after the architecture vision and before the information systems and technology architectures. TOGAF tells you where business architecture sits in an enterprise architecture engagement and what it hands to the phases that follow. Use it for the delivery cycle and the connection to IT architecture.
The Zachman Framework, introduced by John Zachman in 1987, is a classification schema rather than a method: a grid of six interrogatives (what, how, where, who, when, why) against six perspectives, from executive to implementer. It does not tell you how to build anything. It is useful as a completeness check, a way to ask whether a set of artifacts covers the questions a given audience will ask.
Industry reference models supply the content none of the three provide. Examples include BIAN for banking, TM Forum's eTOM for telecommunications, and APQC's Process Classification Framework, which classifies processes rather than capabilities and maps to them well. Use them as starting content, then adapt them to your own business.
| Question | Best source | |
|---|---|---|
| Metamodel | What do we model, and how does it relate? | BIZBOK |
| Delivery | Where does business architecture fit in an EA engagement? | TOGAF ADM, Phase B |
| Completeness | Have we covered what each audience needs? | Zachman Framework |
| Starting content | What does a capability map for our industry look like? | Industry reference models |
| Operating rules | Who owns the model, and how is it kept current? | Your own governance; no standard supplies this |
How to Build a Business Architecture Framework for Your Organization
Build the framework from the decisions it has to support, not from the full list of domains a standard defines.
The most common mistake is to start by modeling everything a standard describes. Months later the practice has a large repository and no decision that used it. Starting from the decisions keeps the framework small enough to maintain and makes its value visible early.
Reference content to start from
The Enterprise Business Architecture Starter Package supplies the reference-content part of a framework: an enterprise capability map, value streams and processes, sample information entities, a business glossary and a business transformation framework.
Six steps to a working framework
- 1 — List the decisions: Write down the questions leaders will bring to the architecture in the next year: investment prioritization, application rationalization, merger integration, operating model redesign, AI adoption. Each question implies domains and relationships.
- 2 — Define the minimum metamodel: Choose only the domains those questions need. Capabilities and value streams cover most first-year questions; add organization and information mapping when rationalization or data work requires them. Write a one-line definition and naming rule for each object type.
- 3 — Adopt reference content: Start from an industry capability map and value stream set instead of a blank page. Adapt the names to your business, merge or split capabilities where your business differs, and record those choices.
- 4 — Set the decomposition rules: Agree how many capability levels you model (three is common, four for detailed work), what distinguishes one level from the next, and the test for a capability versus a process or a department.
- 5 — Assign owners and a cadence: Name a business owner for each top-level capability, an architect steward for the model, and a review cycle tied to planning and budgeting, so updates happen when decisions are made.
- 6 — Apply it to one live decision: Use the framework on a real initiative, such as a heat map for next year's investment portfolio. Fix the definitions that caused confusion, then extend the framework to the next decision.
Where Business Architecture Frameworks Go Wrong
Most framework failures trace to a small number of design choices made early.
Each of the problems below is a framework problem rather than a modeling problem, which is why fixing individual diagrams does not solve them.
- Capabilities named after departments. A map that mirrors the org chart has to be redrawn after every reorganization. Name capabilities for what is done, not who does it.
- Processes recorded as capabilities. "Approve Invoice" is a step in a process; "Accounts Payable Management" is a capability. Mixing them makes the map impossible to heat-map consistently.
- Value streams drawn as process flows. A value stream stage is a milestone in delivering value to a stakeholder, not a task in a workflow. If the stages read like system steps, the framework's value stream definition is not being applied.
- Every domain modeled at once. A metamodel with a dozen domains and no decision to serve produces a repository nobody consults.
- No owner after the first draft. Without named owners and a review cadence, the model is accurate for one planning cycle and trusted for none after that.
- The framework kept in architects' heads. If definitions and rules are not written down, the framework leaves when the architect who built it does.
How the Capstera Framework Fits
Capstera's approach builds on the BIZBOK domains rather than replacing them, and adds the reference content and operating layer a practice needs to use them.
The capability, value stream, organization and information domains follow BIZBOK definitions. On top of them, Capstera provides industry reference models, each with a sector-specific capability map, a value stream collection and a business data entities list, so a practice starts from a structured first draft rather than workshops. The Capstera platform stores the model, maps capabilities to applications, initiatives and organization units, and supports heat mapping and governance workflows.
The practical test of any framework, ours included, is whether two architects working separately produce work that fits together, and whether the model is still current a year later. The crosswalk article linked below maps each BIZBOK domain to its Capstera equivalent in detail.
Go Deeper
Related guides on the domains and frameworks covered above.
- What Is BIZBOK? — The Business Architecture Body of Knowledge and its domains.
- TOGAF vs. BIZBOK — Where the enterprise architecture and business architecture standards overlap and differ.
- Zachman Framework Explained — The six-by-six classification grid and how to use it.
- The Business Architecture Model — The core views (capabilities, value streams, organization and information) in detail.
- Business Capability Modeling — Practices for building and decomposing a capability map.
- Value Stream Examples — Worked value streams and how their stages map to capabilities.
- Mapping the Capstera Framework to BIZBOK — A domain-by-domain crosswalk.
- Enterprise Business Architecture Starter Package — An enterprise-wide capability map, value streams and data entities to start from.
Frequently Asked Questions
What is a business architecture framework?
A business architecture framework is a defined structure for describing an enterprise from the business point of view. It specifies what is modeled (such as capabilities, value streams, organization and information), how those elements relate, the method for building and using them, and the governance that keeps them current.
What is the difference between a business architecture framework and a business architecture model?
The framework is the set of rules; the model is the content produced under those rules. A rule that capabilities are named as nouns independent of org structure belongs to the framework. A capability map for your company is the model.
Is TOGAF a business architecture framework?
TOGAF is an enterprise architecture framework that includes business architecture as Phase B of its Architecture Development Method. It explains where business architecture sits in an enterprise architecture engagement, but it defines the business domains in less depth than BIZBOK.
Should we use BIZBOK or TOGAF?
Most practices use both. BIZBOK supplies the business architecture domain definitions and relationships; TOGAF supplies the delivery cycle and the link to data, application and technology architecture.
What are the main components of a business architecture framework?
A metamodel (object types, definitions and relationships), a method (how artifacts are built and applied), governance (ownership, approval and review cadence), and reference content (industry capability maps and value streams to start from).
How long does it take to set up a business architecture framework?
It depends on scope and on how much reference content is available. A minimum framework covering capabilities and value streams, built from an industry reference model and applied to one live decision, is a much smaller undertaking than modeling every domain a standard defines. Start small and extend the framework as new decisions require it.
Pro Tips
- Write the framework down in a document of a few pages: object types, definitions, naming rules, levels, owners and review cadence. A short document people read beats a long one they do not.
- Test every new capability name with one question: would it still be true after a reorganization? If not, it is probably a department or a process.
- Tie the model's review cycle to the budgeting calendar. Architecture that is current when investment decisions are made gets used; architecture updated on its own schedule gets bypassed.