Strong Enterprise Architecture Uses the Decisions Already Made

The Power of And

My favorite stakeholder speaks about the power of and. What if we can have the S5 and the P5? What if we can have the best of what we have and everything we want?

Before decision, when I am exploring architecture alternatives I love the power of and. In enterprise architecture the power of and crushes the dead hand of how. Every time I aim for an and I must eliminate the barriers to having it all. Frankly, before decision, that is my job.

I love the intellectual challenge of figuring out what it takes to have the S5 and the P5. Side-by-side the aggressive relentless change for best with the placid matching-of-peer-quality and incremental efficiency improvements.

In our work, the power of and always faces the reality of if. We can have and:

• if we change how
• if we shift the work between these functional teams
• if we invent anti-gravity Robbie Rocket Pants

I gain the power of and when we make the architecture decision to put the if on the architecture roadmap. Then ruthlessly govern every change initiative to deliver the if.

I have been in the meeting where they decided to do whatever it took to deliver and, and a very senior person was tasked with making it so.

Crazy ideas, like rebuilding the core of the business from scratch to cut the transaction cost 90%. Or, implementing a custom ERP for one division, while ruthlessly simplifying our application portfolio. Or, implementing an almost written, soon-to-be beta application in the core value producing activity of the company. Or, using visualizations to improve situational awareness and communication.

You can have Robbie Rocket Pants when your stakeholders will take a resolute informed decision.

Resolute informed decisions are enabled by best-practice enterprise architecture.

Everything is in the TOGAF Practitioner's Guide—Table 4 and the Architecture checklists. Table 4 says the enterprise architect needs to know how stakeholder priority and preference adjust in response to value, effort, and risk of change. The target architecture governance checklists tells the ARB to confirm the stakeholders:

• understand the work required to reach the target state
• understand the uncertainty (risk) in successfully accomplishing the work
• understand any limitations in confidence they should have
• understand how benefit is realized

Risk Heuristic

Robbie Rocket Pants are not impossible. Organizations do what appears impossible all the time, when they make a resolute decision that is informed about three things—benefit, work, and uncertainty.

Let's pause. The seeming impossible can be done when we know what we face. When we can imagine the quantified benefit. When we can outline the work. When we adjust for uncertainty.

When we can create the information necessary for a resolute decision.

Use ifs ask the hard trade-off questions. Benefits come from addressing the ifs—if we do all required work, if we overcome all barriers, if we know the win.

Benefits never come from standing at the edge of an impassable canyon wishing it were bridged.

We use a fairly complex heuristic to test our thinking, and make sure we are on solid ground when we are talking about and as well as the following if.

Value = Benefit/Uncertainty - ((Cost-Imp^Uncertainty) + Cost-Ops^Uncertainty))

Visualizations of a distributed power generation and transmission system might change how a large complex production and distribution system was operated.

Cool. We wanted a new way to manage 50,000 gigawatt-hours (GWh) of electrical production. However this is back in the day. Back when green screens were modern. Real operations used analog dials, switches, and knobs. Visual interfaces were science fiction.

Unless you looked at a Macintosh. Then everything was different. Visual interface and a low-code development environment.

I knew what they wanted—S55 Power Control Capability sitting right next to P31 Power Generation Capability. Best-in-class, automated and agile (S55) tied at the hip to predictable, manual and hard to change. Cool. Science fiction, untested technology, and 50,000 GWh of production.

When pressed they explained better, I got exactly what I expected with a S—enabling people. Thinking, situational awareness, and communication. After thinking about it they could add a lower training burden on quality of operating the system.

Remember, I'm chasing a capability—we want the ability of Power Control to be radically different. We want the ability to control generation and distribution to be better than average. To be better than very good. To be best. We want Superior.

We'll know it when we get there.

I came up with three ifs.

• if we can bridge the HyperCard / control system gap
• if we can build a wide-area AppleTalk network
• if we can build a very tight iterative user/developer relationship and distributed release control years before the Agile Manifesto

Innovation sitting right next to proprietary control systems with decades long lifecycles. Proprietary control systems sitting next to billions of dollars of power generation and transmission infrastructure. Infrastructure that has half-century planning horizons and decade-long decision cycles.

Superior Architecture

Everywhere you look you are surrounded by superior architecture—prior architecture decisions, architecturally compliant implementations, and Target Architectures we are still working towards. The superior architecture that guides and constrains our current architecture project.

This power generation example is my strongest superior architecture example. No one will lightly rebuild a few billion dollars worth of generation and transmission infrastructure. There is no clever what if about alternative revenue or value proposition. We deliver predictable electricity. All day.

In the control room we had skilled people looking at analog dials and turning knobs. When they turn knobs huge turbines start moving and gigawatts of power production spin-up, or spin-down. Flipping a switch shuts down one transmission line powering a city so crews can safely climb the tower to inspect the line.

All these decisions are based on a myriad of factors. Production must precede demand. That multi-ton turbine might need 10-15 minutes to overcome inertia. Your lights don't wait. Flipping the switches is also important. You never want stop powering the city or tell the crew it is safe to climb the wrong tower.

My superior architecture was a perfect Parity—match our industry peer's predictable delivery of electricity while actively driving up efficiency. Tied to a highly manual system that was close to unchangeable.

Right next to a superior architecture Parity capability, my stakeholder wanted to change the game. With nifty software that didn't exist and they couldn't describe, my stakeholder thought they could enable better thinking and situational awareness. With nifty assistance, their people could improve the efficiency of generation. They'd probably squeeze millions out of the operations budget. All from good people, better information and communications.

