The Risk in Risk Mitigation

Published on Thursday, March 15, 2007

Back in the day the barrier to entry for the Internet was quite high. The technology used required a steep learning curve, the equipment extremely expensive, and sometimes even hard to acquire. Fast forward to 2007 and things have certainly changed. If you know any tech people you can likely get free hosting for a small website, and even more demanding websites can be hosted for not much. The cost of dedicated servers has dropped even more. And the final kicker: web services. I've started to think of some web services not as a service, but more like outsourcing requirements.

This very dependency adds risk for a multitude of reasons, and when your entire web application platform revolves around a third party, such as is the case with mashups, you incur great risk.


One of the nice things when requirements are outsourced is the fact that risk is mitigated. I'll use SmugMug as an example. In summary, they moved their storage to Amason's S3 network, which is something I will be utilizing as well. Amazon's S3 (and other web services) continue to drive down the barrier of entry -- now you don't even need to purchase hugely expensive servers for the sole purchase of storage! If you don't need to purchase them, you also don't need to manage them. Risk mitigated.

However, continuing the slight allusion from The Other Blog's article on mashups, I see a slight problem with the outsourcing of requirements. While the following thought isn't particularly innovative: mitigating risk and outsourcing requirements creates a dependency on the third-party. This very dependency adds risk for a multitude of reasons, and when your entire web application platform revolves around a third party, such as is the case with mashups, you incur great risk.

But, as is evident by the fact that I've had stitches nine different times, I'm still going to do some cool mashups anyways, so stay tuned.