Co-Creating the Dynamic Architecture Roadmap

 

You only find reality by actively engaging subject matter experts in your architecture analysis.

I'm not saying go out and gather everyone who might know something and bring everyone along. No. That is nonsense. It quickly becomes a long involved discussion about minutia. Irrelevant minutia.

Look at the picture above. On the right you can see where the wood burning kitchen stove was connected to the old chimney. Until I saw that brickwork the kitchen floor plan was inexplicable. Even then, I didn't need to dwell on current the pantry and oven door collisions. We were demoing the kitchen.

You are looking for inconvenient facts. I do need to know if the water supply pipe is too small to support an additional bathroom. Yeah that cost saving corner cut 25 years ago means we have to rip up the driveway to make a pipe 3mm larger. 3mm! Right there I have building code intersecting with new feature design interacting with multiple levels of existing infrastructure delivery.

Superior architecture plus in-the-ground reality crashing into a candidate architecture alternative's value calculation. Adding a sink might have meant digging up the street and driveway, turning off all water to the neighbourhood to install a new pipe. That would be an expensive sink. Not even gold taps.

We find these issues through co-creation of candidate architecture alternatives—I can't tell you how often I work with teams who skip candidate architecture alternatives. Instead obsessively drive towards a preselected target based on inferred requirements. An inferred requirement is not a requirement. It is an untested assumption. Using untested assumptions as facts is simply pretending.

You don't build stable, scalable, sustainable operations by pretending. Pretending during architecture development leads to pretending during design. Then you need to pretend during implementation.

You never get to pretend during operations. This is the “hidden human subsidy” I mentioned in our AI series. The unspoken assumption that people will work around broken processes, missing data, or flawed technology. The lies told to the sponsor and stakeholder that a project would create a sticky benefit.

Good portfolio architecture puts the facts on the table. Early, when the cost of change is cheap.

I'm not saying pretend to be omniscient and capture everything in a big giant detailed design. That is even a worse idea. That path adds pretending about omniscience to pretending about requirements.

Best practice in the Practitioner's Guide table 4 guides us—stakeholders preferences shift in response to changes in benefit, effort, and the effect of uncertainty (risk).

Just cost uncertainty in. If you have not engaged the subject matter experts with specialized knowledge—the operators, implementers, and domain specialists—you have unacknowledged uncertainty. A lot of uncertainty. Probably more uncertainty than certainty.

With unacknowledged uncertainty your stakeholders are evaluating a fantasy. Maserati's are not free, because you didn't ask the price. Data doesn't cleanse itself. Efficiency benefits are not provided by silently dropping additional work arounds into the "hidden human subsidy.”

I said cost in uncertainty. I did not say eliminate uncertainty. Start with rough math. Assume lowered benefit, assume larger scope of change, assume larger estimates of change. Ask whether the candidate still looks good? If it does, great. Sloppy estimates with lots of costed uncertainty are your best candidates. They hold together for a very long time.

Then, you get to have honest conversations with your stakeholders.

Just accept that the stakeholder will often say, 'Oh. Dang. We will not pursue that option.'

When your stakeholder chooses not to pursue a doomed-to-fail or unacceptably-risky candidate reach for your balloons and streamers. Party time! Best-practice enterprise architects celebrate every 'No'. You are celebrating a massive victory. You are celebrating that your company did not initiate doomed work. Work doomed to spend scarce time, effort and resources making the world worse.

Doctors have a professional ethic, do no harm. I wish enterprise architects would join them. We'd have less technical debt. Less organizational debt. And, a better current state.

The Artifact: Not a Gantt Chart! A Navigation Canvas

The core deliverable of Phase E isn’t a timeline. Nor a project plan. It’s an Architecture Roadmap.

Architecture roadmaps are complex work products. They must provide all of the information in the renovation design process plus everything in Google Maps and everything those flawed analogies miss. In Navigate, we use multiple types of work product to provide this depth of information. The four core roadmap work products are:

• Architecture Roadmap Type 1: Heatmap
• Architecture Roadmap Type 2: Lifecycle Chart
• Architecture Roadmap Type 3: Work Package Impact and Dependency
• Architecture Roadmap Type 4: Scenario Analysis and Multiple Candidate

