10.2 Establishing service-level agreements


In discussions regarding SLAs, we should start by defining exactly what the term SLA means. In a generic sense, an SLA is an agreement between a service provider and a client about the quality or degree of service that the client requires from the service provider. As I have discussed previously, the service levels can cover a range of topics such as performance, delivery, availability, reliability, and so forth. Most SLAs tend to focus on the responsibilities of the service provider. However, I would encourage you to include the responsibilities of the end user as well as the messaging system when defining your SLAs for your Exchange deployment. Also, I should probably distinguish an external SLA from an internal SLA. An external SLA for your messaging system is a contract or agreement between the messaging system staff and an external service provider. For example, suppose you rely on an ISP for your Internet mail (SMTP) connectivity for your Exchange deployment. The messaging IT organization may have service levels and agreements defined with that ISP with the messaging system as client. While this external SLA directly affects the internal SLAs you have with your internal clients, it is not an SLA with your clients and therefore is an external SLA—you are the client. As another example, if you provide your messaging services to external organizations such as customers or business partners, you may have established external SLAs with those organizations as well. For the purposes of this discussion, I will stick to the topic of internal SLAs, which are SLAs created between divisions or departments within an organization. In most cases, the service provider is the IT department, and the clients are other departments or business units within the company.

SLAs are part of a big picture in that they establish a commitment to actions or services that the organization requires to do business. Service level commitments provide direct evidence of just how important information technology (and therefore, the IT organization) is to the organization’s success. SLAs also provide a method of measuring the ROI of IT resources. Because of this, we should think of SLAs as a nonstop cycle or loop of dialog, agreement, planning, implementation, monitoring, reporting, and feedback. According to a Ferris Research report, approximately 40% of large organizations have SLAs in place for their messaging systems. Of the organizations that did not have messaging system SLAs in place, about two-thirds either are developing them or have plans to do so. There is an obvious trend toward the establishment of internal SLAs for messagingsystems. This is due to the fact that e-mail and collaborative applications have become an essential business tool, and the need to manage and monitor messaging system performance has become absolutely critical to an organization’s success. SLAs provide a fundamental construct for defining system requirements and evaluating the performance of the messaging service provided. For a messaging system like Exchange Server, SLAs provide a means of establishing the service necessary to conduct business and provide assurance that messaging services are available when needed.

Cost is another driving factor behind SLAs. Organizations will always demand the highest levels possible, but these demands are often tempered by the costs involved. The process of establishing and maintaining SLAs provides a cost factor and justification required for the service expectations of users. The holy grail is found when business units and IT staff find a “sweet spot” between cost and service level resulting from trade-offs between critical business services and tools and the reasonable cost of those services.

There are four factors that will typically motivate you to develop SLAs for your Exchange deployment. The first is the realization that messaging and collaboration is a mission-critical resource. When outages occur, they usually do not go unnoticed. In fact, in the last several years, the importance and visibility of corporate messaging-system downtime have risen to the levels of many Line-of-Business (LOB) applications such as ERP, MRP, and so forth—some would say that the importance of messaging services has even surpassed these applications. Like LOB applications, when the messaging system in down, the organization will suffer productivity losses. In companies where e-mail is a primary means of product or service delivery, the losses far exceed simple productivity losses.

The gap between client expectations and services provided is another motivating factor for establishing messaging-system service levels. As SLAs are developed, the process helps users understand the real challenges (in technology, costs, and other areas) that IT staff members face in providing services. This awareness brings users down to a level of more realistic expectations for the characteristics and qualities of the services being provided. When an SLA has been developed and established, it functions both as a measure of performance and as a measure of the real value of services being provided.

Migration or architecture changes are often another significant factor that drives the need for establishing SLAs. Since the technology (both software and hardware) has such as outrageous rate of change, there are always new “feeds and speeds” calling out to users and technologists alike. The need for better performance, reliability, and new technologies is an example of this. Since Exchange Server has only been around since 1996, the quick rise to fame of Exchange is an example of how organizations with legacy messaging systems jumped on a new technology bandwagon that resulted in major architectural changes and IT investments. Since senior management is not always willing to sign blank checks for technology investments, SLAs have provided a great method of documenting the ROI for these investments.

