This is a method that allows you to easily and quickly, collectively and visually identify risks in a system. The method involves the participation of several people. For a broader view of the system under consideration, the full composition of participants may include people from different directions and with different skills. Method The method itself consists of several sequential steps. Let's look at each of them.
Step 1: Draw Architecture Diagrams Since the method involves searching for risks in a finished or under construction system, we need to somehow see this very system.
Architecture diagrams are a great help in this regard. They will illustrate the main components of the system and their relationships.
Step 2: Individual risk search At this step, each participant writes down absolutely any risks and problems that come to his mind on stickers. This step is carried out in absolute silence and should be limited in time. For example, 5-10 minutes may be enough. Examples of risks can be absolutely any assumptions about the inoperability of something. For example: The data format in the third-party system has changed External services are not available Data Inconsistency
Step 3: Share assumptions At this step, all session participants place their stickers on the architecture diagrams on the basis of which the risks were searched. Sticky notes are placed close to the part of the diagram where the risks described apply. If several session participants described similar risks, the stickers for these risks are placed together.
Step 4: Prioritization And at the final step, each of the identified risks is considered and discussed collectively. The purpose of this step is to determine how high a priority the found potential problem has. There are several options for assessing priority.
I will describe two of them: Planning Poker (PlanningPoker.com - Estimates Made Easy. Sprints Made Simple.) is where participants estimate risks using number cards and brainstorming.
In the end, negotiations must reach a common understanding. Using a special matrix on which the Probability of a problem is located on one axis, and its Impact on the other.
The purpose of this method is not to calculate every possible potential risk. Naturally, there must be limits to what is reasonable. “Shark attacks on data center employees” is a good idea, but it is guaranteed not to happen (unless the data center is located at the bottom of the ocean). The next step is to collectively evaluate each risk found using the team's assessment method.
For example, I will use the matrix method. Let's try to assess the priority of the risk of uploading a giant file to our service (we need to clarify, by giant file I mean any content whose size is beyond what is reasonable and accepted for a given system). Downloading a giant file can cause our system to waste a lot of resources processing and storing it.
Moreover, let's assume that our Image Storage is an S3 service from AWS, which means that storing gigantic amounts of data will cost us a lot of money. So I guess the likelihood is that someone will try thisundefined crank is not zero, so Medium, and The impact on the performance of the system and its maintenance is great, that is, High. Having assessed the risk in this way, I placed it in the appropriate row and column.
So, we have obtained estimates for each of the risks. Using the matrix, you can already draw conclusions about which risks you need to try to process faster than others. For example, an unlimited number of requests to a service can lead to a complete failure of the service due to a DDOS attack. A list of risks with their assessment will later serve as excellent introductory information for creating a technical backlog for the team servicing the service.
Sources:
Risk-storming - methodology website
Digitbin - website with articles on methodology
Leanpub - book by the author of methodology. In the book itself, a small chapter is devoted to methodology.
Top comments (0)