This installment of our RFPs & Rising Technology Demands series examines RFP requirements related to the reliability, uptime, and performance level of technology services rendered by a vendor or the vendor’s third party technology solutions provider.

When a corporation or other large business issues a Request for Proposal for ecommerce, eprocurement, or any technology contract, the issuer will want assurances about the reliability of the technology services provided.

The central document that outlines the reliability, uptime, and performance of the technology services is the Service Level Agreement (SLA) which lays out the service level provided as well as how the services are measured and what the remedies are should the service levels not be met.

Specifics within the SLA may cite how data is backed up, in terms of both Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

The RFP may also seek information on the physical, network, human and other infrastructure employed by the vendor to assure uptime; for example, physical server infrastructure. Whether the RFP does or does not require infrastructure information, the vendor will need sound infrastructure and internal policies in order to meet the SLA.

This installment of our RFPs & Rising Technology Demands series examines RFP requirements related to the reliability, uptime, and performance level of technology services rendered by a vendor or the vendor’s third party technology solutions provider.

Service Level Agreements

A common example of an SLA that most people engage with every day is a cellular service plan.

A Service Level Agreement (SLA) establishes the level of services provided by a vendor to the client, how to measure the service, and what the remedies are if service levels are not met.

A common example of an SLA that most people engage with every day is a cellular service plan. The plan establishes how much data can be used, the speed of the data, and in some cases how many text messages can be sent or how many minute can be spent on phone calls. Simply put, it establishes the level of service that the user can expect.

RFPs, likewise, often state service levels required of the vendor, which the vendor represents in an SLA (although that vendor often may engage a third-party technology solutions provider to meet and maintain the levels). Key parts of an SLA include:

• Services: The services provided and the expectation for service availability. For example, an SLA may promise an ecommerce website that has 99.9% uptime and can accommodate 1,000 concurrent visitors. The SLA is the promise from the technology vendor to the client to provide those levels of service with little or no interruption. The services are often measured in bandwidth, the amount of data transmitted over a network in a given time.
• Responsibilities: The SLA also outlines the responsibilities of each party and the remedy procedures compensation should one party fail to meet it’s responsibilities. For example, if the SLA promises 99.9% uptime and an outage causes more downtime, the SLA will have spelled out the recourse to remedy the situation and/or the loss of business or opportunity.
• Measurement and management: The SLA will also define what will be measured, by what metrics, and the source for the measurement. For example, if the SLA establishes that an ecommerce website will support 10,000 concurrent visitors, the SLA will have pre-defined how concurrent visitors are calculated and by what system.

Other components of the service level agreement may include:

• Security: The SLA may define each party’s responsibility in guarding against a data breach, the infrastructure, both physical and human, in place to prevent security risks, and reasonable expectations for patches and updates that keep the technology secure.
• Business performance: Increasingly, clients want to include their own Key Performance Indicators (KPIs) into the Service Level Agreements. The SLA can define the KPIs and their measurement and management but should also be clear about which KPIs are under the control of the client and which are under the control of the vendor.

Technology Policies and Infrastructure

Physical infrastructure regards the actual physical servers that provide service. Human infrastructure regards policies and training that guard against interruption of service.

The SLA will include language about traditional security: safeguards against hacks, attacks, and data breaches. But the SLA is more concerned with a different kind of security, the security or reliability of service and the prevention of data loss.

The Service Level Agreement assures the client of the services provided, their availability, the retention of data, and what processes are followed should downtime or data loss occur. The infrastructure for the reliability is expressed in two primary ways, physical structure like facilities and human infrastructure like policies.

Physical infrastructure regards the actual physical servers that provide service. That includes how they are physically surveilled and secured, as well as how they are protected against disasters like flood or fire. It also includes how the servers protected against outage, such as a power source and internet connection that that is are physically redundant, as well as potentially other details about the network providing the services.

Human infrastructure regards policies and training that guard against attacks, outages, or other factors that could lead to an interruption of service. The SLA may spell out training that the technology provider conducts to keep data secure and policies in place to protect data such as a Data Breach Notification policy or a Business Continuity Plan in the event of potential interruption.

Data Backup

Backup is expressed in two primary ways: Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

An Request for Proposal is also likely to set standards for data backup, which may be expressed in the Service Level Agreement.

Backup is expressed in two primary ways: Recovery Time Objective (RTO), which is the amount of time it takes to get back to normal operations after an outage or data loss; and Recovery Point Objective (RPO), which is the maximum amount of data that may be lost.

The RTO determines the amount of time it will take for a given application, service, or system to resume normal service after an outage. It may vary by the priority of the application, service, or system and the value it delivers to the client. Factors in calculating RTO include how much time the client can afford (or can tolerate or agree to) lose in the event of a major incident.

Meanwhile, the Recovery Point Objective represents how much data the client can afford (or can tolerate or agree to) lose in the event of a major incident. It is generally expressed as the point in time at which data can be successfully recovered. Depending on the size and need of the clients, typical RPOs may be defined as the most recent close of business or as backup from the point of failure.

RFPs Seek Assurances for Service Levels Received

Companies who issue RFPs for technology services want assurances about the reliability of the service and the level of the service they will receive.

Companies who issue RFPs for technology services want assurances about the reliability of the service and the level of the service they will receive.

The Request for Proposal is likely to include standards for services, responsibilities of each party, measurement and management, and increasingly, security and business performance. The vendor represents the assurances in a Service Level Agreement that spells out the service that the user can expect, as well as recourse for when levels aren’t met.

Vendors will need to deploy physical, digital, and human infrastructure in order to meet the service levels. The RFP may require certain infrastructure or may require that the vendor disclose the infrastructure.

RFPs often cite standards for loss in the event services are interrupted. These are often expressed in Recovery Time Objective, which is the amount of time it takes to bring a service back up if it goes down, and Recovery Point Objective, the amount of acceptabl data loss in the event of service interruption.

Understanding what RFPs require for reliability, uptime, and performance and establishing service levels for to meet the requirements helps prepare vendors to be the winning bidder on more Requests for Proposal.