Designing for the Worst Case Scenario

Nick Randolph posted an interesting entry on The Right and Wrong way to Centralise Services. Firstly, I'd like to clarify the use of the word "Services". The referenced article is referring to the centralisation of IT systems and data so that regional health care units can share data efficiently. I don't believe Nick is referring to "Services" in the context of SOA.

Nick makes a very good point regarding assumptions that architects make when designing systems. It is the responsibility of an architect to design a system so that it will meet all its service level agreements. These SLAs must be met by the system even when things go wrong. It is of course important to determine that the SLAs are realistic in the first place.

Too many times have I seen systems designed for the best case scenario. I tend to find myself asking questions like, "what if this server crashes or is rebooted?". A common response to these questions is "that will never happen," closely followed by "why are you over complicating this?".

The complication comes from the nature of the requirements themselves. Systems that handle unreliable connections are more complex by nature. Burying our heads in the sand and hoping for the best will not deliver a system that does the job. Architects really must start thinking more about designing for the worst case scenario, such that the minimum SLAs are met.

To finish, I'd just like to thank Nick for the warm welcome to the blogosphere. Nick works for Intilecta and is very knowledgeable in the area of mobile applications. You can find out more about Nick's travels here.