Strong Enterprise Architecture Ensures Value Materializes

Enterprise Architecture Use Cases: Top-Down Value

Everywhere we work we do the same thing—guide effective change.

Everywhere we work we have the same problem—finding change worth doing. Change that earned permission to interfere with our successful businesses.

Years ago, I was working with John Sherwood—when he explained security architecture and SABSA it just resonated. He kept coming back to risk. He'd say risk is uncertainty. That there is a potential upside and downside in everything our organizations do. That risk was the uncertainty you would earn your upside. That risk was the uncertainty a downside would sweep everything away.

Someone would always argue that risk was a threat. John would agree it could be, but wasn't always. Thinking only in threat terms strips the power of uncertainty. Thinking in those narrow terms obscures why our organizations put themselves at risk. Why we launch products. Why we enter new markets. Why we try to improve internal operations.

Why we are willing to change working systems.

John built SABSA around the concept of risk in ISO/IEC 27000—as the effect of uncertainty on objectives.

With John, we crafted Integrating Risk and Security into TOGAF Enterprise Architecture. Today a key part of the TOGAF Standard.

Not for the security part. The most powerful part is helping us enterprise architects understand value.

After all, an objective is about gaining something you do not have. We'll create an objective to have the successful product we do not have. The objective to have a simplified scalable platform can only arise when we do not have one.

Uncertainty tests the likelihood that we will squander scarce time, precious resources, and unique talent on work that fails. Fails to give us what we want, or leaves us worse off than we are today.

Uncertainty walks the entire decision landscape an enterprise architect supports.

• Strategy, where the change initiatives, or portfolios, and their terms of reference are selected.
• Portfolio & product, the sweet spot for enterprise architecture. Where the architecture roadmap provides dynamic investment guidance allowing the organization to incrementally harvest value, while stopping, pivoting, or continuing while everything inside and outside continually changes.
• Project, where specific change initiatives fill in the tapestry of the transition stage. Each living with the constraints of superior architecture while building all of the parts of harvestable, sustainable value.
• Solution Delivery, where we constrain the freedom of very clever implementers to ensure they first do no harm to any part of the target, second do something cool for the sponsor, and third make a measurable contribution to the expected architectural value.

At every level we have clean directions

• an objective to create something we do not have
• performance expectations that define the change role
• constraints that limit freedom
• a risk appetite that spells out the acceptable uncertainty

We have everything we need to govern the architecture development. Everything to govern the implementation

We can trace contribution to the top. We can trace contribution through every level.

We can deliver the critical advice—granting permission. Permission to take our scarce time, precious resources, and unique talent and interfere with something that works ok today.

Remember the number of must-do projects is vanishingly small. The scope of what must be done is even smaller. Virtually every change is a choice. A choice that carries a slightly different mix of potential benefits, possible downsides, scarce resources, and uncertainty.

Right here is the key insight I learned from John—every change has uncertainty we will deliver an upside and uncertainty we will make something worse. John used to remind me there was no guarantee I wouldn't be hit by a car on my way to work.

Without that guarantee you should think about whether to get out of bed in the morning.

My job, whatever level I am working on, is to do the same thing. Within the guidance and constraints cascaded from strategy, or portfolio, or project, or solution, or anywhere in my superior architecture figure out what is the most effective change? Your best advice might be—stay in bed. Today there is a blizzard.

Enterprise Architecture: Objectives and Superior Architecture

I love the sound of superior architecture. It sounds hefty. The word evokes better. More authoritative. Even bearing down from above.

Yet, nowhere in the TOGAF Standard is superior architecture defined. Which created a problem in the TOGAF people certification because it is a concept you need to understand.

I put a tight explanation in The TOGAF® Enterprise Architecture Practitioner Study Guide—'Superior architecture is a shorthand term for prior architecture decisions and the Target Architecture that guides and constrains the current architecture project.'

Prior architecture decisions and Target Architecture. The sum total of constraints that limit every architect's freedom and every implementer.

Stop and think about your real world.

You can be working on some major architecture to enable a divestiture, high level stuff. You are bound by a myriad of prior architecture decisions. Including the one where someone used a bespoke shared system across operational boundaries. With the divestiture, you need a way to remove 15 years of integrated data from a shared system so you can give the buyer their billing engine. They did buy the billing engine and the customer records. They didn't buy our other division's billing records.

Or you can be working on a new product launch for a new division operating in a new region. There is a fancy zero-trust Identity and Access Manager. However, it needs to use an 8-character staff identifier because back in 1972 mainframe DASD was expensive. 8-characters, one byte, was the cheapest identifier available.

Yep, prior architecture decisions that guide and constrain everything we are doing today. We either live with the constraint, or explicitly change it.  Working around these decisions is noncompliance. Yeah, noncompliance. That architecture has not been changed, it remains valid.

Every one of those choices has a benefit. A cost to do. A cost to sustain. Uncertainty dripping corrosively on the benefits. Uncertainty lurking underneath the implementation and operational cost like a time bomb.

Then we get to the other superior architecture, the kind that cascades down from above.

The strategy defined a portfolio, and its terms of reference. The portfolio, and its architecture roadmap, specified a project's value contribution and constraints. The project is filling in the tapestry.

Tapestry is evocative. It sounds exciting. A tapestry would include all the things necessary to open a new market, with an untried product sold by a non-existent sales team, while the new support team stands-up.

Yeah stands-up. A nice way of saying, when the team gets hired, gets systems and processes to support themselves. Works the bugs out. And starts supporting the untried product to new customers.

