And then? Then lay out the core tools and method—Navigate and TOGAF—that I keep speaking to.
Let's start with the elephant in the room. Our organizations are successful. We create products and services our customers want. We profitably engage with our customers. We deliver valuable products and services.
We are not broken.
But, we are not happy.
These two statements are the core of the guiding effective change—we are not broken and we are not happy.
Because we are not broken, every change proposal must earn permission to interfere with an organization that is successful. That's right, earn the permission to interfere.
Because we are not happy we want to change our organizations. Often radically. Using phrases like transformation and modernisation.
I know this is radical framing. Just think about how uncomfortable my statement that every change proposal must earn permission was. It ran contrary to built-in assumptions.
My radical framing grows from the simple fact that most changes fail.
Doubt me? Cruise HBR, MIT Sloan, or even Management and Business Review. Every issue is filled with articles that speak to the difficulty of successful change. Every issue is filled with articles that promise to help you effectively change your organization next time. Every issue.
No one was surprised when Forbes led with the MIT/NADA analysis that 95% of AI pilots failed. 95%. Spend, churn, pilot successes and failure to scale. Failure to move the P&L.
No one is surprised when the Standish Chaos Report year after year after year confirms that yet again the majority of projects fail. Fail the basic test of delivering what the project promised. We haven't even gotten to projects that failed to improve the business. Most simply fail to deliver the baseline promise.
No one is surprised when Forrester's executive survey finds transformation benefits fade away and are usually gone after three years. Makes you wonder if the benefits were ever there.
Our profession—enterprise architecture—exists because not improving is normal.
I know enterprise architecture works. My career, Conexiam, and the best-practices of our profession exist because when done well we change the story. We successfully transform our organizations.
We've been there. Not just incremental changes. Transformations.
Over the next few weeks I want to work with you and change your story.
Ships don't slide down the Niagara Escarpment
From anywhere in the world,
with any cargo,
the Welland Canal lifts ships the last 100m
Role of Enterprise Architects
First, the bold claims.
Our profession—enterprise architecture—exists because change activity that generates waste instead of improving our organizations is normal.
Our profession—enterprise architecture—consistently succeeds at guiding effective change.
Second, the hard fact.
Like most skill based activities, there is a wide difference between best-in-class and average.
Like most skill based activities, the best don't use different methods, or tools. They do the same things better.
Third, the principles and practices are consistent, adaptable, and fairly easy to learn. I will admit at a few points they are entirely counterintuitive-sort of like the Heisenberg uncertainty principle, where the more precisely you know a particle's position the less certainty you can have about its speed. Seriously.
One of the most powerful things an architect can do is help a stakeholder decide what not to do and help them stop in-flight change. Seriously, completely counterintuitive. To get better at guiding effective change you have to lead with not changing. Or, stopping in-flight change.
Our profession is based on a clean cascade.
We can help with Strategy:
“we defined what matters”
We can help with Portfolio and the classic Architecture Roadmap
“we funded the right things, and know the path”
We can help with Project:
“we know what value we are going to deliver”
We can help with Solution Delivery
"we know how to constrain the designer and implementer to ensure value"
The stress is on can help.
We can step in at any point on that cascade and help. Everything we do is based on traceability and contribution.
I didn't have to be there when the strategy, vision, and objectives were selected. I didn't need to be there when the portfolio and roadmap was approved. I don't even need to be there when the project was structured. I can step in and help at the last minute because I can walk the chain of decisions and reverse engineer what is every solution's value contribution, and what freedom the designer and implementer must lose to do our bit to move the ball.
I'll admit that I feel sad when I see a strategy, roadmap, or project that could be better.
None of us need to be in the room when an architecture decision is made. Stakeholders don't need to ask our permission. They don't even need to follow our recommendations.
All I ask is for a resolute decision. After they make one I am going to own it like it was my favourite idea of all time.
And when we get to harvestable value, I will apply all the rigour of my profession to help them make the next resolute decision—whether to stop, pivot, or even continue charging forward demanding more of that harvestable value.
And then, whatever their choice, I am going to own it like it was my favourite idea of all time.
Before my stakeholders decide I will think, analyze, debate, and recommend. I'll even argue to the line of insubordination based on my rigorous architectural analysis.
When they decide, magic happens. I am after decision. My authorized decision makers did their job. They made a hard call. Often in the face of contradictory evidence. Rarely with any certainty. Now it is my job to get on board, and move the ball following their play.
After all, if I want the decision power I can always get their job and take their accountability. Been there. Done that. Learned more about EA when my ass was on the line than at any point in my career.
Whenever my stakeholders make a decision I will own that decision like it is my favourite idea of all time. I'll own it because I've been there, and done that, and have a drawer full of accountability t-shirts. We owe them our active championing. Without implementation governance that change isn't going to complete. And we will never make our organizations consistently, sustainably, gloriously better.
Concluding Delivering Value, not Activity
Changing our story is not about changing what we do. It is all about changing how we use the same methods, tools and processes.
Every enterprise architect can speak about a target, models, gaps, and work packages.
The best look first at value. Value is elusive. Value only is measured in the eye of the buyer. Lean Six Sigma tells us value is something that the buyer will pay extra for. Or, if it is missing won't pay at all.
Value is the outcome of the change our stakeholders will pay for. Shockingly often almost directly—they will stake their careers, bonuses, and jobs on a change.
When we do best-in-class enterprise architecture we guide change to deliver value. Not a target, a target is simply a state that has more value than today.
Along the journey from being a successful company which could be better our architecture roadmap is filled with value resting points. Places where our stakeholders start harvesting value.
Places where we ask our stakeholder re-visit their decision and re-assess the target.
Places where our stakeholder can react to the current reality. The moment to assess whether the next stage of the journey has earned permission to interfere with a more successful company.
Places where they can stop, pivot, or even continue the journey. All while they are already harvesting value.
Enterprise architecture is conceptually simple. Given a successful company, we look at where our stakeholders are not happy. We do the work to create architecture alternatives with different sets of value, effort and uncertainty. Most are rejected. The few that are selected are actioned—strategy creates portfolios, which create projects, which have solutions. All deliver the expected value, for an acceptable effort, within tolerable uncertainty.
Every time we reach a stage where there is harvestable value we help that stakeholder decide whether to stop, pivot, or even continue the journey to the next increment of harvestable value.
Along the journey, we guard the expected value from well meaning people. Who inadvertently will distract the change from delivering the expected value, for the acceptable effort, within tolerable uncertainty.
When we do this, our organization succeeds. We are the few with sustainable transformation benefits. We are the minority with successful projects. We are the 5% who move the P&L with AI.
We are the best enterprise architects, who use the same industry standard framework, methods, and tools better.
This week, my challenge to you is introspective. When your stakeholders make a decision are you owning that decision like it is your favourite idea of all time. Do you relentlessly drive to their value preference? Do you structure the entire change program around delivering that value within acceptable effort, and tolerable uncertainty?
The most uncomfortable introspective question—look closely at your current architecture roadmap. Did you implicitly assume continuation was guaranteed? If that choice isn't being made consciously—across strategy, portfolio, and project—then you aren't driving value. You are managing activity.
Next week we will dig into value—capability, efficiency, enterprise agility, and even ROI. We'll talk about how to measure it.
As always, I look forward to your feedback and comments.
Have a great week!
regards Dave
Dave Hornford
Conexiam