At this point, most people ask me what the nifty software did. Almost everyone is surprised that I don't know. Like most of my agile development-EA work, the details of the details of the software were not my job. While I was curious, the how to be best wasn't my architecture problem.

Especially in a Superior Agile 5, because it was going to change as fast as they discovered their next information and communication issue. They could imagine unlimited opportunities to be better.

As an enterprise architect, my problem was creating the conditions so they could be best-in-class. So they could change as they learned, as new threats and opportunities arose. So they could combine best-in-class execution with its inevitable need for enterprise agility. I needed to hand over a big open-ended box of S5.

I was going to give them a visual, low-code platform. They were going to try, learn, and re-work. They were going to tweak the HyperCard for years.

Not one of my enterprise architecture ifs—bridge the HyperCard / control system gap, wide-area AppleTalk network, and create a very tight iterative user/developer relationship—was write code.

Concluding Using the Decisions Already Made

Years later when John Sherwood (SABSA) was teaching me about risk as uncertainty, I thought about this project. Bang! I could see the upside and downside. I could see the uncertainty that modern best-practice TOGAF speaks to. Risk is the effect of uncertainty. Our job, all day and every day, is to drive out uncertainty.

I knew my stakeholder was dreaming of Robbie Rocket Pants. They did want to completely re-wire the control system. Eventually. They knew the uncertainty of re-wiring that control system evaporated any potential value. Their downside was turning out the lights or killing a linesman.

This project highlights enabling S5 through architecture, not through a solution. We couldn't get there in one elegant omniscient project. Look closely at our heuristic. Uncertainty drains value and explodes cost.

Value = Benefit/Uncertainty - ((Cost-Imp^Uncertainty) + Cost-Ops^Uncertainty))

An elegant omniscient project couldn't be the plausible path. Every failure of omniscience is uncertainty. Every time I cannot be sure the benefit divisor and cost exponent grow. Value evaporating with every increment of uncertainty.

Use candidate, architecture alternative, and transition to drive out uncertainty. Reach for the architecture roadmap's value resting point.

Find a place where your stakeholder can stop and harvest value. Not pause. Not gin-up a PowerPoint claim. Stop and harvest.

Never tie benefits to the elegant future. Capture something early. Also, look at the math. Uncertainty kills otherwise plausible ideas. I never fake a proof of concept by deferring defeating uncertainty. The proof of the concept is draining uncertainty. Demonstrate defeating hard things early.

Drain the uncertainty about if.

So, what was VRP-1? It simply drained the uncertainty from bridging the HyperCard / control system gap, and building a very tight iterative user/developer relationship.

Back in the day Macintoshes had serial ports. With those serial ports a certified electrician took the signal moving an old-days mechanical control panel dial and turned it into a serial signal. HyperCard could read serial signals. Then do stuff—display numbers, shade images, whatever is needed. We put the control room staff through a HyperCard camp. Yep, we taught the users about moving a mouse and making stacks—I vanished the developer/user divide by using low-code to vanish the developer.

Bing, bang, boom. A standalone experiment on changing the game. A place for the stakeholder to stop, and evaluate. One site, learning visualizations and control procedures. Figuring out what it took to be better than best.

It was not my job to do the code. I didn't have to worry about better thinking, situational awareness, or communication. That was on them. My job was enabling. Enabling through architecture.

They could change the game if we could get data visualized. If helpful software was developed. Then they would tackle the how. They would, in the control room, iteratively envision better thinking, situational awareness, and communication and create the tools. My ifs were barriers to theirs.

When exploring targets—mainstream improvement or a Robbie Rocket Pants crazy idea—we have to keep in mind everything can be made to occur if. Never pretend the ifs don't exist.

I look for inconvenient ifs. Especially when my stakeholder wants something really badly. I want to have the hard conversation about what it takes to bridge the canyon.

If we cannot, or will not, bridge the canyon I want to celebrate the resolute no. The resolute decision we will not spend our scarce change resources building an expensive narrow impassible canyon.

This week I want you to look in your work for ifs. What must change to deliver the expected value? Then look at your superior architecture. Where does it constrain you? Prior decisions that must be honored, even while they restrict your creativity and freedom. What uncomfortable facts must be addressed? What must you seek permission to change?

Then you can do the math and help your stakeholders. Run the target architecture governance checklists. Confirm that you have informed your stakeholders about:

• all the work required to reach the target state
• all the sources of uncertainty (risk) in successfully accomplishing the change
• how benefit is realized

The deeper question is, are you delivering the architecture required? My stakeholder had shopped for a solution. I converted the ask to an architecture project that enabled an S5 box—best-in-class and extreme enterprise agility. The benefit was continued exploration of better thinking, situational awareness, and communication. They needed the freedom to spend a few decades building transitory disposable solutions.

Next week we'll start the shift to after the decision to act. How do we communicate with implementers—product owners, agile development teams, transformation portfolios, and old-school waterfall projects. How we enable that stakeholder to guide the work and test whether they are on track to harvest value?

As always, I look forward to your feedback and comments.

Have a great week!

regards

Dave

Dave Hornford
Conexiam

PS: Old school 9-inch grayscale leapt past pens, paper, and chalkboards with live visualizations. Today, we'd reach for modern cloud and AI workers to do the same thing—enable our stakeholders to get what they need. Our Capability-Based Planning Guide covers how my team uses basic architecture techniques—P3 and S5—to capture hope and limits before we ask for permission to interfere with a successful organization.