Lesson 204 - Risk Storming For Architects Transcript, AI Summary & Key Points

00:00 hello everyone and welcome to software architecture Monday my name is Mark Richards and in this lesson number 204 we'll take a look at risk storming for Architects risk storming is a technique where we can collaboratively identify and look for risk within an architecture now in Prior lessons specifically lessons 127 128 and 129 uh I took a look and described aspects of assessing architectural risk and as a matter of fact this particular lesson number 204 really pertains to lesson 128 on identifying architectural risk

00:44 what I'm going to show you is a technique called risk storming that allows us to identify risk a couple of resources you can get more information on risk storing the first is uh Simon Brown's book software architecture for developers where he describes this technique of risk storming and also we dedicated a chapter in our fundamentals of software architecture book about risk storming as well when we take a look at assessing or identifying risk within an architecture uh the context of risk storming really falls into the

01:23 identification of that risk uh recalling back to lesson 120 8 oh what we did in that lesson was we saw how to assign risk to various areas of a system based on criteria uh specifically architectural characteristics but I posed the question in lesson 128 how do we identify this risk and I showed you one area or one aspect technique of doing that and that was through this Matrix uh where we take a look at the overall impact of the risk crossed with the likelihood and rate these low medium or high and then multiply each

02:09 of the grids to get a numerical analysis in other words uh 1 to2 is low 3 to four is medium and 6 to9 is a high risk what I want to show you is this technique of risk storming where we can better reduce the level of subjectivity when we're assessing risk within an architecture our risk storming starts with an architecture either a new or proposed architecture or even an existing architecture that is undergoing change and the idea of risk storming is that it is a two-part process uh phase one is really an individual

02:53 phase where the team that is doing the risk storming analyzes the architecture individually and they start without any discussions between them looking for risk areas using that Matrix to identify one to two which would be low risk which would be green 3 to four medium risk which would be yellow and then 6 to9 which would be high risk in terms of being red now phase one this individual phase is usually done a day or two ahead of the risk storming session this is a critical phase and the reason is that if we were all

03:34 just to get together and start looking for risk somebody might point to let's say h a database or one area of the architecture and everybody's eye moves over to that area and so the purpose of this individual phase is so that we're not or any of the team members aren't swayed or redirected away from areas the architecture where they where they might in fact see risk well once that phase one ends everybody gets together and these teams are usually constructed of anywhere from oh three to six people including by the way

04:14 um the architect who of course was is in charge of the architecture um it might include other Architects uh certain stakeholders maybe from operations maybe from infrastructure maybe from data and also developers as well and that's um that's an important piece that I've discovered is a winwin situation in Risk storming uh developers sometimes see areas that we don't see as Architects that might be risk and also it gets the developer involved in the architecture and helps get that buy in okay when Phase 2 starts we all

04:54 get together risk storming sessions usually take on average around an hour or so and everybody gets together and starts putting yellow or red or green Post-it notes with the number on it of where they found areas of risk and and the team members all do this together just kind of put all the the areas of risk found and you can see that this particular architecture it's not important what the architecture is has some areas of risk well what we're trying to do phase two the collaborative phase is to look for consensus

05:35 within the risk areas and we can see already we have consensus um everybody thought that or three people at least thought that the squid proxy servers were high risk the push expansion servers over here were medium risk and finally low risk over in the mcash and Cassandra area so since we all agreed we're effectively done with those areas the real purpose of the second phase of risk storming is really to have discussions to convince others to be able to arrive at a single solution uh so for example we see that two

06:14 people thought the elastic low balancers were medium risk one person said High one person thought the ppns servers were high risk and somebody thought redus was risk well let's take a look at each of these and see how risk storming works so the idea is we start to tackle the areas where we disagree and we might say something like this all right who put the red uh nine there for high risk and somebody says I did why' you put red well listen if we if we lose those expand or those elastic load balancers uh there's no

06:50 access into the system that's pretty high risk well says the other two team members oh we do agree that the overall impact of the risk is definitely high but let us show you some metrics because we gathered some information historical information and we can demonstrate that those elastic low balancers have well as far as we have tracking never gone down so that means the likelihood of that risk occurring is low that's why we put it at a medium number three and that's how this graph or this Matrix actually works it's

07:31 impact over likelihood so the person who put red there said oh okay well in that case I agree with you um it is high impact but I see that it's pretty low risk from a likelihood so we'll put that at a medium and we all agree and that's kind of the process of risk storming now there's two other aspects that I want to show you that happen in Risk storming the first um somebody put a high on PP pns servers well who did that well I did well why did you put a high there listen on the last product I worked on we had to

08:08 interface with those ppns servers and it was our biggest headache they were always unavailable we had to do so many workarounds with those oh well I'm glad we had you on our risk storming session you see getting other Architects perspectives as opposed to just our experiences uh gives the capability of identifying risk where we would not have seen that risk before so we all agree oh okay that's high risk but then we see this one who put high risk for our redis cache and somebody says um I did as a matter of fact it was

08:49 one of the developers it's like well why did you put high risk and the developer says what's redis this is one of the reasons to include developers in your architecture risk storming you see as the architect I made the assumption that all the development teams were well experienced in redus and here one of the developers that will be working on this hasn't even used redus doesn't know what it is so unidentified or unproven Technologies or even unknown Technologies automatically get a high rating and this use of risk

09:26 storming a eventually identifies risk areas across all of the areas the context across the criteria eventually filling in uh this entire risk Matrix I I showed you in lesson 128 well that was the kind of very quick tour of risk storming but there's one other thing I want to show you just as a pro tip and that is try to limit your risk storming sessions to a single criteria or a single context area uh for example maybe after a lot of changes we say um we're going to do a risk assessment based on availability across all

10:11 the areas of the system or you may say today we're going to do a risk storming for all of these categories in test taking and so this kind of uh by criteria by context is a smart way of reducing the scope of these risk storming sessions and by the way another Pro tip this is not a one-time activity this happens periodically through the creation or migration of an architecture but as an architecture undergos change or the technology under goes change or maybe it's the environment or the business uh risk storming up

10:48 efforts uh help collaboratively identify risk areas within the architecture so this has going a follow up to lesson 128 which is lesson 204 risk storming for Architects um please stay tuned in one more month because I am now doing a one-month Cadence uh the first Monday of every month is a new lesson in software architecture Monday so I will see you then