By Harris Kern
My consulting company visits many organizations where each business unit is responsible for its own applications. Applications development is distributed across the organization, while the IT support function resides in its own division. It can be very difficult for a centralized IT service organization to support distributed groups of application developers—especially when both sides want more control over the other’s territory.
In fact, in my experience, of all the IT issues and concerns, none has been more intense than the battle between the applications development and the IT infrastructure support groups. Even when development and support are centralized in the same organization, there’s always a lot of finger pointing. The internal support agreement can be a welcome addition to this unstable mix. In order to keep the peace between applications development and IT support, you must create an internal support agreement that outlines each department’s respective boundaries. Without this agreement in place, this battle might wage on long enough to cause serious problems for certain projects and within the organization as a whole.
Both sides want more control
The basic charter for applications development is to design, develop, and deploy production systems as rapidly as possible. For IT support, the charter is to verify compliance with the guidelines and standards and ensure QA testing and documentation. Most issues seem to revolve around mission-critical applications. Development blames IT support for its failure to quickly restart an application after an error. IT support blames development for poor QA.
Development servers present a special problem for the applications development and IT support groups. Applications development often wants full administrative control of the development servers with limited assistance from IT support for mundane tasks like backup and recovery. This poses a problem, because owners of root passwords can bypass normal safeguards and unintentionally destabilize a machine in seconds. Applications development needs access to perform key tasks, while IT support needs to be responsible for the reliability and performance of the system. Who’s in control here?
How to solve the problem before it starts
My partners and I devised “joint root authority” that maintains that the IT support organization and the two most senior developers own root access. If the developers abuse root privileges, IT support will no longer support development servers.
An important piece of this puzzle is the internal service level agreement (SLA). It is a formal agreement that clearly defines expectations between IT support and applications development. Here are some of the key elements of an internal SLA:
Server root authority
Root access to support Servers AD001 and AD002 is given to Staff A in applications development and Staff B in IT support. They support each other and provide backup in cases where one is ill or on vacation. IT Support will be contacted if both are unavailable.
All changes to the root account are audited to provide a trace of root user activity. IT Support is responsible for the following upon request:
- Operating system changes
- Disk reconfigurations
- Modifying the root user environment
- Installation of binaries into the system directory structure
- Modification to any network-related configuration files
- The modification of any system daemon that is run at the root level
- Changes to the system files
Applications development root owners may perform a well-defined set of tasks, such as changing /etc/exports for mount directories and adding users and groups.
Server availability hours
- 00:00–23:59 Monday, Tuesday, Wednesday, Thursday, Sunday
- 00:00–23:00 Friday
- 03:01–23:59 Saturday
- Full system backups start at 23:00 every Friday, total downtime is 4 hours.
- Incremental backups start at 20:00 Monday through Thursday; approximately 30 minutes
Support responsibility (see Figure A)
- Technical services (TS)
- Desktop support (DS)
- Application development (A/D)
Function of each server
This will be the primary development server designed for intensive workloads. Free temporary disk space is available through UNIX automount. Disk quotas are established for each project. Disk space availability is determined by the scope of the project.
- Solaris version
- DNS and NIS slave server host name, IP address, aliases
- Data base server (for example, /home/oracle)
- Free log disk space via automount (for example, /home/common)
This machine is the preproduction server:
- Solaris version
- Project files, data, databases (for example, /home/hrproj)
- Clients personal files (for example, /home/username)
- Support client software
There are different types of special requests with different estimated completion times (see Figure B). Any change involves investigating its effects on other applications on the server. IT support will notify the requestor in cases where the completion time will be longer than the estimated time.
Add to and customize these key elements and you’ll have an internal support agreement that will clearly define the parameters of IT support and applications development.
For more information on the Harris Kern Enterprise Computing Institute, visit www.harriskern.com.