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.

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.