CBA (ASQ) cheat sheet

Core domain blueprint elements: capability, value stream, information, organization, and strategy; these are the anchors of the business architecture knowledgebase.

A business capability states WHAT the business does (ability to achieve an outcome), independent of how, who, or where it is performed.

A value stream is an end-to-end sequence of activities that creates a measurable outcome for a stakeholder; it is triggered by a value item and composed of value-adding stages.

Capability maps are hierarchical (level 1, 2, 3...) and are typically heat-mapped for performance, risk, or investment to support decisions.

The information concept represents business objects and their relationships; it is distinct from data models, which describe physical/logical data structures.

Value stream maps cross capabilities: each value stream stage is enabled by one or more capabilities, linking behavior (value) to ability (capability).

Business architecture is a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands.

The knowledgebase distinguishes 'business architecture' (the abstraction) from 'business architecture practice' (the discipline, roles, and governance around it).

The business architecture practice defines roles (e.g., chief architect, business architect), competencies, and a career path distinct from IT/enterprise architecture roles.

Certification foundations emphasize a common body of knowledge, a standardized vocabulary, and a defined competency model for practitioners.

A business architect's core deliverables include capability maps, value stream maps, information maps, and business architecture roadmaps.

Practice maturity is often assessed along dimensions such as governance, methods, tools, skills, and stakeholder engagement.

Business architecture is framework-agnostic in principle; practitioners select frameworks based on scope, not doctrine.

Key competencies include business modeling, stakeholder facilitation, strategic alignment, and translation between business and technology.

Certification typically validates knowledge of concepts, blueprint elements, and the ability to apply them to scenarios, not tool-specific skills.

Business architecture value is realized through decisions it informs: investment prioritization, transformation planning, M&A integration, and capability gap analysis.

Stakeholder engagement is segmented by role (executives, business unit leaders, IT, risk/compliance) and by the decisions each stakeholder must make.

Value propositions should be expressed in stakeholder language (cost, risk, time-to-market, customer experience), not architecture jargon.

A business architecture 'value stream' for the practice itself: engage → understand → model → analyze → recommend → govern.

Common value metrics: reduced duplication, faster change delivery, improved investment traceability, and better regulatory/risk transparency.

Engagement artifacts (one-page capability summaries, heat maps, roadmaps) are tailored to audience; executives prefer visual, decision-oriented views.

Business architecture supports strategy execution by linking strategic objectives to capabilities and value streams via traceability.

Frameworks provide structure, vocabulary, and method; examples include TOGAF (ADM), Zachman (ontology), and business-architecture-specific frameworks.

The TOGAF Architecture Development Method (ADM) is a phased, iterative cycle: Preliminary, A–H, with Requirements Management at the center.

Zachman is a 6x6 ontology (What, How, Where, Who, When, Why × perspectives from planner to functioning enterprise).

Business architecture frameworks typically define domains (capability, value, information, organization, strategy) and their relationships.

Framework selection criteria: scope, stakeholder needs, existing investments, governance requirements, and interoperability with other frameworks.

Frameworks are descriptive, not prescriptive; the same enterprise may use multiple frameworks for different purposes.

A metamodel defines the allowed element types and relationships within a framework; it ensures consistency across artifacts.

A reference model is a reusable, standardized model (e.g., industry capability models, process reference models) intended for adaptation, not direct adoption.

Reference models accelerate architecture by providing a starting taxonomy and common vocabulary; they must be tailored to the enterprise context.

Industry reference models exist for sectors such as banking, insurance, manufacturing, and government.

Reference models are typically organized hierarchically (level 1–3 capabilities) to support decomposition and benchmarking.

Using a reference model supports benchmarking and gap analysis against peers or standards.

Reference models differ from as-is models: they are generic and reusable, while as-is models reflect a specific enterprise state.

Governance of reference models includes version control, ownership, and a process for local extension without breaking the shared taxonomy.

Governance defines decision rights, roles, and processes for creating, approving, and changing architecture artifacts.

A typical governance body is an architecture review board (ARB) that reviews proposals against principles and target-state architecture.

Architecture principles are enduring, rarely changing rules that guide decisions; they should be few, testable, and enforceable.

Governance ensures traceability from strategy to capabilities to initiatives, enabling impact analysis and investment control.

Exception management is part of governance: deviations from standards must be documented, time-bound, and approved.

Governance metrics include review cycle time, compliance rate, exception volume, and reuse of architecture assets.

Governance must balance control with agility; overly heavy review processes are a common failure mode.