Recently I started reading the book Just Enough Software Architecture by George Fairbanks. This book helps me to prioritize the task. I Am adding my learning from this book here. This is first part of series of blog.
Software Architecture helps partition software, it provides knowledge, and enable abstraction to reveal the essence of the problem.
Risk driven architecture gives the priority to the risk of the project. So we take a risk in considering instead of an only feature. We can’t follow the same process for all team becasue each team have a different type of risk.
Risk is defined as the chance of failure times the impact of that failure. But measuring the exact chance of failure and impact is not easy. So we use our assumption of the chance of risk and also the impact and use it to measure risk.
Even if we are completely sure that there is no risk still we can’t guarantee it until we analyze and test it. And to analyze and test we need to understand what can be possible risks.
Risks
Describe risks: It is important to understand the type of risk and category of risk because every category of risk has a different way to handle it. Like there are project management risks, engineering risks and we can’t handle both in the same way.
The server can’t handle the 1M user is the engineering risk and the lead team member had an accident is project risk and both need to handle differently.
Identify risk: Requirement gathering can help us to identify the risk. If you're working in a new domain then you gather the requirements and then list down the things that seem difficult to achieve.
Prototypical risks: There are some risks that exist in a domain for a while. This list of risks is valuable for the less experienced and experienced developer.
Prioritizing risks: Not all risks are equally impactful. So we need to prioritize risk. But priority can be different according to a different team. The risk which looks very important for the development team can be less priority according to the leader. So if you are spending enough time on any risk it’s better to discuss with the leader also to understand the priority(there are some risks on which only the development team can make a decision).
I will write next blog on 26th March. Check it here
Top comments (0)