Software Architecture: Scalability? Always? Really?
Several years ago I attended a Software Engineering conference, and a speaker asked the crowd about which characteristics Software Architects should consider, by default, to be embedded in the software they build. Many of us started raising our hands, trying to show how smart we were. Our dear speaker was prompted with characteristics such as Availability, Performance, Reliability, Security, and Fault Tolerance and even Elasticity, amongst others. Of course, I didn't miss a chance to show off: “Scalability” — I screamed at the guy on stage. Well, this action made me turn red just in a few moments…
What do you think happened next..? Exactly, together with the rest, I was crucified, while a very insightful explanation was given why most of the mentioned characteristics are important to consider, but NOT necessarily mandatory to be included in the final piece of software. It made me think more about the fact that everything comes with a cost and “Scalability” is not an exception.
One can wonder: “Why don’t I design the system in a way so that all common software architecture characteristics are embedded from the get-go? Why would I risk, potentially, getting in trouble in the future?” I have to say that is a valid question. In certain situations and for specific products or applications that would be the way to go. But in the world of “Corporate Software” or “Enterprise Software”, implementing those characteristics by default could be considered as overengineering, coming with extra costs quite often and not bringing the desired value.
It is an art to keep the software system as simple as possible, letting it do exactly what it was designed for. No one objected to the KISS principle so far, as per my knowledge. So, what does it take to achieve the required simplicity, and what are the prerequisites?
In my opinion, designing the system so that the architecture can evolve means you need to be crystal clear on the following points:
- Product Value (Idea)
- Product MVP (Working Proof Of Concept — POC)
- Team (Skills and Expertise)
- Product Vision (Strategy and Evolution)
Sadly, many times one or more items from the list above are missing or confusing.
Software Engineers see possibility everywhere, jumping on every single little or big thing that they believe they could improve, just because it’s fun for them. Having an idea of a new product or capability and imagining its potential value, you need to push the engineering mindset aside, as your entrepreneurship skills are required instead. That also embraces certain constraints to the potential solution as costs must not be bigger than value.
In many scenarios, a technical POC is different from the Minimum Viable Product concept but must not be underestimated. Going live early (at least technical go-live) will bring you necessary insights about the potential costs of infrastructure and discover many weak points in your solution, without damaging the business too much.
At the same time, you can’t go far without the team. But what do we mean by that?
Building a highly performant and effective team is a complex task that requires consistency and time. So, what you would need from the beginning to build an effective T-Shaped team is diversity, the right attitude that fits your culture, expertise and the eagerness to learn. Identify skills and capabilities your team would need to have in order to be set up for success and build it brick by brick.
How do I make the right choice, be it technical or business-driven, without having a clear strategy and vision around the product? In my opinion, it is absolutely mandatory to have a person nearby, who can envision one or even a few directions the product may develop into. These insights will not only help save money and time but also will stop you from getting nowhere.
To conclude, before thinking about what are the software architecture characteristics you need to be applying by default, make sure you are clear about the four pillars I’ve mentioned above. Building a “highly-scalable” solution with the potential of processing 20 million requests per second for max 50 concurrent users is most likely not what you are looking for.
The views, thoughts, and opinions expressed in the text belong solely to the author, and do not represent the opinion, strategy or goals of the author’s employer, organization, committee or any other group or individual.
