Stakeholder Conflict Over a Shared Data View
A hospital network is building an enterprise data platform spanning 6 hospitals. The clinical operations director wants a real-time bed-capacity dashboard. The privacy officer insists on strict data minimization and role-based masking. The finance director wants cost-per-patient analytics refreshed nightly. During architecture review, the clinical and finance representatives each claim their view is 'the' enterprise view and that the other is a departmental concern. The privacy officer threatens to block the platform if any patient identifiers reach the analytics layer. The lead architect has one 90-minute workshop to resolve the framing before the design freeze. Budget is fixed; the platform team has 9 engineers.
1. Diagnose why the disagreement is occurring in architecture-framework terms, and explain what an architecture framework provides that resolves it.
Read the worked answer
The conflict is a viewpoint and stakeholder-concern problem, not a requirements-priority problem. Each stakeholder is expressing a legitimate concern (capacity, privacy, cost) and each is asserting that their view is the whole architecture. In framework terms:
- An architecture is a single coherent description; views are projections addressing specific concerns of specific stakeholders.
- No single view is 'the' architecture; claiming so conflates a view with the model it is drawn from.
- A framework supplies the catalog of viewpoints and the rules for consistency between them, which lets the architect show that all three concerns can be satisfied by one underlying model with different projections and access rules.
The answer must reframe 'whose view wins' into 'which concerns must each view address, and what must stay consistent across them.'
2. Propose how to structure the 90-minute workshop to reach a workable framing.
Read the worked answer
A defensible agenda:
- Concern inventory (15 min): each stakeholder states the decision their view must support and the freshness/identification needs that follow. Record as concerns, not solutions.
- Separate data from presentation (20 min): agree that real-time capacity, nightly cost analytics, and masking are different projections over shared source data, not competing platforms.
- Identify cross-view consistency rules (25 min): e.g., patient identity handling must be identical wherever it appears; define the masking boundary as a platform-level rule the privacy officer co-owns.
- Assign viewpoint ownership (15 min): each stakeholder owns acceptance criteria for their view; the architect owns consistency.
- Confirm the design-freeze decision (15 min): what must be true at freeze.
The model answer should show time-boxing and that the privacy constraint is treated as an architectural rule, not a veto to negotiate away.
3. The privacy officer demands zero patient identifiers in the analytics layer. Evaluate this demand and recommend a response.
Read the worked answer
Evaluate it as a constraint with a testable definition. 'Zero identifiers' is ambiguous: direct identifiers, quasi-identifiers, and pseudonymous keys are different things. The response should:
- Clarify which category is prohibited and whether pseudonymous linkage is permitted for cost analytics (often needed to avoid double-counting).
- If pseudonymous linkage is needed, propose a tokenization boundary at ingestion with the mapping held under privacy-office control, satisfying minimization while preserving analytic integrity.
- Recognize that a blanket ban may make cost-per-patient analytics infeasible; surface that trade-off explicitly to finance rather than silently degrading the requirement.
A strong answer refuses to treat the demand as binary and converts it into a precise, verifiable architectural rule with an owner.