# Chapter 16 Reference Solution: Solution Selection and Architecture Review

This reference solution shows one defensible way to complete the Chapter 16 lab. It is not the only correct answer. A strong submission is judged by the quality of its reasoning, evidence, and review trigger rather than by selecting a predetermined technology.

## Expected Matrix Interpretation

With the starter weights and scores, the managed warehouse option normally ranks first because TuranMart’s finance analytics use case values time-to-value, operational simplicity, security integration, and SQL usability. The open lakehouse option remains competitive because it scores well on portability, storage economics, and architectural flexibility. The self-managed stack ranks lower because operational burden and delivery risk dominate its advantages for this scenario.

| Option | Typical interpretation |
|---|---|
| Managed warehouse | Strong fit when the business needs trusted analytics quickly and the team wants to minimize platform operations. |
| Open lakehouse | Strong fit when long-term portability, open formats, and multi-engine access are more important than immediate simplicity. |
| Self-managed stack | Usually justified only when regulatory, latency, customization, or cost conditions make managed options unsuitable. |

## Example Decision

A reasonable ADR may select a **managed warehouse for the first production finance analytics platform**, with explicit guardrails. The decision should state that this is not a permanent rejection of lakehouse patterns. Instead, the team chooses the managed warehouse for phase one because it accelerates delivery, reduces operating risk, and supports finance-governance requirements with less custom integration work.

## Example Consequences

The team should document the consequences honestly. Positive consequences include faster dashboard delivery, simpler monitoring, fewer self-managed services, and easier onboarding for SQL analysts. Negative consequences include vendor dependency, possible compute-cost surprises, and migration effort if the organization later moves to a lakehouse or hybrid architecture.

## Example Review Trigger

A high-quality review trigger is measurable. For example:

> Revisit the platform choice when monthly analytics spend exceeds the approved budget by 20% for two consecutive months, when p95 executive-dashboard latency exceeds the agreed service target for two consecutive reporting cycles, or when a new regulatory requirement demands data residency not supported by the selected platform.

## Common Mistakes

The most common weak submission is a matrix that contains numbers but no evidence. Another weak submission changes the weights until a preferred option wins. Strong submissions explain why the weights reflect TuranMart’s business priorities and record what evidence would change the decision later.

## Instructor Checkpoints

| Checkpoint | Strong evidence |
|---|---|
| Decision statement | Names the workload, decision scope, and excluded decisions. |
| Criteria | Separates functional fit from non-functional qualities such as cost, operations, security, and portability. |
| Scores | Uses evidence notes rather than personal preference. |
| ADR | Captures context, alternatives, decision, consequences, and review trigger. |
| Reviewability | Names measurable triggers that could supersede the ADR. |