Last week I recalled a disussion I had about understanding the quality of a software architecture. As part of that conversation the head of the company was interested in flexibility: if the company chose to pivot, or offer an additional and slightly different kind of service, could the architecture handle that?

I really liked John S Nolan’s comment on the last article:

I find that the architecture as a shared understanding of how the systems work is primarily useful for being able to reason about the changes you want to think about making. If a company doesn’t have a shared view, or has an incorrect vision of the real implemented architecture, this makes change very risky and hard.

That’s particularly relevant here, because rather than asking “Can your architecture do this thing if the company does that thing?” it becomes more collaborative: “Does our architecture fit with the way we see the company going?” It also allows us to have a sensible conversation about cost and consequences: “Well, if we start steering the architecture in this way it will take this much time and effort; do we think that’s a good bet, given what we know about the future?”

I took a different tack: it’s easy to build in flexibility too early, and very costly, too. I’ve worked with too many projects where the team took pains to build in flexibility, but that turned out to be too early. They expected that flexibility to be needed, but when real use cases came along they found they just didn’t fit what they had built—they needed flexibility where they hadn’t built it, and the flexibility they did have went unused. Not only was that disappointing, it had two tangible negative consequences: their system was now excessively complicated (due to unused flexibility) and hacked (because they could no longer afford the time to integrate the new thing in the way they should have done).

In general I steer people away from designing for things we aren’t sure are going to happen. It’s pretty inevitable that the world doesn’t work out the way we expect, particularly when we’re talking about how a business will evolve.

And thanks to John for providing a really useful approach to thinking about architecture in a real organisation.

Photo by Bill Ohl