The final motivator for SLAs may be a change in the IT organization’s status within the organization. Since IT has always been a source of revenue loss (a cost center instead of a P&L business unit), many IT organizations have found themselves last in line when corporate funds are distributed. As a result, IT organizations have had to develop chargebacks, methods of reducing costs and even of making money. Chargebacks to business units who use IT services are a method of both controlling costs and of providing a softdollar revenue stream to the IT organization. With these practices in place, IT can provide not only justification for its existence, but also a legitimate flow of funds back into its coffers that offsets the expense of the IT organization. SLAs are an ideal method of supporting these chargeback policies.

Whatever your motivations, it is clear that establishing SLAs for your Exchange deployment will be critical to your success as a planner or implementer. In the next section, we will take a look at the process of developing SLAs and provide some guidelines that will help you with this foundational piece of implementing proactive management. If you thought the process of developing SLAs for your Exchange deployment was going to be easy, consider the process first. Of course, you could choose to develop SLAs in a vacuum (i.e., without including the client or customer), but I am most certain that, in the long run, you would fail. When done right, the establishment of SLAs should take a fair amount of time and be the result of cooperative efforts and negotiations among all involved parties (service provider and clients). Much of the time involves communication, compromise, and getting a handle on the organization’s expectations and value for the messaging system. Northeast Consulting Resources provides some commonly referenced generic guidelines for establishing SLAs as shown in the following:

start sidebar
Guidelines for establishing a service-level agreement

An SLA defines the responsibilities of an IT service provider and the users of that service.Typically, an SLA will include the following components:

  1. Definition of the service provided, the parties involved, and the effective dates of the agreement

  2. Specifications of the hours and days during which the service will be offered, including testing, maintenance, and upgrades

  3. Specifications of the numbers and locations of users and/or hardware for which the service will be offered

  4. Explanation of problem-reporting procedures, including conditions of escalation to the next level of support and a definition of the expected response time to a problem report

  5. Explanation of change-request procedures, which may include expected times for completing routine change requests

  6. Specification of target levels of service quality such as availability, reliability, response time, throughput, and average and experienced reporting of these metrics as well as explanations of how these metrics are calculated and the frequency of reporting

  7. Specification of charges associated with the service, which may be a flat rate or based on different levels of service quality provided

  8. Specification of the user responsibilities under the SLA, such as training, configuration, or circumvention of change-management procedures

  9. Description of procedures for resolution of service-level disagreements

  10. A defined process for feedback and amending the SLA

end sidebar

Developing and establishing SLAs is a process; an SLA is not simply a document written by IT staff and handed to a client. You need to have a consensus between service provider and client about exactly what services will be provided and the quality of those services. When developing and establishing SLAs for your Exchange deployment, I recommend that you use a four-step process.

10.2.1 Step 1: Service-level agreement planning

The process of planning SLAs for your messaging system should be seen as a process for setting of the stage. The goal of the planning step should be to assemble the right people and other resources necessary to make the SLA development process successful. The process is successful when agreement is reached regarding both the services the messaging system will provide and the quality of those services.

The first task of the SLA planning phase is to get buy in and cooperation from all of the groups within the organization that will be involved as either clients or service providers. The important part here is that client representation (which often is not involved in the process) must be part of the team from the beginning. If you move forward in the process without the involvement of your messaging-system customers, the entire process will fail because SLAs will not meet the business needs of the clients.

Another task in the planning process will be to gather the data necessary for the establishment of the SLAs. Messaging-system cost is one of the important data points necessary for determining trade-offs between the degree of service and quality versus overall cost.

The final key task in SLA planning is the assembly of the SLA development team. Once you have buy in and cooperation from all necessary parties, you need to build a team of individuals representing these parties who are knowledgeable in their respective areas. All members of the team should have the same goal in mind: to develop cost-effective SLAs that meet the business needs for which the messaging system was implemented. You will need experts in technology, as well as individuals who understand the business the organization is in. You should also include representation from the accounting and finance disciplines that can assist in the tedious cost-benefit and ROI calculations.

