The argument
One problem at a time.
The site is organised as a single argument. Each chapter starts with a problem you may recognise, follows its consequences, and only then offers an idea. Every idea is told the same way: problem → consequence → idea → picture → example → detail. Read in order, or jump to the problem that is yours today.
Entries marked draft or proposed are positions being argued, not settled conclusions.
-
Prologue
Data as a first-class citizen
What changes when data is part of the product we build, rather than the exhaust it leaves behind?
The problemApplications are designed, built and deployed; someone else later has to interpret, clean, secure, document and reconcile the data they produced. Adding people to that downstream repair does not scale, whether the team is central or federated.
-
Chapter 1
Why the numbers disagree
Why do two reports answer the same business question with two different numbers?
The problemMeaning, calculation, target and display are fused inside each report. Every new tool, including an AI assistant, becomes another place where a number is defined.
Where this started: Where does a KPI live?
- 1 Measure, metric and KPI Separate what a number means, how it is evaluated, what it is judged against and how it is shown, and give each its own authority.
- 2 Semantic authority is independent of consumption Business concepts and metrics need governed identities that exist independently of every tool that consumes them.
- 3 Put computation where it belongs Recurring analytical work belongs in the data product's serving model and the query layer, not in each consumption tool.
- 4 Process ledger fact Model a coherent business process as a ledger of atomic, additive events at an explicit grain, and compose metrics from it.
- 5 Semantic layer A semantic layer projects governed meaning into many tools; it does not create that authority.
-
Chapter 2
Meaning starts at the source
Where should the meaning of data be decided, and by whom?
The problemMeaning is reconstructed downstream by people furthest from where the data was created. Two fields share a name, so everyone assumes they mean the same thing.
- 1 Meaning and accountability belong at the source Domain owners maintain the meaning of what they publish, and reconciling meaning across contexts is an explicit, recorded decision.
- 2 Make semantic context explicit A domain is an ownership boundary, not a meaning boundary; meaning lives in an explicit context, qualified by role and relationship.
- 3 Source-aligned data as the governed foundation Establish ownership, meaning, contract and classification once, at the source-aligned product, and let everything downstream inherit them.
- 4 Quality starts at the producer Producers declare and observe measurable quality expectations where the business fact is created, and publish the evidence with the data.
- 5 Metadata is produced, not reconstructed Metadata should flow from declaring, building, deploying and operating a product, with people adding only what needs judgement.
-
Chapter 3
Data as products with promises
What turns a table someone can query into something another team can depend on?
The problemEvery table, file and topic gets called a data product. Without owners, meaning and promises, distributed data sharing becomes distributed data dumping.
-
Chapter 4
Who answers for it
Who is accountable for data, and what happens when a team copies it to avoid depending on anyone?
The problemOwnership follows databases rather than business responsibility, and teams copy data to escape a dependency they still have.
In preparation
-
Chapter 5
Promises meet intent
How does a producer's promise meet a consumer's purpose without either side pretending to control the other?
The problemA published contract and a consumer's subscription hide two failures: the same term used differently, and access granted before anyone checked the fit.
-
Chapter 6
Making it executable
How do meaning, policy and promises move through delivery instead of sitting in documents?
The problemGetting data live means tickets to several central teams, and governance becomes a queue that finds problems when they are most expensive to fix.
-
Chapter 7
The platform as a product
How do you give teams ownership without handing them all of the complexity?
The problemDecentralisation without abstraction redistributes a central team's complexity across every domain team.
In preparation
-
Chapter 8
Meaning at scale
How do many bounded contexts understand one another without a single universal model?
The problemSystems interoperate while silently misunderstanding one another, and a central ontology project becomes a second universe that drifts from the products it describes.
-
Chapter 9
AI and analytics
What should an AI assistant be trusted to decide, and what should it only ask for?
The problemPointing a language model at raw data asks it to reinvent the query engine, the semantic model and the analytical modeller, without being reproducible.
In preparation
-
Epilogue
Rehearse, don't assert
How would we know any of this works?
The problemArchitectural claims are easy to make and hard to test. The honest position is to rehearse a real change and treat what happens as evidence.
In preparation