The Architecture Graveyard: Trap #67 Confusing Roles

February 13, 2017

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 no serious architecture development was developed - the real damage is skipping tradeoff and traceability of specification. The change program will be muddled; 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. Our article on basics of architecture governance, and in the TOGAF Practitioner’s paper we identified a set of key roles engaged in architecture development:

  • Stakeholder
  • Stakeholder Agent
  • Decision Maker
  • Subject Matter Expert
  • Implementor
  • Auditor

Most common role confusion occurs when a practitioner who is a Subject Matter Expert or Implementor claim approval rights by subverting the role of Stakeholder Agent. Their parochial preferences are presented as fait accompli with the force of approved architecture.

Good architects know that good architecture is not optimized for a single concern. Good architecture satisfices the set of Stakeholder preferences through active trade-off in the context of the organization’s goals and strategy. Architecture development explicitly addresses Stakeholder Concerns demonstrated 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, all analysis is done 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 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 most dangerous expression of this trap is when the 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 appropriate Stakeholders, in practice, we must routinely short-cut architecture development and engage with Stakeholder Agents.

When seduced, the 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 more statements are made 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 are unable to articulate a trade-off between competing preferences, when they are unable to 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.

If you are struggling with this, we suggest exploring a Stakeholder Workshop to explicitly identify who is playing what role, and clarify the distinction between advising and deciding.