Developer

Talking Shop: Internal support agreements keep IT support and development from butting heads

Achieve better IT management with an internal support agreement


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

Backups
  • 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)
Figure A

Services

Group

Types of Services

Hours

Systems Software

TS

Solaris, Sybase, installation, upgrade, maintenance

00:00-23:59

Systems Hardware

DS

Server, monitor, workstation, installation, maintenance

00:00-23:59

Application

A/D

Setup application, demos, project files access

08:00-18:00


Function of each server
Server: AD0001
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)

Server: AD0002
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

Special requests
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.
Figure B

Emergency backups and restore

Processed within 4 hours

File maintenance

Processed within 8 hours

Change mount directories

Processed within 4 hours

Add users and groups

Processed within 1 working day

Modifications to users, group, and permissions

Processed within 1 working day

Operation request

Up to 2 working days

Backup and restore for UNIX files only

Processed within 1 day

Solaris systems

Up to 5 working days

Database changes

Up to 5 working days

Hardware changes

Up to 5 working days


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.

Editor's Picks