One of the key functions of the software architecture role on software development projects is the identification and mitigation of risks, particularly those that have the potential to cause your project to fail or you to be fired! This all sounds very sensible but assembling a list of risks is often seen as a boring task and it's often neglected. Furthermore, if that list is assembled, it will typically only represent the viewpoint of one person. Like estimates, risks in the real world are rather more subjective than they ought to be and for this reason alone, it makes sense to get input from more than just a single person, especially if that person is the solitary software architect on the team.

I talk about risk on the Software Architecture for Developers training course and use a technique I call "risk-storming", which is a collaborative and visual way to identify risk. There's more information about this in the Software Architecture for Developers book, but here's a quick summary.

Step 1: Draw some sketches

Draw some sketches of your software architecture. I typically use my C4 approach (context, containers, components and classes) but any approach that gives you a small number of different diagrams at different levels of abstraction will do the trick.

Step 2: Identify risk individually

Get the whole team together and ask each person to individually (because risk identification can be subjective) identify the risks and score them based upon probability and impact. If you multiply the probability and impact scores together (see diagram below), you'll come up with a number and you can use these numbers to group the risks into low (1-2), medium (3-4) and high (6-9) priority. Ask everybody to write each risk they identify on a sticky note, preferably colour-coded according to the score that you come up with. Timeboxing this exercise (10-15 minutes) can work well.

Step 3: Converge risks on the sketches

Ask everybody to place their sticky notes on the sketches. For example, if you identified a risk with a component that may perform too slow, place the sticky note representing this risk over the top of that component on your sketch. If you see duplicate risks, just overlap the sticky notes rather than removing them from the sketches.

Step 4: Discuss and prioritise

As with software development estimates, some people may not agree on the probability and impact of some risks, so further discussion and prioritisation may be needed.

You still need to mitigate your risks

Now you should have a nice "at a glance" view of where the risks are across your software architecture, which might include everything from the use of new technology through to design complexity and infrastructure becoming unavailable at runtime. If you've used different colour sticky notes to represent different priorities of risk, it should be very obvious where the riskiest areas of your software architecture are. If you've ever struggled to sell a prototype to your management, this sort of picture may really help. Don't forget that you still need to deal with or mitigate those risks though!

Responses[1]

Posted by Simon Brown on 11 July 2012 10:35:44 BST #