CBA (ASQ) common mistakes
CBA · Understand the traps and how to avoid them.
Treating the Business Architecture Knowledgebase as a glossary and memorizing isolated term definitions, rather than learning how each artifact, blueprint, and viewpoint relates to the others within the knowledgebase structure.
The knowledgebase is organized as an interconnected set of domains, artifacts, and mappings; candidates who study term-by-term build no relational understanding and then cannot answer scenario or 'which artifact' questions.
What to do instead
Build a one-page map of the knowledgebase showing how business architecture domains, blueprints, viewpoints, and mappings connect, and practice explaining how a change in one element propagates to the others.
Confusing the purpose and content of blueprints (e.g., capability, value stream, information) and using them interchangeably when a question asks which blueprint addresses a given concern.
Many blueprints share underlying concepts, so candidates rely on surface keywords instead of the specific concern each blueprint is designed to communicate.
What to do instead
For each blueprint, write a two-line statement of 'the question it answers' and 'the stakeholders who use it,' then test yourself by matching scenarios to blueprints without looking at the names.
Answering certification-foundation questions from personal job experience rather than from the standardized body of knowledge the exam is built on.
Experienced practitioners default to how their own organization labels roles, deliverables, and processes, which often diverges from the standardized terminology and scope the exam expects.
What to do instead
Separate 'what my organization does' from 'what the standard says' by reviewing the defined scope and terminology for each knowledge area and flagging where your practice differs.
Memorizing role names and certification levels without being able to distinguish the responsibilities, competencies, and boundaries between them.
Role questions are often phrased as scenarios about who should perform an activity or own an outcome, which definition recall alone cannot resolve.
What to do instead
Create a comparison table of roles across responsibility, key deliverables, and decision rights, and practice assigning scenario activities to the correct role with a written justification.
Describing business architecture value only in abstract terms (alignment, clarity, transformation) without linking it to specific stakeholder decisions or measurable outcomes.
Candidates learn the value proposition as slogans and then cannot select the answer that ties value to a concrete decision, cost, risk, or time-to-change benefit.
What to do instead
For each value claim, practice stating the stakeholder, the decision it informs, and the outcome metric, then rewrite abstract statements into decision-linked ones.
Treating stakeholder engagement as a single generic communication step instead of tailoring artifacts, level of detail, and language to each stakeholder group.
Candidates underestimate how much of the exam tests selecting the right viewpoint or level of abstraction for a given audience and concern.
What to do instead
Build stakeholder profiles (concern, decision, preferred abstraction) and practice choosing the artifact and detail level for each, justifying the choice in one sentence.
Treating frameworks as competing methodologies to be ranked, rather than as complementary tools selected by purpose, scope, and context.
Candidates look for a 'best framework' answer, but exam questions usually test fitness for a given situation, layer of the architecture, or stakeholder concern.
What to do instead
Map each major framework to the questions it answers and the layer it addresses, then practice 'which framework for this situation' scenarios with explicit selection criteria.
Using reference models as prescriptive templates to be copied rather than as adaptable starting points requiring tailoring to context.
Reference models are presented as standardized structures, so candidates assume they should be adopted wholesale and miss questions about adaptation, extension, and mapping to the organization.
What to do instead
For each reference model, note what is standardized versus what must be localized, and practice describing how you would tailor and map it to an organization's context.
Confusing governance with management and describing governance only as approval gates rather than as decision rights, accountability, and escalation structures.
Day-to-day experience with review boards leads candidates to equate governance with process steps, missing questions about who owns decisions and how conflicts are resolved.
What to do instead
Reframe governance in terms of decision rights, accountabilities, and escalation paths, and practice mapping a given decision to its owner, inputs, and escalation route.
Ignoring how governance and architecture change interact, answering questions about lifecycle, versioning, and exception handling as if architecture were static.
Candidates study governance and architecture content separately and do not connect them, so they miss questions about maintaining integrity across change, exceptions, and waivers.
What to do instead
Study governance as the mechanism that keeps architecture current through change, and practice scenarios on exception handling, change impact, and architecture lifecycle with the governance touchpoints identified.