Decision making is the one of the fundamental characteristics of an architectural practice and it often puts an architect in two minds. Computer science has come a long way from abacus and Turing machines, and is very mature and sophisticated in almost every aspect. It offers multiple solutions for same problem in the same context. However, it causes a bigger trouble, the problem of plenty.
Selecting one option among many is a daily challenge for architects and system designers. Often, it even affects the pace of work as lots of time is spent in reaching to an agreement. It is common to find architects arguing to reach a consensus but in vain. Even if an agreement is reached, convincing other stakeholders remains an uphill task as they have their own experiences and biases.
This choose one among many problem is not unique to computer science only. In daily life one often faces this challenge. For example, when one walks into an electronic supermarket to buy a laptop, one can easily be perplexed by the diverse range of laptops put on sale in store. However, often this little venture results in one buying a laptop without much confusion. How the problem of plenty doesn’t have much impact in one’s decision making while shopping?
There is something that helps people in there routine life in decision making and if we can apply this something into architecture decision making, it will take the pain away from an architect’s life. In above example, when one went to buy a laptop, one might already had few things sorted,
- Ecosystem – Apple, Windows, Google
- Preferred Brand (If not in apple ecosystem) – Dell, Lenovo, HP or something else
- Must have feature – E.g. Capability to play graphic heavy games
It is like having some ground rules before stepping out to buy a laptop, and if something similar can be practiced during architecting and designing, it will potentially help in the process. These ground rules are Core Architecture Principles.
Core Architecture Principles act as a guide to all the stake holders and make the whole decision making process much simpler. There are two simple rules to craft these architecture principles –
- Define at very early stage
- Define at a very abstract level
Consider an example where an enterprise is looking forward to modernize their legacy system. Leadership specifically is looking to build a digital platform that enables them to offer new capabilities on regular basis without any disruption on existing one. Focus of new system should be towards achieving better time to market to get an edge in highly competitive environment. Cost is another factor and needs to be optimized. Organization has a bias towards public cloud.
Backed with above vision statement, along with some tailor made interviews with stakeholders, following rules can be crafted:
- Cloud First
- Some particular cloud provider First (AWS First or Azure First or GCP First)
- Serverless First
- PaaS First
- SaaS First
Above rules are very abstract but in real world they act as a guiding principle for all the stakeholders and ultimately help in decision making. Above rules might result in following architecture.
Above baseline architecture can actually be defined with just one day of huddle. It might be just a jumpstart and it is bound to see variations in due course. However for every deviation from the outlined principles, team will have a reason. E.g., assume that after few weeks team finds that AWS API is not a good fit. At the same time, team has better clarity what capability it wants from API gateway and even among those capabilities, which ones are deal breaker. This information along with core principles will help in getting common consensus and it makes decision making far easier.
Core Architecture Principles are very abstract by design as they should act just as a guiding principle for architecture and should never dictate it. Often, few of these principles are defined not at system level but at enterprise level. Moreover, there is no standard process to define them. One has to carefully get to the essence of work along with all the constraints and biases to define it. Last but not the least, these principles are dynamic in nature and so suppose to be change with time, though the rate of change is very slow.
Software Architecture & Technology 