Also, don’t forget your legal department. As part of the SLA development process for areas such as messaging retention/deletion and archival, it is a good idea to understand the legal implications that an SLA can have on the organization. Overall, you need to use the planning step in SLA development as the cornerstone of the process. The people and resources you bring together at this juncture will determine the long-term success of SLAs you establish for your Exchange deployment. Take the steps necessary to ensure that the right individuals with the right skills are assembled and have the same goal in mind.

10.2.2 Step 2: Service-level agreement development

The first task of this step is to get a handle on the true business needs of the organization. The SLA development team needs to have an understanding of the various business activities and processes that occur within the organization. You need to know how e-mail and collaborative applications impact these activities and processes, as well as how individual employees utilize these services in their everyday jobs. When doing this research in your organization, make sure you talk with the different departments, including cost centers, profit and loss centers, support and administrative centers, and those business groups that are on the front lines and have critical deadlines or risks. Talk to groups that are high producers and low producers, as well as those with high costs and low costs. You need to have a good understanding of how the business works and how the services your Exchange deployment provides can positively or negatively impact each key department in the organization. As your team learns about your organization’s key business activities, try to identify just how the e-mail and collaborative applications provided by Exchange Server are used in the day-to-day tasks of conducting business. This can also be a great opportunity and exercise for your messaging-system staff to determine possible future uses and applications they may be able to deploy. As part of this process, determine what happens when the messaging system fails. For example, if the sales department uses e-mail or a custom-developed application for submitting sales orders, what happens when Exchange is down for 8 hours (and how much does this cost the company)?

Don’t forget to factor in user perceptions and overall satisfaction with the current system. Using this information, you can start to get an idea of the most critical aspects and services of your messaging system and to which business units they are most critical. This, in turn, will give you a starting point for selecting the metrics (such as delivery time, system availability, and so forth) on which you should begin to focus. You can begin to monitor these metrics immediately and establish baselines for the performance of these metrics for the various services your Exchange deployment offers. You can gather these statistics over a period of several months in order to establish empirical data on which to base further decisions in your SLA development process.

At the same time that you begin to gather data on metrics driven by the business activities, begin to look more closely at statistics and other data that the IT organization may already be gathering for the messaging system. You may already have help desk data on the types of problems that occur most frequently or information regarding client satisfaction and perceptions. For your Exchange servers, you may already be gathering data on performance metrics such as message volume, size, delivery times, and error rates. You may have data on the causes of downtime or outages and capacity planning information documented as well. While many of the metrics that an IT organization maintains internally are not directly tied to business activities and goals, these metrics are useful data and should be included in the SLA development process. Both the business-driven metrics and these are a vital part of ensuring that you develop realistic and measurable SLAs.

Once you have a clear understanding of how the business works and how certain key business activities need the support of SLAs for your Exchange deployment, you can set out on the next task in the SLA development process. That task is the identification of potential service levels. The idea is to get many potential SLA candidates on the table and narrow things down from there. As the team brainstorms, many ideas for possible SLAs may be conceptualized. The important point at this stage is to select service levels that support the ability of your organization to meet its business objectives. There is not a right or wrong type of SLA. However, Table 10.1 lists some important qualities for potential SLA candidates.

Table 10.1: Qualities of SLAs

Business-based

An SLA should support specific business objectives and not be implemented for the sake of attainment.

Realistic

Service levels should be achievable. For example, setting a goal of 99.999% availability for your messaging system may be unattainable.

Measurable

SLAs must be measurable to ensure that they are achieved. If you are not capable of measuring a particular SLA metric, there is no point in its definition. Also, do not establish SLAs that are beyond your control to affect.

Cost-effective

Service-level definition, management, and attainment can be a costly endeavor. An SLA and the resulting business benefit should not be more costly to achieve than the business impact if it is not achieved.

Consensus-based

All parties involved should agree on all aspects of an SLA. An SLA without mutual consensus is doomed to failure.

