Software architecture: Strategic design thinking for beginners
It is challenging for people who are new to software architecture design to identify the scope of their initial architecture design plan. Typically, software architecture design is a little disorganized, especially during the early planning stages. When I first started designing as part of my day job, I found myself aiming for perfection. But, sooner or later, I discovered that there is no such thing as perfect architecture and that if I am doing it, I am doing it incorrectly.
Instead of simply pursuing the perfect idea, the objective should be to establish an architecture that can provide the groundwork for future enhancements. Herbert A. Simon coined the concept “bounded rationality” which aids in decision-making. Bounded rationality is the idea that rationality is limited when individuals make decisions. Planning for perfection in software architecture is difficult due to time, budget, experience, and knowledge limitations. This pushes us to be satisficers, seeking a satisfactory solution rather than the optimal one. So, what should we look for in our initial design plan?
Based on my experiences, below are a few established essential aspects that will assist you in designing better and faster:
- Early-stage experiments
Every idea that occurs to you has an uncertain chance of becoming successful. Treat them like experiments to test the essential features of your design and determine whether they’re good enough to fit. Define a small set of experiments that will help you validate your ideas faster, for less money, and in less time. - Fail Fast, Learn Faster
The faster we learn, the more we can try out new ideas, and the more confident we will be in our answers. Let’s find out whether we’re wrong as quickly as possible. Fail quickly, and you’ll learn speedily. Shorter, tighter design cycles with concrete outcomes should be preferred over longer design iterations that just focus on abstract aims. - Stick to the problem statement
Many times, we go so deep in finding the solution that we lose track of the broad problem statement. This happens when we try to over-engineer the solution. Over-engineering is similar to overthinking in that it aims to solve problems that do not yet exist or are too early to address. Overengineering occurs when your design actually complicates things rather than simplifying them. Always examine each alternative solution to see if it adheres to the problem statement. - Identify risks
The software system’s architecture is its basis. If it fails, everything else will fail as well. The identification of what may go wrong and recovery planning should be an ongoing effort. Risk can help us decide what is next to create.
We’ll have to determine how much of the architecture we want to prepare ahead of time and how much we want to let evolve with time. Choosing a design approach early in the life cycle of a software system serves as a stepping stone on the way to constructing the entire architecture. We should strive to design for improvement and make decisions that will prevent rework on the proposed design once development has begun.
If you found the post helpful then please do Clap :)
