Cloud 6 Mins Read July 11, 2019 Amit Govil

The Devil is In the Details- Why the Small Architectural Decisions Matter

What Are Architectural Decisions and Why Are They Important?

Architecture is defined as a set of principal design decisions about a software system. An easy way to decide whether a choice is an initial decision or not is to determine the cost of changing the resolution.

Decisions which will involve a lot of time and resources to change thus become the architectural decisions. Based on the cost involved, architectural decisions can be classified as big or small. These big and small decisions together determine how well the software system will scale and evolve.

While many of the significant architectural decisions need to be made before the project even begins, the smaller decisions are usually made as the project evolves. Most of the architect’s energy is focused on big decisions. Interestingly enough, most of these big decisions, when made with enough forethought, prove to be correct. The trick to good software architecture is in getting the smaller decisions right.

Philippe Kruchten once said, “The life of a software architect is a long (and sometimes painful) succession of sub-optimal decisions made partly in the dark.” While this may seem like a slightly pessimistic point of view, the fact of the matter is that every technology project is unique. Every product has its journey, and much of the architecture gets shaped by decisions that are made during the trip.

How Architectural Decisions Have Evolved with Time

Traditionally, software architecture believed in the Waterfall style of working. All architectural decisions, both big and small, were taken in the design stage before a single line of code was written. And the project was then executed using the Waterfall style.

When Agile methodology came into the picture, people found that sticking to a very detailed plan created an undesirable rigidity in the execution of the project. Taking all architectural decisions upfront made it challenging to incorporate critical feedback from stakeholders during the project. As a result, many teams began to take only big decisions up front.

These big decisions gave an overall direction to the project architecture without compromising on the project flexibility. This means that some smaller decisions which were earlier taken before the project started are now made on the fly when development is in progress.

Which Are the Big Architectural Decisions?

The big architectural decisions involve making choices around the fundamental architecture design. These depend to a high degree on the product, the business model, and the future growth path. Here are some of the big choices tech architects face.

Architecture Pattern

The architecture pattern is probably the key to all further architectural decisions. For instance, if you decide to build a monolithic software system, the language you choose becomes essential. On the other hand, if you go for a microservices architecture, you can make the services in different styles. However, you will have to think through development and deployment decisions. Similarly, a hexagonal architecture means you can delink business logic from technology choices altogether which makes future decisions a lot simpler. Again, there are trade-offs you need to consider.

Tech Stack

LAMP was trendy a few years back, following which the MEAN stack dominated. Today, there are some permutations and combinations available. The choice of tech stack is often dependant on the skills your team already has.

Apart from the availability of talent, how the user interacts with your product should be the critical driver behind choosing the tech stack. Other significant considerations are security, speed and performance criteria, and legacy systems.

Why the Big Decisions Don’t Usually Go Wrong

While the big architectural decisions have a significant impact on how a project develops, they don’t usually go wrong. Here are some of the reasons why.

There Is a Lot of Forethought and Planning Behind These Decisions

Many of the big architecture decisions take place even before the project starts. This gives the architect enough time to plan things and make an informed decision. Sometimes, startups prefer to do a proof of concept with the most convenient technology available such as WordPress and move to a full-fledged setup later on. Even in this case, there is plenty of time to decide before the transition takes place.

They Are Based More on the Availability of Talent Than Anything Else

The fact of the matter is that major architectural decisions like choosing the tech stack depends more on the availability of skills within the organization. For instance, if the CTO and the first few developers in a startup are skilled in Node.js, that’s the language the backend will be coded in. On the other hand, if your first few developers are proficient in Python and you need to build a quick MVP, you will probably end up using the Django framework. Again, if you’re starting a new project within an established organization, you will first look for the skills that your in-house team already has and which of them can be used in the original plan.

Big Decisions Don’t Change with the Project

The other thing about big decisions is that they are almost impossible to change once they’re made. This is because these decisions come with a very high cost of change. For instance, imagine you are a two-year-old app, and you want to shift your entire backend from PHP to Python or Node.js tomorrow.

You would have to either replace your current developers or get ready for a long training period as they learned an entirely new language. You will probably have to hire consultants to help with the transition. Not to mention the potential downtime and customer experience issues. Since the costs for change when it comes to big decisions is just so enormous, they are usually made very carefully. And, since changing them is almost impossible, they stay static over time.

How the big decisions play out over time is usually out of your control

When big decisions turn out to be wrong, it is mostly because technologies evolve unfavorably. For instance, a technique you adopt may be transitioning into a new phase, or you may take a relatively new technology thinking it will grow quickly, but that may not always happen.

For example, your backend may be written in PHP, and you may be using javascript for your frontend. You may have chosen PHP when Node.js was in its very nascent stages. The phenomenal growth of Node.js has resulted in a programming language that can be used both on the client-side and the server-side, so you don’t need to switch between the two. So, your decision to choose PHP may seem like the wrong one in hindsight. However, this has mostly happened due to an evolution in technology which was mainly out of your control.

Why Are the Smaller Decisions More Prone to Going Wrong?

Many of These Decisions Depend on Individual Developers and Are Taken on the Fly
These include decisions like whether a new function is just part of utilities or whether it affects the business logic or whether a particular line of code adheres to the overall coding standards. Since developers make these decisions while they’re writing code, they can be very subjective. If there are no code reviews to make sure these decisions are aligned with the overall architecture, they can have a profoundly negative impact going forward.
The Decisions Get Overlooked Very Often Because of the Cost of Change Is Low
By definition, architectural decisions are those decisions that have a very high cost of change. So, the bigger the decision, the more it costs to change it. Consequently, the smaller decisions have a relatively lower price of change attached to them. People tend to think these decisions can always be reversed later if they turn out to be wrong. As a result, there is not much forethought when it comes to these decisions which makes them more likely to go wrong.
Refactoring Is an Option
When it comes to these smaller decisions like design consistency, refactoring is always an option. Refactoring is nothing but, “the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.”Since smaller architectural decisions are always amenable to refactoring, people don’t usually give too much importance to them when they’re being taken. However, the fact of the matter is that most companies don’t invest time in refactoring later on and the wrong decisions add up over time.
The Volume of These Decisions Is Large
Small decisions like adhering to coding standards, cut and pasting code, choosing a library to work with are made every day. Many poor small choices add up over time to create an architecture that becomes messed up at scale. Since the volume of these decisions is so large, finding each problem and resolving it becomes very difficult as the system scales up. It’s easier to find and fix one big mistake than a thousand smaller ones.

It is the details which matter more than the big decisions when it comes to software architecture. Of course, putting adequate thought into big choices is essential. However, it is equally important to put in place a structure that enables developers to get the small decisions right.

Insisting on coding standards is the right place to start. These could include having comments and documentation, using helper methods, and avoiding hard-code as much as possible. You should also make code reviews and refactoring a part of your Agile process so that those poor decisions can be fixed as and when they are made. You want your software system to be as smooth and scalable as possible, and the devil lies in the details.