One ADR template does not fit every architectural context. Five purpose-built variations — for standard decisions, agentic AI, cross-domain impact, fast delivery, and high-risk reversals — plus governance automation to make the system run without manual follow-up.

ADR Templates: 5 Variations for Different Contexts + Governance Automation

A clear executive guide explaining LLM, RAG, AI Agents, and MCP using the Brain model to prevent enterprise AI instability.

AI Architecture Clarity: Understanding LLM, RAG, Agents, and MCP Through the Brain Model

A structured executive guide to analyzing business strategies using a four-layer framework that connects intent, positioning, capability, and execution discipline.

Analyzing Business Strategies: From Strategic Intent to Execution Discipline

A practical guide explaining why Architectural Decision Records (ADR) are the missing link between enterprise architecture strategy and engineering implementation.

Architectural Decision Records (ADR): The Missing Layer Between Strategy and Implementation

A governance framework introducing the Architectural Decision Rights Matrix (ADR-M) to clarify accountability between Enterprise, Solution, and Technical Architects in Context-Driven Architecture.

Architectural Decision Rights Matrix: Governing Enterprise, Solution, and Technical Architecture

A practical guide explaining which type of architect is required at each stage of the application lifecycle to prevent governance friction and structural instability.

Architecture Across the Application Lifecycle: Which Architect Is Needed When?

A governance-driven perspective explaining why software architecture cannot be automated because decision accountability and consequence ownership cannot be delegated to AI.

Architecture in the Age of AI: What Can Be Automated — and What Cannot

The patterns that solve your hardest distributed systems problems were already solved — in a submarine, a postal sorting office, and an electrical panel. Most architects never look.

Architecture Patterns That Travel Across Industries

A clear explanation of the difference between architecture and design, why organizations confuse them, and how this confusion creates structural instability in technology systems.

Architecture vs Design: Why Most Organizations Confuse Them

Organisations debate batch versus real-time as if it is a technical preference. It is not. It is a structural mismatch between data freshness and decision cadence — and the mismatch is where the cost lives.

Batch vs Real-Time Is the Wrong Debate.

Just as buildings must adapt to snow, desert, or tropical climates, software architecture must align with business geography to improve predictability and reduce complexity.

Context-Driven Architecture: Why Software Design Must Adapt to Business Geography

Decision velocity is not constrained by leadership intent but by architectural design. Governance systems built for slower eras create mechanical delay between insight and execution.

Decision Velocity Is Not a Leadership Problem. It Is an Architecture Problem.

Developer experience is not about making developers happy. It is about controlling the conditions that determine delivery output. Organizations that treat DX as a perk have removed the control system from their delivery engine without knowing it.

Developer Experience Is Not a Perk. It Is a Delivery Control System.

Most enterprises build data architectures one layer at a time. Business, logical, and physical layers exist as separate artefacts owned by separate teams. That separation is the structural gap that makes data estates ungovernable.

Complete Enterprise Data Architecture Framework: Business, Logical, Physical Layers with Real Templates

A structured executive guide explaining the difference between Enterprise, Solution, and Technical Architects using Context-Driven Architecture to clarify responsibilities and reduce structural misalignment.

Enterprise, Solution, and Technical Architects: Who Does What in a Context-Driven Architecture?

A practical framework for reducing delivery slowdown caused by unmanaged structural code complexity — improving cycle time, reducing regression risk, and clarifying ownership boundaries.

Execution Stability: How Structured Refactoring Improves Delivery Predictability

A clear executive guide explaining Generative AI, AI Agents, and Agentic AI using a corporate office analogy to prevent autonomy risks in enterprise AI.

From Creation to Autonomy: Understanding Generative AI, AI Agents, and Agentic AI Through a Workplace Analogy

MCP is classified as an AI integration protocol. It is actually a governance primitive — the stable interface layer that architecture fitness functions have been missing for years.

MCP Is Not an AI Protocol. It Is a Governance Layer.

