Internal Support Agreement
The differences between applications development and operational support are well documented. Even when evelopment and operations were centralized, fingerpointing was common. There weren't many options and most IT professionals opted to pass the buck rather than face the music. Networked client/server computing has changed all that.
Most of the issues were always around implementation and support of mission-critical applications. Development would blame operations for messing up a restart to an abend or operations would blame development for lack of QA or support on their part. There were many issues of this nature.
In most 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 creates additional friction between the groups.
At Sun Microsystems, where two of the three authors worked during the transformation from mainframe to client/server computing, we not only went through decentralization, but we dealt with cultural differences. Many of our new development staff came from a Unix or client/server background. And we had a number of people on board who had been in the legacy world.
The development organization still wanted centralized IT to support their servers for system administration types of functions such as backups and restores, so it's not much different than the old way of doing business when operations would support the development environment on the mainframe.
At first, our development staff attempted to support their own servers. Well, they tried. They wanted to do things their way. They enjoyed the freedom of being on their own and having root authority (security privileges). Reality set in when it was time to perform system administration functions on a consistent basis (backups, O/S maintenance, etc.). But who wants to? That sort of stuff is boring. Operations support has been providing these services for years.
The first meeting we had with one of our development groups was memorable. We met with a manager and two of his senior technical staff. One topic that we discussed was who would own root functionality to their Development environment.
It started out as a pleasant discussion. We had worked with this manager in the past and there was a mutual respect. He requested that we perform system administration functions while his organization keep root. We stated (in true dictatorial fashion) that the only way to effectively perform system administration functions and to maintain integrity is for the data center to own root. They said, oh no, we must own root. It would tie our hands and slow us down from effectively performing our job. We knew this conversation wasn't going anywhere. Why argue? So we played along with their request, giving them root authority and we'd perform the support role. We knew that within days they would clobber their environment, and they did just that. We came back and told them that the only way they could maintain high reliability, availability, and serviceability with the limited resources we had was to own root. They said that it was essential for performing their job. We were sympathetic and understood the deadlines and pressure they were under. We came back and said that we no longer wanted to perform these system administration functions because of this issue. The conversation was going nowhere. But then, for whatever reason (maybe frustration), we eased up and said, OK, let's try something as an experiment—joint root authority. The data center will own it and two of your senior technical staff will own it as well. If the developers abused this policy, the data center would no longer support their servers. Everyone agreed! Eight years later and it's still working. A sample ISA (the original one which was developed in 1990) is included in Appendix C.
External Service Agreement
The entire concept of service agreements evolved once again from those mainframe environments. In its inception, the sole purpose of what MIS referred to as a service level agreement (SLA) was a contract between the IT department and its end-users. All service related expectations were outlined in black and white. The following was recorded and monitored:
Online availability
Response times
Report deliveries
Problem resolution expectations
Special requests for services, etc.
Many shops still use this SLA, and we've included one in Appendix B. The only problem with this process is that once the document is signed and heralded by all participants, in many instances it just gets put on a shelf somewhere to gather dust. What we recommend is to incorporate the function of the SLA into the CSPA process for each application. The CSPA is an active process that promotes and instills effective communication practices.