Each type of work product shows you different aspects of a Candidate Target and architecture alternatives. Together they enable your stakeholder's complex value assessment—where they assess potential benefits, changes and uncertainty through the lens of concerns.

Earlier I said you need to accept informed stakeholders will say no. Then I told you to celebrate.

In my work I search for no. I love to hear a strong definitive no. In fact I prefer 'NO!!!!!! Never!!!'

At never I get to abandon a line of inquiry. Until then all I have is another plausible candidate.

Remember 'yes' is just a more pleasant 'maybe'. It simply acknowledges the candidate is plausible. Especially a yes hiding behind a transition stage.

Every transition stage (value resting point) is designed to be an off-ramp. Points where your stakeholder knows they can stop, or pivot to a different next direction. They might double-down and race forward. Pragmatically, expect stop and pivot. Off-ramps are built-in enterprise agility, supporting value capture and a different priority.

At every transition you have assessment work—find whether the transition even delivered the expected value? Test whether we are still inside the risk appetite? Or, most valuably, whether a different direction is more attractive?

Enabling enterprise agility allows inevitable stakeholder priority and preference adjustments to capture harvestable value. Stakeholders are going to change direction. Tackle new, or more pressing problems. Help them avoid leaving behind a partially rebuilt kitchen, a trench in the driveway, with the water pipe still 3mm too small. Help them find a path to at least dropping the kids at the bus stop.

Dynamic architecture roadmaps are just like Google Maps, constantly updating as reality unfolds.

Concluding Co-Creating the Dynamic Roadmap

Co-creation doesn't change the hard fact that your stakeholders own the architecture. They have the only votes to approve it.

Co-creation is not a negotiation. An implementer can tell you all day they don't like the target, Don't believe in the target. They might even say it isn't feasible. They can say it all day. If you have a solid cost, effort, and risk assessment and your stakeholder says I'll pay for that, you are golden.

Co-creation is all about facts. Your operators and subject matter experts can champion different preferred options. Explaining their different, sunnier future at every meeting. If your target addresses the current state deficiency and your stakeholder says I'll pay for that, you are golden.

Nowhere in the architecture development process is organizational change management, or placating subject matter experts. The TOGAF target architecture governance checklist simply says you need to tell the stakeholder about the disagreement and assume less confidence.

Let's be blunt you will often be developing a target that the subject matter experts, operators, and implementers do not want. Your job exists to help the organization change in ways it cannot change without you and your profession.

This means serving the stakeholder with the truth.

• the true current state and true source of the deficiency
• a target state that honestly resolves the deficiency with complete Work Packages

Your value goes through the roof when you find a transition state with enough of the deficiency filled that there is meaningful harvestable value.

Stakeholders have experience. They know every conceivable problem will not be solved. They simply want a measurably better today. They know the implementation will hit snags.

They want to know where they have risk. They want to know what work delivers value. That way they can effectively direct their portfolio. They can have confidence a corner cut is not simply transferring cost to the 'hidden human subsidy'.

Again, I'm not talking about omniscience. Find your unknown and account for it. I have a 100-year-old house. Today asbestos is a hazardous material. For most of my house's existence it was a preferred construction material—testing a couple of dozen likely spots in the house found known asbestos. Removing the known contaminated kitchen wall uncovered the contaminated concrete used to plug the unknown wood-burning stove connection to the chimney.

This week, I have a very personal and difficult challenge for you. Look at a current roadmap, preferably one that is not getting traction. Ask yourself about the target and the work packages—are they delivering on inferred requirements or tested assumptions. Did anyone have the hard conversation with the stakeholder about how valuable the sink is? Did anyone ask whether sportscar meant Maserati or Miata? How confident are you there is not asbestos lurking in the wall?

Next week, we’ll look at using this honesty. Creating a fact-based architecture that drives a portfolio of effective change work packages and transition points. Defining the constraints, the architecture specifications, that drive effective change and enable your stakeholders to control their portfolio.

As always, I welcome your comments.

Have a great day,

Dave

Dave Hornford
Conexiam