Scope, Data, Decision Models and Architecture

Scope, Data, Decision Models and Architecture

Quick Answer: Before running algorithms, CBDA practitioners produce models that structure analysis: a scope model (what is in/out of the study), a data model (entities, grain, relationships needed for the question), and a decision model (how outputs map to choices and actions). High-level architectural diagrams—especially data-flow views—show how sources, preparation, analysis, and consumption connect. Domain 3 is about Analyze Data (~16% of exam weight); modeling is how you keep that analysis honest and usable.

Analyze Data is the third CBDA knowledge area. Domains 1 and 2 framed research questions and made data fit for use. Domain 3 turns that foundation into evidence: descriptive baselines, diagnostic explanations, and—later—predictive work. Competencies around producing analysis models (scope, data, and decision models) and understanding architecture at a conceptual level are not optional paperwork. On scenario items, candidates who skip models often pick techniques that answer the wrong population, at the wrong grain, for a decision nobody owns.

This section builds competency awareness for model production (aligned to CBDA competencies in the analysis area, including awareness of 3.1–3.2-style modeling expectations): what each model is for, what “good” looks like, and how the business analyst partners with technical specialists without abdicating business ownership.

Why Models Structure the Analysis Phase

Analysis without models is ad hoc exploration that may or may not hit the research question. Models force explicit answers to:

1. What are we analyzing? (scope)
2. What data structure represents the business reality we care about? (data)
3. What decision will this analysis inform, and how? (decision)
4. How do pieces of the analytics system connect? (architecture)

These artifacts travel with the work into interpretation (Domain 4) and decision influence (Domain 5). When executives challenge a finding, mature teams open the models—not only the chart.

Scope Models for Analysis

A scope model for analysis is tighter than the project charter. It is the contract for this analytical study: who/what is included, at what grain, for which period, against which definitions.

Core elements

• Population — Units of analysis (customers, claims, SKUs, facilities, opportunities).
• Inclusion and exclusion rules — Employees, test accounts, wholesale, incomplete periods, acquired clinics with bad keys, etc.
• Time window and cadence — Last 12 complete months; fiscal vs calendar; as-of date for snapshots.
• Grain — Customer-month vs order-line vs claim-event; never leave grain implicit.
• In-scope metrics and outcomes — The measures the research question requires (for example, voluntary cancel rate, not “all cancelations including involuntary”).
• Out-of-scope — Explicit non-goals (brand sentiment NLP deferred; competitive price scrape not approved).
• Assumptions and constraints — Identity resolution quality, known data gaps, legal limits on attributes.
• Success criteria for the analysis — What must be produced to answer the research question (baselines, segment comparisons, ranked drivers)—not “build a cool model.”

Why scope models prevent exam-style disasters

CBDA scenarios often show a team that “analyzed all customers” when leadership meant “active U.S. online subscribers who could receive a retention offer.” A documented scope model makes the mismatch visible before results go to the board. Scope also protects against moving goalposts: if marketing later asks to include enterprise accounts, that is a scope change with implications for data, methods, and claims—not a silent filter tweak.

Mini example: Research question = which mobile checkout stages drive recoverable abandoned revenue among new customers in priority categories. Scope model includes: new customers (first order intent in window), mobile app + mobile web only, priority category list v3, completed and abandoned checkouts with stage timestamps, excludes employee accounts and B2B wholesale. Out of scope: desktop journey, post-purchase returns, competitor apps.

Data Models for Analysis

A data model for analysis describes the structure needed to answer the research question—not necessarily the entire enterprise warehouse. CBDA practitioners work fluently at conceptual and logical levels; physical implementation may belong to data engineers.

Conceptual data model

Business entities and relationships in plain language: Customer places Order; Order contains Line; Line references Product; Ticket relates to Customer. Cardinality matters (one-to-many vs many-to-many) because it drives aggregation rules.

Logical data model (analysis-oriented)

Attributes, keys, and analysis tables or views at the agreed grain. Example logical artifacts:

• customer_month fact with tenure, plan, engagement counts, cancel flag
• checkout_stage_event with stage_id, timestamp, session_id, customer_id
• Reference dimensions: product hierarchy, region, channel

Analysis grain as a modeling choice

If the decision is about customer retention offers, customer (or customer-period) grain is usually primary. If the decision is about warehouse pick-path redesign, order-line or pick-task grain may be correct. Data models make grain explicit so Domain 2 joins and Domain 3 statistics stay coherent.

Linking data models to quality work

The data model names the keys and relationships Domain 2 integrity checks must protect. If the conceptual model says every Order has one Customer, orphan orders are not “interesting edge cases”—they are model violations that threaten analysis.

Decision Models: Linking Outputs to Choices

Analytics that never touch a decision fail CBDA’s business purpose. A decision model (sometimes called a decision framework or decision map) documents:

1. Decision statement — What choice is being made (for example, which retention intervention to fund this quarter).
2. Decision owner — Role accountable for the choice (not “the analytics team”).
3. Options — Discrete alternatives under consideration (A/B/C interventions; proceed / pilot / stop).
4. Information needs — Which metrics, segments, uncertainties, and confidence levels the owner needs.
5. Thresholds and rules — If lift ≥ X and cost ≤ Y, expand pilot; if match rate < Z, do not claim national results.
6. Constraints — Budget, policy, capacity, ethics, regulation.
7. Action path — Who implements what after the decision; how success will be monitored.