Observability is not a monitoring add-on. It is an architectural constraint. Systems built without observability baked in cannot be understood, cannot be governed, and cannot be improved. The OSAF model tells you exactly where your architecture is blind.

Monitoring Added After Deployment Is Not Observability. It Is Archaeology.

Why Architectural Decision Records are the only structure most organizations already have that can govern AI agent accountability — and how to extend them into an Agentic Decision Log before the EU AI Act deadline.

Nobody Uses ADRs as an Agentic Decision Log. They Should.

A structured framework for defining personas that eliminates scope creep, reduces rework, and aligns engineering delivery with actual user needs — before development begins.

Requirement Clarity: How Structured Persona Definition Reduces Rework and Misalignment

Why the second run of an Event Storming workshop — the one most teams never attempt — is the fastest way to surface governance gaps that architecture diagrams will never show.

Run Event Storming Twice. The First Maps the System. The Second Exposes Governance.

A practical framework explaining how organizations can systematically reduce technical debt while delivering new features, instead of running disruptive modernization programs.

Solving Technical Debt Through Feature Development: Turning Product Delivery into Architecture Improvement

A structured executive guide explaining the difference between Technology Leadership and Technology Governance, and why confusing the two creates instability in enterprise execution.

Technology Leadership vs Technology Governance: Why Confusing the Two Creates Structural Instability

A structured guide explaining how AI systems evolve from simple model usage to governed platforms, and how to scale complexity without losing architectural control.

The AI Evolution Stack: How AI Systems Mature from Simple Models to Governed Platforms

A practical framework explaining how software architecture evolves from startup experimentation to enterprise-scale governance, and what architectural practices are needed at each stage.

The Architecture Evolution Model: How Architecture Changes from Startup to Enterprise

Why traditional capability maps fail to support governance decisions and how Queryable Capability Architecture turns static maps into interrogable decision systems.

The Capability Map That Cannot Answer a Question Is Not a Capability Map

A structured executive guide explaining how to move from AI experimentation to an Enterprise AI Operating Model with governance, autonomy control, and cost discipline.

The Enterprise AI Operating Model: From Experimentation to Institutional Capability

A practical architectural model explaining why most companies only need a modular monolith, a workflow orchestrator, and outcome-based events.

The Minimum Architecture Every Company Needs: The House, the Hallway, and the Doorbell

Why strategic intent evaporates before it reaches engineering teams — and how Enterprise Architecture creates the translation layer that makes organizational strategy executable.

The Strategy-to-Execution Gap: How Enterprise Architecture Bridges the 'What' and the 'How'

Enterprise architecture maturity is not a feeling. It is a score. Organizations that cannot measure their architecture maturity cannot improve it. The EAMS model gives you the score.

You Cannot Improve an Architecture You Have Not Measured.

AI agents are making micro-architecture decisions in production. No ADR recorded them. No review board approved them. No architect ever saw them. Here is the structural fix.

Your AI Agents Are Making Architecture Decisions. Nobody Assigned Them That Role.

Why architecture diagrams describe a system that no longer exists, and how Observable Architecture uses production telemetry to reveal what is actually running.

Your Architecture Diagrams Are Lying to You

A practical architecture technique showing how Git commit patterns reveal structural instability, boundary violations, and ownership gaps in software systems.

Your Git History Is an Architecture Health Report. Nobody Is Reading It.

Most organizations evaluate private cloud and HCI platforms by running a technical POC. The POC passes. The platform fails. The reason is structural — and fixable. The Platform Fitness Evaluation Model (PFEM) tells you what to measure instead.

Your HCI Proof of Concept Measures the Wrong Thing.

Why on-call rotation data is the most accurate org chart your engineering organisation has — and almost nobody uses it to make structural decisions.

Your On-Call Log Is Your Real Org Chart.


# Executive Summary

