Oh no, a post about risk. Yes, I know this post might seem boring from the title, but bear with me. Here is a picture of cat to keep you going.

Right are you refreshed and invigorated, ready for a roller coaster ride of risk. Lets get started….

The normal approach to managing risk it is identify it, classify it and then provide some form of mitigation to stop it turning into an issue. Architecture is often defined as managing technical risk. When there are a lot of risks and/or their impact is high there is tendency to do work to mitigate them early. This why you might see lots of upfront design work or project planning. It is an attempt to make the uncertain, certain. It is an attempt to avoid the risk occurring because the cost of it’s impact is too high to bear.

Some examples of risk are

  1. Unreliable architecture meaning a server failure causes an outage that results in loss of revenue
  2. Changing requirements late in the day causes cost overruns or implement delays

OK, you have done well getting this far. Here is another picture of a cat to keep your energy up.


Still here, great!

If you could arrange things so that the impact of the risk was next to nothing, would you approach risk management in the same way?

If the impact of the risk is nothing you change from a mindset of reducing risk to accepting it. Bad things will happen but you have systems and tools in place that mean you are not affected. But how might you do this.

  • Working in small batches means that changes are smaller and the impact of that change not realising it’s intended value is low.
  • Reducing the lead time between you having an idea and testing it with real customers means you can regularly deliver. You can get feedback from your customers quickly and change course as necessary. There is less chance  of investing time and effort building something nobody wants.
  • Building a reliable and repeatable release pipeline means that the transaction cost for getting the next version of your software in front of customers is lower. Automating this also eliminated the chance of human error.
  • Regularly introducing failure into your Live environment and ensuring that your systems and processes can cope means that when something fails for real it is routine and customers don’t even notice.

Any of this sound familiar?

I have kept this short and to the point. Here is a picture of some beer as a reward. Hopefully there be some real beer nearby.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s