Roles

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 trade-off 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 identifiedThe 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.

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. 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. a set of key roles engaged in architecture development:

Stakeholder

Stakeholder Agent

Decision Maker

Subject Matter Expert

Implementer

Auditor

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. 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](https://conexiam.com/insights/blog/blog/essential-ea-governance/). 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.

‘if we only had a mandate‘;
‘we need a design authority‘;
‘the business unit is doing their own thing again.’

All these phrases mean the same thing; the EA team thinks they own a single decision. Falsely believing your team owns the decision leads only one way. What masquerades as target architecture, along with the associated specification and standard are doomed to live out their days in bitter irrelevance. All because the practitioners failed to act as architects.

Architects inform stakeholder of the path that best addresses the set of stakeholder preferences; they ensure all concerns are addressed and then own the stakeholder decision. Poor practitioners believe that their narrow expertise and analysis of a problem space to optimize against a single parochial concern provides some super-power allowing them to see the one right path. It is a moot point how nicely a foot bridge is designed if there isn’t a road leading up to it.

Conexiam’s EA Capability practice sees this trap in organizations everywhere. Teams that fall into this trap are on a fast path to the Architecture Graveyard. While EA teams heading on this route are a market opportunity for us, it is a trip you never want to make. The most dangerous part about this trap comes from its behavioral roots. Symptoms include a practitioner trying to use their seniority, status, or perceived expertise of a subject to influence support for an idea instead of providing a crisp traceability the organization’s goals, objectives or gaps.

The implications of this behavior are dire. Teams will experience symptoms such as sensing a loss of credibility, cuts in resources, and increasing bitterness. Typically these lead to an inability to meet with Stakeholders and other decision makers, followed by exclusion from decision-making meetings. Meanwhile, the entire enterprise may as well aim a shotgun at its foot.

There is an easy solution to this trap: do architecture and follow the architecture governance process. Not the part where change initiatives are governed, the more foundational process where the creation of architecture is governed. In Essential EA Governance and the Leader’s Guide, we outlined a simple checklist designed to combat this trap.

Are the correct stakeholders identified?

Are constraints and guidance from superior architecture taken into account?

Do appropriate subject matter experts agree with the facts and interpretation of the facts in the architecture?

Do any constraints or guidance produced to reflect the Views provided for stakeholders and any underpinning architecture models and analysis?

Do the Views created for the Stakeholders reflect their Concerns and reflect any underpinning architecture models and analysis?

Do the Stakeholders understand the Value, and any uncertainty in achieving the Value, provided by reaching the target state?

Do the Stakeholders understand the work necessary to achieve the goal state and any uncertainty in successfully accomplishing the work?

Do the Stakeholders understand any limitations in confidence they should have in the target architecture?

Have the Stakeholders approved the Views?

This checklist ensures the architect has actually described a target that addresses the preferences of the Stakeholders rather than the parochial interest of subject matter experts or bystanders. Architecture that addresses Stakeholder’s preferences, and willingness to change, is an architecture that gets used.

Most importantly, the checklist highlights that no-one has decision rights other than Stakeholder; not the architect; not a subject matter expert; not an implementer; not the architecture review board. Just the Stakeholders. If you want to own a decision get the right job title.

A common failure pattern is to establish an Enterprise Architecture Governance board that believes it maintains decision rights about the target architecture, change to the architecture, relief and enforcement. Decision rights about the target architecture, relief and enforcement are always vested in the architecture’s Stakeholders. Successful teams providing the EA Capability make sure that even within the lowest tier (technology architecture governance), Stakeholders own the decision rights. An Enterprise Architecture Governance board owns process, and a recommendation regarding completeness and confidence in the work that led to the target architecture.

The short decision-tree checklist for an Enterprise Architecture Board to require an architect to demonstrate when assessing a target architecture is:

Were the correct stakeholders identified: Y/N

If yes, proceed

If no, send direct the architect to engage with the stakeholders appropriate to the scope of the architecture being developed

Were constraints and guidance from superior architecture taken into account: Y/N?

If yes, proceed

If no, either exercise Architecture Governance change, relief and enforcement, or direct the architect to take into account guidance and constraints from superior architecture

Do appropriate subject matter experts agree with the facts and interpretation of the facts in the architecture: Y/N?

If yes, proceed

If no, either direct the architect to engage with the subject matter experts or develop a recommendation for the Stakeholders that they should have limitations in confidence

Do any constraints or guidance produced reflect the Views produced for stakeholders and any underpinning architecture models and analysis: Y/N?

If yes, proceed

If no, direct the architect to do their job

Do the Views produced for the Stakeholders reflect their Concerns and reflect any underpinning architecture models and analysis: Y/N?

If yes, proceed to the Stakeholders for approval

If no, direct the architect to develop appropriate Views

Do the Stakeholders understand the Value, and any uncertainty in achieving the Value, provided by reaching the target state: Y/N?

If yes, proceed

If no, direct the architect to develop appropriate Views and return to the Stakeholders

Do the Stakeholders understand the work necessary to reach the target state and any uncertainty in successfully accomplishing the work: Y/N?

If yes, proceed

If no, direct the architect to develop appropriate Views and return to the Stakeholders

Do the Stakeholders understand any limitations in confidence they should have in the target architecture: Y/N?

If yes, proceed

If no, direct the architect to develop appropriate Views and return to the Stakeholders

Have the Stakeholders approved the Views: Y/N?

If the answer to the last question is yes, the Enterprise Architecture Board should approve the architecture for publication in the EA repository as approved target architecture. Because the failure pattern is so embedded in practice we will re-iterate: There is no role for Enterprise Architecture Governance Board to debate, or approve, the contents of the target architecture and its constraints or guidance.

If the answer to the last question is no, the Enterprise Architecture Board should make a decision to either direct the architect to re-work the architecture usually through more advanced trade-off, or more often by finally embracing the Stakeholder’s preferences, or cancel the architecture initiative.

When the architecture is being used changes to the Enterprise are being guided, or constrained. Two factors impact governance of change. First, organizations operate in a dynamic environment, and the analysis of the target architecture cannot have assessed every circumstance, or change option possible. Second, the target was produced for a purpose and may not have been developed to the level of detail required for the current use. The Governance process requires the ability to change the architecture, provide relief from constraint and enforce the architecture.

The role of Enterprise Architecture Governance is to manage the process of assessing compliance. All change is subject to compliance reviews against the constraints and guidance in the target architecture. Typically, these assessments are performed on a periodic basis to assess the operationally changing current state, and associated with a project to assess project-driven change. Where there is non-compliance the Stakeholders have three choices: First, enforce compliance; Second, provide relief; third change the target architecture.

The short checklist for an Enterprise Architecture Board to require an architect to demonstrate when assessing a non-compliance report is:

Did the organization embarking on a change reasonably interpret the target architecture’s guidance and constraint reasonable: Y/N?

If yes, their interpretation should be accepted as compliance and any issues addressed through a change to the architecture

If no, proceed

Do appropriate subject matter experts agree with the facts and interpretation of the facts in the impact assessment: Y/N?

If yes, proceed

If no, either direct the architect to engage with the subject matter experts or develop a recommendation for the Stakeholders that they should have limitations in confidence

Do appropriate subject matter experts agree with the recommendation to enforce the target, grant time-bound relief, or change the architecture: Y/N?

If yes, proceed

If no, either direct the architect to engage with the subject matter experts or develop a recommendation for the Stakeholders that they should have limitations in confidence

Do the Views produced for the Stakeholders reflect the impact assessment and reflect any underpinning architecture models and analysis: Y/N?

If yes, proceed to the Stakeholders for approval

If no, direct the architect to develop appropriate Views

Do the Stakeholders understand any limitations in confidence they should have in the impact assessment: Y/N?

If yes, proceed

If no, direct the architect to develop appropriate Views and return to the Stakeholders

Do the Stakeholders understand the impact on prior expected Value, and any change in certainty in achieving the Value, provided by reaching the target state: Y/N

If yes, proceed

If no, direct the architect to develop appropriate Views and return to the Stakeholders

Have the Stakeholders approved the recommendation to enforce the target, grant relief, or change the architecture: Y/N?

If the answer to the last questions is yes, the Enterprise Architecture Board should approve the non-compliance action recommendation for publication in the EA repository. Because the failure pattern is so embedded in practice we will re-iterate: There is no role for Enterprise Architecture Governance Board to debate, or approve, the recommendation. Lastly, where relief is provided the Enterprise Architecture Board should ensure that future compliance assessment and reporting take place to review time-bound relief. Without this step, the enterprise has simply agreed to change the target architecture without the bother of approval.

If the answer is no, the Enterprise Architecture Governance board has a difficult decision. In short, either the architect must be directed to expand the information provided to the Stakeholder, or re-work the recommendation to embrace the Stakeholder’s preferences.

Following these governance checklists and arranging your EA governance to respect Stakeholder decision rights will enable efficient, enforceable Enterprise Architecture. Decision rights about the target architecture, relief and enforcement are always vested in the Stakeholders. Attempting to vest these rights anywhere else is illusionary.

In the real-world, stakeholder engagement is usually discussed as stakeholder management. All too often it is delivered as stakeholder manipulation, where the EA sells their preferences to the stakeholder.
It is a common saying that initiatives have about as much ability to choose their stakeholders as children have to choose their parents. You need to identify who the stakeholders are, assess their impact, classify their concerns and clarify their requirements.

Stakeholder mapping is an early activity. At this point, it is important to avoid two temptations of simplifying or reducing the set of stakeholders and confusing the stakeholder with those who claim to represent the stakeholder or the common communication channel. It is important to include all the relationships initiative affects and who can influence the initiative.

Thinking broadly about stakeholders will create a list that is too long to be of any practical use. Avoiding engagement burnout requires classifying your stakeholders to understand common concerns, power, and interest.
Classify Stakeholders

TOGAF provides a simple template that classifies stakeholder along an interest & power. Interest in the outcome of the initiative and their power to shape the initiative are starting points.
ISO 42010 defines concern as an interest in a system by one or more of its stakeholders. In practical terms, concerns are subjects – containers that classify the objectives, requirements, preferences and worries of the stakeholders.

Putting together a map demonstrating interest, power and concern immediately surface a central focus of good enterprise architecture: stakeholder conflict. Look for overlap and gap – it is as important that key stakeholders have overlapping concerns as dissimilar concerns. In the former your initiative may have to address edge-of-scope issues; while in the latter there is the real possibility of conflicting requirement.
Requirements: wants, objectives, preferences & fears

Requirement is a busy word in stakeholder management – nothing else requirements the set of wants, objectives, preferences and fears that shape the acceptability of an enterprise architecture to the set of stakeholders who must be served.

Classic stakeholder management tries to nail these down early – following the practices of project management and engineering where there is a clear end-goal. Best-in-class enterprise architecture recognizes that until the last architecture trade-off is made requirements are fluid, as is the architecture. Interesting, for best-in-class enterprise architecture constraints, are usually fluid as well.
Represent everything with a Stakeholder Map

There are a range of methods to represent this set of stakeholders, power, interest and concerns in a ‘Stakeholder Map’. Usually, the set of relationships is too complicated represent everything in a graphical format. In Navigate, we often use a Business Alignment Model, a traceability diagram or a gravity well. In the end, we are trying to represent the variety of stakeholder relationships, their relative proximity or strength.

Real stakeholder engagement – weighing organization and stakeholder preference, internal and external constraints is a critical first step. Without understanding the set of Stakeholders, requirements, objectives, influences, and preferences the trade-off necessary to develop a Target Architecture will be incomplete. Then we are forced into an anti-pattern selling the Target to obtain agreement to a Target Architecture that addresses a subset of stakeholder requirements.

Primary Sidebar

Conexiam training teaches the exact tools and techniques we use when delivering enterprise architecture. Our enterprise architecture education is one of the tools used in developing a robust EA … read more ... about Training