Understanding Service Level Agreements (SLA)
SLA vs OLA
Most Seattle IT Support companies and their clients really don’t understand how to utilize the SLA. Service Level agreements (SLA) and Operation Level Agreement (OLA) are two ideas the Modern Network Architect needs to understand. IT Support Company should be promising their customers a certain level of service. Understanding OLA and SLA the network architect can provide the level of service promised and saves the department money by not promising more services than are possible. Most IT support companies are based on a break / fix model of support. So it’s to their advantage to offer speedy service after a failure, but not in their advantage to offer an SLA.
I usually think of an OLA as an agreement between a “vendor” and customer where the customer is the IT department. As long as the vendor can provide the level of service that the IT department is promising to the departments end users everything is ok. The problem comes when the IT department promises more service than the IT vendor can provide.
A Seattle IT consulting client I worked with found itself in trouble when a vendor promises 1.5 Mbits/sec to the internet to the IT department. Yet the IT department promised 10 Mbits / sec to the end users in the company.
Obviously the end user will only have 1.5 Mbits / sec even if the internal network infrastructure could support 10 Mbits / sec. The bottle neck for the system will be the vendor OLA.
An OLA is important to understand when designing the network. Knowing what the OLA agreement from the vendors determines the SLA that can be provided to end users.
In many companies the IT department is separate from the other departments. Agreements are made between the individual departments and the IT department. Each department pays the IT department for support, bandwidth, server access and other variables managed by the IT department. These agreements between the IT department and the company are SLAs.
An SLA is valuable because it promises a level of service that is quantifiable. One SLA focus is availability measured in 9’s. 99.9% availability means less than 9 hours of server downtime per year. 99% availability means 3.65 days per year of down time.
So if a vendor was providing an OLA promising 99% availability of service. Then the IT department provided an SLA promising 99.9% availability to end users. Obviously there would be a problem because the IT department can’t provide more availability than the OLA of its vendor.
The network architect obviously must understand all these requirements. First the network architect must understand the business requirements of each department. Next network architect must understand the OLA of its vendors. Finally the network architect must match business requirements and vendors OLAs before committing to a departmental SLA.
Consider that the typical Seattle IT Support Company is a break / fix company. Break / Fix model of support companies function at an 85% availability rate. Consider that a good managed services company can provide 95 to 99% availability. A cloud based company can provide 99.9% availability or better. Plus the cost for a cloud company reduces the Capital Expenditures on computers and replacements by 30% or more. Before buying another server take a look at a cloud system.
At Seattle IT Edge we help businesses move into the cloud. Imagine your systems are more reliable, your data is more secure and your costs are usually less than the cost of a break / fix or even a managed services company. Give us a call to find out more…