Trap #195 - Not following the conversation

Architecture concerns are the criteria to assess acceptability. Enterprise architects' highest value is assisting stakeholders identify the best path to improving their organization. Then provide the governance tool for the stakeholder to gain the expected improvement.

Crash and burn stories

Too many EA teams are low functioning. Literally hanging on by their fingernails. If you see these practices, stop! Stop now!

Eject while you still can.

Enterprise Architecture Graveyard

Learn the failure patterns to avoid

Tests for a Wicked Problem

  • We do not understand the problem until after the formulation of a solution
  • The problem has no stopping rule
  • Solutions to the problem are not right or wrong
  • Problem and solutions are essentially novel and unique
  • Every solution is a 'one shot operation’
  • We cannot compare given alternative solutions

Be a better architect

Free 90-day Personal Enterprise Architect Kickstart to be a better architect.
Weekly recorded webinar, with downloads

Free EA Community Membership
Free training, guidance, tools and techniques from Conexiam Consulting

Start today

Trap 195 - not following the conversation We see it all the time. The struggling enterprise architect complains that the decision-makers have changed their minds. Again. Frustrated, the struggling enterprise architect declares they will have to start all over. They rework using the latest transitory idea. Rinse and repeat. Build frustration.

The worst part of this trap is struggling enterprise architect's repetition. They usually start with the initial error of trying to identify the priority.

Enterprise architecture exists to help answer complex problems with multiple contradictory goals. It exists to find solutions to our stakeholder's wicked problems. We do not need enterprise architecture to answer questions with straight-forward criteria.

Our struggling enterprise architect usually compounds their error by assuming that their job is to provide an answer. Nothing can be further from the truth. A high-functioning enterprise architect manages the decision-making process. In short, they facilitate the stakeholder to make the best possible decision. Usually the least-worst.

Lets spend a minute and unpack these errors - providing an answer, and believing the stakeholder changed their minds.

Wicked Problem Solving At the root is a weak understanding of how we make complex decisions. We like to assume there is a simple linearity to decisions. We start with a problem, gather data, perform analysis, formulate a solution, and have the answer.

This approach might be true for deciding which toothbrush to purchase. It has no place in enterprise architecture. It has no place in addressing a Wicked Problem.

Enterprise architect's get asked to work on wicked problems. We base our method on stakeholder's concerns to drive out contradictory criteria. We use architecture views to describe the architecture.

How else can we determine if the target architecture is sufficiently aligned, cost-efficient, low-change-impact, and agile? Seriously. My stakeholder wants to 1) align to strategy, 2) control change and operating cost, 3) minimize change impact, and 4) keep the ability to react to an expected future. I wish they only wanted world-peace.

In comes the struggling enterprise architect. They have been working hard and have provided an answer that is low cost. In the conversation with the stakeholder the agility concern, or the alignment concern comes up and the low-cost answer dies. Out comes the frustrated enterprise architect vowing a need to start all-over. After working hard on an answer, they go back in with a far more agile answer.

You know what happens. During the conversation, the stakeholder considers change impact. The answer dies. The struggling enterprise architect stomps out, complaining that yet again the stakeholder changed their mind.

You know they are going to do the same thing again. It is so predictable. You can see it coming a mile off. Crash & burn.

All because the struggling enterprise architect failed to understand their job. Often the very skills that are causing the crash got the struggling enterprise architect the job. Planning and implementation are after architectural decision.

The contrast between a high-functioning and struggling enterprise architect is blinding.

In our example the stakeholder wants to 1) align to strategy, 2) control change and operating cost, 3) minimize change impact, and 4) keep the ability to react to an expected future. Those statements net down to four concerns.

  1. Alignment
  2. Cost of Change / Cost of Operations
  3. Change Impact
  4. Agility

High-functioning architects know they cannot optimize for a single concern. High functioning architects know they have to put the mess in-front of their stakeholder and facilitate trade-off.

The struggling architect embarks on a system design. Testing the system against their priority. That priority is usually something concrete and measurable, like cost or time-to-change.

The high-functioning architect looks at the system and seeks to understand what elements drive cost? Which parts are hard to change? What types of external change happen? What deficiency the system has against strategy? The high-functioning architect is doing their job and analyzing a system against the stakeholder's concerns.

The struggling architect shows up with a change optimized against a single criteria. Usually a system diagram. They explain the new architecture in terms of benefits to the criteria. In the conversation, they crash and burn. They leave the stakeholder uninformed about how to address a complex set of criteria.

Right here is why enterprise architecture exists. Help the stakeholder make the best decision in the context of a set of contradictory concerns. Help the stakeholder change a complex system. Help the stakeholder manage the change to achieve the expected benefit.

The high-functioning architect shows up with an exercisable model that lets the stakeholder see the impact of distinct changes. The stakeholder gets to understand the change. Where they incur cost. Where they lose agility. Where they lose alignment. Where change impact comes from.

The high-functioning architect has views. At a minimum, the high-functioning architect can interactively explain the impact of different change options. In effect, acting as the model.

Enterprise Architect's Guide

Download the Enterprise Architect's Guide a TOGAF Series Guide on developing useful enterprise architecture.

When I work with architects, we spend a lot of time on this trap. I ask for stakeholder concerns. I ask how the concerns impact the system under examination. I ask where the curves cross-where optimizing one concerns harms another.

What I am doing is effective governance of the architecture development process. Asking the questions in the governance checklist:

  • name your stakeholder
  • tell me their concerns
  • explain your architecture in terms of concerns

I show-up prepared for a battle with the struggling architects. I will be told that there is a priority! I am told the stakeholder expects an answer! I always hold my ground. I know good enterprise architecture.

All too often I have to show them developing architecture involves the stakeholder. That good enterprise architects know the system. They know the impact of change on key concerns, and impact of not changing. That we have to guide the stakeholders through painful trade-off.

A couple of years ago we had a daily meeting with key stakeholders. The EA team were panicking. We had a nasty trade-off that had stumped the company for several years.

My team of new enterprise architects was panicking. Every day my team looked for a way out. They tried to find an option that defeated reality. Every day we went in with the same set of information. Every day we had the same conversation with the stakeholders. Every day the stakeholders tried to defeat reality. We got to an answer. It wasn't pretty.

No answer to a wicked problem is pretty.

I never made the mistake of showing-up with a change optimized against a single criterion. My change never fell apart when we looked at a second, or third criteria. Because of this I never had the problem of the stakeholder changing their mind.

Instead, we helped our stakeholders identify the best available path to improving their organization. They understood the trade-off and implication of their choice. They could govern the following change.

Enterprise architecture methods like TOGAF are complex for a reason. They help us address the most complex problem our organizations face: how to get better.

High-functioning enterprise architects always follow the conversation. Usually because they are leading it. Without an artificial answer, we never have the stakeholders changing their minds and picking a new criteria.

Scroll to Top