Trap #67 Confusing Roles
Enterprise architects know their role is to facilitate a better decision. Their value proposition comes from analysis. They support people who own complex decisions - the stakeholder.
Crash and burn stories
Low-functioning EA Teams. One anti-pattern after another.
If you see these practices, stop! Stop now!
Eject while you still can.
Be a better architect
Free 90-day Personal Enterprise Architect Kickstart to be a better architect.
Weekly recorded webinar, with downloads
The specialist stands, speaks, and assumes that their view of the world is definitive and we shall line-up and march to their tune. There is usually a serious discussion about the path to implementing the specialists' change. Then nothing happens.
The specialist, frustrated, reconvenes a smaller meeting which follows the same journey to nothing happening. Within a short period, the specialist joins a quiet group who complain to each other about the one true path. None of them can figure out why no one is listening—they have confused their role of Subject Matter Expert with the decision-rights role of Stakeholder.
Role confusion is one of the fundamental reasons we invented Enterprise Architecture. If parochial interests, or specialist opinion, actually led to a better world, we wouldn’t need the overhead of enterprise architecture. Real architects speak to decision makers and provide the information to make an informed decision. Then facilitate guiding and controlling the resulting change program.
Tightly associated with Trap 1: Owning Decision Rights is confusing roles. The outcome is the same: they developed no serious architecture development—the real damage is skipping trade-off and traceability of specification. We will muddle the change program; typically the organization faces random priority re-ranking and argument about the suitability of decision choices without a decision-making framework that points to sustained value.
Role confusion is endemic in low-functioning EA teams. Clarifying the different roles involved in the creation and consumption of architecture is one of the most important steps in developing a high functioning EA team.
- Stakeholder Agent
- Decision Maker
- Subject Matter Expert
Most common role confusion occurs when a practitioner who is a Subject Matter Expert or Implementer claim approval rights by subverting the role of Stakeholder Agent. They present their parochial preferences as fait accompli with the force of approved architecture.
Good architects know that good architecture is not optimized for a single concern. Good architecture satisfies the set of Stakeholder preferences through active trade-off in the organization's context’s goals and strategy. Architecture development explicitly addresses Stakeholder Concerns showed through the development of Views.
Good architecture development balances the set of Stakeholder preferences through trade-off. A high fraction of the value of good architecture comes from the trade-off process where the potential value of the Target is tested against the impact and cost of change. When the approval role is artificially claimed, trade-off is short-circuited. Worse, they do all analysis through the lens of the Subject Matter Expert’s specialty, or implementation & operational challenges.
Usually Subject Matter Experts and Implementers confusing role think they are acting as an Architect, under the misapprehension that Architect’s own decisions. A classic sign of this role confusion is failing to provide an architecture (See Trap #16 Just the Diagram). Performing architecture governance readily catches role confusion when the pretender cannot identify the Stakeholders’ Concerns, provide crisp alignment with goals and strategy, or identify the trade-off performed.
The most dangerous expression of this trap is when the enterprise architect is seduced by their knowledge and experience gained through previous trade-off and implementation governance activity and act as a Stakeholder Agent. In theory, we always test with Stakeholders. We must routinely short-cut architecture development and engage with *Stakeholder Agents*.
When seduced, the struggling enterprise architect appropriates the Stakeholder’s exclusive decision-making rights. Given that *Architects* routinely need to act as Stakeholder Agents when short-cutting and performing tactical implementation governance, this trap sneaks up on the most careful practitioners. As they make more statements on behalf of Stakeholders, the *Architect* becomes more confident and identifies with the priorities of key Stakeholders.
The solution for this trap is effective governance of the architecture development process. Even informally stepping through the governance checklist will highlight to good practitioners when they have been seduced: when they cannot articulate a trade-off between competing preferences, when they cannot frame out a View for more than one *Stakeholder.
In the real-world, the Target is never perfectly aligned with a single goal, single objective, single Stakeholder preference, or Subject Matter Expert’s predisposition. Is it a compromise that provides the best fit against the set of goals, objectives, and Stakeholder preferences; all informed by Subject Matter Experts’ advice. We get this best fit by clearly knowing what role is in play.
Usually Subject Matter Experts and Implementers confusing role think they are acting as an enterprise architect, under the misapprehension that Architect’s own decisions. A classic sign of this role confusion is the failure to provide an architecture (See Trap #16 Just the Diagram). Performing architecture governance readily catches role confusion when the pretender cannot identify the Stakeholders’ Concerns, provide crisp alignment with goals and strategy, or identify the trade-off performed.
The solution for this trap is effective governance of the architecture development process. Even informally stepping through the governance checklist will highlight to good practitioners when they have been seduced: when they cannot articulate a trade-off between competing preferences, when they cannot frame out a View for more than one Stakeholder*.
If you are struggling with this, we suggest exploring a Stakeholder Workshop to identify who is playing what role, and clarify the distinction between advising and deciding.
Join the Enterprise Architecture Kickstart
Free 12-week program to be a better enterprise architect