Strong Enterprise Architecture Frees Implementation to Create Value

Guarding Value

A few months ago, The Open Group asked a few of us to refresh the Architecture Compliance Review Checklists. The old document suffered a serious flaw. It implied that a compliance checklist was not explicitly drawn from the Target Architecture. It implied that constraints not in the architecture should be assessed because they were good ideas. This is not governance guarding value. This is applying opinions, preferences, and lazy thinking. Never confuse opinion and preference with architecture governance.

To correct the mistake, we leaned into the TOGAF implementation governance checklist's first question:

• Did the organization embarking on a change reasonably interpret the target architecture’s guidance and constraints?
  If yes, accept their interpretation as compliant and address any issues through a change to the architecture

What a powerful question. Did the people executing the change reasonably interpret the guidance and constraints in the target architecture? This is implementation governance 101—performance expectations, constraints, and risk appetite.

Guidance and constraints will be:

• Architecture specifications
  Property, Principle, Pattern, Standard, Rule
• Gap or Work Package
• Acceptance criteria for a VRP

Inside the architecture, all guidance and constraints are traceable to:

• Benefits we want to earn
• Downsides we want to avoid
• Uncertainty we need to mitigate

S55 and P33 as Guidance and Constraints

I look at the simple Capability properties—Competency, Agility, Automation, and Efficiency—guidance and constraints leap off the page.

S (Superior) means we want to be past the productivity frontier and invent the next best practices. In terms of software, this is custom built. You cannot buy better than everyone else. Ever.

P (Parity) I want to be in the sweet-spot of the productivity frontier. Right where the cost curve for the next increment stops being linear and curves up. You know when you push down on the gas, the tachometer jumps another 1,000 RPM. But the speedometer just budges a bit. That is past parity. When you start working too hard for the next increment. In software terms, I am looking for a suite that addresses the entire capability. Where standard industry practices and metrics are pre-packaged. Where I can hire anyone from a gazillion consultants who all have a pre-packaged playbook.

Efficiency tells me how important productivity is. Am I allowed to spend more to get the expected business outcome? Or, do I have to invest to gain more efficient delivery of the same quality? Our mental model is manufacturing—switching from hand tools to a lathe to a CNC. Then offshoring the CNC to gain one more widget per $.

Efficiency tells me not to pursue improved quality or agility. Often Efficiency is tied with automation, but not always. High efficiency can tell me not to automate. We don't gain efficiency with robotic loggers. The price per tree simply goes up.

As an enterprise architect used to working with Navigate and formal models, when I see A35, P33, or P43 guidance and constraints leap off the page. I'll stumble when I forget what properties are in the shorthand.

Working in Phase F at the transition between architecture and implementation, use the TOGAF concept of the architecture contract. Spell out the inferences into explicit guidance and constraints.

Do the basics—document procurement criteria. After all, Parity demands we benchmark and hit the point where the quality curve stops being linear. Procurement should shop for a mainstream suite with demonstrated OOTB coverage, bundled with a cookbook carrying implementer. An A (Advantage) demands a boutique package and a specialized implementer with demonstrated experience scrambling closer to the productivity frontier.

Mixing up these procurement directions means we will overpay for the P and fail to realize the A.

Mixing up these procurement directions means we failed to support the business architecture. Full stop. Failed to support the business. Failed in our professional purpose.

Let's look hard at this. Procurement guidance matters. For a Parity capability, it does not matter how funky the boutique software is. Or the cool guidance you gained from the frontier consultant. You were buying platinum framing nails. 100% waste.

Mess-up the directions for an A (Advantage) and you failed to deliver required value. Required value that demanded a special outcome. Frankly, telling me what a great deal you got on a packaged implementation is testifying for the prosecution at your trial.

Go further, document a work package. I'm always thinking 'acceptance criteria' when I document a work package. Tell the implementer how to know when they are done. This is very important when you are using a transition point. You need to explicitly tell the implementer to stop. Most implementers will assume they are supposed to go all the way to the target. So they will sneak in extra work.

A few years ago, we were improving an IT Operations team. Transition 1 was to implement Elastic observability at one data center. We needed demonstrated improvement in operations before we scaled Elastic across all facilities. During implementation governance, there were one million attempts by the implementation team to do the obvious thing and deploy Elastic everywhere. They saw the obvious thing, and I saw a deliberate effort to defer gaining the experience and operational practice changes that justified expanding the footprint.

