The Case Against Interim Architectures

Ensuring a stepping stone does not become the end goal

No one who is confident in their ability to implement future state has ever asked for an interim architecture. An interim architecture is a logical architecture diagram that represents meaningful progress toward the end goal of your digital transformation, but doesn’t go all the way toward depicting future state. It’s a stepping stone.

If someone is insisting on an interim architecture, it might mean the future state architecture you’ve developed does not yet meet their needs. Future state is complicated and different and hard to conceptualize; interim state is, by its nature, less so. Sometimes an interim architecture is a useful tool. Sometimes, it’s a trap. Once you’ve introduced that stepping stone, it’s tempting to start thinking of what should be a milestone as the finish line.

Rather than acquiesce to the request for an interim architecture, the architect and anyone else responsible for advocating for future state should work to understand the concerns that prompted the request and account for them during the development of the future state architecture.

To do this, we can apply design thinking to architecture diagrams.

In a previous life, I owned a product company. The first time I engaged a consulting firm, it wasn’t a great experience. My entire identity (not to mention net worth) was tied up in that company, and I was very protective of it. I wasn’t in the mindset to be a full partner, and the consultants I’d hired didn’t know how to help me get there.

I want to help people get there. That means understanding and accommodating the pressures my clients are under, the obligations they have and the fears they’re harboring. It means ensuring my recommendations reflect that reality.

If I know my primary stakeholder has a limited budget, or limited political capital to go get more budget, I’ll work with the architect to see if we can reduce the number of net new tools we’re suggesting.

If I know my stakeholder is particularly worried about meeting the needs of, and getting buy-in from, a certain business stakeholder, I’ll prepare talking points about how the architecture benefits that part of the business.

If my stakeholder isn’t particularly technical, I’ll help develop a process view of the architecture. And the architect and I will document the business value of our key recommendations. When we practice the presentation, we’ll make sure we have a few analogies in our back pockets.

No matter who I’m working with, I’ll try to be mindful of the fact that asking someone to embrace a new technical architecture can mean asking them to stake their professional reputation, millions of dollars and months of their teams’ lives on my recommendations.

I never want to spring an architecture on someone, and I never want the final readout to feel like a hard sell. Developing a future state architecture should be done in conversation with the people who are going to have to live with it. That means showing your work well in advance of the final due date, and being open to and serious about the feedback that comes out of those review sessions.

The goal is to develop a future state architecture that is inoculated against the need for an interim architecture because it is already well understood and situationally appropriate.