Book 3 of The Architect’s Playbooks
The System-of-Systems Playbook
Architecting Across Programs, Agentic AI, and Organizational Boundaries for Defense and Space
Architecting across programs nobody controls: govern the boundaries, respect independence, and verify continuously at the edges.
About the book
The problem with no one in charge.
Two programs I worked, years apart, had never spoken to each other in any formal sense. Different customers, different contracts, different budgets. And yet, by the time anyone with authority over both of them noticed, each had quietly become dependent on an assumption about how the other one behaved — an assumption nobody had written down, because nobody had ever been in a position where writing it down was clearly their job.
That is the specific problem this book is about. The system you’re responsible for is really a collection of independently owned, independently funded, independently scheduled systems, and your job is to make sense of the whole without ever having had authority over any of its parts. A large single system, however complex, still has one authority who can force a decision. A system of systems structurally lacks that backstop — and every technique built for the single-system case fails, quietly, when applied to the other.
The System-of-Systems Playbook is the third volume of The Architect’s Playbooks. Drawing on four decades of mission-critical defense, space, and intelligence work, Dr. Daryoush Tehranchi shows senior architects and technical leaders how to:
- Run Maier’s disassembly test before reaching for the full toolkit — if each part wouldn’t still be useful and independently managed, you may not need this book at all
- Match the architecture framework to the actual question — 4+1 for technical structure, perspectives for cross-cutting concerns, TOGAF only where the system touches enterprise IT
- Govern interfaces you don’t control with versioned, visible specifications — changes announced the moment they’re proposed
- State the verification method explicitly for every requirement that crosses an organizational boundary
- Find the specific overlap between each organization’s own incentives and the shared outcome, one organization at a time
- Build the funding and authorization case through each organization’s own contract with the same rigor as the technical case
- Integrate bilaterally and verify at the boundaries continuously, instead of betting on one comprehensive event
- Measure what actually exists to measure — governed-interface ratio, integration-validation age — rather than a unified model this scale rarely has
- Recognize multi-agent AI orchestration as a system of systems structurally, and govern agent boundaries the same way
Tool-agnostic, anonymized, and grounded in composite cases from real programs, it ends with the book’s 12 Rules — the compressed version you can carry into a program review.
Key takeaways
Six ideas worth keeping.
Takeaway 01
Ask Maier’s question first.
If this effort were disassembled, would each part still be useful and independently managed? Maier’s defining criteria are operational and managerial independence — a collection of systems that lacks them isn’t a system of systems no matter how complex. A four-contractor program where one customer can compel changes on schedule is a large single system wearing a system-of-systems costume. (Chapter 1)
Takeaway 02
Independence is not a problem to architect away.
A system-of-systems failure is rarely a story about someone doing their job badly. It’s two or more people doing their jobs well, inside boundaries that were individually correct and collectively incomplete. The discipline is what it takes to produce a coherent outcome from parts that were never going to be centrally controlled — and shouldn’t be. (Chapters 1 and 9)
Takeaway 03
Emergent behavior runs in both directions.
The same independence that produces an unmanaged failure can produce a genuine, unplanned capability that no centrally-planned architecture would have arrived at. You can’t architect emergence away directly; you build the observability to notice something unplanned quickly enough to act on it either way — and you investigate why an interaction actually works before formalizing it. (Chapter 9)
Takeaway 04
An interface you don’t control needs its own governance built in.
Without a backstop, a specification one side can silently reinterpret isn’t a specification — it’s a shared hope in a document’s formatting. Treat the interface spec as a version-controlled artifact both sides can see changes to, so a proposed change is visible the moment it’s proposed. (Chapter 7)
Takeaway 05
Contracts are architecture.
A technically sound decision still needs a funding and authorization path through each organization’s own contract — a harder constraint than any technical one. An architect who treats contract structure as someone else’s problem will keep proposing decisions the governance structure has no path to fund. The business case for the contract modification is real engineering work, not a detour from it. (Chapter 8)
Takeaway 06
Verify the boundary, not the whole.
A system of systems can’t be fully verified even in principle: the constituent systems keep changing on their own schedules, so a comprehensive campaign goes stale before it finishes. Concentrate continuous, automated verification at the boundaries. The same governance applies to AI agents, which exhibit runtime independence at their interaction boundaries. (Chapters 10, 11, and 12)
Who it’s for
For architects working across boundaries.
Questions
Before you ask.
Do I need to have read the first two books in The Architect’s Playbooks?
No. The throughline is familiar if you have — the first book on credibility and influence without authority, the second on the connected model — but each book stands on its own, and this one restates what it needs from the earlier ones.
How is this different from an architecture book about large, complex single systems?
A large single system still has one authority who can ultimately resolve a disagreement. A system of systems structurally lacks that backstop. This book’s techniques are built for the case where no one can force a decision — and they are the wrong toolkit where someone can.
Is this only for defense and space?
The case material comes from defense, space, and intelligence programs, but the discipline applies to any effort where independent organizations share an outcome nobody fully owns.
Does it address AI, or is it purely about traditional systems?
Chapter 10 treats multi-agent AI orchestration directly: independently-specialized agents are, structurally, a system of systems, so the same boundary-governance principles apply — versioned interfaces between agents, bounded autonomy, observability for emergent behavior in both directions.
What do I get that’s actionable?
Every chapter ends with the reasoning behind one or two of the book’s 12 Rules, compressed near the end into a short chapter you can carry into a program review. Chapter 1 also provides a one-page diagnostic for deciding how much of the discipline a given effort actually warrants — and Chapter 14 argues honestly when this discipline is overkill.
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