Book 5 of The Architect’s Playbooks · New Release
The Data Architect’s Playbook
Architecting Authoritative, Trustworthy, and AI-Ready Data for Defense and Space Programs
For any data your program depends on: know where the original is, what has happened to it since, and how you would prove it.
About the book
The data underneath digital engineering.
Which file is the right one? On almost every defense and aerospace program, a room full of capable engineers eventually loses an afternoon to that question — and the answer ends up depending on one person’s memory.
Programs rarely design their data. They accumulate it, one sensible local decision at a time, until they are running on an architecture nobody chose. The cost shows up later: in design reviews that turn on which number is right, in migrations that quietly drop business rules, and in AI efforts built on data no one can source or verify.
The Data Architect’s Playbook is a practical guide to the data underneath digital engineering. Drawing on four decades of mission-critical defense, space, and intelligence work, Dr. Daryoush Tehranchi shows chief engineers, architects, and digital engineering leads how to:
- Assign authority so every important value has one owner and one official source
- Match the architecture and controls to each class of data — not one rule for everything
- Keep the original, change only the copy, and record every change
- Build lineage and integrity evidence that holds up in a review
- Exchange data across suppliers, enclaves, and security boundaries
- Judge whether engineering data is fit to train or feed an AI system
- Migrate a legacy data estate and prove the new system matches the old
Tool-agnostic and grounded in anonymized composite cases, each chapter ends with something you can do on Monday, and the appendix provides ready-to-use templates.
Key takeaways
Six ideas worth keeping.
Takeaway 01
A “single source of truth” doesn’t exist until someone assigns it.
Authority over data has to be decided and written down — not inferred from which tool is newest or which team is loudest. Every piece of data has an origin (where it was created) and an authority (who decides what it should be), and they are often not the same. (Chapter 1)
Takeaway 02
Classify the data first, then choose the controls.
Sort data by volume, nature, urgency, and criticality before picking a platform or process. One policy applied to everything either buries high-volume data in overhead or under-protects what matters. When a dataset’s use changes, its controls have to change with it. (Chapter 2)
Takeaway 03
Keep the original, change the copy, record the change.
Preserve data exactly as it arrived, apply every treatment to a labeled derived version, and record what was done, by which process and version. A change that isn’t recorded is a decision no one can reconstruct later. (Chapters 4–5)
Takeaway 04
Intact and correct are two different questions.
Integrity asks whether data is unchanged since it was approved; correctness asks whether it is right. Data can be perfectly intact and still wrong, so programs need both kinds of evidence — and lineage is not the same as requirements traceability. (Chapters 5–6)
Takeaway 05
Across organizations, the exchange is the architecture.
Every inter-company data exchange needs a short written data contract covering structure, meaning, validation, handling, timing, and how changes are announced. Govern it federally: decide centrally only what must be consistent, and delegate the rest to the teams that own the data. (Chapters 7–8)
Takeaway 06
“AI-ready” is a claim about a specific use, not a property of the data.
Readiness has to be shown against tests such as quality, meaning, and lineage for the decision the AI will support. And when replacing a legacy system, counting records proves almost nothing — reconcile the outputs people actually rely on. (Chapters 10–11)
Who it’s for
Written for the people who own the consequences.
Questions
Before you ask.
Is this book tied to a specific tool or platform?
No. It is deliberately tool-agnostic. The playbook is about the architecture underneath your data — authority, classification, lineage, exchange — which outlasts any particular platform choice.
I’m not a data architect. Is this book for me?
Yes. It was written for the people who own the consequences of data decisions: chief engineers, architects, and digital engineering leads. You don’t need a data title to be accountable for the data.
How is this different from a data governance book?
Governance books describe the policies you should have. This book is about the architecture those policies sit on — how data is authored, preserved, changed, exchanged, and proven fit for use, in real program conditions.
What will I actually be able to do differently?
Each chapter ends with something concrete you can do on Monday, and the appendix provides ready-to-use templates — for data contracts, lineage records, migration reconciliation, and AI-readiness checks.
What formats is it available in?
It is available in Kindle and paperback on Amazon. Get it on Amazon →
The author
Dr. Daryoush Tehranchi is an engineer, architect, educator, and author whose work focuses on complex systems, systems and software architecture, digital engineering, artificial intelligence, technical leadership, and the decisions that remain fundamentally human.
The Architect’s Playbooks
More from the series.
Connect with Daryoush