Navigate Best Practice—Integrity of the Unbroken Contract

TOGAF Says Implementers Own Implementation Decisions

Right in the TOGAF framework Practitioners’ Guide Section 15.2 (Roles, Duties, and Decision Rights), "All decision rights about proposed implementation choices, such as design, product selection, and change sequence, are vested with the implementer."

Unambiguous. Implementers own all implementation decisions.

As unambiguous as 'Stakeholders own the architecture. They provide priority, preference, and direction. All decision rights about the Target Architecture, and any relief from and enforcement of the target, are vested with the stakeholders.'

Unambiguous. Stakeholders own all architecture decisions.

We put Section 15.2 statements together—stakeholder decision rights and implementer decision rights—together with Carver's unfettered decision space. Using the implementation governance checklist and everything snaps into place.

Did the implementer reasonably interpret the Target Architecture’s guidance and constraints? In Carver terms, did they follow the explicit performance expectations and constraints surrounding their decision space?

As I said above, tell them how victory is judged. Add the minimum constraints. Get out of the way. Expect excellence.

Give your implementers an easy problem. Give them a hard problem. Give them a wicked problem. It doesn't matter, because if they know the rules of the game they will deliver every achievable victory. Every achievable victory. Every time.

It follows, as enterprise architects we cleanly define the rules of the game—how score is kept and what is not allowed. Our tools the trade—gaps, work packages, VRPs, dynamic roadmaps and architecture specifications. Guidance, constraint, and the maximum local freedom.

Frankly, getting out of the way is one of the hardest things best practice enterprise architects do. We are passionate and committed problem solvers.

To develop a target I have to think of one plausible way to reach target. Without a plausible implementation, I have exploding uncertainty draining the benefit to zero.

That plausible implementation is the way I'd do it. It appeals to my experience, preferences, and biases. I can rattle off the obvious reasons to do things my way. Beware. It is a very short step from being in love with the way I'd do it to pretending omniscience and infallibility.

To develop architecture specifications, I need to undo omniscience and infallibility. I need to shift the way I'd do it to rules. Then shift the rule to standards, standards to patterns, patterns to principles. Always looking for the last shift, to no constraint at all.

Falling in love with my approach leads to the failure of hubris. Instinctively, we add more and more constraints. Each constraint unjustified. Each chipping away at our implementers' freedom. Each limiting their creativity and genius.

Pause and think about it. When you unleash the domain expertise, experience, passion, creativity and genius of your implementers they will always make you look good. Damn good.

They make our ideas real.

They make the stakeholders hopes and dreams real.

They will transform our organization.

When Things Go Wrong

Things always go wrong.

It can be as simple as a legacy data flow. It can be as insidious as an implementation choice made decades ago. It can be time pressure.

It can be you listened to me, then gave your implementers a hard problem, a harder problem, and finally a wicked problem. Sometimes, to follow my sports metaphor, our implementers just can't put it in the net. Sometimes they cannot win the game.

On that sad day we move on to implementation governance checklist question 2 through 7.

Question 2 through 7 are very like developing a target. The difference is we are already spending so every choice has costs to be bourn. Our role is to guard the maximum benefit.

To think about benefit, I run to the Navigate value heuristic:

Value = Benefit/Uncertainty - ((Cost_Implementation^Uncertainty) + (Cost_Operations^Uncertainty))

I run to the heuristic because when something has gone wrong one of two things is happening:

• the expected benefit is vanishing
• the expected costs are increasing

Or, the worse case, benefit is vanishing and costs are increasing. However we do the math, available value is evaporating.

Let's go back to my simple strong EA Elastic Observability example. We are implementing Elastic. We expect two benefits. First,  IT operations to have better insights and run a better application/infrastructure environment. Second, application development will have better telemetry and be able to improve their applications. As an enterprise architect, I don't care about anything inside the implementer's decision space. I only care about the value, benefits, and constraints the architecture imposed on the project.

We all know the story when something goes wrong. The implemenation team comes to the update meeting looking sad. They'll tell us one of four things has gone wrong.

• The project can only deliver a narrower impassable canyon—benefit collapse
• The project needs to do extra work to close the gap—cost increase
• An architecture constraint is blocking success—non-project benefit collapse or non-project cost increase
• They failed to follow an architecture constraint—non-project benefit collapse or non-project cost increase

If you have a weak portfolio architecture and implementation governance, you can expect implementation teams to dress-up delivering a narrower impassable canyon as victory. They will highlight they are de-risking, meeting timeline, and even saving money. From a portfolio architecture perspective they are explaining why the project should not have been funded and that they are stealing the portfolio funding.

