To make a decision survive the meeting. It records the decision, the context that forced it, the options rejected, and the consequences accepted — so six months later nobody relitigates it, and the reasoning is available along with what was traded away. Fifteen of them were authored and reviewed on this platform.
Case study
Fifteen decisions, written down
Enterprise Data Architect · iGaming company under NDA · Nicosia, remote · November 2024 to present. Where the hard part is not the technology choice but getting four functions to agree on decisions that bind all of them.
The actual problem
Product, data, engineering and security each had a defensible position on how ingestion, historical migration, governance and production readiness should work. None of those positions was wrong. They were simply incompatible, and no one of the four could settle it alone.
That is the characteristic failure mode of an enterprise data platform, and it does not look like a technology problem. It looks like a platform that has three ways to onboard a source, two definitions of the same metric, and a security review that arrives after the design is finished.
The deliverable that fixes it is not an architecture diagram. It is a set of decisions written down in a form that binds everyone who has to live with them.
Fifteen ADRs
Fifteen architecture decision records, authored and reviewed.
An ADR is a small, unglamorous artifact: the decision, the context that forced it, the options rejected, and the consequences accepted. Its value is that it survives the meeting. Six months later nobody relitigates ingestion semantics, because the reasoning is on the record along with what was traded away.
Each one arrived with acceptance criteria rather than intent. "We will use data contracts" is a preference. A data contract with a defined schema-versioning policy, a stated compatibility rule, and a test that fails the pipeline when it is violated is a decision a team can implement and an architect can verify.
The platform underneath
| Layer | Choice |
|---|---|
| Streaming | Kafka |
| Analytical store | ClickHouse |
| Table format | Iceberg |
| Orchestration | Airflow |
Around those four, the standards that make them behave predictably: data contracts, schema versioning, replay and backfill, observability, lineage, ownership, and access controls.
That second list matters more than the first. The four technologies are conventional and defensible on any comparable platform. The standards are what determine whether adding the eleventh data source costs the same as adding the third.
Onboarding a source without a bespoke integration
Provider onboarding is the clearest example of what an ADR is for, because it is the decision that quietly sets the cost of everything afterwards.
The default path is to integrate each new provider by hand. It works, it ships, and it accumulates: every source becomes its own small system with its own failure modes, and the team that built it is the only team that can fix it.
The alternative is a standard every source is required to meet:
- Data contracts — the shape and meaning of what arrives, agreed before the first byte does.
- Schema versioning — how change is announced and absorbed, rather than discovered in production.
- Idempotency and checkpoints — so a re-run is safe and a partial failure is recoverable.
- Replay and backfill — so history can be rebuilt without a bespoke script.
- Observability — so a silent source is visible as a silent source.
- Ownership — a named owner per source, because unowned pipelines decay.
- Security controls — applied at onboarding rather than retrofitted at review.
No separate integration bus or middleware layer is claimed here. The standard is the mechanism.
Where AI fits
The AI surface was scoped in the same way as everything else — as architectural direction with boundaries, not as a set of deployed models.
The directions covered content optimization, recommendation, ranking and auction concepts, a semantic layer with Text-to-SQL, and secure LLM integrations — governed rather than open-ended, with the same ownership and access-control expectations as any other consumer of the platform.
Specific production models and vector storage choices are not published, and no claim is made here about what is running in production.
What this case shows
| Claim | Evidence |
|---|---|
| The work was decision-making, not diagramming | 15 architecture decision records authored and reviewed |
| Decisions were implementable, not aspirational | each carrying acceptance criteria for the teams that had to build to it |
| The platform is specified | Kafka, ClickHouse, Iceberg and Airflow, with data contracts, schema versioning, replay and backfill, observability, lineage, ownership and access controls |
| Scope spanned the full surface | DWH, provider onboarding, clickstream, experimentation, recommendation, and governed LLM integrations |
| Attribution is bounded | Enterprise Data Architect, iGaming company under NDA, Nicosia, November 2024 to present |
Scope of this case
- The client is under NDA. The company, its regulator, its jurisdiction beyond the working location, and its size are not disclosed.
- No maturity score. No data-management maturity level is claimed, because no independent assessment is available to support one.
- No efficiency metric. Onboarding time before and after the standard is not published; the case describes the mechanism, not a measured delta.
- No production AI claims. Architectural directions are described. Deployed models, vector storage choices, and live usage are not.
FAQ
Frequently asked questions
By making every source meet the same standard: data contracts for shape and meaning, schema versioning for how change is announced, idempotency and checkpoints so re-runs are safe, replay and backfill so history can be rebuilt, observability so a silent source is visibly silent, a named owner, and security controls applied at onboarding rather than at review.
Kafka for streaming, ClickHouse as the analytical store, Iceberg as the table format, and Airflow for orchestration — with data contracts, schema versioning, replay and backfill, observability, lineage, ownership and access controls layered around them.
Because product, data, engineering and security each hold a defensible position, and none of them can settle the question alone. The result is a platform with several ways to onboard a source and competing definitions of the same metric. Written decisions with acceptance criteria are what convert four defensible positions into one implementable one.
An iGaming company under NDA. The engagement runs from November 2024 as Enterprise Data Architect, based in Nicosia and working remotely. The company, its regulator and its size are not disclosed.
Prefer a conversation first?
If you would rather talk it through before sending a brief, book a short routing call and we will point you to the right next step.