EA Reflection: Take Responsibility for the Decision, Not the Territory

·

·

,

The hardest decisions often have no clear owner.

Do not claim the territory.

Help the enterprise establish responsibility.

On major transformations, I have seen the most consequential issues sit between functions: data ownership, operating-model readiness, vendor dependency, and benefit accountability. Architecture added value when it framed the decision and secured an owner rather than trying to absorb the problem permanently.

The most difficult enterprise decisions often sit in organizational gaps. A transformation may depend on business ownership that no function accepts. A platform may create vendor dependency that procurement, technology, and finance each see differently. Data may be essential to the outcome while accountability remains fragmented.

Enterprise Architects are naturally drawn into these gaps because they can see across capabilities, operating models, information, applications, and technology. That visibility is valuable, but it creates a trap: the architect may become the temporary owner of every unresolved enterprise problem.

Taking responsibility does not mean claiming the territory. The architect’s role is to frame the decision, expose consequences, identify the parties involved, and help establish legitimate ownership.

Start by naming the decision in plain language. Avoid broad statements such as “we need better governance.” Ask instead: Who can approve the common customer definition? Who accepts the cost of maintaining two operating models? Who decides whether speed outweighs vendor lock-in? Who owns the capability outcome after the program closes?

Then distinguish the roles. The executive owns the outcome and final trade-off. Business and technology leaders supply operational evidence. Risk, security, data, finance, and procurement assess consequences. Architecture connects the perspectives, tests coherence, and identifies what must be escalated.

This work can feel like choosing a mountain because contested decisions are uncomfortable. They expose incentives, authority gaps, and commitments leaders may prefer to leave implicit. But the enterprise cannot act coherently while ownership remains hidden.

This boundary is especially important after go-live. Programs dissolve, consultants leave, and temporary governance ends. If architecture has absorbed ownership, the issue returns when attention shifts. If the proper capability or process owner is established, the enterprise can sustain the decision beyond the project.

The architect earns trust by staying with the decision until accountability is explicit—not by becoming the permanent owner. The goal is a stronger operating model, not a larger architecture empire.

Reflection

Which unresolved issue has quietly become “architecture’s problem” because no accountable owner has been established?

Practice

Create a decision ownership brief for one cross-enterprise issue. State the decision, outcome owner, contributors, architecture role, evidence needed, escalation route, and date by which ownership must be confirmed.

Comments Welcome

Darin Paton is the Owner of Cornerstone Consulting Inc., an Alberta-based enterprise architecture and SAP ERP transformation advisory firm serving organizations across complex business and technology change for over 15 years. 30+ years as an EA and advising SAP transformations.



Leave a Reply