What IT ShouldShould Not Support

What IT Should/Should Not Support

In deploying web-centric applications, it is often more important for IT to know what services you don't provide, particularly in those gray areas where previous practices might lead to differences of opinion unless support policies are clear. For instance, in a traditional client-server environment, IT controlled not only all servers, but all desktops where client software was installed. In a web-centric approach, no client software other than a Java-capable web browser needs to be pre-installed. All application software can be downloaded at run time. In such a scenario, especially if the application is deployed over the Internet, IT may have no control of client desktops, other than to specify a minimal browser revision level. If a business unit uses some special, non-IT supported browser and the application runs into difficulty, IT might do an initial diagnosis but normally should pass along the problem to the business unit, who chose the unsupported browser in the first place.

Besides caveats, there are a variety of responsibilities IT and business unit customers accept as part of the Internal Support Agreement. Customers are responsible for providing the list of services they need to support their operations. The levels of service should be held to as few categories as necessary. Customers are expected to work closely with IT to ensure all users carefully select, control, and regularly change user passwords, according to corporate security policy. Final configurations are the responsibility of IT, implemented and supported as defined by the WCPA questionnaire. In cooperation with the local facilities organization, any distributed web and proxy servers are managed to ensure an adequate environment for systems. The Internal Support Agreement also spells out what some consider the ultimate responsibility: funding. The business units, not IT, should be responsible for obtaining funding and approval for all their appropriate capital assets to ensure sufficient computing resources. They are responsible for future adds, moves, and changes, as well as funding for those future systems. If management doesn't allocate money and resources to meet those customer needs, IT and the customer must and will negotiate a reduced level of support.

Finally, anything included in the service-level agreement and budgeted for IT services, will be provide by IT. Anything not included is either done without or later negotiated.

The WCPA is not foolproof. In fact, there are many ways to defeat its purpose:

• Put an application into production without thorough testing and documentation.

• Treat every application as an exception and take shortcuts.

• Reassign application developers to new projects before completing deployment of the current application.

• Be too busy to thoroughly document.

• Let the WCPA gather dust, versus making it an ongoing process.

Barring such willful ignorance or neglect, the WCPA doesn't just happen on its own. Here are some things you can do to make sure the WCPA succeeds in your organization:

• Start early; don't wait until an application is nearly ready for production.

• Intimately involve developers and users; build their sense of ownership.

• Always adhere , without exception, to the WCPA for new applications and releases.

• Clearly spell out and document responsibilities and duties in the WCPA questionnaire.