Architecture is a set of future options

I ask which changes are likely, where uncertainty is high and which commitments would be expensive to reverse.

The answer is rarely to maximise flexibility everywhere. Simplicity has value too. A strong architecture discussion explains where deliberate boundaries are useful and where abstraction would create work without protecting a meaningful option.

Architecture discussions go wrong in two opposite directions. Some engineers design for imagined futures, adding layers of abstraction to protect against changes that never arrive. Elsewhere, product pressure leaves structure entirely to chance, and the architecture is decided implicitly by whichever team ships first. Both errors share a root cause: the options an architecture protects are rarely visible to the people who set product direction. Without that visibility, leaders cannot judge whether the engineering effort being spent on flexibility is well placed, or whether an important option is being closed off without anyone noticing.

I ask teams to write a short decision record for each significant architectural choice. It describes the context, the alternatives considered, the change the design anticipates, the cost of reversing it and the signal that would prompt a review. I also ask teams to classify decisions by how easily they can be undone. Choices that are cheap to reverse can be made quickly by the people closest to the work. Choices that are expensive to reverse, such as data models or contracts with external parties, receive more scrutiny and involve product leaders in the discussion.

Consider a product team deciding whether to build billing logic directly into its application or to isolate it behind a clear interface. If pricing models are expected to change frequently, perhaps with new subscription structures or usage-based charges, the interface protects a valuable option and is worth the extra work. If pricing is stable and simple, the same interface adds complexity that every engineer must understand for little return. The right answer depends on product strategy rather than engineering preference, which is exactly why product leaders belong in the conversation.

A common argument is that architecture matters less than it used to, because modern tools make refactoring cheap. That is partly true. Internal structure within a well-tested service can usually be reshaped without great cost. The argument weakens at the boundaries: data models that many services depend on, interfaces published to customers or partners, and commitments built into contracts. Those are expensive to change because the cost falls on people outside the team. I concentrate architectural rigour there and encourage teams to move quickly everywhere else, which keeps the discipline proportionate to the risk.

This asks product leaders to share their honest view of what is likely to change, including the uncertainty in that view, rather than presenting a fixed roadmap and expecting engineering to absorb the consequences. It asks the chief technology officer to explain architectural choices in business terms, so the leadership team understands what it is buying. And it asks everyone to revisit significant decisions when strategy shifts, because an option that once justified its cost may no longer be needed, while a new direction may require an option nobody thought to protect.

I ask architects to name the options their design protects and the price of protecting them. Some options are worth paying for; many are not. A leadership team that understands that trade-off can fund architecture deliberately, rather than treating it as an invisible tax on every product decision.