Before the decision to act, I will analyze and explore any architecture alternative. I will join them in blue-sky what-ifs. I expect most of the plausible ideas to go down in flames. I will celebrate every time we find an idea that fails to clear their minimal cost-benefit-uncertainty hurdles. I celebrate because killing these doomed ideas is the cheapest way to build change capacity.
After they make an architecture decision, I own it. Last week you heard my Terry story. Where owning the resolute decision meant speaking with Terry's voice and shutting down an idea, I had passionately pitched to Terry. So passionately, I closed on insubordination. So passionately Terry asked if I believed so firmly, did I still want to be involved. [I owned the decision so completely that more than once I reminded Terry when he started to stray.]
When I owned Terry's decision, it wasn't sycophancy. It was architecture governance.
Best-practice enterprise architecture fails without best-practice architecture governance.
Fails.
When I owned Terry's decision, authority for every subordinate decision seamlessly flowed. Every subsequent decision that traced to my key stakeholder's preferred value, benefit, constraint, and risk appetite was essentially made by the stakeholder. Failure-resistant architecture governance.
Over the next few weeks, we are going to nail down best-practice architecture governance. We are going to nail down architecture that:
- helps change leaders gain permission to rework a successful organization
- helps change leaders get an implementation that delivers what they promised in return for permission to rework a successful organization
This week I'm going to start with the governance cascade. To give us a mechanism for direction to cascade down—Performance Expectations, Constraints, Risk Appetite. And a mechanism that enables controls to report up—Objective Verification.
Drive without stopping
and keep the cow
Tools of the Trade
I use my Terry story because it is visceral. Speaking with Terry's voice that afternoon is seared into my memory. I also know the backstory.
This wasn't Dave and Terry. We had an architecture based on analysis, trade-offs, and resolute decisions.
When we spoke about the proposed pivot, Terry was looking at the capability model. He had watched his executive team score 105 logical processes, and had the score summary and implication slide at hand. He kept flipping to the value-delivering project controls data flow diagram. Terry had personally briefed his largest customers on the transformation.
This wasn't Dave and Terry—it was an advisor briefing a stakeholder. It was textbook TOGAF Phase H where solutions, projects, and portfolio VRPs collapse into a value decision moment.
Negative Space Unleashes Freedom
TOGAF, through the Leader's Guide and Practitioner's Guide, recommends John Carver’s policy governance approach. Carver has a brilliant and simple governance model—in a decision domain, the decision maker has absolute freedom, except where they have had their freedom has been explicitly limited.
Unlimited freedom of choice is the starting point. An objective followed by a blank piece of paper.
It certainly makes implementation governance easier. Jump to the implementation governance checklist's first question—Did the organization embarking on a change reasonably interpret the target architecture’s guidance and constraints?
With a blank piece of paper, the answer is always yes. Ok, there are a few edge cases where the implementation is so mis-directed that it couldn't conceivably deliver the outcome. But let's be honest, simple project initiation will filter them out. So we are back to, with a blank piece of paper, everything is compliant.
Every single element of superior architecture constrains an implementer's freedom. Every single element of the target architecture constrains an implementers freedom. Every single element in the architecture roadmap constrains an implementer's freedom.
Outside of those negative constraints, unlimited freedom of choice.
It's right there in TOGAF, in the Practitioner's Guide—the implementer owns all implementation decisions.
We are left with a counterintuitive situation. Negative space defined by constraints unleashes creativity. All because the implementer does not have to explain anything inside their decision space!
Unleashed Creativity Frees Implementation Governance from Trivia
An EA Capability is like every other capability. It can be parity, advantage, or superior. Parity EA Teams, Superior EA teams, and weak teams use the same words. We all read the same TOGAF.
I always talk about best-in-class EA. I always talk about a superior EA Capability. I always talk about using the same TOGAF and doing the same things differently. Doing them better. Doing them in a way that guides effective change. In a way that helps an organization that is not broken, but not happy, improve.
Parity EA teams drown in trivia.They fuss over every detail. They engage inside the implementer's decision space.
Sadly, they do this without their Terry's authority seamlessly flowing from architecture decisions. Remember, an architecture decision can only be made by a stakeholder. All because our stakeholders own the outcomes, resources, and spend. This is why TOGAF transitions from candidate to target architecture in Phase F, when the target is funded. Without committed resources, without the decision to act, all we have is a candidate. We only have a good idea.
We have a blank piece of paper.
Despite this parity, and weak EA Teams are very, very busy fussing over details. When I read common literature, I see the problem. These teams complain about their lack of mandate because when they jump into the implementer's decision space, the implementers go in a different direction. The implementers complain about interference.
We have all seen the results of this. Days spent in detailed reviews that net down to a negotiation. The irony being everyone involved in the negotiation is trying to do the right thing. They never have the means to determine a priority or an authoritative preference. Even break a tie.
Carver warned about this. If you do not provide an objective and constraints, you have to get involved in every decision. Looking over the shoulder of the person you expect to deliver. Crippling their creativity. Bogging down in trivia.
All because of a blank piece of paper.
Best practice has negative space. Decisions the implementer cannot make because they were already made.
In my Terry story, I had a capability model. I had an S5 and a P5. I had a 'value-delivering data flow.' I had 105 process areas scored for competency, automation, agility, and performer. I had a lot of negative space.
When it came time to talk about ERP customizations, I had parity—buy a suite, get an implementer with best-practice knowledge, require out-of-the-box, and adapt the organization's process and the organization to support best practice. That is a bucket-load of negative space. We have a darn clear answer to the customization question. No.
Except for one process. It was a P5. Yep, an Automation 5. Here the answer was you must customize the ERP to remove all manual steps. Not can customize. Must customize. When my implementer fretted, 'This isn't the current process'. When they asked, 'What about all the manual approvals'? I had a very clear answer—end-to-end automation, change the process. If necessary, change the organization.
When they went to the process owner and fretted, the process owner knew what to do. They pulled out the 105 logical processes scored by the executive team, saw P5, and said, 'Tell us what the new end-to-end automated process will be'.
I love negative space. I enjoyed the implementation governance review—are there any manual steps in the process? Every time they tried to explain, 'it's hard', or 'some user is sad', or 'we are worried about', I just asked one question, 'Shall we go to the executive team and explain they cannot have a P5'?
I was prepared to make a non-compliance recommendation any day. I was prepared to contrast an annual saving of 2,000,000 labour hours with 'hard' and 'sad'. I was pretty sure my stakeholders were prepared to pay to get our ERP integrator to do something hard if it saved a few million hours of labor. I knew my stakeholders thought these very expensive computers were supposed to improve productivity.
Concluding the Architecture Governance Cascade
Negative space and open space. Decisions already made and open decisions in the hands of the person with an improvement to deliver. An implementation team closest to all the details of who, what, where, and how. A team who were specialists in the ERP, the specific module, configuring and customizing the ERP, and who showed up with a resume brimming with industry experience. They owned their decision space.
They were my EA Team's rocket fuel. We didn't need to know very much under the ERP hood, because there were expert subject matter experts at hand. Yeah, expert SMEs. It was sweet!
We saw they were struggling to figure out how to engage with us. They expected to be quizzed about trivia. When they said the customization was hard, they expected a detailed conversation about native ERP workflows, custom code, and stuff. Instead they were asked about sustainability through an ERP upgrade. They expected someone to jump in and fret the details. Someone who would stop guarding value and start co-designing the solution. Instead they got someone who said, 'If it doesn't add sustainment cost, I do not care'.
When they said, 'Some users were sad', they expected a conversation about who and why. Frankly, they expected t retroactive relitigation of a clear architecture decision. They expected the solution boundary would be renegotiated. They got P5—change the process and organization as needed.
Now, when they said they were worried, we stopped everything and sat down. I had a worried SME. Worse, I had a worried expert SME. Hold the phone! I needed to know what they knew that I didn't know. Worried expert SMEs are dragging trainloads of unexpected uncertainty into the room. Trainloads of uncertainty terrify me.
Think about it. A worried expert SME slams us outside our risk appetite. They know things we don't know. Immediately, we're red. Risk Appetite 101 says stop the presses and immediatly get to green.
I didn't have a clear answer to their worry, that seamlessly flowed from superior architecture. That meant I was no longer cleanly interpreting the architecture in Phase G. I no longer had the authority to speak with any Stakeholder's voice.
I needed an architecture decision. So, I went and got one. With a decision, we had more negative space, and the worry vanished. The vanishing worry took the trainloads of uncertainty with it. Bang! Risk Appetite Green! Full steam ahead to an end-to-end automated process.
Here is my challenge this week. Do you separate negative and positive decision space? When developing architecture, do you know where your stakeholders have no freedom of choice? Do your implementers know where they have no freedom of choice? Without this how do you craft your architecture contract?
How do you perform implementation governance and keep your implementers in-bounds? Please don't say you climb into their decision space and engage in evaluating implementation decisions. Fly, you should be hearing the Balrog's drums.
Next week we'll move further into architecture governance. We'll cover the messy reality of competing priorities and conflicting authoritative decision makers.
Have a great week!
As always, I welcome your feedback and questions.
Regards,
Dave
Dave Hornford
Conexiam