The revenue meeting has three totals. Finance uses booked revenue from the ERP. Sales uses contract value from the CRM. The executive dashboard joins both, drops amendments posted after midnight and labels the result “revenue.”
A new data platform will move that disagreement faster unless someone settles the meaning first.
That is the opening test for data architecture consulting. Pick one disputed number and follow it all the way from the business event to the person who acts on it. The trace makes architecture choices concrete. It also reveals where a technical diagram has been covering a policy decision.
Pick the number with consequences
Choose a measure that changes a decision. Revenue is obvious, but the same method works for inventory available to promise, active customer, order fill rate, member eligibility or unresolved service cases.
Write the decision beside the number. “Revenue” is too broad. “The amount the CFO uses to approve the next hiring tranche on the fifth business day” has a consumer, a deadline and a consequence.
The first working record should fit on one page:
| Trace field | Entry to resolve |
|---|---|
| Business event | The real-world event that creates or changes the fact |
| Grain | What one row represents and which identifier keeps it distinct |
| Meaning | Inclusion, exclusion, status and timing rules |
| Authority | Source that wins when records disagree |
| Freshness | Latest acceptable arrival for the named decision |
| Consumer | Person, process, report or model that uses it |
| Access | Roles allowed to see the detail and the aggregate |
| Reconciliation | Independent check against the source or control total |
| Owner | Person who can approve a definition change |
The consultant should lead the disagreement into the open. If finance and sales mean different things, store two named measures. Do not hide the conflict under a universal semantic layer called “gold.”
Walk the current path
Follow a handful of records through the present system. Use one ordinary case, one amendment, one late arrival and one correction. Screenshots are weaker than identifiers and timestamps.
At every hop, record what changed:
- The source event and its identifier.
- The extract or message that moved it.
- The transformation rule and version.
- The stored object, partition and retention rule.
- The business model or metric definition.
- The access decision applied to the consumer.
- The report, API or model response the consumer received.
- The evidence available when the result is wrong.
This is not a complete enterprise lineage program. It is a thin slice with enough friction to expose the architecture’s real boundaries.
AWS’s Data Analytics Lens separates concerns across operational excellence, security, reliability, performance, cost and sustainability. Use those as prompts, not as a vendor score. The buyer still needs workload-specific evidence for the path under review.
Mark decisions and plumbing separately
The current-state trace will contain two kinds of work. Plumbing work copies, stores and serves data. Decision work defines identity, meaning, authority, access and acceptable delay.
Color them differently.
This distinction protects the engagement from a familiar mistake: engineering is asked to “clean up the data” when the unresolved issue belongs to business owners. A pipeline can enforce a rule. It cannot decide that booked revenue should replace contract value for every purpose.
For each decision, name the person with authority and the evidence they need. For each plumbing step, name the team that operates it and the failure signal they can see.
Compare target shapes against the trace
Do not ask for one target diagram. Ask for credible shapes and the burden each introduces.
| Target shape | Useful when | Burden to expose |
|---|---|---|
| Improve the current warehouse | Core sources and serving model are sound | Existing coupling and release process remain |
| Add governed data products | Domains can own definitions and service levels | Ownership and platform standards must be real |
| Separate operational and analytical serving | Transaction and analysis workloads conflict | More movement, reconciliation and on-call surface |
| Use federated query selectively | Copying is slow, restricted or wasteful | Source performance and cross-system failure become user concerns |
| Build a new unified platform | Several decisions need a common control plane | Migration, coexistence, cost and skill demands rise |
The labels are less important than the comparison. Each option should show the same number, source cases, freshness target, access boundary and operating test.
AWS describes modern data architecture as a combination of data lake, warehouse and purpose-built stores with governance and data movement across them. Its own documentation also shows that moving data between specialized stores can become complex. The AWS description is a product-family pattern, not proof that every buyer needs every component.
Build a thin path that can fail
The proof should carry the disputed number through a production-shaped path. Keep the data set bounded, but use real identities, permissions, schema rules and operating signals.
Then break it on purpose:
- deliver the source after the reporting cutoff
- replay an event with the same business identifier
- remove a field that a transformation expects
- change a code that alters a business rule
- request detail as a user who should see only an aggregate
- publish a result that does not match the independent total
Record what the consumer sees and what the operator sees. A red pipeline is useful only when somebody knows which business decision is affected. A green pipeline proves little when the number is wrong.
The proof passes when the system detects the condition, preserves enough evidence to diagnose it, follows a named recovery route and reconciles the corrected result. This is a buyer test proposed for the engagement, not a guarantee attached to a cloud service.
Put ownership in the architecture
Boxes and arrows rarely show who may change a definition, approve access or accept stale data. Add an ownership layer to the target.
| Asset or decision | Accountable role | Operating responsibility |
|---|---|---|
| Source contract | Source-system owner | Announces and versions material changes |
| Business definition | Named domain owner | Approves meaning and resolves disputes |
| Transformation | Data product or engineering owner | Tests, deploys and rolls back logic |
| Access policy | Data and security owners | Approve roles, purpose and exceptions |
| Service expectation | Consumer and platform owners | Agree freshness, availability and response |
| Reconciliation | Independent control owner | Reviews mismatch and closes the case |
Microsoft’s data guidance places organizational readiness, architecture, governance and security, and operational standards in the same program. That grouping is useful because a platform diagram without ownership and operations is incomplete. It does not require the buyer to adopt Microsoft’s preferred platform.
Cost the operating shape
Cloud estimates often price storage and compute while leaving people out. Ask the consultant to model the work created by the design:
- number of pipelines, products and environments to support
- release and schema-change cadence
- expected backfills and replay volume
- monitoring, catalog and access-review duties
- after-hours response for decision-critical data
- vendor-specific skills and replacement effort
Use ranges. Name assumptions. A cost model that cannot show which workload unit drives spend will age badly.
The same rule applies to performance. Record the query, concurrency, data shape and freshness need behind a target. “Fast” is not an architecture requirement.
Accept a decision pack, not a poster
The final pack should include the current trace, unresolved facts, definition decisions, credible target options, the selected option and why others lost. It should also contain the thin-path results, ownership map, security boundaries, operating model, cost assumptions and a sequenced change plan.
Keep diagrams. They are useful. Tie every material box and arrow to a decision record, owner or test.
Data architecture consulting ends well when the business owner can explain which number is authoritative and the operator can recover the path when it is late or wrong. If the new drawing cannot answer either question, the old disagreement has simply moved into newer boxes.