Minimal Design, Maximum Gains

👷‍♂️ Software Architecture Series — Part 6.

😇“A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.” — Antoine de Saint Exupéry

⚖Every architecture characteristic has its trade-offs and it will certainly impact other characteristics when in play. For example, enhancing “security” means “performance” taking a hit. A real-life analogy is that aero plane pilots struggle to learn how to fly helicopters, as the latter requires balancing from each hand and leg.

🎯A product is aimed to solve a particular business problem and to best aid its development is to provide it with resources needed for its development not to overload it with resources. Overload is synonymous to dissipation of energy. A software design trying to be generic is bound to fail.

🔦“With more architecture characteristics comes more complexity.”

📉And supporting more and more architectural characteristic will ultimately deviate the developers from writing the code for the original problem intended.

🔑The key to avoid this trap is to agree upon the minimal list of characteristics an application should support and plan the development lifecycle around this goal. Another reason to support this thesis is that the understanding of architects and vision of domain stakeholders are completely different. While an architect will think around availability, interoperability, learnability, and fault tolerance in the application, the priority for domain stakeholder will lie around user satisfaction, mergers and acquisitions, competitive advantages, etc. An architect must form the list of necessary characteristics around the domain needs.

📌So, when stakeholders talk about user satisfaction, an architect must aim for Performance, availability, fault tolerance, testability, deployability, agility, and security. But if the product is centred around mergers and acquisitions, designing the product with characteristics like Interoperability, scalability, adaptability, and extensibility will take you far. If stakeholders are constrained about time and budget, then just keep the product simple and feasible.

📑So, it boils down to mapping the requirement of stakeholders to the specific architectural characteristics, and this is where domain knowledge is beneficial for architects. A seasoned architect designs a system based upon real life experiences as well. It may not be mentioned in the requirement document of a commercial product that it should be supporting concurrency of thousands of users (but the expected users of the product would definitely be specified), yet, based upon the past experiences, the architect would design a system that can easily “scale” during peak hours. And in this case, with scalability, architect must consider and make sure that “performance” of the system remains intact during peak hours.

⛓Now, scalability and performance for a commercial product were obvious explicit characteristics required, but then there would be some implicit characteristics which must be derived, even though their requirement mapping might not be present in requirement document. In our case of a commercial product, it should always be available and reliable (i.e. accessible and up during user interaction). For a commercial product, it is imperative to note that the security should not be violated at all costs, however, aspects of security will require more detailed discussion as it will vary case to case. To make it short, if product supports payment via users, integrating with a third party secured library might be much more viable option that implementing it as a feature of structural design of the product.

📃So, it is up to architect to gain deep insight into domain knowledge and then collaborate with developers, managers, and business stakeholders, etc. to decide upon the priority list of architectural characteristics to be supported for product development.

⛵In short, an architect must aim for an architecture with least trade-offs. As Matshona Dhliwayo says, “A small boat that sails the river is better than a large ship that sinks in the sea.”

#softwarearchitect #requirement #architecture #softwaredevelopment #design #business