EA Reflection: Authority Is Not Accountability

·

·

,

You may never receive the mandate you expected.

But the enterprise still needs a clear decision.

Here is how architects can act without overreaching.

I have seen enterprise architects held accountable for coherence while lacking authority over budgets, delivery teams, or executive decisions. Progress began when they stopped waiting for a broad mandate and clarified the specific decisions where they advised, recommended, approved, or escalated.

Many Enterprise Architects are asked to protect enterprise coherence without being given formal authority over the choices that create fragmentation. They are expected to reduce risk, connect strategy to execution, and identify consequences, yet they may not own funding, delivery, procurement, or operations.

That tension can create two unhelpful responses. The architect may wait for a perfect mandate that never arrives. Or the architect may act as though every decision belongs to architecture. One creates irrelevance. The other creates resistance.

The better response is to distinguish accountability from authority. You may be accountable for making consequences visible without owning the final decision. You may be responsible for presenting options without having approval rights. You may need to escalate a material risk without controlling the outcome.

This changes the daily work. Before entering a meeting, identify the decision being made, the accountable executive, your role in that decision, and the evidence leaders need. State clearly whether architecture is advising, recommending, assuring, approving, or escalating. Do not hide ambiguity behind frameworks or process language.

A simple decision-rights canvas can expose where the operating model is unclear. It can show who owns the business outcome, who supplies evidence, who decides, and who accepts the remaining risk. That clarity often matters more than a broad architecture charter.

The distinction also protects relationships. When an architect explains the basis of a recommendation and the limits of the role, disagreement becomes a legitimate executive choice rather than a contest over organizational power. The decision remains transparent, traceable, and owned.

The architect’s purpose is not to collect authority. It is to improve the quality and timing of enterprise decisions. Sometimes the most mature contribution is a recommendation. Sometimes it is a warning. Sometimes it is accepting that leaders have chosen a different trade-off after the consequences were made visible.

Influence grows when people know what architecture is there to do—and what it is not there to control.

Reflection

Where are you waiting for authority when the enterprise only needs you to clarify the decision, consequences, and ownership?

Practice

Create an EA mandate and decision-rights canvas for one live decision. Define the decision, accountable executive, architecture role, evidence required, escalation threshold, and risk owner.

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