Let's take a moment and spell out the value equation.

Value wasn't Elastic Observability installed. That is a project task. Sign-off is easy—product installed, users trained, test cases run.

Value was better operations. This is not a project task, this is capability development. When do we start using Elastic to find issues that trigger the SRE to make changes and prevent outages and slow-downs? When does the Development team start using Elastic to find performance issues and expensive infrastructure use? Then treat them as defects in the backlog. Value came from operational changes.

I know you can see how the bottom-up obvious thing actively undercuts expected value. Racing to extend the Elastic footprint delays the day the company starts gaining value from its investment in Observability.

Elastic was just a means to an end. Without the delivered value, we were prepared to abandon Elastic—to pivot.

Conclusion of Freeing Implementation to Create Value

When my approved target architecture says P33, my stakeholder explicitly decided to get Parity and average automation and efficiency. They are explicitly saying, ''I will forgo the funky optimizations that are possible." Explicitly! They are saying that they will reserve our scarce intellectual resources and capital for where our organization demands more. To where we cannot simply leverage OOTB functionality and packaged services.

Where we demand more I want to harvest the creative power of my implementers. They are closest to doing the work. They invariable have deeper domain knowledge. Yet, every guideline and constraint removes a degree of freedom.

My constraints have to be traceable to value the implementer cannot see and will not value. I never need to tell a strong digital product team to delight the user. They hang with the user. They can see frowns, smiles, and all the delighted table dancing. Most users will even tell them their secret delights.

I need to say, "These are the three acceptable Master Data implementation patterns." I need them to use these three patterns even if it causes the users to wail. I need to say, "You will use a message-based integration (because I need the freedom to add, remove, and alter every player in the process)." I will enforce the message-based integration even if it creates more work. Even if the users cry themselves hoarse.

Again, let's take a moment and spell out the value equation. Sometimes my role supporting the stakeholders requires a hard ass. When my stakeholders are looking for Agility 4 or 5, they don't want freedom. They are demanding freedom. They will pay bills and accept impacts on lesser priorities to gain that freedom.

Freedom to react to sales success and scoop an entire new service into the product. Freedom to replace those users with an army of AI Bots. Freedom to replace the downstream message consumers with a 3rd party.

A few weeks ago I said, 'When my stakeholders make a resolute decision, I will own it like the best idea ever.' Agility 4 or 5 is a resolute decision—they told me the priority is the freedom to react to any threat or opportunity. To own the resolute decision, I'll architect an enterprise agility fence. When I architect an agility fence, that fence matters more than any local table dancing. I'm prepared to enforce the fence. Even if there is wailing and gnashing of teeth. Even if the sprint team posts snarky comments about EA in Slack.

I'll own every stakeholder's resolute decisions. All day long.

My challenge this week is all about value. Look at your current architecture work. Look at in-development digital products. Look at an inflight project. Do you know what the expected enterprise value is? Do you know how that work moves the portfolio needed? Can you trace procurement guidance to a P? How about an A or S? Did you provide this guidance?

The really hard question—do you know when to step in? When to drag the implementers in-front of a stakeholder. Have them explain why they think using the stakeholder's scarce resources to not ensure expected stakeholder value is acceptable behaviour. Do that a few times and two things happen—your stakeholders send presents and you get fewer snarky comments about EA in Slack. Yes, stakeholder presents are a real thing.

Next week we're going to return using the value resting points to stop, pivot, and even continue. Everyone else assumes the world will continue unchanged, that continuing is a given. You and your stakeholders watch the real world unfold. The real world has infinite exciting opportunities and scary threats. Your architecture roadmaps are filled with off-ramps. We'll explore the mechanics of stop, pivot, and continue.

Have a great week! Tomorrow is Canada Day!

As always, I welcome your feedback and questions.

Regards,

Dave
Dave Hornford
Conexiam

PS. Mach 2 at $10,000 a seat shrank the Atlantic, for the few who needed it. Everyone else flies economy in a Boeing. Investing for Superior or Parity is a deliberate business design choice. When our stakeholders make that choice, they are giving unequivocal directions. Grab our Capability-based Planning Guide.