Ever wonder why project results are so bad? It has nothing to do with implementation quality, sponsorship, or engaged teams. It is the buckets of uncertainty we forgot to account for while talking about the tapestry. The uncertainty corroding some benefit every minute. The effort and scope uncertainty lurking under every activity.

Right here. This is why we have to earn permission to change something that works. There is a real chance the change will deliver nothing. Worse, it might simply make things worse.

We want superior architecture. When some joker suggests extending a common platform to the new region for efficiency I want to know what constitutes victory for the company.

I never care about the project, I know they will take care of themselves. I want to know whether they must take the shared system and live with the common process—because we value scalability, efficiency, ability to consolidate work. I want to know when they cannot take the shared systems—because we value modularity, local optimization, and the ability to restructure for local needs.

It was all in the header—objectives tell me how to win, and superior architecture tells me where I have no freedom.

Enterprise Architecture: Never Solving an Easy Local Problem

Here we face the core difference between average, good, and great enterprise architects—do they serve their stakeholders or do they sell someone else's preferences.

I know it is easy. The joker suggesting a common platform believes in efficiency. Frighteningly often when you talk to them about competing preferences—modularity, local optimization, and the ability to restructure for local needs—they simply look pityingly at you. To them efficiency, scalability, and standardization are so obvious there isn't any other criteria.

I call them a joker, because I am an enterprise architect. I know there is never a universal preference.

Never. Not in the history of the universe. Not even efficiency.

Because I know about superior architecture.

I know that Berkshire Hathaway is designed as a conglomerate and between company divisions they share only one thing—who owns the company. Many of them add the tag A Berkshire Hathaway Company to their branding. Every member of that conglomerate stands alone.

The top elements of your superior architecture are concepts like business model, and operating model.

Let's get blunt and unambiguous, the reason TOGAF says the information systems architect must enable the business architecture is to ensure every good enterprise architect knows the efficiency proponent is a joker. They are not to be trusted.

These jokers have decided:

• some parochial preference is more important than their organizations' superior architecture
• that the problem your architecture project is addressing is subordinate to fulfilling their private preference
• that your stakeholder architecture decisions are ill-informed opinions that must be over-ridden for their preferences

These jokers have decided that best practice enterprise architecture doesn't guide effective change.

I pity the fools.

I've watched our transforming clients crush organizations that don't change well.

I also know that often the superior architecture must be reverse engineered. Often no one bothered to create a well considered model, and document explicit trade-off between architecture alternatives. So, to be the best enterprise architect, I actively look for superior architecture. I look for my stakeholder's problem, preference, risk, and value definitions listed in the Practitioner's Guide Table 4.

I repeat this often. A few weeks ago we talked about engaging stakeholders, I said I am continually testing my assumptions and analysis. Just last week, I said 'After my stakeholders make a resolute decision, I will own it like it was my favourite idea of all time.

They all protect me from being ill-informed, or a joker projecting parochial preferences.

I have the time to think and to be right. To know when the implementers must take the shared system and live with the common process. And to know when they cannot take the shared systems.

In every case, in every recommendation, in every conversation I need to help my stakeholders select the best path forward. To help them create the best organization possible. And yes, to crush the organizations that implement to parochial preferences. That never finish anything. That are caricatures of what they could be if they would only effectively change

Conclusion of Ensuring Value Materializes

For the past twenty years I have spent at least half my time building strong EA teams. EA teams that have it all. They have pressure to answer the hard questions. They are expected to have looked ahead and around opaque corners to be ready with good advice in their pockets.

Stakeholders expect the ability to have hard conversations about wicked problems. They expect someone who is carrying the accumulated set of architecture decisions and can contrast architecture alternatives in a continually shifting current context.

They need someone who will continually look up and down the cascade from strategy, through portfolio & product to solution delivery and back.

They need someone who will own every architecture decision like it was the favourite idea of all time.

They need someone versed in the architecture roadmap, always able to help with the dynamic investment guidance—can we stop yet? Should we pivot? Or is today the day to stay the course and ignore the clamouring horde of other potentially good ideas.

They need someone who helps guide effective change.

Guiding effective change is all about delivering value.

I know my team rocks. I know you can rock at your organization.

We read the same TOGAF you do. We give our in-house specialization, Navigate, away.

Sometimes Navigate is explained in these emails. Sometimes when we knock something into readable format like the Capability-based planning Guide. Or, when we think something is worth donating like the AI Adoption Reference Architecture and Seven Levers of Digital Transformation.

So be a better architect.

Start by looking at your superior architecture. Is it handy? Do you know when there are no degrees of freedom and the decision is already made? When it is must; when it is must not? Or in the really hard case of maybe, what are the enterprise criteria.

If you are in the room answering an unfair, hard, wicked question there are always enterprise criteria and enterprise values that must be served. If it is a purely local question, you don't need to be there. Everyone else can answer a narrow question. Join me in cutting projects loose—for local issues they will take care of themselves.

Last week and this week I qualified value. We know that value is required to earn permission to interfere with your successful operations. We know that the definition of value inside an architecture project cascades down from above embedded in an objective, performance expectation, constraint, or risk appetite. We know sometimes value is simply defined in the superior architecture.

Next week I want to look deeper into value and help you test whether a change is earning permission to interfere. I'm going to anchor the conversation in Capability-based planning so we can look at what it takes to improve.

As always, I look forward to your feedback and comments.

Have a great week!

regards

 

Dave

Dave Hornford
Conexiam