Fragile Support

The concept behind fragile support is twofold: One, it demands that systems be designed to function as robustly and intuitively as possible, so that they will never require much support; Two, it emphasizes pushing the support function back outside the business by providing fewer internal devices or services in the first place.

This is entirely backward from traditional support approaches which assert that control over as much of the user experience as possibles equates to more efficient operation. There is some superficial sense in this: control over every aspect of the user's end-to-end experience should allow the organization to optimize it, and a robust internal support organization familiar with the system should be able to more rapidly resolve incidents to the user's satisfaction. But this isn’t optimal at all, as a moment’s consideration should tell you: if anything is getting referred to the support team at all, there is a failure that is costing valuable staff time to resolve. And the more of the process you take responsibility for, the more support you will have to provide. Bad enough you had failure that has one of your staff scratching their head; doubly bad that you are paying both that person and another one or two of your IT staff to look into it.

Fragile support attempts to address this fundamental structural problem by restructuring internal systems to robustly support core functionality, and shift ancillary functionality outside the business, to more individualized or specialized providers. The classic example of this method in action is transitioning internal applications to web services and allowing users to access those services through whatever basic devices they desire. This allows the IT department to focus resources on providing a solid, well-defined service without a vast array of complexity at the periphery, and it allows users to use devices or methods which they are most familiar and comfortable with (theoretically reducing their own likelihood of running into circumstances requiring support). The business itself benefits both from the added stability, but also from the predictable cost structure... because it is not providing on-demand support via internal staff, it can manage costs by providing a standard stipend to the end-users (who are then responsible for obtaining support, and often procuring, their own gear and software).

There are numerous opportunities for deploying this model in most IT organizations, but there is often resistance both from IT (which dislikes the implied loss of control), management (who sees it as an attempt to shirk responsibility), and staff (who are used to the safety net of internal support). In a time when cost cuts are inevitable, however, this becomes a much easier sell. Ultimately, each party will realize the benefits from their own perspective: IT can focus on "pure" technology functionality, without those pesky users constantly interrupting the normal and logical flow of information; management has predictable, and lower, IT budget expenditures; and users can pick and choose among technologies and adopt their own preferred devices or software, without IT constantly saying "no" or changing systems under them.