Decision model vs research question

The research question defines the unknown. The decision model defines the use of the answer. Together they prevent “so what?” presentations.

Exam trap: outputs without decisions

A stem may describe beautiful clusters or a high R² model with no owner, no options, and no threshold. The CBDA-aligned critique is that analysis is incomplete without a decision linkage—recommend defining decision owner, options, and how results change action—not only “tune hyperparameters.”

Architectural Diagrams at Conceptual Level

CBDA does not require you to design enterprise data platforms. It does expect conceptual architecture awareness: how data flows for analysis and who consumes outputs.

Data-flow diagrams for analysis

A simple analysis data-flow view typically shows:

Sources (CRM, warehouse, web events, external enrichments) → Ingest/extract → Preparation and quality gates → Analysis environment (sandbox, feature tables, notebooks, BI models) → Outputs (metrics, model scores, reports) → Consumers (decision owners, ops systems, downstream apps).

Annotate:

• Latency — batch nightly vs near-real-time (must match decision cadence).
• Responsibility boundaries — BA, data engineer, data scientist, report owner.
• Control points — quality scorecards, approval of metric definitions, model promotion gates.
• Feedback loops — decision outcomes and intervention results flowing back as new data (critical for learning systems).

Why architecture matters on the exam

Scenarios may hide architecture failures inside “analysis” problems:

• Decision needs same-day insight but architecture only supports weekly extracts → timeliness / architecture mismatch, not a modeling algorithm problem.
• Production dashboard uses a different join path than the analysis notebook → architecture and data model inconsistency.
• Scores written to a file no system reads → decision model and architecture both broken (no action path).

Keep diagrams conceptual: boxes and arrows with clear labels beat tool-vendor logos. The exam rewards clarity of flow and fitness for the decision, not platform brand names.

How Models Structure Work Inside Domain 3

A practical sequence CBDA practitioners use:

1. Confirm research question and decision model — still valid after Domain 2 quality findings?
2. Lock scope model — population, grain, window, exclusions.
3. Confirm data model — tables/views at grain; relationships validated.
4. Sketch architecture flow — ensure data can reach the analysis and the consumer in time.
5. Select analysis path — descriptive → diagnostic → (later) predictive as justified.
6. Execute and iterate — re-open models only with documented change control when findings force scope or decision redesign.

Models are living documents. If EDA shows 40% of the “in-scope” population lacks a required attribute, the scope model and decision model may need revision (narrow population, change metric, or delay decision)—that is professional analysis, not failure.

BA Role vs Data Scientist on Modeling

CBDA is a business analysis + analytics credential, not a pure data-science exam. Role clarity is a recurring theme.

Healthy collaboration pattern

• BA produces scope, decision, and conceptual data models; facilitates agreement.
• Technical partners refine physical design and statistical methods.
• BA reviews outputs against the decision model: “Does this change the options or thresholds we defined?”
• Neither role “throws work over the wall.” If the data scientist optimizes AUC on a label that does not match the business outcome definition, the BA must catch the mismatch.

Exam traps on roles

• “Only the data scientist models.” False for CBDA: scope, data meaning, and decision models are core BA analytical work.
• “The BA must code gradient boosting.” Not required; conceptual competence and business ownership are.
• “Models mean only ML models.” On CBDA, model often means structured representations (scope/data/decision), not only predictive algorithms.

End-to-End Mini Scenario

A hospital system wants to reduce avoidable 30-day readmissions for heart-failure discharges. The practitioner:

1. Decision model — CMO and care-management director will choose among enhanced discharge education, remote monitoring pilot, or status quo; budget supports one major pilot; success = reduction in avoidable readmissions without increasing length of stay unsafely.
2. Scope model — Adult heart-failure discharges from owned hospitals in FY2025; excludes observation-only stays and transfers out; 30-day window per agreed clinical definition; facility X excluded until identity resolution improves (from Domain 2).
3. Data model — Encounter-level grain with patient, facility, comorbidity flags, discharge disposition, follow-up appointment kept (Y/N), readmission flag; claims costs aggregated to encounter to avoid fan-out.
4. Architecture — EHR + claims → nightly warehouse → quality gates → analysis sandbox → care-management dashboard; pilot enrollment feed is weekly, so real-time scoring is out of scope for this decision cycle.
5. Analysis plan — descriptive rates by facility and cohort → diagnostic factors associated with readmission → later predictive risk scores only if the decision model needs prioritization lists for outreach.

That sequence is Domain 3 foundations: models first, techniques second.

Study Checklist for This Section

• Name three analysis models (scope, data, decision) and one purpose for each.
• List at least six elements of an analysis scope model.
• Explain how a decision model differs from a research question.
• Sketch a conceptual data-flow for analysis (sources → prep → analyze → consume).
• Contrast BA vs data scientist responsibilities on modeling without dismissing either role.
• Recognize the trap of equating “model” only with machine-learning algorithms.