The implementation governance checklist question 2 through 7 are about creating your stakeholder an architecture compliance recommendation. The Elastic project was funded to have SRE/Operations run a better application/infrastructure environment, and have application development improve the application portfolio through telemetry.

You have three real choices:

• Move forward with the extra work to claim the expected benefit delivering less value
• Reduce expectations and relax a constraint reducing project or enterprise benefit delivering less value
• Conclude the benefit/cost calculation will always be negative and kill the initiative

Testing the Recommendation

The  implementation governance checklist questions 2 through 6 are simply tests whether you did your job. The checklist asks:

• Whether SMEs agree to the facts and your interpretation (question 2)
• Whether the SMEs agree to your recommendation (question 3)
• Whether your architecture analysis supports your conclusion and recommendation (question 4)
• Whether there are special issues generating uncertainty your stakeholder should know about (question 5)
• Whether your stakeholders understand the impact this issue will have across the architecture's expected value (question 6)

I know, tough governance questions. All asked to the enterprise architect, about the architecture.

All because question 1 blew-apart the stakeholder's approval of the target.

Let's go back to the Practitioners’ Guide table 4—the stakeholder approved interfering with an otherwise successful organization to get something more. In return for that benefit they were prepared to do work and take risk. The math showed sufficient value after adjusting for risk.

Question 1 is wide open. It asks are they following the architecture. That question is big. It will be tied to every concern every stakeholder had. It will include:

• Are they delivering expected benefit?
• Are they within expected effort?
• Is their implementation sustainable?
• Did they follow all the constraints?

Every time our implementers did not reasonably interpret the architecture is a sad day. It doesn't matter why, the outcome is the same. Our stakeholder will not get what they agreed to pay for.

This is why the enterprise architect has to jump back in and come up with a recommendation to the stakeholder about their target. Not a discussion with the implementers about implementation choices. Not a negotiation with a project lead about scope. A recommendation to the disappointed stakeholder.

I hate these recommendations. I hate it when I have to admit to myself that not even my implementers could make my ideas real. If my implementers couldn't make the idea real, I am faced with the uncomfortable reality that my analysis was faulty. That I misadvised my stakeholder.

This situation is very different than when my stakeholder doesn't follow my recommendation. Then I have to conclude that I didn't understand the stakeholder's constraints, risk appetite, or priorities.

When my implementer doesn't deliver, either I failed to communicate. Or my analysis did not meet my standards.

Concluding Integrity of the Unbroken Contract

Right here we are at the center of best-practice enterprise architecture. Why the profession exists.  Why complex systems like the TOGAF framework exist. Why we use formal models. Why we work hard to build architecture roadmaps. Why we work so hard to de-risk change initiatives.

Enterprise architecture is hard. It's complex. Guiding change has real impacts to our organization.

Every time I must develop a non-compliance recommendation we are in a pickle. The implementation project has burnt cash, and is burning more cash. Time is burning-down expected value contribution. I am under the gun.

This is why TOGAF Phase G stresses enterprise architect engagement. Why we draft an architecture contract in terms the implementers can follow. We perform implementation governance reviews early with an eye to capture problems early.

Every earlier catch is cheaper than a later catch. Early catching is constant in TOGAF. Phase A tests whether  an idea can pass minimum hurdles? Phase E's dynamic roadmap is full of VRPs providing de-risking stop, and pivot steps. Phase G guides us to review at initiation, design, and major phases. As a last resort, at go-live.

Whenever we catch the shortfall, our action is always the same. A recommendation on what to do—double down and spend more, take a lesser benefit, or scrap the work. Scrap at Phase A is cleaning the whiteboard. In Phase G we are scrapping things we just bought. Things we hoped would make things better. Things that everyone will secretly hope can still make things better.

Here is my challenge this week. Look at the guidance in your architecture. What are you doing to help your implementers? Are the rules of the game—how to win and what is prohibited clear?

Go further, can you trace the value your architecture specifications are enforcing? When you laid out a pattern did you include the hard bit in Navigate pattern template to enable value calculation?

Next week we'll move to the business architecture domain. Given the information systems architecture must enable the business architecture, we need to know it. Our business architecture has many uses. First, it explains the contours of the Enterprise Context. Second, it shows where and how my organization generates value. Last, its tells me the boundaries of change. Capability models have a special role in the boundary and needs of change. I think it will be a fun series.

Have a great week!

As always, I welcome your feedback and questions.

Regards,

Dave

Dave Hornford
Conexiam