Strong Enterprise Architecture Builds the Off-Ramps

Continuation Must Be Earned

I think about the default answer—what is the position that doesn't need to be proven. What position is accepted without compelling evidence and explanation.

In criminal law, 'guilt must be proven beyond a reasonable doubt'. Think about the default—innocence. There is no obligation for a defence team to even 'point out the prosecutions flaws.' There are many cases where the defence rests. More importantly, there are a plethora of cases where the prosecution team doesn't even try, when they know the presumptive case will win.

All because the default position is innocence.

Let's dig into the presumptive case in our architecture.

When we kicked off this series I laid out the uncomfortable truth that change success is unlikely. Forrester executive survey report the transformation benefits the executives claimed to achieve vanish over three years. Forrester makes me wonder what 'success' the Chaos report says a minority of projects deliver?

I think it is just activity, dressed up in a green PowerPoint success-suite.

Here is my thesis—most project waste our organizations funding. If, at the end of the major initiative to modernize my portfolio and retire technical debt I have a lot of obsolescent technical debt in the portfolio why? Why didn't I spend all that money and energy on a new product?

That makes the default position at the VRP boundary, pivot or stop.

Yes, by default jump to a more value per effort alternative. Pivot!

I know your head is spinning. You instinctively want to finish the job.

I am aggressively challenging this position because our professional responsibility is to minimize squandering of precious change resources.

It is also why we talk about value-resting-points and economics. Most planning work is designed to fail. Forester, the Chaos report and others keep showing the design works—we do not succeed.

Planning the Pivot

There are many points in our EA consulting where I get unbelieving stares. Telling an EA Team the default position is stop or pivot always gets unbelieving stares.

Let me unpack the logic.

When you have an architecture roadmap filled with value resting points pivoting happens by design. We can treat the architecture roadmaps just like how we use Google Maps. Responding to traffic, construction, accident alerts. Responding to unplanned side-journeys for gas or lunch. Responding to changes in plans when we shift the picnic destination.

Just this weekend I shifted my picnic destination. Iron Mine Bay is an easy trail to a lovely pebble beach cove. Some of the picnickers found the windy drive nausea inducing. We pivoted! In the end, a lovely picnic in East Sooke Park not at Iron Mine Bay. 100% of the picnic-on-the-sea-value. Much lower cost.

When we build large elegant programs that only delivery any value at the end we build brittle failures.

This fix is to just don't do that.

Last week I told a story about using Elastic Observability to improve operations. Value was SRE reducing toil and development improving performance and cost. Without achieving the value adding more Elastic licenses was simply making IT operations more expensive.

Most organizations get confused right here. They want less toil and improved performance and decide to implement Elastic. They tell the boss, and the boss' boss, that Elastic provides cool insights and facilitates better operations. They build a plan to implement Elastic.

They built a large brittle plan to increase costs and not improve operations because they failed to address the Gap. The Gap was not don't have Elastic, the Gap was don't use real telemetry to improve. The Gap was a a weak capability.

I'll bet they even piloted Elastic, with a pilot that proved Elastic could monitor. The pilot needed to be will improve operations. The first measure of success should have been turning Elastic's cool insights into SRE and App Development backlog. The parade should have been cleared backlog.

If that didn't happen what was the assessment of the pilot?

You got it. Missed, let's Pivot.

When the project isn't delivering better operations and wants to do the obvious thing of increasing IT cost by installing more Elastic licenses what is the assessment of the VRP?

You got it. Missed, let's Pivot.

A simple PowerPoint highlighting the amazing success of the implementation team, and the need for SRE and App Dev to onboard the amazing insights. A re-gigged project that explicitly harvests value.

If you want to get to best-practice when the pivot happens deliberately use the value heuristic—Value = Benefit/Uncertainty - Cost^Uncertainty. What is toil, app performance and infrastructure savings worth? Challenge SRE and APP Dev to explicitly report on improvements.

I know you can see you just created a virtuous feedback loop. The measure of better operations is better operations not more installed dashboards.

The power of VRPs is every EA use case (strategy, portfolio, project, and solution delivery) combine into a single moment of implementation governance accounting. Bang!

Right here you have the value measures to prove the strategy and portfolio are moving. To confirm the project will deliver value. To test the solution design is on track. You can look backwards and look forwards.

When I lean into VRPs I do not need to wait for a portfolio review. The VRP gives me value measures, gaps and expected changes. I can look at every release, every project initiation, every phase and ask 'are we on track'.

Returning to the Elastic example. Frankly, I don't care if the teams use Elastic, or Splunk, or Azure's thingy. I want the value. Because I started with my business architecture and the shorthand of a capability I know organization, process, applications, data, and infrastructure are just components to be adjusted to create the outcome my stakeholders want.

When we are 'on track' I shift my gaze elsewhere. When we are not, Bang! I am talking about the miss. If I can guide the implementers, great. If not, the stakeholder can guide. The earlier we jump in the less likely we need to stop or pivot.

