Architecting When the Decision Window Collapses

Architecture at Multiple Horizons

Running out of time before you can harvest value is guaranteed to be 100% waste. Every initiative that runs out of runway before it delivers a single ounce of benefit was doomed before it started.

Preventing this waste is why architecture to support portfolio is a sweet spot for enterprise architecture. It addresses a critical challenge of helping a stakeholder select the best changes and drive them. The direct cost of wasted effort easily justifies the time and expense of an EA Team. The opportunity cost of misplaced and wasted effort simply blows the ROI through the roof.

Avoiding wasted effort is why EA teams will celebrate saying ''there is no viable improvement, we should do nothing.' There is always work that could be done. However, just doing possible work does not mean you improved. It just means you did work.

Just doing work is like buying a home gym, hiring a personal trainer, working out for 15 minutes a week. Then continuing to sit around eating nachos. You can point to doing the right thing. Weight, cholesterol, stamina, fitness and health are not any better.

You would have been further ahead not buying the home gym and not hiring the personal trainer. Health outcomes would be the same, but you'd be financially ahead.

That is why we always start with a crisp understanding of your organization's objectives and tie every architecture alternative to benefit, work, and uncertainty.

That is why we cross every domain. Implementing a system and retaining the same process is just like stopping for nachos on the way home from the fitness equipment store. That cool Pilates reformer and titanium balanced rowing machine doesn't help your fitness collecting dust.

Enterprise agility is easier to see when there is a crisis. Glasswing is a great crisis. We have weeks before our primary vendors start releasing patches—last month Firefox fixes more security issues that they had in the previous twenty months combined. Firefox gets to release into a near auto-update environment.

Every threat or opportunity we see is time bound. Whether we have weeks, months, or decades the clock is always counting down to the point where change is irrelevant. Nokia had almost a decade from the introduction of smartphones to their CEO sending a company wide email using the metaphor of a burning oil platform—the key point simply jumping into the sea was the safest choice.

They ran out of time. They did not demonstrate enterprise agility .

We see four elements of an agile enterprise:

1. Alertness – Can you detect opportunities and threats?
2. Accessibility – Can you access relevant information in time to respond?
3. Decisiveness – Can you decide using the available information?
4. Swiftness – Can you implement your decisions in the time available?

Nokia had a decade to see, determine reasonable responses, select a response, and complete the actions.

Your transformation roadmap has a clock ticking. A few week ago I told you about the project that became our NA Construction case-study. 18 months from initial strategy to a transformation initiative to enabling the system that changed them forever. Returning to the gym, at 18-months they had the home gym installed—along the way they changed their diet, their approach to fitness, and built the habits to succeed. They made many hard choices along the way, and continually selected what was needed to improve. There the time boundary was whatever was needed. They would happily have taken 30 months. Or 48. We didn't need more because we built a transformation roadmap that got them to a transition point with no extra work.

Years feel natural. Years give us the illusion we don't have a deadline. We pretend there is always time to look further and explore more alternatives. All we are doing is deferring decisions. Essentially pretending that if we look harder we can find the right combination of equipment in the home gym that doesn't require anything more than telling the delivery guys where to assemble things.

Good architecture is time-bound. Great architecture is in a hurry.

Great architecture teams can deliver when the clock accelerates. They can do this because they are always watching the clock.

When the decision window collapses we can see the number of meaningful architecture alternatives shrinks quickly. We can see entire classes of work simply fail to fit inside the available time. Others become irrelevant because they cannot alter the outcome in time.

Frankly this is unchanged for Nokia, for NA Construction, or Glasswing.

It is an absolute property of developing a viable candidate architecture. In the available time. In the available budget. In the available risk tolerance. In the available change impact:

• Which options are plausible?
• Which actions meaningfully reduce irreversible downside?
• Which choices preserve freedom to decide later?
• Which options meaningfully deliver the desired upside?

These questions are the fundamental root of good architecture development.

Glasswing as an Initial Value Resting Point Example

The Glasswing shock architecture response was exploratory. The conclusion was provisional.

It started with a simple question—how was our environment expected to change?

It led to normal architecture work—what can we do to respond?

It delivered a simple answer—in the available time this is exactly what can be delivered by a resolute decision to act.

We didn't apologize for being decisive. Nor did we apologize for not solving information Security. We simply solved for the architecture problem—what can usefully be done before the patch tsunami?

This matters. The most common stakeholder reaction to all architecture work is "I didn't realize what it takes to fulfil my hopes, realize my dreams, or dodge my fears. Dang!" Immediately followed by denial and looking for loopholes.

