How to start using big data SLAs
Many companies have moved past the experimental stage of big data and turned their attention to implementing big data and analytics processing in production—they’re even making some of these applications mission critical. Moving these applications to a mission-critical status requires them to be timely and readily accessible to the decisions makers who need them.
Given these circumstances, the time has come for big data service level agreements (SLAs).
The purpose of an SLA is to guarantee business users get certain minimum performance and service levels on their IT investment. SLAs are most commonly used for transactional systems, such as the ability to process x millions of hotel reservation transactions an hour or a commitment to 24/7 computer uptime for an airline reservation system.
Because big data and analytics have been largely experimental for organizations, users have yet to demand SLAs for big data from IT, and IT has not volunteered to offer them, either. It’s time for this to change.
First, let’s look at the big data user side.
If users are utilizing analytics reports and they expect IT to deliver these reports in a timely way to achieve business impact, requirements have to be defined for report delivery. In some cases, such as the Internet of Things (IoT), users will want real-time status reporting with to-the-minute alerts that are actionable. In other cases, it might be sufficient to get analytics reporting on a daily, weekly, monthly, quarterly, or yearly cycle.
A second area of user concern is the time to market for new big data applications that they want for the business. Users want these applications as quickly as possible so they can start getting business value from them.
Now, let’s look at the services that relate to IT operational performance that must be met in order to meet business users’ needs.
As new big data applications are developed, the underlying technical goals have to be 1) speeding up the time it takes to develop, debug, and place new applications into production; and 2) speeding up system efficiencies and processing so that more developers can use development resources concurrently.
On the systems side, this could translate into SLAs for system performance, the ability to handle a specific number of application development users concurrently at one time, or tools that can reduce the time it takes to debug applications because of the automation they offer.
