Get your act together Sell your users an Internal Support Agreement, but get your IT house in order first

July  1996

Before the rise of PCs, it was easy to identify and understand who was responsible for solving certain problems. Everyone knew where the demarcation was between the Data Processing subcultures. We knew how to interact and where to seek help for troubleshooting problems. Networking grappled with networking issues, Database Administration hovered over the DBMS, and so on. That simple time has passed, and today we distribute everything everywhere. The question of who supports what and when looms like a dark cloud. (700 words)

Mail this article to a friend

In our previous articles we explained that today's IT needs to develop and deploy streamlined, flexible, and inexpensive processes. These processes are the products and services IT must now market and sell to internal customers. But before treading this path, you need to examine IT's strengths and weaknesses, and bundle its products and services under an enticing wrapper a salesperson can sell enthusiastically. What is this wrapper? The Internal Support Agreement (ISA), which is an update to the time-tested Service Level Agreement (SLA).

Mainframers certainly remember SLAs, but our Unix-only readers might not. The SLA was a signed contract between MIS and users that outlined the services provided (i.e., response times to online access, report distribution, and so on.) The SLA was a valid process in the mainframe age, and it still is today. But what good is an agreement unless you get your house in order first? You need to define roles and responsibilities. Like theatergoers, your users (your customers!) should not see the mess behind the scenes. Users should need only one telephone number when they have a problem.

Who does what when in IT
With applications running wild all over your WAN and down to the LANs, when a problem occurs it's not easy to pinpoint the trouble and figure out which group is responsible for solving it. Users know that when a process goes awry they should notify IT -- that's the easy part. Pity the poor Help Desk person who must find the right group or groups from whom they they can obtain solutions to these problems. The ISA is not only for defining these types of support roles and responsibilities, it also should be established as a model within the different IT groups throughout your company and should define customer expectations.

Although we preach the same organizational methodology as we once had with centralized control in the legacy world, today (in most companies) IT support people are scattered throughout divisions where they once were cloistered in the same building. Wasn't it difficult enough to support the production and development environments and interacting between the centralized MIS staff? It is a nightmare now in the complex world of distributed computing with decentralized support organizations.

In most of the companies we visit around the world, the Applications Development staff is located at the division- or business unit-level. Unfortunately, the support groups reside in different buildings. They would like to use the services of centralized IT support. How does a centralized IT support group provide help to scattered corporate developers? These issues and more should be clearly defined in the ISA.

Once you get your house in order then you can put together a marketing program to sell your services. But don't bother to start selling until it's all running smoothly.

Resources

• Other Unix Enterprise
  /sunworldonline/common/swol-backissues-columns.html#unix

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-07-1996/swol-07-unix.html
Last modified: