The Devil Is in the Details

The terms in your service level agreement can make or break your relationship with your ASP

By Debashish Bhattacharjee

Deciding to outsource your IT infrastructure has a strong business case. In the outsourcing model, you focus on your core competencies and leave the headaches about IT maintenance and costs to the application service providers (ASPs) such as USinternetworking (USi) Inc., Corio Inc., or Exodus Communications Inc. Although this business model has been in practice for a while in many companies, it has truly come of age with the Internet and open networking.

Enabling technologies such as virtual private networks (VPNs) for secure networking, remote connectivity software by Citrix Systems Inc., and Web-enabled applications promise to make remote applications processing a distinct possibility. Numerous ASPs are building impressive infrastructures and delivering services for this burgeoning market. But can the ASPs deliver?

Some of the ASPs can deliver, but others cannot. The key to a successful outsourcing solution is to build a partnership with an ASP that is capable of delivering results. The foundation of this partnership is the service level agreement (SLA). The SLA should address critical goals for your outsourcing solution (See Table 1)

In the article, I will examine each of these goals, identify what you should expect from the ASP, and briefly look at the technical implementations that ASPs need to provide service at the expected levels.

Performance

An application transaction's response time is a good measure of applicationlevel performance as well. You can think of a transaction as a unit of work that varies from application to application. For example, you can break up ERP application transactions into the time it takes to open up a window, retrieve data, and update that window. (In PeopleSoft, you refer to the window as a panel; SAP calls the window a transaction; and in Web-based applications, you call it a page or Java applet.)

Measuring the response times for these transactions can give you a good indication of how the application is performing end to end. This response time will tell you about the performance of the network, application servers, database, and operating system. When drafting the SLA, both you and the ASP should agree on the application transactions and set thresholds.

Scalability

Software distribution becomes a necessity every time you add a new user to the system or you apply an upgrade to the software. Web-based architectures follow the "zero administration" paradigm and require no software distribution, but client/server systems need client software placed on each user's desktop. Client distribution can be a major undertaking in a global system.

Citrix MetaFrame provides a popular alternative for remote connectivity to ASP infrastructures. Citrix lets multiple users remotely access applications installed on NT servers or Sun-based systems. Citrix MetaFrame sends a bitmapped image to the Citrix client installed on the remote desktop. The product runs on varying bandwidth and performs well even across WANs and dial-up connections. Citrix MetaFrame performance is comparable to Web-based access and facilitates the "zero administration" paradigm because software distribution (apart from the Citrix client) is not required.

During an application's life cycle, data volumes will grow. You must conduct a capacity plan to understand the nature of this growth at the very beginning of the system implementation because this growth will impact your database performance. The backup window will take longer, which may affect the guaranteed system availability. Furthermore, the database size will influence your choice of storage media. A large database may require solid state storage media, such as an EMC disk.

Optimal application architectures will depend on the type of package you implement. Most ERP systems such as PeopleSoft and SAP give you the option of implementing three-tier (the most scalable) or two-tier architectures.

Security

Where possible, you should implement adequate authentication procedures, such as password expiry and restricted super user access. Data encryption using VPN or public key/private key technologies will provide an additional layer of security. Finally, the ASP should apply patches to operating systems and databases on a regular basis to prevent hacker attacks through commonly known holes in these systems.

Availability

Uptime and recovery time are good metrics for availability. But what can ASPs do to implement robust, high availability? The answer is redundancy. ASPs should implement redundancy at all levels of the system architecture. Dedicated network pipes such as frame relay should have a failover and they should be load balanced if possible. You can also help safeguard your data by using RAID arrays. High availability solutions for NT and Unix servers can ensure failover and continued operation.

Additionally, ASPs need a solid disaster recovery strategy. Disaster recovery is usually done at a location that is geographically removed from the data center. Using a systems monitoring tool such as Tivoli or CA Unicenter can help ASPs ensure that all application components are up and running.

The system maintenance window will impact uptime. All systems require maintenance, which can include tasks such as backup of files and data, software upgrades, and scheduled server reboots. In most cases, you can conduct system maintenance while keeping the applications online. You can conduct database backups, for example, either online or offline. You should weigh the costs and the benefits for extended online hours vs. the amount of offline time needed to do the maintenance.

Support

You also need to determine the dynamics of reporting and resolving the problem. A help desk and ticketing system does help streamline the process and work flow, but if the ASP does not have a help desk system, a formal communications and reporting mechanism between customer and service manager needs to be in place. During the definition of this process, you need to set up metrics that will categorize problems by priority and a response time for problems at each priority level. You also need to determine escalation procedures for problems that are not resolved within the required parameters.

An SLA is a binding contract. If either you or the ASP violate its terms, you may face severe monetary penalties. Defining an effective SLA is therefore critical, and you should negotiate its terms with the goals of scalability, availability, performance, security, and support in mind. By clearly spelling out your needs before entering your relationship with the ASP, you will minimize risks and ensure that you receive quality service and a quick ROI. And you can get back to doing what you do best.

Return to Article