Comments on: Single Point of Failure http://antipatter.com/2008/07/single-point-of-failure/ The Web, The Business, The Smoke and Mirrors Sat, 01 Jan 2011 06:07:56 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: loren http://antipatter.com/2008/07/single-point-of-failure/comment-page-1/#comment-6 loren Tue, 22 Jul 2008 17:40:42 +0000 http://antipatter.com/?p=14#comment-6 @Lon I like how you frame the idea as a "higher-order" bus test. I think you may even be treading on a deeper issue - too often systems are treated as one time investments that are allowed to fester, rather than the builders accepting responsibility of ongoing maintenance of an automated business process. Business processes evolve and require people to keep them alive - automation doesn't change that basic fact. @Lon I like how you frame the idea as a “higher-order” bus test. I think you may even be treading on a deeper issue – too often systems are treated as one time investments that are allowed to fester, rather than the builders accepting responsibility of ongoing maintenance of an automated business process. Business processes evolve and require people to keep them alive – automation doesn’t change that basic fact.

]]> By: Lon http://antipatter.com/2008/07/single-point-of-failure/comment-page-1/#comment-5 Lon Mon, 21 Jul 2008 20:21:57 +0000 http://antipatter.com/?p=14#comment-5 The bus test is one that comes up in regular conversation around my office. Designing a system that passes the test is not that hard, once people keep the idea in mind. Which is easy enough when the boss (me) says it ad nauseum (I do). Now, the harder part, is about getting system architects to think about higher order bus test. That is, not whether the system can run after key people are bus-ed (ouch), but whether or not the software maintenance can occur. This is something about ensuring knowledge of maintenance and code expansion. A simple way to wrap one's head around the problem is by asking "what would it take to replace a developer?" For instance, if a system is based on a key technology that almost no one knows, and there is only one guy in the company who knows it. And he gets bus-ed (again, ouch), how system may not crash that moment, but it has transformed into a ticking time bomb. This is a problem most companies face in legacy systems that use legacy technologies. The bus test is one that comes up in regular conversation around my office. Designing a system that passes the test is not that hard, once people keep the idea in mind. Which is easy enough when the boss (me) says it ad nauseum (I do).

Now, the harder part, is about getting system architects to think about higher order bus test. That is, not whether the system can run after key people are bus-ed (ouch), but whether or not the software maintenance can occur. This is something about ensuring knowledge of maintenance and code expansion.

A simple way to wrap one’s head around the problem is by asking “what would it take to replace a developer?” For instance, if a system is based on a key technology that almost no one knows, and there is only one guy in the company who knows it. And he gets bus-ed (again, ouch), how system may not crash that moment, but it has transformed into a ticking time bomb.

This is a problem most companies face in legacy systems that use legacy technologies.

]]>