- **Who this is for:** Enterprise Architects, CTOs, CIOs, Architecture Leads, Engineering Directors
- **Problem it solves:** Technology decisions stall, duplicate, or collide because authority is assumed rather than assigned
- **Key outcome:** A structured model that maps decision rights by domain and altitude across the technology estate
- **Time to implement:** 30–60 days to build a working decision rights architecture for your organization
- **Business impact:** Faster delivery decisions, fewer escalation bottlenecks, reduced architecture conflict, and governance that works before something breaks

---

# The Shipmaster and the Harbourmaster

A container ship arrives at port.

The captain has commanded that vessel for weeks.

They have made every decision.

Route. Speed. Crew assignments. Emergency protocols.

Their authority at sea is absolute.

Then the ship enters the harbour.

And a different authority takes over.

The harbourmaster controls berth allocation.

Entry timing.

Channel sequencing.

The weight and width limits for each dock.

The captain cannot override this.

They do not ask to.

Because the boundary is known.

The captain owns every decision about how the ship operates.

The harbourmaster owns every decision about where and when the ship moves within the port.

Neither tries to do the other's job.

Not because of hierarchy.

Because the decision rights are clear.

---

Now imagine a second scenario.

Same ship. Same port.

But no clear handoff exists.

The captain believes they own the berthing decision — they have been making navigation calls all week.

The harbourmaster believes they can direct the ship's internal readiness — the berth is ready and the ship must comply.

Nobody formally disagrees.

But nobody formally agrees either.

The ship sits at the channel entrance.

Waiting.

Not for a decision.

For someone to decide who gets to decide.

This is the exact state most enterprises are in with technology decisions.

---

# The Escalation Ladder Is Not a Decision Rights Model

Most organizations have a process for technology decisions.

It usually looks like this:

A team cannot agree.

They escalate to the architecture board.

The architecture board cannot agree.

They escalate to the CTO.

The CTO makes a call.

Everyone returns to work.

This is an escalation ladder.

It is not a decision rights model.

The escalation ladder answers one question: *who breaks the tie when things get stuck?*

A decision rights model answers a different question: *who should have decided this in the first place, and why was it escalated at all?*

Most organizations have invested heavily in the first.

Almost none have built the second.

---

# The Three Failure Modes

When decision rights are unclear, three failure patterns appear consistently.

---

## Failure Mode 1: Decision Vacuum

Nobody is certain who holds authority for a class of decision.

So nobody decides.

Teams wait.

Delivery stalls.

The work technically belongs to someone — but nobody wants to claim a decision they might later be accountable for.

The vacuum looks like a process problem.

It is an authority problem.

---

## Failure Mode 2: Decision Collision

Two parties make the same decision independently.

Neither knew the other was deciding.

A domain team selects a messaging platform.

An enterprise architecture team has already standardized on a different one.

Both decisions were made in good faith.

Neither party had clear authority to make the call without informing the other.

The collision surfaces weeks later.

By which time one decision has been implemented.

The cost of unwinding it is no longer a governance conversation.

It is a delivery crisis.

---

## Failure Mode 3: Decision Gravity

All decisions pull upward.

Regardless of their actual altitude.

Library choice. Cloud provider. Platform build versus buy. API naming conventions.

All of them travel up the same chain.

The architecture board reviews things it should never see.

The CTO is asked to decide things a team lead should own.

Leadership becomes a bottleneck.

Not because they are unwilling to delegate.

Because nobody has defined what delegation actually means.

Decision gravity looks like slow governance.

It is an undefined rights structure.

---

# Technology Decision Domain Architecture (TDDA)

The solution is not a better escalation process.

The solution is a structured model that assigns decision rights before conflict requires them.

This model is called **Technology Decision Domain Architecture (TDDA).**

TDDA maps every class of technology decision to a defined altitude and domain.

It answers two questions simultaneously.

*At what altitude should this decision be made?*

*Within which domain does this decision belong?*

Once both are answered, the right decision authority is clear.

---

# The Two Axes

TDDA operates across two axes.

---

## Axis 1: Decision Altitude

Technology decisions exist at four altitudes.

| 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 |

The altitude tells you how wide the consequence of this decision reaches.

Enterprise-altitude decisions affect everyone.