As part of the process of defining SLAs, you will also need to determine how they will be measured. This may involve the development or purchase of new tools and facilities with which to do so. If tools are not available to monitor and measure an SLA, I would not recommend establishing the SLA in the first place (see the “Measurable” quality in Table 10.1). Part of the SLA development step is selecting the right tools that will provide monitoring and reporting of the various levels of service you desire to achieve. Having a tool available can be a major decision point for determining whether or not a service level is feasible. If your organization cannot afford such tools, you will have to justify the cost of these tools against the business objectives and their criticality. Later in this chapter, we will provide an overview of some of the many tools available that can aid in proactive service-level management.

10.2.3 Step 3: Service-level agreement deployment

Once you have invested the effort in planning and developing your SLAs, you need to provide a mechanism for converting the service levels agreed upon by business units and IT staff into tangible units of management activity. Before this step begins, ensure that the necessary facilities and infrastructure are in place. This includes the necessary training and tools required to monitor and report on the SLAs to be deployed. I do not suggest that you try to do this and deploy an SLA in parallel. Take the time to allow for steep learning curves and to develop familiarity with the tools and practices. The utilities and practices will take some tweaking before they are ready for prime time. The client/customer of the SLAs may need an adjustment period as well in order to grow accustomed to the new levels of service.

Also, the new SLAs may call for specific requirements or deliverables from the client as well. The best way to assist customers in this phase is to provide some sort of training or orientation on the SLA. This would provide education on why the SLAs are important to them and the organization and what they must do to make them successful. For maximum impact, I would recommend that this occur throughout the entire SLA process to ensure stronger support from the business units that require these service levels. If the SLA team does a good job of working and cooperating with the business units through the entire process, it will be evidenced by strong support and acceptance during the final SLA deployment phases.

10.2.4 Step 4: Service-level review and feedback

As you are developing and documenting your SLAs for your Exchange deployment, you need to ensure that there are mechanisms in place to allow for the SLAs to be reviewed. I recommend that you include a periodic review process or feedback loop. This process would provide for customer feedback as to how effective the SLAs are in furthering business objectives. This would also evaluate how clients and service levels impact each other. This will provide you with an opportunity to fine-tune SLAs if they are not meeting business needs. The review may also be a point at which customer expectations can be reconsidered or reset. Along the way, this review process can also serve as a means of determining requirements for technology enhancements. I recommend that you review your SLAs frequently to ensure that they are meeting business objectives and are being administered adequately by your IT staff. Most organizations review their SLAs for the messaging system at least once per year. However, I tend to lean toward a more frequent review cycle, such as semiannual or quarterly reviews. Many times, organizations will rely on major milestones or technology inflection points as a determinant of when reviews are required. For example, a migration from Exchange Server 5.5 to Exchange 2000/2003 may be one such point at which an organization performs a complete review of all SLAs associated with the messaging system. Other milestones might include business or IT reorganization/consolidation, a merger or acquisition, an outsourcing decision, or a major outage event. Regardless of what motivates you to review your SLAs, the process must take place in order to ensure that they are serving the purpose for which they were developed and deployed.

There are many issues and decision points that go into the SLA implementation process that are both technical and nontechnical in nature and can form barriers and stumbling blocks during the process. At any point in the process, issues such as inappropriate user expectations or misunderstood business processes can interfere with or sabotage your effort to implement sound SLAs. For the nontechnical issues, the cause usually boils down to perceptions, communication, politics, and money. On the technical side there are not usually as many issues. While there may always be technical issues encountered, they are usually not specific to the SLA process. Issues such as network bandwidth and design, heterogeneous environments, and the unpredictability of external systems are among the top technical issues that trouble the deployment and management of SLAs. Organizations are working harder and harder to develop SLAs for messaging systems that support business objectives, are meaningful to users, and are manageable for the IT organization. When setting out on the path of implementing SLAs for your Exchange deployment, ensure that you have a process in place that will provide for step-by-step success.




Mission-Critical Microsoft Exchange 2003. Designing and Building Reliable Exchange Servers
Mission-Critical Microsoft Exchange 2003: Designing and Building Reliable Exchange Servers (HP Technologies)
ISBN: 155558294X
EAN: 2147483647
Year: 2003
Pages: 91
Authors: Jerry Cochran

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net