# ADR-016: Select the TuranMart Finance Analytics Platform

## Status

Proposed.

## Context

TuranMart finance, operations, and executive teams need trusted daily revenue, margin, refund, and fulfillment analytics. The platform must ingest operational data, retain at least five years of history, support governed SQL analytics, and refresh executive dashboards within the agreed freshness target. The decision must balance time-to-value, operational burden, security controls, portability, and predictable cost.

## Decision Drivers

| Driver | Why it matters |
|---|---|
| Functional fit | The platform must support ingestion, storage, transformation, SQL analytics, governance, and historical retention. |
| Performance at target scale | Representative dashboards and analyst queries must meet latency and freshness targets. |
| Operational simplicity | The team must be able to monitor, upgrade, recover, and secure the system without heroics. |
| Security and compliance | Finance and customer data require strong identity, encryption, audit, and masking controls. |
| Cost predictability | The platform must remain affordable under expected first-year growth and visible enough for FinOps review. |
| Team skill fit | The solution should match current SQL, Python, Spark, and cloud operating skills. |
| Portability and exit cost | The architecture should avoid irreversible lock-in unless the business value is explicit. |
| Ecosystem maturity | Connectors, documentation, support, and community maturity reduce adoption risk. |

## Options Considered

| Option | Summary | Main benefit | Main risk |
|---|---|---|---|
| Managed warehouse | Use a commercial or cloud-managed analytical warehouse as the primary query and storage layer. | Fastest time-to-value and lowest operational burden. | Higher vendor dependency and possible cost spikes under concurrency. |
| Open lakehouse | Use object storage, open table formats, and a lakehouse query engine. | Strong portability and lower storage cost at scale. | More platform engineering and governance integration work. |
| Self-managed stack | Operate storage, processing, orchestration, metadata, and query services mostly in-house. | Maximum control and customization. | Highest operational burden and slowest delivery. |

## Evidence Required Before Acceptance

| Evidence | Expected artifact |
|---|---|
| Weighted matrix | Completed `technology_selection_matrix.csv` with criteria, weights, candidate scores, and evidence notes. |
| Validation output | `python shared/labs/ch16_solution_selection_architecture_review/tests/validate_matrix.py` runs successfully. |
| POC evidence | Short notes or measurements for the highest-risk assumption, such as query latency, concurrency, or governance integration. |
| Cost estimate | One-page estimate of storage, compute, orchestration, support, and migration cost. |
| Security review | Notes on identity, encryption, audit, masking, and data residency. |

## Decision

Select **TBD** after completing the weighted matrix and evidence review.

## Consequences

The selected option will become the default Part IV reference architecture for TuranMart finance analytics. The team must document implementation tasks, operational responsibilities, cost guardrails, and migration risks. Any accepted decision should include a measurable review trigger rather than becoming permanent by default.

## Review Trigger

Revisit this decision when daily incremental data volume, dashboard concurrency, compliance requirements, or monthly platform cost changes enough to invalidate the assumptions recorded in the matrix. A suggested first trigger is: **review when monthly run cost exceeds the approved budget by 20% for two consecutive months or when p95 dashboard latency exceeds the target for two consecutive reporting cycles**.