Build one case
Choose one familiar business—real or fictional—and carry it through all ten domains. One integrated example reveals relationships that flashcards hide.
Certified Business Architect exam
Study the system, not a bag of nouns.
The CBA exam becomes manageable when the ten domains are understood as one linked architecture. These notes focus on practical understanding, common category errors, and scenario judgment—without reproducing proprietary material or exam questions.
The central study mistake
Business architecture contains many concepts that sound obvious in isolation. The difficulty appears when a scenario includes several of them at once and asks what the architect should do next.
Memorization is necessary, but it is not sufficient. You need to know what question each domain answers, how it differs from adjacent domains, what it links to, and when using it would be excessive.
A repeatable method
Six moves that produce durable recall.
The goal is not to accumulate study hours. It is to make the distinctions and linkages available under scenario pressure.
Draw from memory
Recreate a small capability map, value stream, stakeholder view, information concepts, and linkage map on blank paper. Then compare.
Drill distinctions
Maintain a two-column error log for pairs you confuse: capability/process, value stream/process, stakeholder/organization, strategy/initiative, information/data.
Practice scenarios
For each problem, ask: what decision is needed, which domain answers it, what must be linked, and what is unnecessary?
Teach it aloud
Explain a domain without jargon to an operations leader. Where the explanation becomes fuzzy, the understanding is not yet stable.
Review errors, not comfort
Spend the final review cycle on wrong answers, uncertain distinctions, and scenario-selection mistakes rather than rereading familiar chapters.
The ten domains
Translate each domain into something you can do.
Use these as study prompts, then verify terminology and scope against the official objectives and your authorized BIZBOK materials.
Foundational Concepts
Be able to: Explain what BA is for, what it is not, how the framework fits together, and why the discipline creates value.
Common trap: Memorizing definitions without understanding the governing purpose and ecosystem.
Core Mapping Knowledge
Be able to: Create and connect capability, value, organization, and information maps—and explain why each answers a different question.
Common trap: Treating capability as process, value stream as workflow, organization as stakeholder, or information as data design.
Extended Mapping Knowledge
Be able to: Link strategy, stakeholders, initiatives, products/services, and policy to the core domains.
Common trap: Knowing each map separately but not the relationship that makes the analysis useful.
Related Business Disciplines
Be able to: Explain how BA complements business models, process management, requirements, case management, and Lean/Six Sigma.
Common trap: Letting an adjacent discipline replace the architecture question instead of contributing evidence or implementation detail.
Business Performance Analysis
Be able to: Use measures, heat maps, assessments, and portfolio views to expose gaps and support prioritization.
Common trap: Coloring a map before defining the question, scale, evidence, owner, or consequence of the rating.
Business Architect Role
Be able to: Act as advisor, facilitator, communicator, relationship manager, and mentor—not merely as a model producer.
Common trap: Choosing the technically pure answer when the scenario requires influence, sequencing, or stakeholder judgment.
Business Architecture Governance
Be able to: Establish purpose, decision rights, standards, engagement, maturity, stewardship, and a sustainable practice model.
Common trap: Starting with a repository or tool before proving demand, ownership, and governance.
Business and IT Alignment
Be able to: Use BA to guide application, data, solution, service, and transformation decisions without turning BA into IT architecture.
Common trap: Jumping directly from strategy to systems and skipping capability, value, stakeholder, and information impacts.
Situation and Scenario Usage
Be able to: Select and combine the right architecture domains for transformation, impact analysis, issue resolution, customer experience, or a tactical problem.
Common trap: Applying every artifact to every scenario instead of selecting the minimum useful architecture.
Infrastructure Management
Be able to: Manage architecture knowledge, packaging, tooling, automation, metadata, reuse, and controlled change.
Common trap: Confusing diagram storage with a governed knowledgebase of typed, owned, source-linked relationships.
Scenario triage
When a question feels muddy, reduce it to four things:
- Decision: What choice or diagnosis is actually required?
- Object: Is the question primarily about an ability, value, stakeholder, organization, information concept, product, objective, initiative, policy, metric, or implementation?
- Relationship: What must the object connect to for the answer to become useful?
- Level: Is this strategic architecture, operational detail, or solution design?
This does not guarantee the answer. It prevents the most common failure: solving a different problem because one familiar word appeared in the stem.
Study help
Stuck on a distinction?
Email the concept pair or scenario that is giving you trouble. I will help you reason through it using a fresh example rather than giving you a memorized answer.
Free, best-effort support.
Do not send exam questions or copyrighted pages.
Email a CBA study question