By Todd Piett - October 6, 2011
In the first installments (Part 1, Part 2, Part 3, and Part 4) of our Cloud and NG9-1-1 series we gave a primer on Cloud technology, deployment options, service models, and security. This week we'll take a look at Quality of Service, Service Level Agreements and putting together your requirements.
Quality of Service and Service Level Agreements
Vendor SLAs have long been a part of the public safety lexicon, however; as critical services become more interdependent and sometimes outside the direct control of the emergency communications agency, these agreements become more important. Whether the public safety entity decides to manage its own cloud infrastructure or outsource that to third parties, QoS and SLAs are keys to ensuring success. Availability of emergency communications services depends on redundancy and elimination of single points of failure and effective failover/back-up processes should those redundant systems fail. Strong service level agreements ensure that the provider(s) of cloud services are aligned with the stringent requirements public safety requires.
At a high level, an SLA should include the following components:
IBM came up with a very useful list of responsibilities to consider when developing an SLA (source: "Cloud Computing Use Cases Whitepaper" Version 4.0, developerWorks Editors, IBM). While oriented toward evaluation of a third party it is an extremely helpful checklist regardless of the service model. A subset of the items relevant to public safety use of the cloud is below:
It is easy to request extremely high levels of service across the board on all functions, but that can be very costly. One option to consider in developing SLAs for NG9-1-1 related solutions is to tier the communications services. What functions are critical to the core mission of answering a call and dispatching? As you move out from those core functions, consider the SLA that you need (and pay for) for those functions.
As with any solution, it is imperative to carefully document your requirements for both functionality and performance. Through the i3 process, NENA and the participants in the process of defining NG9-1-1 have done an outstanding job of defining a broad set of capabilities that are expected of a NG solution. Because of the inherent interoperable nature of the solution, this baseline definition is key. However, each agency will have localized needs – there is no one size fits all solution. Within the broad framework that is defined as "NG9-1-1", there is sufficient flexibility to create a solution that works for a specific agency in terms of functionality, performance and cost, but that also seamlessly interoperates with other locales. Each entity should carefully evaluate their functional needs against the broad definition of what is possible.
Todd Piett joined Rave in 2005 and today runs the global organization that has its technology deployed at thousands of colleges, universities, businesses and communities. Prior to joining Rave, Todd was responsible for launching new products for Unica Corporation where he helped drive their successful IPO. Previously, Todd was VP of Product and Marketing for iBelong, a portal provider targeting affinity organizations and a Program Manager at Dell Computer where he launched Dell’s branded ISP. Todd graduated with honors from the United States Military Academy at West Point and holds an MBA from Harvard Business School. After graduation from West Point he served 7 years in the US Army as an aviation officer.
The recent extreme heat warnings across the south and south-west of the country brought back memories of last summer...