Internally we call a lot of our deliverables Kale Documents—the implicit joke is while kale is good for you the choice between a kale smoothie, roast kale, and a kale sandwich is still a lot of kale.

The second most common stakeholder reaction is "I don't want to do all that." I love reeling in an artificial target. A target that is usually elegant and complete. A target that makes a domain specialist smile warmly. A target where the stakeholder just said, "'I'll never find that."

I'll be blunt, if there is a simple, easy answer no one is going to as an EA Team. They are simply going to press the easy button, sit back and watch the benefits leap into their lap.

Transition Points Provide Multiple Horizons

EA teams gravitate to longer time frames because that is where portfolio investment, capability evolution, and operating‑model change usually live. Architecture roadmaps, scenario alternatives, and transition states make the most sense when we have time deliver organizational change.

When you have a long running transformation you will never follow a simple, brittle, linear path.

Reality will strike. Glasswing will happen. Gas will get more expensive. LLM-based AI will be invented. Competitors will release a new product. Bang, the long complete plan is in the ditch. Well I hope it is in the ditch. You can probably walk away from that. Most often the correct metaphor is Wile E. Coyote suspended in the air waiting for gravity to smash him into the ground with nothing to show for any of his hard work.

Every architecture transformation needs transition points. Points where your company can stop. Not pause, stop. Stop dead and never move another iota towards the target. Stop and harvest measurable value.

Our Glasswing recommendation was the point where our organization could reasonably say—we won't be blindsided. We will have broken a long taboo about doing anything that might possibly negatively impact a legacy application. Like everyone we are terrified those fragile houses-of-cards will tumble down.

Then we can move on and do the next thing. The next wave has additional work around better internal perimeters, stack simplification, and stack updates. Basically, if we are going to have to upgrade, let's start the hard boring work we have been putting off, because the choice of when will be vanishing.

In Glasswing you can see that much of the architecture surface area falls away on its own:

• Options whose value depends on long adoption curves become irrelevant
• Decisions that require organizational realignment exceed the available window
• Perfect answers lose their value if they arrive too late

Just like every other architecture analysis effort that is faced by a time horizon. Long adoption curves have huge uncertainty. Change that happens too late is, well, too late. Change that is bigger than we can do, is, well, too big.

We can see this in a crisis because everything is compressed. The compression makes it obvious.

I want you to see it every day in everything you do.

Conclusion of Architecting When the Decision Window Collapses

This was orthodox EA work. It wasn't an exception.

We face an ugly problem without the time or energy to realize an elegant perfect transformation.

We need to provide a reasonable recommendation to our stakeholders about the real problem and the available choices. Those choices need to be feasible—feasible change impact, level of uncertainty, and time-line. Feasible.

Basic standard architecture analysis that looks at the real problem and available choices.

My team and I think a lot about the 5 elements of Enterprise agility. I mentioned four above—Alertness, Accessibility, Decisiveness, and Swiftness. These four are with you all day, every day.

The fifth element is flexibility. The parts of your organization that:

• dim your ability to detect opportunities and threats
• slow your ability to access relevant information to the threats or opportunities
• prevent resolute decisions
• block your ability to make the changes in the time available

You won't solve flexibility in the crisis. We solve it every day by continually removing barriers and blocking new ones from occurring.

At the start I called out the common thrust of conversations I had about Architecting the Glasswing Shock. I trust that you can see that the very interesting approach was best-practice enterprise architecture. It took a hard question with a tight time frame and provided a crisp recommendation regarding what we can do to materially mitigate a threat implacably coming at us.

Even better, the Glasswing message stands as a complete example of always linking your enterprise architecture and enterprise agility. We can see the timeline. We can see the compressed choices forced a level of realism that is often missed when we have more time.

Time is always limited. Nokia, RIM(Blackberry), and Microsoft's handheld divisions had plenty of time. They had a decade. They saw the slow motion train wreck. Like almost every organization that missed an opportunity or was smashed by a threat they did not react. Failure to react will come down to failing to create a resolute action, or simply having no flexibility.

This week, my challenge is based on time. Time to architect. Time to decide. Time to act. Look at your current work. When does the change cease to matter? When will the opportunity slip away? When do you run out of time and the threat materializes?

What are you going to do to architect, decide, and act in time.

Next week, I'll talk about the hard question—where do you take ideas and recommendations like these? The best architecture roadmap in a binder on the shelf is not helping your organization seize available opportunities to be great.

As always, I welcome your comments and questions.

Have a great day,

Dave

Dave Hornford
Conexiam

PS. Yes, a weekly accidental attempt on my life is demonstrably within my risk appetite. The accidental attempts happen and I ride. If you want to see the true risk appetite simply watch.