Individual-altitude decisions affect almost no one beyond the person making them.

Most escalation failures happen because a team-altitude decision gets treated as enterprise-altitude — or an enterprise-altitude decision gets made without any governance at all.

---

## Axis 2: Decision Domain

Technology decisions also belong to a specific domain of concern.

| 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 |

A decision belongs to a specific altitude AND a specific domain.

Together, these two axes define the precise location of decision authority.

---

# The TDDA Decision Map

Combining both axes produces a decision map.

| | 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.

Not every altitude applies to every domain.

An individual engineer does not make investment decisions.

An enterprise architecture team does not decide variable naming conventions.

The map makes the authority visible.

And it makes the blanks visible too.

A blank where a cell should not be blank is a decision rights gap waiting to become a delivery failure.

---

# Identifying Decision Rights Gaps

Once the map exists, three gap types become visible.

---

### Gap 1: Altitude Mismatch

A decision is being made at the wrong altitude.

A team is making a vendor selection that should sit at enterprise altitude.

Or an architecture board is reviewing implementation approaches that belong at team altitude.

Altitude mismatch generates either ungoverned decisions or governance bottlenecks.

Both are expensive.

---

### Gap 2: Domain Vacancy

A decision domain has no assigned owner at any altitude.

Integration contract standards.

Data classification at domain level.

Security review ownership for new services.

These vacancies do not stay quiet.

They generate conflict at the moment a decision becomes necessary.

---

### Gap 3: Authority Overlap

Two owners share authority over the same cell in the map.

Both believe they have the right to decide.

Neither is wrong — the map was never drawn.

Authority overlap produces Decision Collisions.

The TDDA map makes overlaps visible before they produce incidents.

---

# What Breaks When This Is Ignored

When decision rights are undefined:

**Delivery stalls on decisions that should never have escalated.**

A team needs to choose between two logging frameworks. Both are acceptable. Neither is on an approved list. The decision goes to the architecture board. The architecture board has twelve items on its agenda. The team waits three weeks. The sprint is blocked. The reason recorded in the retrospective is "architecture process." The real reason is that nobody defined who owns this decision class.

**Parallel solutions appear without coordination.**

Two domains independently select different API gateway vendors. Both decisions were technically correct. Neither team had a mandate to inform the other. Six months later, enterprise architecture discovers two incompatible standards in production. The rationalization programme takes two years and costs more than either original selection.

**Governance looks broken even when it is working.**

Leadership is asked to decide too many things. They are not bad at governance. They are absorbing decisions that should never have reached them. The decision gravity makes governance feel slow. The real problem is that nobody has defined what should stay at team altitude.

When TDDA is in place:

The architecture board reviews enterprise-altitude decisions.

Not everything.

Domain teams make domain-altitude decisions confidently — without waiting for approval they were never supposed to need.

Delivery moves at the speed decisions actually require.

Governance stops being a bottleneck.

It becomes a guardrail.

---

# Implementation Guide (30–60 Days)

Building a decision rights architecture requires honesty more than technology.

The hardest part is naming who does not hold authority.

---

## Phase 1: Map the Current State (Weeks 1–2)

Identify the ten most common technology decision classes in your organization.

For each:

- What altitude does it currently reach before resolution?
- Who believes they hold authority to decide?
- How long does it typically take to resolve?

Do not design anything yet.

Document what actually happens.

**Deliverable:** Current-state decision inventory — ten decision classes with altitude, owner claim, and resolution time

**Success Metric:** At least three decision classes where two different parties claim ownership — these are the Decision Collisions waiting to happen

---

## Phase 2: Build the TDDA Map (Weeks 3–4)

Using the two axes, map each decision class to its correct altitude and domain.

For every cell in the map:

- Assign a named owner or authority body
- Mark cells that should be blank as intentionally vacant
- Highlight cells where current practice mismatches the correct altitude

Document every mismatch as a **Decision Rights Gap**.

**Deliverable:** First version of the TDDA map with gaps identified

