The architectural work in software development evidently involves sketching the blueprint of a vision. This vision is influenced by several factors that lead developers to make a series of decisions about how they will start building. The common misconception is that the phenomenon is restricted to some major choices made at the beginning. However, in reality, the architectural decisions are ongoing till the completion of a project. There are an infinite amount of minor details that can make or break the final product. It is not just about the scaffolding, but all the layers that follow, and the finishing touches.
Big Architectural Decisions
The big architectural decisions in software development are mostly concerned with technology selection. These decisions are made by team leaders at the beginning and are permanent. Although they define the grounds of a project, they will hardly have an effect on how it progresses. LAMP, ROR and MEAN are a few popular tech stacks that have been used perpetually in the past. Despite the arrival of newer technologies, they still occupy a special place in the IT industry.
The development components you choose to work with, especially at the back-end are all included in big architectural decisions. These decisions are entirely driven by preference, skill and experience of the persons in charge. Despite being static, technology decisions can occasionally cause blunders, usually when they are immature or out-dated. Newer technologies are designed to be simpler, faster and more productive. While they are rapidly replacing the old school choices, many don’t have sufficient documentation or support. On the other hand, many aged technologies that were known to rule their era, are now deemed incapable of fitting the modern requirements.
That being said, the back-end stuff is still rarely at fault. The groundwork is generally set by seniors of an organization, so mistakes seldom happen.The actual team of developers who is going to work on the project day and night, has little or no contribution to the tech stack. Many members of the team are added after most big decisions have been finalised. This is a fact that is partially responsible for the numerous minute mistakes made during execution.
The type of database server we choose for hosting our software application is another one of the crucial decisions. IT managers usually go for what they’re familiar with; both dedicated and shared servers have pros + cons. The greater confusion usually arises when opting for a cloud-based server. Despite being around for a while, they are regarded as the unconventional kind. Modern cloud servers run microservices; despite having some obvious advantages, it hasn’t proven to be beneficial for everyone.
The Architectural Decisions We Don’t Count
The selection of libraries, plugins and other third party tools are all part of architectural decisions. These small to medium sized decisions are made by different developers of a team. Most companies nowadays are implementing the Agile development methodology which is supposed to enforce a collaborative approach. The people working on a team have varying opinions, nonequivalent skill level and a unique style of working. Tasks within a project are distributed in spite of cooperative strategies.
Developers working on separate features or parts of the software will make personal choices. When contributions from multiple sources are put together, they often don’t fit perfectly. The code, the APIs, modules and other elements within a software system should complement each other. Some developers write clean code, some write poor code and some copy paste it from somewhere without even reading it. If all these details are not carefully implied, our project will exhibit multiple dead-ends. As a result the application is too buggy, full of errors or entirely dysfunctional.
Team members may repeatedly create functions without understanding the business logic. Agile or no Agile, these decisions are seen as minor and nobody cares about the aftermath. The reasoning behind this ignorance is subtle – developers know that fixes are possible and can be dealt with later. The problems are seen as part of an iterative and incremental approach. The team will continue to change and amend small decisions prior to reaching an acceptable product.