First-time tech lead? Here is how you can take effective Architectural decisions

Any software project has primarily two kinds of requirements, one is a set of the functional requirement (product features) and another is a set of quality attributes (also called Non-functional requirements) such as Performance, Interoperability, Usability, Reliability, Availability, Security, Maintainability, Modifiability, Testability, etc.

These quality attributes are key system characteristic and behavior which demands architectural consideration. If you are a tech lead then probably it is somewhat your responsibility to make sure that the team takes a rational architectural decision. However, Every developer has biases based on their previous experience and things that interest them. These biases might cloud their judgment. As part of this post, I am not going to tell you which architectural techniques you should follow, instead, I’ll try to explain a few techniques which can guide you to take more effective architectural decisions.

Tale of Two Extreme

In the early years of my career, I was putting all of these quality attributes on the same level. I wanted software system to be performant with great user experience and highly secure and testable and yadda yadda, failing to realize that We can build a system which has all the quality attributes only if we had infinite time, but engineering among other things is about best usage of available resources including time.

On the other extream, Working in start-up made me think that, we don’t need to pay much attention to these qualities attributes, Just one monolith is good enough (after all time-to-market was the key driver for developers and PO). All we needed to do was to deliver the features, PO didn’t care if we do micro-services or monolith as long as feature/product was delivered. We had some kind of ad-hoc architecture which so far was working for us. It was only when active development ceased and the project went into maintenance mode we started to face issues around performance, usability, and Modifiability which ultimately led us to rewrite the whole system.

Prioritizing Quality Attribute concerns

Software quality attributes are key deciding factors which drive the architecture of the project. While all of these attributes might seem important, It is necessary that we prioritize certain attributes over others. For instance, if you are building a financial system, you might value resilience and fault tolerance over performance. However, while building an embedded system, you might favor raw performance over resilence and reusability.

Every quality attribute that we choose to prioritize over others has its own benefits and trade-offs. For instance, Performace might be nice to have but it could make code rigid and hard to modify, but if you value modifiability higher, then you should reject design that yield performance at the expense of modifiability.

What this means is that we need to create a project-wide understanding of the priorities of these quality attributes. This can be a simple list as shown below

Modifiability > Usability > Performance

This helps developers to make rational architectural decisions whenever faced with choices. Also, this priority list can solve a lot of disagreements among developers, For example, if one developer thinks option A is better and another think option B is better whereas Option A helps in performance and option B help Usability. Looking at the priority list, we can see that Usability is a higher priority for the project than performance and settle for option B.

Bring Risks to prominence

Risk can come in various shapes and sizes, some of the typical risks are misunderstood or incomplete quality attribute requirement, Complex, poorly understood the problem, choosing wrong COTS software, Integration with existing, poorly understood software, etc.

The idea is not to be obsessed with feature completion, rather bringing risks to prominence. This can be done by relentless questioning process: “What are my risks? How can I mitigate them”. If the risk project threatening, It should be treated on par with the feature.

For instance, if you pick up a new feature which involves integration with an external system, you should think about possible risks, what happens if the external system is down, do we need need to be resilient, do we need to worry about transaction consistency and rollback, should we worry about cascading failures, should we have some kind of retry mechanism, etc. There could be many risks, but looking at the quality attribute priority list for the project, we can decide which ones are important requiring architectural considerations.

Summary:

1. Have a project-wide consensus on quality attributes for the project. This list of the quality attributes would serve as the key architectural drivers for the project and decision can be based on it whenever faced with choices.
2. Relentlessly asking “what are my risk?”. These risks are guided by quality attributes of the project.
3. Once risks are identified, Prioritise them based on the impact on key quality attributes.
4. Come up with strategies to mitigate/eliminate.
5. Decide on Strategies which aligns with the key architectural drivers (point 1).
6. Finalize on strategies which mitigates more than one top risks.
7. Evaluate the risks again.

Further Reading:

Just enough Architecture by George H. Fairbanks.