Software Development: Building Reliable Systems
Internal Support Agreements (ISAs)
Service-level agreements have long been the mainstay of mainframe production systems and larger Unix client-server systems. On the web, however, service-level agreements become much harder to define and monitor. No longer are all the components of the application residing in a glass-house data center, or even distributed within a company. web-based applications may span multiple companies in an Extranet or, in the case of the Internet, may span across the world. The WCPA questionnaire, when filled out, helps span the many environments of the web and becomes a template for an internal support agreement between users and IT.
The internal support agreement is aimed at three groups: business managers receiving IT services, who need to ensure that the services delivered are in line with their business requirements at a cost they are prepared to pay; the system administration staff, who deliver these services and need to fully understand the commitments that customers require in order to provide quality service; and the new enterprise network services staff, who coordinate the delivery of these services across the web to their respective business units or external customers to ensure maximum contribution to business effectiveness.
With an internal support agreement, both internal and external customers can understand the kinds of service they should expect from their computer resources and how those resources are expended. On the other side, an internal support agreement makes sure system administration personnel understand their jobs well what services they provide as well as those they don't provide.
The differences between applications development and operational support are well publicized and have been going on for decades. Even when development and operations were centralized under one MIS organization, finger pointing was common behavior and everyone had no choice except conform to the same rules and guidelines. Networked computing has changed all that. Most of the issues centered around implementation and support of mission critical applications. Development would blame operations for messing up a restart or operations would blame development for lack of QA or support on their part. There were many issues of this nature.
In many companies today applications development is located within the business unit or division for business reasons this is good for quickly responding to business issues and requirements, but puts additional friction between the groups. After decentralization, companies must also deal with the cultural differences that occur. Many of the younger development staff come from a Unix, NT, or client/server background. So now you often have Unix mentalities versus legacy culture mixed within the same development organization.
In the early days of client/server computing, development organizations would attempt to support their own servers. Today, most development organizations want centralized IT to support their servers for system administration functions such as tape backups and restores . This is not much different than the old way of doing business when operations would support the development environment on the mainframe. One of the cultural changes that must be addressed when IT takes control of development servers is ownership of "root" authority (security privileges). Development organizations without IT support often enjoy the freedom of being on their own and having root authority.
One of the hottest topics when IT support first meets with development groups is the discussion of who will own "root" functionality. This generally starts out as a pleasant discussion with mutual respect among the participants . Development requests IT perform system administration functions while they keep root authority. IT responds that the only way to effectively perform system administration functions and to maintain integrity is for the data center to own "root". This is the only way IT can maintain high reliability, availability, and serviceability (RAS) with their limited resources. Development then typically responds that they cannot effectively complete their jobs if they don't have root authority. Many companies solve this dilemma by having joint root authority the data center owns it and several of the senior developers are also provided with root access. An internal support agreement is an excellent place to document such a root access policy. This model has proven to work well for many development organizations. A sample internal support agreement is included in Appendix C.