Service Level agreements (SLA) and Operation Level Agreement (OLA) are two ideas in Modern Network Architecture. Many departments promise their users levels 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.
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.