**Success Metric:** At least one altitude mismatch, one domain vacancy, and one authority overlap identified and documented

---

## Phase 3: Operationalize the Model (Weeks 5–8)

Introduce the TDDA map as a standard governance artifact.

Add a decision rights check to every architecture review.

For each initiative: identify every decision class it will require, and confirm the authority owner before work begins.

Update the map quarterly.

Decision classes change as the organization changes.

The map must evolve with it.

**Deliverable:** TDDA map embedded in architecture governance cycle

**Success Metric:** At least two delivery decisions resolved without escalation because the authority was clear — and at least one escalation that should not have occurred, now prevented by the map

---

# Evidence from Practice

Organizations that build a TDDA map for the first time consistently find the same patterns.

The altitude mismatch count is higher than anyone expected.

Teams are making vendor decisions that should sit at enterprise altitude.

Architecture boards are reviewing implementation details that belong at team altitude.

Both believe they are doing the right thing.

Neither knows the other is compensating for the same undefined rights structure.

The domain vacancy findings produce a different discomfort.

Nobody owns integration contract standards at domain level.

Nobody owns data classification authority below enterprise level.

The vacancies were not designed.

They were inherited.

Nobody drew a map when the domains were defined, so the gaps were never visible.

The authority overlaps produce the most important conversations.

Two functions have been resolving the same class of decision independently for months.

Sometimes they reach the same answer.

Sometimes they do not.

Nobody knew both were deciding.

The TDDA map names the overlap.

Named gaps get resolved.

Unnamed gaps become production incidents.

---

# Action Plan

## This Week

Ask three questions:

1. Can you name the owner of every technology decision your most important initiative will require — before the initiative starts?
2. In your last architecture conflict, was the disagreement about the decision itself — or about who had the right to make it?
3. How many decisions reached your architecture board last quarter that should never have left team altitude?

If these answers are unclear, your organization has an escalation ladder.

Not a decision rights architecture.

---

## Next 30 Days

Select one delivery domain.

List the ten decision classes it encounters most frequently.

Map each to the correct altitude and domain using the TDDA model.

Identify every gap.

Document every overlap.

That map is your decision rights starting point.

---

## 3–6 Months

Extend TDDA across all delivery domains.

Embed a decision rights check into every new project initiation.

Every initiative should begin with a clear map of what decisions it will require — and who holds authority to make each one.

Governance becomes predictable when authority is legible.

Not when conflict forces it into the open.

---

# Final Thought

The ship waited at the channel entrance.

Not because nobody had authority.

Because both parties had assumed they did.

The harbourmaster owned that boundary.

The captain knew it.

The ship moved.

Technology decisions do not stall because organizations lack governance.

They stall because nobody drew the map that tells authority where it ends.

---

## Turn Your Escalation Ladder Into a Decision Rights Architecture

If your architecture board is reviewing decisions it should never see…
if delivery teams are waiting for approvals they were never supposed to need…
or if the same authority conflicts keep appearing in different projects under different names —

your organization may have an escalation process where a decision rights architecture should be.

In a focused 30-minute Technology Decision Rights Diagnostic, we will:

- Map the decision classes your organization encounters most frequently
- Identify altitude mismatches, domain vacancies, and authority overlaps in your current practice
- Introduce the TDDA model for your technology governance environment
- Define a 30-day plan to build a working decision rights map for your highest-priority domain

No governance theater.
No escalation redesigns that add committees instead of clarity.
No authority conversations postponed until delivery forces them.

Just a map that tells everyone where their authority ends — before the conflict begins.

→ **[Book an Architecture Strategy Session](https://calendly.com/naveen-innoventurex/free-consultation-with-naveen)**

or

→ **[Contact me directly](/contact)**

The ship knew its captain.

The harbour knew its master.

The boundary was the governance.

Why most enterprises confuse escalation ladders with decision rights — and how Technology Decision Domain Architecture maps exactly who decides what, at which altitude, before the conflict arrives.

Decision Rights for Technology — Who Decides What in a Modern Enterprise

Related Articles