Even if you eat a 5 Star and do nothing, the system, once built, will still have an architecture. So it is up to you: either follow the process, identify ASRs, constraints, trade-offs and quality attributes, and take mindful design decisions so that it is the architecture you wanted, or it will be chosen for you.
Diverge to see options, converge to decide
If you don't diverge, it is like choosing flip-flops for a hike because you didn't know about shoes. As Indians, before selecting one T-shirt, we check out multiple shops and ask for rates, to satisfy our ego that we are the best negotiators and that the decision is the best. The same mindset should be used while choosing anything. Explore 10 things to strengthen the reasoning for why a thing is chosen, why it fits, and why others don't.
- Explore architecturally significant things that promote or influence the quality attributes.
- Explore elements, relations, interfaces, domain models, technologies, frameworks, CI/CDs, and past design perspectives.
Accept Constraints
Be mindful when accepting business constraints. Technical constraints cannot be changed, but business ones can sometimes be changed, or satisfied outside the architecture. For example, maybe outsourcing the development satisfies the business constraint of completing in 2 months, while we cannot.
It can also be satisfied by making certain decisions in the architecture, but be mindful that the architecture is more about quality attributes and not so much about business constraints, otherwise the constraints have chosen you, not you have chosen them.
Promote Desired Quality Attributes
A decision must promote quality attributes. As the example mentioned, for a system that makes a smoothie, the quality attribute is a tasty smoothie. We explore 3 options: a standard blender, a hand blender, and a chainsaw blender. What if the constraint is to make the smoothie on a beach? Then a chainsaw blender might actually be the better fit.
Decision Matrix
A decision matrix is a simple tool to summarize the trade-off analysis.
Never put numbers, put yes, no, or maybe. Two motors might both have copper windings and 1 Hp power, but with our biasedness we might end up giving different numbers to both products, which was also observed in AI doing comparisons of Amazon products.
- While making this matrix, it forces us to ask and answer questions, which makes things more clear.
- Also, taking a decision is easier when we see the matrix as a whole, so aggregates, averages, etc. fog our decision.
Assign Functional Responsibilities to Elements
An element without any functional responsibility is good to be deleted. Create a diagram with elements and relations, and catalog the responsibilities.
Design for Change
Change is inevitable, so the design must not be so rigid that a change brings storms and catastrophe.
The way to deal with it is to take decisions only at the last moment. It gives us time to explore and keeps the flexibility to absorb changes.
If a design decision is easy to change later, then it's not significant for the architecture. Avoid wasting time on that and let it be open until the last moment, when making that decision becomes very important.