Communicating the Pivot

A common fear of Stop and Pivot is what will others think? How will the boss react? How will the boss explain it to the boss' boss?

Simple. With the stunning Powerpoint I just mentioned. The one highlighting the amazing success of the implementation team, and the new focus of onboarding the amazing insights.

Or, the private chat that says 'we are cutting our losses. The operational changes have run into headwinds, and we are going to improve operations by ___.' You had better believe the smart boss, supported by a strong EA Team, had already told the boss' boss that the hard part and the value producing part was change to SRE and App Dev. The bosses had already talked about cost and risk.

Frankly, the conversations and communication is easier when we have an architecture roadmap filled with value resting points. In this case I had a set of independent operational and AppDev improvements. My stakeholder had pre-packaged pivots, and absolute clarity of the value producing part of the project and where her risks lay.

My stakeholder had been grilling the poor PM and implementation team about SRE and AppDev actionable insights from the day they proudly mentioned dashboards at an update. She knew Elastic would be wonderful if the teams changed. She knew they didn't want to change. She knew AppDev was seduced by their users dancing on tables, while the entire product family had a cost problem big enough Finance was using it as an example.

When the trajectory of the implementers, SRE, and AppDev to not delivering value was emerging, she started prepping her boss about the pivot. I believe they even suggested their careful management had lowered costs—after all they avoided shelf-ware. They avoided a new line on Finance's slides.

Communication is easy. Communication is the stories we tell in public.

Communication and public story-telling are trivial if you know the path to value.

Let's do the math. We got permission to change—to implement Elastic and then alter SRE and AppDev practices—to deliver value. Value is better operations, a better cost curve, and better performance. Missing these meant we were better off not spending to not create value.

In private, we have the hard conversations. We explore architecture alternatives, assess the architecture roadmap, and do the reporting on architecture governance. Including the hard conversations about recovery when value is at risk. The conversations where cancelling, enforcing, and surrendering the value are considered.

Hard conversations, where we tell our stakeholders uncomfortable truths. Those that start with the 'Power of And' combined with the 'Reality of If'.

Never confuse Planning the Pivot with Communicating the Pivot.

Conclusion of Evaluating Off-Ramps

Your stakeholders own the architecture decision because they own communicating. Standing on the rooftops and claiming credit. Explaining to the boss' boss' boss what went wrong, and what they are doing next. I've been there, done that, and have a drawer full of accountability t-shirts.

I love my job providing crisp advice. Always thinking further about value—Value = Benefit/Uncertainty - Cost^Uncertainty. Never stepping far from the TOGAF Phase H value realization assessment.

I always own my stakeholder's architecture decision like it was the best idea ever! After all, they took my advice. Then asked the bosses to give her permission to change a successful organization to make it better.

I own strategy, portfolio, project, and solution delivery decisions. I even keep track of the traceability of architecture decisions walking up the architecture deconstruction. Traceability improves ownership. Traceability tells me what is victory. Traceability is simply using my superior architecture.

There are other things I need to keep track of because enterprise architecture is aimed before the decision to act. While I think in targets, architecture roadmaps and VRPs my implementers think of releases, sprints, phases, and project. I think in possibilities. My implementers think in hard reality.

My stakeholders spend some time with me considering possibilities. As fast as they can they switch to driving reality. I need to know when the decision has been made. When I switch from exploring possibilities to owning the decision, I become the Balrog.

I become a foe beyond the power of any misguided implementer trying to steal my stakeholder's funding and authority for their own confused purposes. All day every day I will guard the expected value.

As long as that Observability project is chasing improved operations I do not care how they do it. I'll even listen to a discussion about Open telemetry and rolling our own platform—but I'm running the value heuristic testing for where they are adding cost and piling up uncertainty on the value delivering ifs.

This week, I'm going to return to the value challenge. Look at an inflight change—project or product release. Do you have any grounds to step in? Look at the TOGAF implementation governance checklist—Did the organization embarking on a change reasonably interpret the target architecture’s guidance and constraints?

Do you have an architecture or an opinion? Bluntly, to be the Balrog and drag a set of misguided implementers in-front of a stakeholder you need an architecture. You need to have done the work to produce architecture views. You should have a crisp VRP

If not, what are you doing to gain the position to guard the stakeholder and guard the stakeholder's expected value?

Next week I'm going to look at how we put TOGAF Phase H into action—linking value realization to product release, portfolio reviews, and project phases. How we do the work to make a recommendation to continue, stop, or pivot.

Have a great week!

As always, I welcome your feedback and questions.

Regards,

Dave
Dave Hornford
Conexiam

PS. Over the summer my consulting team is having me take these messages in a different direction. We'll be diving into the developing of an enterprise architect focused on the sweet spots of supporting portfolio and supporting solution delivery. Their objective is a refresh of our practical training program EA with TOGAF and Navigate.