Framework · Leadership
Technology Decision Domain ArchitectureTDDA
Who decides what — before the conflict arrives.
Maps every class of technology decision to a defined altitude and domain, so authority is assigned before conflict requires it. It answers two questions at once: at what altitude should this decision be made, and within which domain does it belong? Once both are answered, the right decision authority is clear.
The problem
A ship's captain commands at sea. When the ship enters the harbour, the harbourmaster takes over.
The captain owns every decision about how the ship operates; the harbourmaster owns where and when it moves within the port. Neither tries to do the other's job — not because of hierarchy, but because the boundary is known.
Take the boundary away and the ship sits at the channel entrance, waiting. Not for a decision — for someone to decide who gets to decide.
- An escalation ladder answers
- Who breaks the tie when things get stuck?
- A decision rights model answers
- Who should have decided this in the first place — and why was it escalated at all?
The three failure modes
Decision Vacuum
Nobody is certain who holds authority, so nobody decides and delivery stalls. It looks like a process problem. It is an authority problem.
Decision Collision
Two parties make the same decision independently. The collision surfaces weeks later, when unwinding it is no longer a governance conversation but a delivery crisis.
Decision Gravity
All decisions pull upward regardless of altitude. Leadership becomes a bottleneck — not from unwillingness to delegate, but because nobody defined what delegation means.
Axis 1
Decision Altitude
How wide the consequence of a decision reaches. Most escalation failures happen because a team-altitude decision is treated as enterprise-altitude — or an enterprise-altitude decision is made without any governance at all.
| Altitude | Description | Examples |
|---|---|---|
| Enterprise | Decisions that set constraints for the entire organization | Architecture principles, approved cloud providers, mandatory security standards |
| Domain | Decisions that govern a bounded business or technology domain | Domain platform choices, data ownership rules, integration contracts |
| Team | Decisions within a team's implementation boundary | Library selection within approved standards, internal service structure |
| Individual | Decisions a practitioner makes in the act of delivery | Variable naming, local refactoring, in-sprint implementation approach |
Axis 2
Decision Domain
The domain of concern a decision belongs to. A decision belongs to a specific altitude and a specific domain; together they define the precise location of decision authority.
| Domain | Covers | Typical owner |
|---|---|---|
| Investment | Build vs. buy, vendor selection, budget allocation | Architecture board + CTO |
| Standards | Approved technologies, languages, protocols | Enterprise Architecture |
| Platform | Core infrastructure and shared service decisions | Platform Engineering + EA |
| Integration | APIs, events, contracts between systems | Domain Architecture |
| Implementation | How a team delivers within its boundary | Engineering Team |
| Security | Access, data classification, threat surface | Security Architecture |
Worked example
The TDDA decision map
| Altitude | Investment | Standards | Platform | Integration | Implementation | Security |
|---|---|---|---|---|---|---|
| Enterprise | CTO + Arch Board | Enterprise Arch | CTO + Platform Lead | Enterprise Arch | — | CISO |
| Domain | Domain Lead + Arch | Domain Arch | Platform Eng | Domain Arch | — | Security Arch |
| Team | — | Eng Lead (within standards) | — | Team Arch | Eng Lead | Security review |
| Individual | — | — | — | — | Engineer | — |
Every blank cell is intentional: an individual engineer does not make investment decisions, and enterprise architecture does not decide variable naming. A blank where a cell should not be blank is a decision rights gap waiting to become a delivery failure.
What the map reveals
Three decision rights gaps
Altitude Mismatch
A decision is being made at the wrong altitude — a team making a vendor selection that belongs at enterprise altitude, or a board reviewing implementation approaches that belong to a team. It generates either ungoverned decisions or governance bottlenecks.
Domain Vacancy
A decision domain has no assigned owner at any altitude. These vacancies do not stay quiet: they generate conflict at the moment a decision becomes necessary.
Authority Overlap
Two owners share authority over the same cell. Both believe they have the right to decide; neither is wrong — the map was never drawn. Authority overlap produces Decision Collisions.
Interactive
Build your decision map
Start from the example map and make it yours, then place the decisions your organisation actually makes. The builder shows who decides each one and where the three gaps are. Your map stays in this browser only.
1 · Your decision map
Name the owner of each cell — a role or authority body. Leave a cell blank only where it is intentionally vacant: not every altitude applies to every domain.
| Investment | Standards | Platform | Integration | Implementation | Security | |
|---|---|---|---|---|---|---|
| Enterprise | ||||||
| Domain | ||||||
| Team | ||||||
| Individual |
2 · Place your decision classes
Take a decision your organisation makes often. Say where it belongs, how high it actually travels today, and who believes they decide it.
Implementation · 30–60 days
Honesty more than technology
The hardest part is naming who does not hold authority.
- Phase 1 · Weeks 1–2
Map the Current State
Take the ten most common technology decision classes. For each: what altitude it reaches before resolution, who believes they hold authority, how long it takes. Document what actually happens — design nothing yet.
DeliverableCurrent-state decision inventory — ten decision classes with altitude, owner claim, and resolution time
- Phase 2 · Weeks 3–4
Build the TDDA Map
Map each decision class to its correct altitude and domain. Assign a named owner to every cell, mark cells that should be blank as intentionally vacant, and record every mismatch as a Decision Rights Gap.
DeliverableFirst version of the TDDA map with gaps identified
- Phase 3 · Weeks 5–8
Operationalize the Model
Make the map a standard governance artefact. Add a decision rights check to every architecture review, confirm the authority owner before work begins, and update the map quarterly.
DeliverableTDDA map embedded in architecture governance cycle
Go deeper
Decisions stalling or colliding?
Draw the map before the next escalation
Bring the map you built above — or the decision class nobody will claim — to a free 30-minute diagnostic.