There is a current state.
There is a target state.
And between them sits a transformation plan.
flowchart LR
C["Current State"] --> T["Transformation"]
T --> G["Target State"]
This is useful for describing direction.
It is less useful for understanding how organizations actually change.
Organizations do not remain passive while a transformation is implemented. Teams respond to new incentives. Managers reinterpret priorities. Platforms create new dependencies. Customers behave differently. Regulation changes. Local decisions alter the conditions assumed by the original plan.
The organization observes some of these effects and responds again.
Change creates behavior.
Behavior creates outcomes.
Outcomes create new information.
That information influences the next change.
A better model therefore looks less like a transition between two static states and more like a system with feedback.
An operating model does more than distribute work. It determines how the organization senses change, who can respond, which actions are available, and how quickly the consequences become visible.
In that sense, the operating model is part of the organization’s control system.
Consider a simple transformation.
An organization wants to reduce duplicated technology. Leadership establishes a strategic platform and asks product teams to migrate.
The intended transformation looks straightforward:
flowchart LR
F["Fragmented Platforms"] --> S["Standardization"]
S --> P["Shared Platform"]
But implementation changes the organization.
Product teams become dependent on the platform team.
The platform team receives more demand.
Its backlog grows.
Delivery times increase.
Product teams begin creating workarounds.
Architecture observes new fragmentation.
Management responds with stronger platform governance.
That changes team behavior again.
The transformation has become a feedback loop.
flowchart LR
T["Desired Outcome"] --> D["Decisions & Interventions"]
D --> O["Operating Model"]
O --> B["Organizational Behavior"]
B --> R["Observed Outcomes"]
R --> F["Feedback"]
F --> D
The target still matters.
But so does the mechanism through which the organization observes the difference between what it wanted and what actually happened.
Control theory provides a useful vocabulary for thinking about this.
The analogy should not be taken literally. Organizations are social systems, not machines. Their goals are ambiguous, people interpret signals, causality is difficult to isolate, and behavior itself changes in response to measurement.
But the analogy exposes something that static operating-model diagrams often hide: feedback, delay, response, and adaptation.
A simplified mapping might look like this:
| Control system | Organization |
|---|---|
| Reference / setpoint | Desired outcome or strategic direction |
| Controller | Governance and decision mechanisms |
| Plant | Operating organization |
| Control input | Decisions, priorities, funding, policies, guardrails |
| Output | Actual organizational outcomes |
| Sensor | Metrics, observations, customer feedback |
| Disturbance | Markets, regulation, incidents, competitors |
| Feedback | Learning that influences subsequent decisions |
The interesting part is not whether every control-theory term maps perfectly.
It does not.
The useful question is what the analogy reveals about organizational design.
Some transformations are effectively operated as open-loop systems.
Leadership establishes a target state.
A program defines the activities required to reach it.
The organization executes the plan.
flowchart LR
T["Target State"] --> P["Transformation Plan"]
P --> E["Execution"]
E --> R["Expected Result"]
The underlying assumption is that sufficiently good planning will produce the intended outcome.
Feedback may exist through status reports, steering committees, milestones, and project metrics, but much of it answers:
Are we executing the plan?
rather than:
Is the system responding as we expected?
Those are different questions.
A platform migration can be 80 percent complete while creating dependencies that make product delivery slower.
A reorganization can be completed on schedule while leaving decision authority less clear than before.
A new governance process can achieve 100 percent compliance while increasing lead time without materially reducing risk.
Execution evidence tells us whether the intervention happened.
It does not necessarily tell us whether the intervention produced the desired system behavior.
A closed-loop view treats the transformation as a hypothesis.
We intervene.
We observe what happens.
We compare the outcome with what we intended.
Then we adjust.
flowchart TD
T["Desired Outcome"]
T --> C["Change"]
C --> O["Observe"]
O --> E["Evaluate"]
E --> A["Adjust"]
A --> C
This does not mean abandoning strategic direction whenever a metric moves.
It means acknowledging that the relationship between organizational intervention and organizational outcome is uncertain.
The target provides direction.
Feedback provides information.
Decision rights determine who can respond.
The operating model determines how quickly that response can happen.
Organizations often invest heavily in sensing mechanisms.
Dashboards.
Employee surveys.
Customer metrics.
Architecture assessments.
Operational telemetry.
Risk reports.
Retrospectives.
These improve visibility.
But sensing is only one part of a control system.
Suppose a platform team sees that its lead time has doubled because demand from product teams has increased dramatically.
The information is available.
But the team cannot increase capacity, change its service model, reject demand, alter priorities, or delegate capabilities to product teams.
The organization has successfully detected the problem.
It has not created an effective feedback loop.
Feedback without authority is just information.
For feedback to change organizational behavior, someone must have both the responsibility and the authority to act on it.
This connects operating-model design directly to decision rights.
A feedback loop needs more than measurement.
For an organizational feedback loop to work, several things need to connect:
flowchart LR
O["Outcome"] --> S["Sense"]
S --> I["Interpret"]
I --> D["Decide"]
D --> A["Act"]
A --> M["Measure Effect"]
M --> S
Start with the behavior or outcome the organization is trying to influence.
Not:
Adopt the shared platform.
But:
Reduce the cost and lead time of delivering integrations without increasing operational risk.
The distinction matters because platform adoption is an intervention. It is not necessarily the desired outcome.
If the organization measures only adoption, it can successfully execute the transformation while making the underlying system worse.
The organization needs signals that reveal whether the system is moving in the intended direction.
For a shared platform, these might include delivery lead time, platform demand, reliability, exceptions, workarounds, adoption, support load, and product-team dependency.
No individual measure describes the system.
Together they provide signals about its behavior.
A signal does not explain itself.
An increase in platform exceptions could mean that teams are avoiding standards.
It could also mean that the platform is missing an important capability.
The people interpreting the signal therefore need enough context to distinguish symptoms from causes.
This is where qualitative feedback matters alongside metrics.
Someone must be able to respond.
If everyone can observe a problem but nobody can change priorities, funding, guardrails, platform capabilities, or decision rights, the loop remains open.
flowchart LR
S["Signal"] --> I["Interpretation"]
I --> D{"Authority?"}
D -->|"Yes"| A["Action"]
D -->|"No"| E["Escalation"]
E --> A
The escalation path is part of the feedback loop, not an exception to it.
When the organization responds, it should be possible to distinguish the intervention from the outcome.
For example:
Platform lead time is increasing.
The organization decides to introduce self-service provisioning.
That creates a testable relationship:
flowchart LR
P["Observed Problem"] --> H["Hypothesis"]
H --> I["Intervention"]
I --> O["Observed Outcome"]
O --> E["Evaluate"]
E -->|"Adjust"| H
Now the organization can ask whether self-service actually reduced lead time rather than simply recording that self-service was delivered.
The feedback interval should reflect how quickly the system can reasonably respond.
Operational metrics may provide useful feedback within hours.
A platform change may take weeks.
A change in decision rights may take months before its effects become visible.
Reacting faster than the system can respond creates noise and encourages overcorrection.
The cadence of governance should reflect the response time of the system being governed.
A useful feedback-loop design can therefore be summarized as:
| Element | Question |
|---|---|
| Outcome | What are we actually trying to change? |
| Signal | What tells us whether it is happening? |
| Interpretation | Who can understand what the signal means? |
| Authority | Who can respond? |
| Action | What can they change? |
| Delay | When should we expect an effect? |
| Learning | How does the result change the next decision? |
A feedback loop is therefore not a dashboard, a retrospective, or a governance meeting. Those may be components of one.
The loop only closes when observation can lead to an authorized intervention, the consequences of that intervention can be observed, and what is learned influences the next decision.
One of the most important properties of a control system is delay.
Organizations contain enormous amounts of it.
A decision is made today.
Teams interpret it over the following weeks.
Funding changes next quarter.
People are recruited.
Systems are migrated.
New behaviors emerge.
Customers eventually experience the result.
Metrics finally reveal whether the intervention worked.
The feedback loop may take months.
This creates a dangerous temptation.
When the expected result does not appear quickly enough, another intervention is introduced.
Then another.
Consider a familiar cycle:
flowchart TD
A["Teams are inconsistent"]
B["Centralize decisions"]
C["Delivery becomes slower"]
D["Increase team autonomy"]
E["Fragmentation increases"]
F["Strengthen governance"]
G["Teams become dependent on approvals"]
H["Decentralize decisions"]
A --> B
B --> C
C --> D
D --> E
E --> F
F --> G
G --> H
H --> A
Each intervention may be understandable.
Together they can produce oscillation.
The organization keeps correcting itself without allowing enough time to understand the effect of the previous correction.
Organizations can become unstable when the rate of intervention exceeds the rate at which the effects of previous interventions can be observed.
This is one reason repeated reorganizations can be so disruptive.
The organization may still be adapting to the previous operating model when the next one arrives.
When outcomes move away from expectations, organizations often respond by increasing control.
More governance.
More reporting.
More approvals.
More standards.
More centralization.
This may reduce variation.
It may also create new delays and dependencies.
Imagine that architecture quality varies significantly between teams.
One response is to require central architecture approval for every significant design.
Initially, consistency may improve.
But the central function now receives more decisions.
Queues grow.
Teams wait.
Architects become involved earlier because teams fear late rejection.
Eventually even relatively local decisions begin flowing through the central function.
The attempt to increase control has changed the dynamics of the system.
More intervention has not necessarily created better control.
It may simply have increased the gain of the controller.
Modern organizations rarely have one controller.
They have many.
Product teams optimize customer outcomes and delivery speed.
Platform teams optimize reliability, reuse, and standardization.
Security functions optimize exposure and control effectiveness.
Finance optimizes cost and capital allocation.
Operations optimizes stability.
Architecture optimizes coherence and long-term optionality.
Each can behave rationally from its own perspective.
flowchart TD
EO["Enterprise Outcomes"]
P["Product<br/>Delivery"]
PL["Platform<br/>Standardization"]
S["Security<br/>Risk"]
F["Finance<br/>Cost"]
O["Operations<br/>Stability"]
A["Architecture<br/>Coherence"]
P --> EO
PL --> EO
S --> EO
F --> EO
O --> EO
A --> EO
The problem is that locally sensible control loops can interact.
A product team optimizes lead time by bypassing a shared platform.
Architecture responds to fragmentation by introducing stronger standards.
The platform team responds to demand by limiting supported use cases.
Product teams create more exceptions.
Governance responds with an exception process.
Every participant may be behaving rationally.
The system-level result may still be poor.
This is why organizational optimization cannot be reduced to making every individual function more effective at achieving its own objectives.
The interactions matter.
Measurement is not passive either.
Once a metric influences decisions, people respond to the metric.
If teams are measured primarily on delivery speed, they may avoid work whose benefits appear elsewhere.
If a platform team is measured on availability, it may resist changes that increase operational uncertainty.
If architecture is measured on standards compliance, it may optimize for conformity rather than business outcomes.
If transformation is measured on migration completion, teams may technically migrate while preserving old structures underneath.
The sensor has begun influencing the system it is observing.
This makes organizational feedback fundamentally different from measuring temperature in a room.
People interpret measurement.
They anticipate consequences.
They adapt behavior.
The design of metrics is therefore part of the operating model itself.
Transformation plans often implicitly assume a relatively stable environment.
Reality provides disturbances.
A competitor launches a new product.
Regulation changes.
A major customer leaves.
An acquisition introduces another technology landscape.
A security incident changes risk tolerance.
A supplier changes pricing.
AI changes the economics of software delivery.
These are not exceptional events outside the operating model.
Responding to them is one of the reasons the operating model exists.
A resilient operating model therefore needs more than an optimized target structure.
It needs the ability to detect meaningful change and adapt without requiring the entire organization to be redesigned each time the environment moves.
This also provides another way to understand the difference between gates and guardrails.
A gate controls individual decisions directly:
flowchart LR
D["Decision"] --> A["Approval"]
A --> X["Action"]
A guardrail changes the conditions under which decentralized decisions can be made:
flowchart LR
G["Guardrails"] -.-> D["Local Decision"]
T["Team"] --> D
D --> A["Action"]
A --> E["Evidence"]
E -.-> G
The first mechanism depends on central intervention.
The second attempts to shape local behavior while preserving local control.
Neither is always correct.
High-risk, irreversible decisions may justify explicit approval.
Frequent, reversible decisions usually benefit from being made closer to the relevant information.
The operating-model question is therefore not simply:
Should we centralize or decentralize?
It is:
Which feedback loops need central authority, and which can safely close locally?
Architecture is often described through artifacts.
Principles.
Target architectures.
Standards.
Roadmaps.
Decision records.
These matter.
But architecture also participates in organizational feedback.
Architects observe recurring local decisions and identify patterns.
They see when several teams solve the same problem independently.
They identify when a platform creates unintended dependencies.
They notice when an exception is becoming a de facto standard.
They connect local behavior to consequences that may only become visible elsewhere.
That information can influence guardrails, platform capabilities, investment priorities, and decision rights.
flowchart LR
LD["Local Decisions"] --> O["Observed Patterns"]
O --> A["Architecture"]
A --> G["Guardrails & Direction"]
G --> LD
Architecture therefore does not need to control every decision to influence the system.
Its value may be greater when it improves the quality of the feedback loop.
An operating model is often described through organizational structures, roles, processes, capabilities, governance, and technology.
Those elements also determine how feedback moves.
For any important organizational outcome, we can ask:
| Question | Operating-model implication |
|---|---|
| What are we trying to achieve? | Strategic direction |
| What can we observe? | Metrics and sensing |
| Who interprets the signal? | Accountability |
| Who can respond? | Decision authority |
| What actions are available? | Capabilities and guardrails |
| How quickly can action occur? | Organizational latency |
| When do we escalate? | Governance |
| How do we know whether it worked? | Feedback |
This provides another lens for operating-model design.
Do not only map who performs the work.
Map how the organization senses, decides, acts, and learns.
The goal of an operating model should not be to eliminate variation or continuously force the organization toward a perfectly defined state.
Organizations operate in environments that change faster than any target model can remain accurate.
The stronger design objective is therefore adaptability.
Can teams detect problems close to where they occur?
Can they act without unnecessary escalation?
Are enterprise consequences visible when local decisions create wider effects?
Can authority move when the scope of a decision changes?
Can feedback alter guardrails without requiring a complete governance redesign?
Can the organization distinguish a temporary disturbance from a structural change?
These properties determine whether the organization can continuously correct itself without constantly reorganizing.
A target operating model describes a desired arrangement.
It does not explain how that arrangement will respond when reality differs from the assumptions used to design it.
That requires feedback.
Organizations continuously sense their environment, make decisions, observe consequences, and respond again.
Sometimes the loops are explicit.
Often they are not.
Poorly designed loops create delays, hidden dependencies, overcorrection, conflicting local optimization, and repeated organizational oscillation.
Well-designed loops allow decisions to happen close to relevant knowledge while still making wider consequences visible.
The operating model therefore does more than determine where responsibilities sit.
It determines how the organization senses change, who can respond, what they are allowed to change, and how quickly the organization can learn from the result.
In that sense:
]]>The operating model is a control system.
A strategy is agreed. A target operating model is designed. Platforms are consolidated. Responsibilities move. New ways of working are introduced.
From the transformation program’s perspective, these changes may form one coherent journey from current state to target state.
But the people involved do not experience the transformation from the perspective of the program.
They experience it from where they stand.
An executive may see strategic simplification. An architect may see reduced fragmentation. A platform team may see greater responsibility. A product team may see another dependency. An engineer may see constraints on choices that were previously local.
They are participating in the same transformation.
They are not necessarily experiencing the same change.
A transformation may be one initiative on a roadmap, but it is not one change. Every role experiences a different transformation.
This matters because what organizations describe as resistance may sometimes be a rational response to how the transformation redistributes authority, accountability, capability, dependency, risk, and incentives.
Understanding that difference does not mean avoiding difficult change.
It means understanding the change we are actually asking people to make.
Consider an organization that wants to replace several locally managed integration solutions with a shared integration platform.
The enterprise case may be compelling:
From an enterprise perspective, the direction appears straightforward.
flowchart LR
A["Fragmented Integration Landscape"]
B["Shared Integration Platform"]
A --> B
But this diagram hides most of the transformation.
For technology leadership, the change may mean reducing fragmentation and improving control.
For architecture, it may mean establishing clearer patterns and boundaries.
For the platform team, it may mean becoming responsible for a service that many more teams depend on.
For a product team, it may mean replacing technology it already understands with a platform it does not control.
For developers, it may mean learning new tooling and giving up implementation choices that were previously local.
For operations, it may introduce new concentration risk.
For finance, the organization may incur migration and platform costs long before consolidation produces savings.
The target architecture is the same.
The transformation is not.
Architecture is good at describing structural change.
Current-state and target-state views can show which applications disappear, which platforms become strategic, where responsibilities move, and which capabilities should become shared.
Those views are necessary.
But they can make transformation appear cleaner than it is.
Current State
↓
Transition
↓
Target State
The middle box contains much of the actual organizational change.
Teams may need to maintain old and new platforms simultaneously. Someone must perform migrations that produce little immediate product value. Responsibilities may move before capabilities are ready. People may need to learn new skills while continuing to deliver existing commitments.
A target state describes where the organization wants to arrive.
It does not automatically describe what the journey means for everyone required to get there.
When transformation becomes difficult, resistance is a tempting explanation.
The teams don’t want to change.
Sometimes that may be true.
But the label can also hide useful information.
Suppose a product team resists migrating to the shared integration platform.
From the transformation program’s perspective, the team is delaying standardization.
From the team’s perspective, the situation may look different.
Their current solution works.
Their roadmap contains customer commitments.
The migration consumes capacity without creating an immediate customer outcome.
The new platform introduces a dependency on another team.
And after migration, they may remain accountable for their product while having less control over one of the components required to operate it.
Resistance in that situation is not difficult to explain.
Resistance can be evidence of a mismatch between the transformation’s intended benefits and its distributed consequences.
That does not mean the migration should be cancelled.
Enterprise benefits sometimes justify local costs.
But those costs should be visible rather than interpreted simply as unwillingness to change.
A transformation changes more than technology and processes.
It can redistribute several things simultaneously.
What becomes better from this role’s perspective?
An enterprise platform may reduce total organizational cost while providing little direct benefit to the first product team required to migrate.
Benefits that are obvious at one level may be invisible at another.
What can the role decide before and after the transformation?
Standardization often deliberately moves decisions.
A team that previously selected its own integration technology may now need to work within platform guardrails.
That may be the correct architectural direction.
It is still a reduction in local decision authority.
What outcomes must the role answer for?
A platform team may gain responsibility for a strategically important capability without receiving enough capacity, mandate, or operational support to provide it reliably.
Transformation can therefore create the same problem that appears elsewhere in governance:
Accountability without sufficient authority.
What must the role learn, build, or stop doing?
A transformation may require new engineering practices, domain knowledge, operating capabilities, vendor-management skills, or leadership behaviors.
A box moving on an operating-model diagram can represent months of capability development for the people inside it.
Who does the role become more or less dependent on?
Centralization can reduce duplication while increasing dependency.
A shared platform may simplify the enterprise landscape while making twenty product teams dependent on one platform team’s priorities and reliability.
That is not necessarily an argument against the platform.
It is an architectural consequence that needs to be designed for.
Does the transformation align with how the role is measured?
A product team may be measured on product outcomes while being asked to spend significant capacity on an enterprise migration.
The enterprise receives the benefit.
The team absorbs the cost.
If incentives remain local while transformation benefits are enterprise-wide, resistance should not be surprising.
These perspectives can be turned into a simple lens.
For any role materially affected by a transformation, ask:
| Lens | Question |
|---|---|
| Outcome | What becomes better or worse from this role’s perspective? |
| Authority | What decisions does this role gain or lose? |
| Accountability | What outcomes will this role now answer for? |
| Capability | What must this role learn, build, or stop doing? |
| Dependency | Who does this role become more or less dependent on? |
| Incentive | Does the change align with how this role is measured and rewarded? |
flowchart TD
T["Transformation"]
T --> O["Outcome"]
T --> AU["Authority"]
T --> AC["Accountability"]
T --> C["Capability"]
T --> D["Dependency"]
T --> I["Incentive"]
The purpose is not to create another stakeholder template.
It is to change the question.
Instead of asking:
How do we convince this stakeholder?
Ask:
What transformation are we actually asking this stakeholder to undergo?
The difference matters.
The first question assumes the transformation is understood and the remaining problem is adoption.
The second allows the transformation itself to be examined.
Transformations often create disagreements where both sides have legitimate arguments.
Architecture may say:
We need one strategic integration platform to reduce fragmentation.
A product team may say:
Moving to that platform will make our delivery dependent on another team’s roadmap.
Both can be correct.
Leadership may say:
Consolidation will reduce operating cost.
Operations may say:
Consolidation also concentrates operational risk.
Both can be correct.
A platform team may say:
Standardization allows us to provide better self-service capabilities.
Developers may say:
Standardization removes flexibility we currently use to solve local problems.
Again, both can be correct.
The purpose of architecture and transformation leadership should not be to make these tensions disappear rhetorically.
It should be to make them explicit enough to decide which trade-offs the organization is willing to make.
One of the harder realities of transformation is that not every participant has to benefit equally.
Sometimes an organization should deliberately make something harder locally because doing so creates greater value elsewhere.
A team may lose freedom to select technology because the organization needs fewer technologies to operate.
A business unit may lose a customized process because a common process enables shared capabilities.
A platform team may accept greater responsibility because centralizing a capability reduces duplication across dozens of teams.
The mistake is not necessarily creating these asymmetries.
The mistake is pretending they do not exist.
If a transformation creates enterprise value by imposing local cost, that cost should be recognized, funded, prioritized, and governed accordingly.
Otherwise the organization effectively asks one part of the system to subsidize another while describing its reluctance as resistance.
There is another reason to take resistance seriously.
Sometimes it reveals a flaw in the transformation itself.
A security team may identify that consolidation creates unacceptable concentration risk.
A product team may expose that the proposed platform cannot support an important customer need.
Operations may discover that the target architecture lacks a workable recovery model.
An engineer may know that a supposedly obsolete component supports behavior absent from the replacement.
Treating every objection as something to overcome removes an important feedback mechanism.
The goal should therefore not be zero resistance.
It should be the ability to distinguish between:
Preference
Constraint
Local optimization
Missing capability
Misaligned incentive
Unmanaged risk
Structural problem
Some should be challenged.
Some should be accommodated.
Some should change the transformation.
Many transformations implicitly change who gets to decide.
Moving from independent product technologies to shared platforms changes technology decision rights.
Creating common data ownership changes who can define information.
Centralizing procurement changes vendor authority.
Introducing product-oriented operating models changes prioritization and funding decisions.
Yet these changes are often presented primarily as process or technology changes.
That can leave the new decision model ambiguous.
A team is told it remains autonomous but discovers that several previously local decisions now belong to a platform, domain, security function, or enterprise authority.
The organizational chart may barely change.
The decision architecture has changed substantially.
This is why transformation and decision rights cannot be treated separately.
If authority is being redistributed, that redistribution should be explicit.
Architecture has an important role in transformation, but it should not own every aspect of the change.
Architects can make structural consequences visible.
They can identify new dependencies, changing boundaries, duplicated capabilities, concentration risks, transitional states, and decisions that move between organizational levels.
They can also expose when a target architecture requires an operating-model change that has not yet been acknowledged.
But architecture should be careful not to confuse architectural coherence with organizational feasibility.
A better target architecture does not make its consequences insignificant.
A shared platform may still be the right answer even if teams dislike migrating to it.
The architectural contribution is to make the trade-off visible: what improves, what becomes constrained, where dependencies move, and which new capabilities are required.
The organization can then make the decision deliberately.
This leads to a broader view of transformation.
Transformation is not simply moving an organization from one designed state to another.
Changing one part of the organization changes the conditions experienced by others.
flowchart LR
A["Authority"] --> D["Dependencies"]
D --> C["Capabilities"]
C --> I["Incentives"]
I --> B["Behavior"]
B --> A
Centralizing a decision may create a new dependency.
The dependency may require a new platform capability.
The platform capability may change team incentives.
Those incentives may change behavior.
The changed behavior may eventually require another adjustment to authority.
Transformation is therefore less like installing a new organizational design and more like changing a system whose parts respond to one another.
The target state matters.
So do the responses created on the way there.
Transformation is often communicated as a common journey toward a shared destination.
The destination may be shared.
The journey is not.
Different roles experience different changes in authority, accountability, capability, dependency, incentives, workload, and risk.
Some will gain autonomy.
Others will lose it.
Some will receive new capabilities.
Others will become responsible for providing them.
Some will see benefits immediately.
Others may carry costs whose benefits appear somewhere else in the organization.
That does not make transformation impossible.
It makes perspective part of the architecture of change.
Resistance should therefore not automatically be treated as something to overcome. It can provide information about consequences that the transformation has not yet made visible.
The useful question is not only:
Why won’t they change?
It is:
]]>What does this change actually mean from where they stand?
A product team introduces a local data store because the shared platform cannot meet a delivery date. Management funds a customer-facing capability but postpones the supporting platform work. Security mandates a control after an incident. A business owner accepts a resilience risk to avoid delaying a launch.
None of these decisions may appear in an architecture repository. Yet each can create dependencies, boundaries, standards, and constraints that remain long after the immediate problem has passed.
Architecture is usually documented through systems, platforms, integrations, capabilities, and target states. These views are useful, but they mainly show what exists. They rarely show who had the authority to create it, who accepted the trade-offs, or who can change it now.
By decision architecture, I mean how authority, involvement, accountability, escalation, and organizational memory are distributed around consequential decisions.
Explicit decision rights clarify who can decide, who must contribute, who is accountable for the outcome, and where a decision goes when it exceeds the current mandate.1
Every architecture reflects a history of decisions.
Some were deliberate and carefully governed. Others were made locally to meet a deadline, recover from an incident, satisfy a customer, or work around a constraint.
A team may introduce a second customer record because the existing source is slow to change. The temporary solution works, the product ships, and the workaround gradually becomes part of the operating model. Two years later, several teams depend on it and nobody is certain who can retire it.
Over time, decisions like these determine which platforms become shared, which technologies remain supported, where data ownership sits, and which dependencies teams have to live with.
They also raise questions that diagrams alone cannot answer:
Not every decision involving technology is architecturally significant. Choosing between two supported test libraries is different from introducing a new identity provider or creating another source of truth for customer data.
A decision becomes architecturally significant when it creates consequences beyond the immediate task. It may establish a long-term dependency, affect several teams, change an important boundary, introduce material risk, create a precedent, or become difficult and expensive to reverse.
Governance should reflect those consequences, not simply the fact that technology is involved.
The wider the impact and the harder the decision is to reverse, the more explicit its decision authority should be.
Organizations often claim to have autonomous teams.
In practice, a team planning a new integration may not know who can stop the work. Nobody has formally asked for five approvals, but the team often seeks them anyway because it does not know whose objection could appear later.
When decision rights are unclear, teams search for informal approval, wait for the next forum, or seek agreement from everyone who might object later.
The formal gate may have disappeared.
The hidden gate remains.
Organizations often blur different forms of involvement.
An architect may recommend a solution without holding final decision authority. A security specialist may identify a risk without being authorized to accept it. A Product Owner may prioritize delivery without being able to override enterprise policy. A manager may approve funding without deciding the technical design.
These distinctions matter:
| Decision role | Meaning |
|---|---|
| Advise | Provide expertise or options |
| Consult | Give input before a decision |
| Recommend | Propose a preferred direction |
| Approve | Confirm that a proposal meets defined conditions |
| Decide | Select the course of action |
| Accept risk | Formally accept residual exposure within delegated authority |
| Execute | Implement the decision |
| Be accountable | Own the outcome and answer for the consequences |
Consider a team proposing a new authentication flow. Security may advise on threats, architecture may recommend a shared identity pattern, and the product team may explain the customer impact. If security can reject the proposal, however, it is not only advising. It holds approval authority for that part of the decision.
Problems emerge when one role believes it is giving input while another believes it is granting permission.
Approval authority is itself a form of decision authority because an approver can prevent the proposed course of action. It should therefore be assigned as deliberately as final decision authority.
Organizations sometimes make people accountable for outcomes without giving them sufficient authority.
A Product Owner may be accountable for product outcomes but unable to influence platform priorities. An architect may be expected to reduce duplication but have no mandate to challenge competing investments. A delivery team may own reliability targets while being required to use a platform whose roadmap and service levels it cannot influence.
The reverse is equally problematic. A forum may approve a design and then disappear from the consequences.
The architecture board approved the design.
That statement explains how the proposal passed a checkpoint. It does not tell us who owns the operational risk, who funds remediation, or who answers when the design fails to support the business outcome.
Approval cannot be treated as a harmless administrative step. It changes what can happen and therefore carries decision authority.
Authority, influence, and accountability will rarely align perfectly, but large gaps between them should be visible and deliberate. Accountability without authority creates helplessness, while authority without accountability creates careless governance.
Not every decision belongs to the same role or forum.
A team should normally be able to choose how it structures an internal component. A domain-level decision may be needed when several products must agree on how customer consent is represented. Selecting a new enterprise identity provider is broader still because it affects security, integration, cost, migration, and future product choices.
The right level depends on scope, reversibility, risk, cost, strategic importance, regulatory impact, and the number of teams affected.
Decisions should be made at the lowest responsible level where sufficient context, competence, authority, and accountability exist.
That is not the same as pushing every decision downward. A team may understand its immediate problem better than anyone else while still lacking visibility into wider consequences.
Decision rights should therefore be placed close to the relevant knowledge while authority and control mechanisms remain aligned.2
For every consequential decision, five questions should be explicit:
flowchart TD
Decision["Consequential Decision"]
Significance["Significance"]
Authority["Authority"]
Involvement["Involvement"]
Escalation["Escalation"]
Memory["Memory"]
Decision --> Significance
Decision --> Authority
Decision --> Involvement
Decision --> Escalation
Decision --> Memory
The examples below show how decision rights change with scope and consequence.
Most delivery teams should be free to decide how to structure code, implement tests, refactor components, and choose between supported technologies.
A team choosing between two approved logging libraries should not need an enterprise forum. A team introducing a new event-streaming platform because the existing one is inconvenient is making a different kind of decision. The second choice may create new operational skills, support obligations, security controls, and integration patterns for other teams.
A useful distinction is:
| Situation | Typical treatment |
|---|---|
| Choose between supported libraries | Local team decision |
| Select a database from the approved technology catalog | Local decision within guardrails |
| Use an unsupported database for a specific need | Exception with explicit conditions |
| Introduce a new strategic cloud or integration platform | Enterprise-level decision |
Product authority concerns customer and business outcomes: which problem to solve, which trade-off to make, what enters the roadmap, and what can wait.
Suppose a Product Manager wants to introduce automated cancellation to reduce service costs. The product decision belongs with product leadership, but the choice may also affect billing, customer data, legal obligations, and contact-center processes. Architecture should expose those consequences without taking ownership of the product backlog.
When a product choice conflicts with enterprise guardrails or creates dependencies outside the product boundary, consultation or escalation becomes necessary.
Some architectural decisions are too broad for a single product but do not automatically require enterprise-level authority.
Three customer-facing products may, for example, use different definitions of an “active customer.” Each definition works locally, but the differences create problems for reporting, service, and integration. Resolving the meaning, ownership, and authoritative source is a domain-level decision because the consequences cross product boundaries.
Other decisions create wider and more durable commitments. Selecting an enterprise identity provider, adopting a strategic platform, establishing technology lifecycle policy, or approving an exception that others may use as a precedent can affect several domains and constrain future choices.
The distinction is mainly one of scope.
Final authority may still sit with technology leadership, management, an investment forum, or another explicitly authorized body. Architecture should make the consequences visible and help place the decision with the role that can actually stand behind it.
Security functions may define mandatory controls, identity requirements, approved cryptographic methods, and logging obligations. Delivery teams implement them, while security or assurance functions may verify compliance.
Risk acceptance is a different decision.
Consider a service that does not meet the required recovery-time objective. The team can explain the implementation, operations can estimate recovery time, architecture can describe dependencies, and security or resilience specialists can assess exposure. None of those roles should automatically accept the remaining business risk.
| Responsibility | Typical role |
|---|---|
| Define mandatory controls | Security or resilience function |
| Implement controls | Delivery team |
| Verify compliance | Security or assurance function |
| Explain architectural consequences | Architecture |
| Fund remediation | Product or management |
| Accept residual business risk | Authorized risk owner |
The risk owner must decide whether the remaining exposure is acceptable within the delegated mandate.
Established risk-management guidance makes a similar distinction between specialist assessment and accountable risk-based decision-making.3
Platform teams need enough authority to operate their services as products. They should normally control the platform roadmap, supported capabilities, service levels, upgrade strategy, deployment patterns, and self-service interfaces.
A delivery team using the platform should decide how to build within those boundaries.
Tension appears when a platform team makes an enterprise strategy decision through its backlog. For example, it may deprecate a capability used by twenty teams because maintaining it is inconvenient, or add a new vendor service that creates a long-term licensing commitment.
Operating a platform does not automatically grant authority over enterprise platform strategy.
Some decisions cannot be made responsibly from a single perspective.
Selecting a strategic platform may require business leadership to explain the outcome, product teams to describe demand, architecture to assess dependencies, security to evaluate exposure, finance to test the economics, procurement to examine the contract, and operations to assess supportability.
This is where organizations often confuse participation with authority. Because many people need to contribute, the decision gradually becomes something that “the group” owns. Meetings continue, concerns accumulate, and nobody is quite sure who can bring the discussion to a close.
A shared process still needs an explicit decision authority. That authority may sit with an individual or a formally mandated body, but participants should understand where input ends and the decision begins.
Approaches such as EDGY can help participants examine the same enterprise through complementary perspectives of identity, experience, and architecture.4 This improves shared understanding, but it does not replace authority or accountability.
Autonomy becomes real when teams know what they can decide without asking permission.
A newly formed team may be told that it owns a service end to end. In its first month, however, it discovers that database choices need architecture approval, production access depends on operations, security exceptions go to a monthly forum, and API changes require agreement from an owner nobody can identify.
The team is accountable, but it is not autonomous.
Teams need to know which decisions are theirs, which guardrails apply, when consultation or approval is required, how to request an exception, who can accept risk, and where uncertainty should be escalated.
Without that clarity, teams either wait unnecessarily or act locally and create wider problems.
Escalation is sometimes treated as a failure. It is not.
A team may have authority to select technology from an approved catalog but discover that none of the supported options meets a regulatory requirement. Escalation is the correct response because the decision exceeds the team’s mandate.
A useful escalation path defines the trigger, destination, required information, final authority, expected response time, and how the outcome becomes visible to others.
flowchart TD
Team["Team Authority"]
Domain["Domain or Shared Authority"]
Enterprise["Enterprise Authority"]
Risk["Authorized Risk Owner"]
Team -->|"Cross-product impact"| Domain
Domain -->|"Cross-domain or strategic impact"| Enterprise
Team -.->|"Risk above local threshold"| Risk
Domain -.->|"Risk above domain threshold"| Risk
Enterprise -.->|"Material residual risk"| Risk
Risk acceptance does not always need to pass through an enterprise-level authority. It should sit at the level defined by the organization’s risk thresholds and delegation model.
Escalation should be predictable. It should not depend on who knows whom.
Clear decision rights should be complemented by decision records.
Architecture Decision Records provide one lightweight mechanism for preserving architecturally significant decisions, their context, and their consequences.5
A decision record should normally identify the decision, authority, context, alternatives, trade-offs, consulted roles, conditions, and review point.
This matters because temporary decisions have a habit of becoming permanent.
A team may receive a six-month exception to use an unsupported database while a platform capability is developed. Two reorganizations later, the platform work has disappeared, the exception has no owner, and new teams assume the database is an approved standard.
Without organizational memory, exceptions turn into precedent and old discussions are repeatedly reopened.
Decision records create continuity and make governance easier to audit, learn from, and improve.
Lightweight review, exception, and decision-record practices are also included in the Architecture Review & Governance Toolkit.
A decision model should not live only in governance documentation. It should be visible where work happens: product playbooks, team onboarding, platform documentation, technology catalogs, exception processes, architecture repositories, and decision records.
A simple table can remove more ambiguity than another governance forum:
| Decision | Decision authority | Required input | Execution |
|---|---|---|---|
| Product backlog priority | Product Owner | Delivery team and architect when relevant | Delivery team |
| New domain integration pattern | Domain authority | Product teams, security, and platform teams | Delivery teams |
| Enterprise platform introduction | Authorized management body | EA, security, finance, procurement, and operations | Platform organization |
| Local implementation detail | Delivery team | Specialist advice when needed | Delivery team |
| Material risk exception | Authorized risk owner | Security, architecture, legal, and business stakeholders | Responsible delivery organization |
Residual risk should be accepted separately by the authorized risk owner whenever it exceeds the decision-maker’s delegated threshold.
Decision rights are not permanent.
A central architecture function may initially approve every cloud design because teams lack experience and the platform is immature. Later, standard landing zones, automated controls, documented patterns, and stronger team competence may allow most designs to become local decisions.
The movement can also go in the other direction. A product team may initially control its own customer data model. Once several products depend on the same information, domain-level ownership may become necessary.
The question is not whether centralization or decentralization is inherently better. The question is whether the current placement of authority matches organizational capability and the consequences of the decision.
Centralization is more defensible when risk is high, expertise is scarce, coordination is weak, or decisions are difficult to reverse. Decentralization becomes safer when guardrails are clear, platforms encode preferred patterns, teams have sufficient competence, and local choices have limited wider impact.
Uncertainty often gets redirected to architects. They should not become the default owners of every uncertain decision. Their contribution is more valuable when they identify architecturally significant choices, expose wider consequences, establish principles and guardrails, facilitate cross-boundary discussions, create escalation paths, and preserve decision context.
Architecture is also shaped by product priorities, platform capabilities, mandatory controls, contractual commitments, and local delivery choices.
The purpose of a strong architecture function is not to own every decision. It is to help the organization make consequential decisions with clearer authority, better context, and fewer hidden dependencies.
Architecture diagrams describe structures. They do not show the negotiations, trade-offs, mandates, exceptions, and risk decisions that allowed those structures to emerge.
When authority is unclear, teams wait or search for informal approval. Forums become hidden gates. People may be held accountable for outcomes they cannot influence, while others exercise authority without carrying the consequences.
Clear decision rights do not eliminate disagreement, uncertainty, or poor decisions. They make it easier to see where a decision belongs, who needs to contribute, when it should escalate, and who must ultimately stand behind it.
Architecture is shaped not only through formal architecture work, but through the decisions an organization repeatedly permits, constrains, escalates, and records.
Who decides shapes the architecture.
The following articles explore adjacent questions about architecture, authority, governance, and organizational decision-making.
Peter Weill and Jeanne W. Ross, IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Harvard Business School Press, 2004. ↩
Michael C. Jensen and William H. Meckling, “Specific and General Knowledge, and Organizational Structure,” in Contract Economics, 1992. ↩
NIST, Prioritizing Cybersecurity Risk for Enterprise Risk Management, NIST IR 8286B, 2022. ↩
Intersection Group, Enterprise Design with EDGY. ↩
Michael Nygard, “Documenting Architecture Decisions,” 2011. ↩
They want teams to move quickly, but they also want solutions to remain secure, maintainable, and aligned with enterprise direction.
The usual response is to create approval gates.
Teams prepare material.
Architects review it.
A forum approves or rejects it.
This may create control.
It does not always create flow.
Gates control decisions before work can continue. Guardrails define the boundaries within which teams can decide for themselves.
The difference matters.
A gate requires work to stop until someone approves it.
This may be appropriate when the decision is difficult to reverse, carries significant risk, or affects the wider enterprise.
But when every decision becomes a gate, governance creates queues.
Teams wait for:
The organization may appear orderly.
Delivery still slows down.
flowchart LR
Team["Delivery Team"]
Review["Review Gate"]
Approval["Approval"]
Delivery["Delivery"]
Team --> Review
Review --> Approval
Approval --> Delivery
The problem is not that reviews exist.
The problem is that too many decisions require permission before work can continue.
Guardrails work differently.
They define the boundaries within which teams can act independently.
A guardrail may state:
Within those boundaries, teams do not need approval for every choice.
flowchart LR
Principles["Principles"]
Standards["Standards"]
Guardrails["Guardrails"]
Teams["Autonomous Teams"]
Delivery["Delivery"]
Principles --> Guardrails
Standards --> Guardrails
Guardrails --> Teams
Teams --> Delivery
Good guardrails reduce the number of decisions that need central review.
They replace repeated approvals with shared direction.
Autonomy does not mean that every team can choose anything.
Without boundaries, local decisions can create enterprise-wide consequences.
Teams may introduce:
Guardrails are therefore a form of governance.
They shift governance from individual approval toward predefined constraints.
The goal is not less control.
The goal is control that scales.
The amount of governance should reflect the impact and reversibility of the decision.
| Decision | Preferred Mechanism |
|---|---|
| Implementation detail within agreed standards | Team autonomy |
| Selection from an approved technology catalogue | Guardrail |
| Exception to an established standard | Exception process |
| Introduction of a new strategic platform | Architecture gate |
| Acceptance of material business risk | Accountable owner decision |
| Enterprise-wide data or identity model | Cross-domain governance |
A team should not need enterprise approval to choose an implementation detail within established guardrails.
Introducing a new customer master, identity provider, or strategic integration platform is different.
Those decisions create long-term dependencies across products and domains.
They may justify a gate.
Gates tend to accumulate.
A review is introduced after a failure.
Another approval is added after an audit finding.
A new forum appears after a cross-team conflict.
Each addition may appear reasonable in isolation.
Together they create a governance system where routine work requires repeated escalation.
This produces several problems.
The people approving the work may not understand the local constraints as well as the team doing the work.
Teams may feel that approval transfers responsibility to the review forum.
It does not.
When every initiative requires review, architects spend more time processing volume than examining important decisions.
The objective becomes passing the gate rather than making the best decision.
A principle such as:
Prefer reusable solutions.
is not enough.
Teams still need to interpret what reuse means, when it applies, and what happens when reuse creates unnecessary complexity.
A useful guardrail should be:
For example:
Customer-facing APIs must be exposed through the approved API management platform unless an exception is documented and approved by the domain architect.
This tells teams what is expected, when escalation is needed, and who owns the decision.
The strongest guardrails are often implemented through platforms rather than documents.
Examples include:
flowchart TD
Guardrails["Architecture Guardrails"]
Platform["Shared Platform"]
Templates["Templates and Paved Roads"]
Teams["Delivery Teams"]
Outcomes["Consistent Outcomes"]
Guardrails --> Platform
Platform --> Templates
Templates --> Teams
Teams --> Outcomes
A paved road makes the preferred approach easier than the alternatives.
This is more effective than asking every team to interpret a policy independently.
No guardrail fits every situation.
Organizations need a clear way to handle exceptions.
A good exception process should answer:
Exceptions are not evidence that governance has failed.
They are evidence that the organization recognizes context.
The failure occurs when exceptions remain undocumented, unowned, or permanent by default.
Guardrails only help when decision rights are clear.
Teams need to know:
Without this clarity, guardrails become suggestions.
Or worse, they become hidden gates because teams still need to ask for informal permission.
Architecture governance should therefore define both boundaries and authority.
Architecture is often treated as the function that reviews solutions.
A stronger role is to design the system through which architectural decisions are made.
That includes:
The objective is not to place architects in every decision.
It is to create an environment where good decisions can be made without them.
Gates are sometimes necessary.
They protect the organization from decisions that are difficult to reverse, carry significant risk, or create enterprise-wide consequences.
But gates should be the exception, not the default.
Guardrails allow teams to move quickly while remaining aligned with shared direction.
They create autonomy without abandoning coordination.
The goal of architecture governance is not to approve every decision.
It is to make more decisions safe to decentralize.
]]>Gates scale control. Guardrails scale autonomy.
The intention is good. Move faster. Empower teams. Reduce bureaucracy. But removing structure is not the same as removing bottlenecks.
Don’t confuse order with bottlenecks.
A bottleneck exists when work cannot progress because a required decision cannot be made.
That bottleneck may be:
The problem is rarely the existence of governance itself. The problem is how decisions are made. Governance becomes a bottleneck when decisions are centralized unnecessarily, decision rights are unclear, or every issue follows the same approval path regardless of impact.
Good governance should not slow organizations down. It should enable predictable decision-making.
When decision rights are clear:
Governance should increase flow, not reduce it.
flowchart LR
Context["Decision Context"]
Owner["Clear Decision Owner"]
Decision["Timely Decision"]
Delivery["Delivery"]
Outcome["Outcome"]
Context --> Owner
Owner --> Decision
Decision --> Delivery
Delivery --> Outcome
The faster the right decisions are made, the faster value can be delivered.
Organizations sometimes celebrate removing architecture reviews or decision forums.
Six months later they discover:
The bottleneck did not disappear. It moved downstream. What initially looked like speed created delay later through duplication, integration complexity, security remediation, and architectural debt. Removing governance can therefore improve local flow while reducing enterprise flow.
A common governance failure is treating every decision as equally important. A team should not need enterprise approval to select an implementation detail within agreed guardrails. Introducing a new strategic platform, customer master, identity provider, or enterprise integration pattern is different. Those decisions may create long-term dependencies across products, teams, and business domains. The amount of governance should therefore reflect the scope and reversibility of the decision.
| Decision Type | Typical Decision Level |
|---|---|
| Implementation detail within guardrails | Delivery team |
| Product functionality and priority | Product Owner |
| Domain architecture and shared dependencies | Domain or solution architecture |
| Strategic platforms and enterprise standards | Enterprise architecture and management |
| Business risk acceptance | Accountable business owner |
The goal is not to escalate more decisions. The goal is to escalate the right decisions.
Instead of asking:
How do we remove governance?
Ask:
Which decisions belong at which level?
Some decisions should be made by delivery teams. Others are product decisions. Some require coordination across products or domains. A smaller number belong at the enterprise level. The objective is not centralized control. The objective is to distribute decisions to the lowest responsible level. This does not mean pushing every decision downward. It means placing each decision where the necessary context, competence, authority, and accountability exist.
The alternative to centralized approval is not the absence of control. It is clear guardrails.
Guardrails define:
flowchart TD
Principles["Principles"]
Standards["Standards"]
Guardrails["Guardrails"]
Teams["Empowered Teams"]
Exceptions["Exception Process"]
Principles --> Guardrails
Standards --> Guardrails
Guardrails --> Teams
Teams --> Exceptions
When teams understand the boundaries, they spend less time asking for permission. Architecture becomes less about reviewing every decision and more about creating the conditions for good decisions to be made locally.
Architecture should reduce friction. Not by approving everything.
But by providing:
Good architecture creates order before delivery reaches a bottleneck. It reduces repeated discussions and helps teams avoid solving the same enterprise problems independently.
Governance should be evaluated by how well decisions flow through the organization.
Useful questions include:
If governance repeatedly delays low-risk decisions, it is too centralized. If teams repeatedly create enterprise-wide problems independently, it is too weak. The goal is a decision system that balances autonomy with coordination.
Order is not bureaucracy. Governance is not delay. Architecture is not automatically the bottleneck. Poor decision-making is. The fastest organizations are rarely those with the fewest governance mechanisms.
They are the ones where:
Good governance does not remove autonomy. It makes autonomy scalable.
]]>Should architects be part of management? There is no universal answer. The better question is: What decisions should architects influence?
Organizational placement matters far less than decision rights.
Architecture exists to support decision-making. Architects help organizations answer questions such as:
These are strategic decisions. They rarely belong to a single delivery team.
Managers are accountable for people, budgets, and business outcomes. Typical responsibilities include:
Architects may influence these decisions, but they are rarely accountable for them. Confusing architectural authority with management authority creates unnecessary tension.
Some organizations position architects outside management and outside strategic decision-making. The result is predictable. Architects create principles. Delivery teams ignore them. Architecture becomes documentation instead of decision support.
The opposite extreme also has risks. When architects become line managers, people management can begin to dominate architectural thinking. Time spent on recruitment, budgeting, and performance reviews is time not spent on enterprise strategy, governance, and long-term planning. Some architects thrive in both roles. Many organizations benefit from keeping them separate.
Rather than asking whether architects belong in management, define their decision rights.
For example:
| Decision | Manager | Architect |
|---|---|---|
| Hire engineers | ✓ | |
| Allocate people | ✓ | |
| Define architecture principles | ✓ | |
| Approve technology standards | ✓ | |
| Prioritize delivery backlog | Product Owner | |
| Recommend strategic investments | Shared | Shared |
The goal is not to give architects managerial authority. The goal is to give them architectural authority.
Many successful architecture functions operate through influence rather than hierarchy.
Architects provide:
Delivery teams retain ownership of implementation. Managers retain ownership of people. Leadership retains ownership of business strategy. Each role contributes different expertise.
Architects do not need to be managers to be influential. Nor does becoming a manager automatically make someone a better architect. Architecture succeeds when organizations clearly define responsibilities and decision rights.
The question is not:
Should architects be part of management?
The better question is:
Are architects involved in the decisions that shape the enterprise?
When the answer is yes, architecture becomes a capability that enables better decisions rather than a function that reviews them.
]]>Architects optimize the system. Product Owners optimize the product.
Understanding this distinction creates clearer governance, faster delivery, and better strategic alignment.
Architects focus on creating sustainable solutions that align with enterprise objectives. Product Owners focus on maximizing the value of a product by making prioritization decisions. Both contribute to successful delivery, but from different perspectives.
flowchart LR
Strategy --> Architecture
Architecture --> Product
Product --> Delivery
Delivery --> Outcomes
Architects typically influence decisions such as:
The goal is to optimize the system as a whole.
Product Owners typically decide:
The goal is to maximize customer and business value.
The confusion rarely comes from responsibilities. It comes from unclear decision rights.
| Architect | Product Owner |
|---|---|
| Defines architectural guardrails | Prioritizes product backlog |
| Recommends technology direction | Decides what to build next |
| Optimizes across products and platforms | Optimizes a specific product |
| Balances long-term sustainability | Balances short-term customer value |
| Governs architecture | Governs product priorities |
When both roles understand their decision rights, conflict becomes collaboration.
The relationship is complementary rather than hierarchical.
flowchart LR
Strategy --> Architect
Architect --> ProductOwner
ProductOwner --> DeliveryTeam
DeliveryTeam --> Outcomes
The architect provides direction. The Product Owner decides priorities within those guardrails. The delivery team determines how to implement the solution.
Architects and Product Owners should not compete for ownership. They own different decisions. Architects ensure that products fit within a sustainable enterprise architecture. Product Owners ensure that products deliver maximum value. Neither role is more important than the other. The most effective organizations clearly define decision rights and allow each role to focus on the decisions it is best equipped to make.
]]>A capability-centric operating model organizes change around what the business must be able to do rather than how the organization happens to be structured today.
Capabilities describe what an organization needs to do. They deliberately avoid describing who performs the work or how it is implemented. Examples include:
Unlike projects, products, and organizational structures, capabilities tend to survive reorganizations, technology replacements, and leadership changes. That stability makes them an excellent foundation for long-term planning and investment.
One of the greatest strengths of capability-centric thinking is that it creates traceability across the enterprise.
flowchart LR
Strategy --> Capabilities
Capabilities --> Investments
Investments --> Products
Products --> Delivery
Delivery --> Outcomes
Outcomes --> Strategy
Instead of asking:
Which project supports this strategy? Organizations begin asking:
- Which capabilities require investment?
- Which capabilities create competitive advantage?
- Which capabilities are underperforming?
- Which capabilities should be modernized?
The conversation shifts from solutions to business outcomes.
Many organizations assign capability ownership without giving capability owners meaningful authority. The result is accountability without influence. Capability owners should have clearly defined decision rights. For example, they may be responsible for:
Those decisions belong closer to delivery. A capability-centric operating model works because decision rights are distributed to the appropriate level.
Capability ownership and product ownership complement one another. A capability owner looks across multiple products and focuses on long-term business outcomes. A product owner maximizes the value of an individual product.
| Capability Owner | Product Owner |
|---|---|
| Owns a business capability | Owns a product or service |
| Long-term strategic focus | Short-term delivery focus |
| Prioritizes investments | Prioritizes backlog |
| Measures business outcomes | Measures product outcomes |
| Coordinates multiple products | Optimizes a single product |
Neither role replaces the other. Together they connect enterprise strategy with product delivery.
Enterprise architecture becomes significantly more valuable when aligned with capability ownership. Instead of reviewing individual solutions in isolation, architects support capability owners by answering questions such as:
Architecture becomes a decision-support capability rather than an approval function.
Traditional budgeting allocates funding to projects. Capability-centric organizations increasingly allocate funding to strategic capabilities. This changes the conversation from:
Which project should receive funding? to: Which capability requires investment to achieve our strategic objectives?
Projects become temporary implementation vehicles. Capabilities become long-term investment portfolios.
A simplified capability-centric operating model might look like this.
flowchart TB
Strategy["Business Strategy"]
Leadership["Executive Leadership"]
CapabilityOwner["Capability Owner"]
Architect["Enterprise Architect"]
ProductOwner["Product Owner"]
Teams["Delivery Teams"]
Leadership --> Strategy
Strategy --> CapabilityOwner
CapabilityOwner --> Architect
CapabilityOwner --> ProductOwner
ProductOwner --> Teams
Architect --> Teams
Responsibilities are intentionally separated.
Everyone has clear responsibilities. Everyone has appropriate decision rights.
Traditional governance often reviews projects. Capability-centric governance reviews outcomes. Typical questions include:
Governance shifts from approving work to measuring progress.
Capability-centric operating models are not without challenges. Organizations often struggle with:
These challenges are organizational rather than technical. They require executive sponsorship, governance, and a shared understanding of accountability.
Capability-centric operating models are particularly effective when organizations:
Smaller organizations may not require a formal capability model, but the principles remain valuable.
Projects are temporary. Products evolve. Organizations reorganize. Capabilities endure. That stability makes business capabilities a powerful organizing principle for enterprise change. A capability-centric operating model doesn’t replace product management, agile delivery, or enterprise architecture. It connects them. When strategy, governance, funding, architecture, product management, and delivery are all aligned around business capabilities, organizations are better equipped to adapt continuously rather than transform occasionally. Ultimately, capability-centric operating models are not about changing organizational structures. They are about creating clarity. Clarity of ownership. Clarity of governance. Clarity of investment. And, most importantly, clarity of decision rights.
]]>Strategy defines where we’re going. An operating model for change defines how we get there.
Many organizations treat change as a collection of projects. Projects begin. Projects end. The organization moves on. Successful organizations think differently. They treat change as a continuous organizational capability. Instead of asking:
Which project delivers this initiative? they ask: How does our organization continuously adapt?
One optimizes projects. The other optimizes change.
Enterprise architecture provides direction. It defines principles, target states, capabilities, and technology strategy. But architecture alone does not create change. Successful transformation also requires:
Without these elements, even the best architecture becomes shelfware.
A practical operating model answers questions such as:
If these questions remain unanswered, delivery teams will create their own operating model. That rarely scales.
One way to think about change is as a chain of connected decisions.
flowchart LR
Strategy --> Capabilities
Capabilities --> Investments
Investments --> Products
Products --> Delivery
Delivery --> Outcomes
Outcomes --> Strategy
Each stage influences the next. Most importantly, outcomes feed back into strategy, creating a continuous learning loop rather than a one-way roadmap.
Governance is often mistaken for bureaucracy. In reality, good governance reduces uncertainty. When decision rights are clear:
The goal is not more governance. The goal is better governance.
There is no universal operating model. Different organizations optimize for different types of change.
Change is delivered through temporary projects. Characteristics:
Best suited for organizations with predictable, discrete initiatives.
Long-lived product teams own products from idea through operation. Characteristics:
Best suited for organizations delivering digital products and services.
Business capabilities become the primary organizing principle for investment. Characteristics:
Best suited for large enterprises undergoing strategic transformation.
Shared technology platforms provide reusable capabilities for delivery teams. Characteristics:
Best suited for organizations with many engineering teams.
Decision-making is distributed while governance remains consistent across the enterprise. Characteristics:
Best suited for large organizations balancing autonomy with consistency.
Few organizations operate using a single model. A modern enterprise might:
The objective is not to copy another organization’s operating model. The objective is to create one that enables continuous change while remaining aligned with business strategy.
Architecture should not exist outside delivery. Nor should it become a centralized approval function. Instead, architecture enables change by providing:
Organizations don’t transform because they produce better architecture diagrams. They transform because they establish an operating model that consistently turns strategy into outcomes.
Architecture is one part of that model. Governance is another. Delivery is another.
The most successful organizations connect them into a system that continuously learns and adapts. An operating model for change is not about controlling transformation. It’s about making continuous transformation possible.
]]>Organizations design systems that mirror their communication structures.
For decades, it has helped explain why software architecture often reflects organizational boundaries. But AI introduces an interesting question. What happens when software is no longer designed, documented, and operated solely by humans?
At first glance, nothing changes. Organizations still define strategy. People still make decisions. Teams still communicate. Software architecture will continue to reflect those communication structures. Conway’s Law remains remarkably relevant.
The interesting question is not whether AI changes software. It is whether AI changes the organization itself. Increasingly, teams work alongside AI assistants.
Developers use coding agents. Architects use AI to explore alternatives. Product Owners refine requirements with AI. Business analysts generate documentation with AI.
Communication patterns are beginning to change.
Traditional software delivery looks something like this.
flowchart LR
Business --> Product
Product --> Team
Team --> Software
Increasingly, it may look more like this.
flowchart LR
Business --> Product
Product --> Humans
Product --> Agents
Humans --> Software
Agents --> Software
AI agents are not organizational actors in the same legal or accountable sense as people. Yet they increasingly participate in the flow of work, including analysis, design, implementation, testing, documentation, and operations. That changes how work happens.
Conway’s Law is often discussed in terms of teams and communication paths. If AI changes how work is distributed, it may also influence where organizational boundaries are drawn. Some responsibilities that previously required coordination between teams may increasingly be handled through shared AI capabilities.
For example:
This could reduce some dependencies while creating new ones. Teams may become less dependent on one another for routine coordination, but more dependent on shared data, models, platforms, and knowledge. Organizational boundaries may therefore shift from teams and reporting lines toward shared platforms, knowledge sources, data products, guardrails, and decision rights.
flowchart LR
Business["Business"]
ProductTeams["Product Teams"]
AIPlatform["Shared AI Platform"]
Knowledge["Shared Knowledge"]
Software["Software"]
Business --> ProductTeams
ProductTeams --> AIPlatform
ProductTeams --> Knowledge
AIPlatform --> Software
Knowledge --> Software
AI may not remove organizational boundaries. It may redraw them around shared context, platforms, and decisions.
Conway’s Law has traditionally been interpreted through human communication structures. AI introduces something broader. People no longer communicate only with one another. They increasingly communicate through documentation, models, platforms, and shared knowledge.
Architectural decisions, business terminology, capability maps, architecture principles, and API documentation become shared context for both humans and AI. Communication increasingly flows through knowledge rather than conversations alone.
One common misconception is that AI reduces the need for documentation. The opposite may be true.
As AI becomes part of everyday work, documentation becomes one of an organization’s most valuable assets. A wiki is no longer just documentation for people. It becomes context for AI.
Enterprise search, retrieval-augmented generation, coding assistants, architecture copilots, and internal AI agents all depend on structured, trustworthy information.
The quality of AI-generated answers increasingly depends on the quality of the organization’s knowledge. This changes the role of architecture documentation.
Architecture principles, decision records, capability maps, reference architectures, standards, and operating models are no longer static documents. They become part of the organization’s information flow. In an AI-enabled enterprise, documentation is not a by-product of delivery. It becomes infrastructure.
Organizations have spent years investing in software architecture. AI increases the importance of another discipline.
Information architecture.
Questions become:
Poor documentation creates poor AI. Well-structured knowledge creates better decisions.
Despite these changes, one thing remains constant. AI can suggest. Humans decide.
Organizations must still determine:
As AI capabilities increase, decision rights become more important, not less.
Perhaps Conway’s Law does not need to change. Perhaps our understanding of an organization does.
Tomorrow’s organization may consist of:
Communication structures will evolve. Software architecture will evolve with them. The principle remains the same. The participants change.
AI does not invalidate Conway’s Law. It may, however, change the organization whose communication structures software reflects. Teams may become smaller. Boundaries may shift.
Shared AI platforms, knowledge sources, and decision structures may become more important than traditional coordination paths.
Software will still mirror how the organization communicates. The difference is that communication increasingly flows through people, AI agents, platforms, and shared knowledge.
Architecture documentation, decision records, and capability maps are therefore no longer passive artefacts. They actively shape how both humans and AI understand the enterprise.
Perhaps AI does not change Conway’s Law. Perhaps AI changes the organization that Conway’s Law describes.
]]>