When to Make Architecture Decisions?

The process of architecting a system (and later evolving it) involves making a series of principal design decisions or architectural decisions. In fact, architecture itself can be defined as a set of principal design decisions:

“Architecture is a set of principal design decisions about a software system”
– Richard N. Taylor

How do we know if a design decision is an principal design decision or not? It is determined by the cost of change. It is clear in case of software under maintenance, as Chris Verhoef observes: “The software architecture of deployed software is determined by those aspects that are the hardest to change”.

In my experience, I observe that architects find it very difficult to make architecture decisions; they are (rightly) worried to ensure that they make correct decisions because wrong architecture decisions can even derail a project. Making architecture decisions is difficult because of many reasons:

Architecture decisions need to be made considering different factors, including time (“how long is it going to take?”), team (“how productive team will be?”), cost (“how much is it going to cost?”), risk (“how much risk are we exposed to?”), and scale (“how many users and how fast can the software serve?”). These are interrelated aspects and they often conflict. For example, an architect may want to choose microservices style for her web-based application that she is designing. It may be a good technical choice, but if her team is not familiar with this style, then adopting that style becomes difficult. Further, if the software is security critical, then there are security risks that she has to deal with as a result of that architecture decision.

Architects have to often make architecture decisions under conflicting stakeholder needs. When the product owner who pays for the software project wants a secure system with multiple levels of authentication, the end user may want the software to be very usable (in this case, it is security vs. usability requirements). Should the architect give priority to the paying customer, end-user, or strike a balance?

Lack of clarity on what is required from the software. Assume that an architect is designing a predictive analytics software. Even her customer does not have any idea of the size of the dataset, level of abstraction that should be used for displaying the reports, etc. (Only in theory customers clearly know what they want). With this limited understanding on requirements, it is hard to make architecture decisions on the underlying solution approach that would be most suitable for the software.

These are only some of the aspects that make taking architecture decisions difficult. To make the life of the architect even more difficult, she faces a major dilemma: should I have made this decision earlier, make the decision now, or postpone it to a later moment?

Of course, in the early stages of the project, most requirements are unknown and it is hard to make significant decisions without clear understanding on the software requirements. However, still some architecture decisions must be made early in a software development project. For example, what platform to use is something that must be decided on the onset of the project – or else, the project cannot get started.

How about other architecture decisions? Consider this question, for example: “should we reuse or buy a reporting component or should we build one?”. For most of the buy/reuse vs. make decisions, the answer is often not immediately evident. Trying out a solution through prototyping, checking legal aspects of reusing a component, checking with the management about the cost and licensing issues – all these aspects need time and focused effort. Once we have enough information in hand, we can make a careful decision on the buy vs. reuse choice.

For making architecture decisions when requirements that aren’t clear, consider Mary and Tom Poppendieck’s approach:

“Delay commitment until the last responsible moment, that is, the moment at which failing to make a decision eliminates an important alternative”.

This approach works reasonably well in Agile approach where architecture evolves from a core as the requirements are discovered over time. Significant design decisions still need to be made, but the idea is to defer decisions to the ‘Last Responsible Moment’ (LRM).

Jeff Atwood: “The key is to make decisions as late as you can responsibly wait because that is the point at which you have the most information on which to base the decision.”

Least responsible moment does not mean procrastination, or not taking responsibility for making architecture decisions. For this reason, as Rebecca Wirfs-Brock notes, instead of the term “last responsible moment”, a better phrase to use is the “Most Responsible Moment”.

In real-world projects, a few architecture decisions still need to be made with partially available information (or worse, by guessing) to make progress. Otherwise, the project will get stalled.

As Philippe Krutchen rightly observes, “The life of a software architect is a long (and sometimes painful) succession of sub-optimal decisions made partly in the dark”.

For most architecture decisions, with the guidance from the principle of “Most Responsible Moment”, we can make them when we have all relevant information available. In this way, the principle of ‘Most Responsible Moment’ can certainly help us deal with making architectural decisions.