SLAs

Service level agreement (SLA) fulfillment is the key metric for measuring the success of IT operations. With the Late Criterion setting in the jobstream definition, AAI can help your company increase its SLA fulfillment. This topic explains how AAI supports SLA fulfillment and how you can use the same mechanisms for managing company-internal processes and aiding optimization of any process execution.

What is an SLA?

Basically, an SLA is a deadline, a time when something must be delivered or completed. When talking about AAI, "SLA" is used in the following two contexts:

• As a business requirement, which is backed by a binding contract with failure penalties
• As a technical mechanism to support compliance with the terms of the business contract

The SLA as a business requirement

In the first place, SLA is a business term that describes the real-world sense of the term. An SLA is a contractual agreement between a service provider and a customer to deliver a service according to clearly defined requirements. The requirements cover what is to be delivered, what entails completion, and when it needs to be delivered. Because you, as the service provider, incur penalties when you fail to deliver as contracted, missing SLA deadlines can result in significant costs to your company.

The SLA as a technical mechanism

In the second place, SLA is a term in IT tooling that refers to the technical mechanisms that support compliance with the conditions of the business SLA contract. Specifically, IT processes are developed to produce the output that needs to be delivered according to the SLA's definition of completeness. Through scheduling tools, you can collect data about actual execution times as proof of whether the deadlines were met. AAI helps you set realistic deadlines and enables you to proactively prevent missing them as well as continually optimize processes to ensure higher SLA fulfillment across your entire workload automation landscape.

How the business and technical SLA are related

For IT service SLAs are IT processes always support business SLAs by producing the required output.  

When a business contract to deliver an IT service is made with a customer, the business process owner brings the requirements of the contract to the IT department. Developers and schedulers work together to analyze the processing steps needed to deliver the service. They translate those steps into jobs in a workflow or batch on the appropriate automation scheduler. With that you have a way to deliver the service.

When you bring that process into AAI as a jobstream, an SLA deadline is always part of the jobstream definition, defined by the Late Criterion settings of the jobstream. With that, AAI adds the capability to measure and track the performance of that process. More than that, in AAI you can increase your rate of fulfillment for the SLA.

External versus Internal SLAs

We tend to talk about SLAs as being linked to service agreements with customers of your company. However, your IT department can also provide services to company-internal "customers" for their IT needs. By creating jobstreams in AAI for your internal IT processes, you can support internal teams and their requirements. These might not have direct financial costs but they do have specific company objectives, requirements for successful execution, and their own chain of accountability. As such, you have internal SLAs to fulfill. The deadline can originate from an operational requirement or another kind of internal requirement.

When you define jobstreams for internal processes, you can apply the same monitoring, tracking, and optimization capabilities that AAI provides to support your customer SLAs.

How You Define SLAs in AAI

You do not explicitly define SLAs in AAI. Instead, for the jobstream that defines the process for the service to be delivered, you specify when the jobstream executions must finish by. You do this in the jobstream's Late Criterion tab when you edit the jobstream definition.

A jobstream can be considered late based on a specific end time or a duration from start to finish for its executions. AAI automatically provides a system-calculated late criterion that it bases on the jobstream's historical execution data.   If you need to, you can override this by specify the late criterion manually.

For more information, see Adding and Editing Jobstreams.

How AAI Supports SLA Fulfillment

AAI has end-to-end functionality to keep you from missing SLA deadlines and incurring the related penalties. The following are the main AAI features that support SLA compliance during runtime:

• The Late Criterion that is specified for every jobstream.

  Because AAI bases its system-calculated late criterion on historical execution data, you can trust that the late deadline is a realistic and reliable metric of the process execution time.

• Various alert options for each jobstream that are triggered as defined at runtime during the jobstream executions

  With numerous alert types, each with varying severity levels for any jobstream as well as different delivery options, not only operators but all interested parties can be informed in time to take action as required.

• The execution history that AAI stores and uses for forecasting and predicting execution times

  AAI's can aggregate and abstract huge quantities of historical execution data to give you reliable forecasts for future runs. During runtime, AAI can calculate complex job and resource dependencies to predict failures and latencies in jobstream executions., This can give your operations team a fair head start to take remediation steps or give adequate warning to process owners and customers.

• Dynamic critical path that is continuously adjusted during runtime

  For each runtime jobstream, AAI calculates and recalculates the dependencies of the jobs within the jobstream that form the critical path towards completion, dynamically while the execution is in progress. This gives you valuable input into the kind of remedial action that you might need to take if the execution is in danger of failure or latency.

Besides supporting SLA compliance during runtime, AAI benefits your optimization efforts and can support higher company goals in the following ways:

• Supporting optimization by identifying trends and trouble spots

  Whether viewing historical data in AAI or the aggregates and extractions in targeted reports that focus on performance over time, you can identify execution trends to mitigate future SLA breaches or to find optimization opportunities.

• Bringing awareness that increases accountability

  Having reliable comparisons of SLA targets with actual execution performance, all your teams get visibility to your workload automation management. This awareness fosters a greater sense of accountability and ownership of processes and provides the insights needed to support process optimization.

• Steering towards self service

  With jobstream executions meeting SLA deadlines more reliably, you can introduce more automated process management into your company service provisions.

Who Is Involved in SLA Management in AAI?

As SLAs are the driving force for AAI, almost all AAI users are involved in some way with SLA management.

Nevertheless, even though everyone understands that fulfilling SLAs is essential, not everyone knows the business reasons for the individual SLAs. In fact, not everyone needs to know the business details to fulfill their role in SLA management.

People who work directly with customers, such as the process owners and to some extent also managers, need to understand the detailed requirements and the significance of the SLA. They also know the details of the financial costs of missing the SLA deadlines and would have direct contact with the customers. The business area coordinator generally also knows the requirements, although maybe in less detail. Process analysts and developers need only the specifications to be able to design the technical application that supports the SLA.

By the time the process is translated into jobs, workload processes, and batches on schedulers, and then become AAI jobstreams, operations staff often have little knowledge about why the process needs to be executed. However, when they see that jobstream ABC is running late, they know what actions to take and whom to notify.

Example: Compiling Daily Retail Orders

Suppose that a retail company for which you provide IT services needs to have all orders in by end of business day so that they can be sent to the production warehouse in Asia in time to be able to fulfill the orders. Otherwise, the retail company cannot keep its commitments to its own customers. If this deadline is not met, your company must pay penalties to the retail company. All that operators developers know is that the jobstream Retail_Orders_Daily must complete by 5 PM Pacific Standard Time. So when AAI forecasts that an jobstream will be late and therefore breach its SLA, operators and process owners can react to the alerts issued by AAI and take timely remedial action.

Using Aspirational SLA Goals to Test Processes

Your development team can use the same AAI jobstream and monitoring features that support external and internal SLAs to test new, modified, or problematic workload or batch processes.

After a process has been designed and programed by developers, they can define aspirational Late Criterion settings coupled with alerts in the related jobstream. Operational staff can then monitor jobstream executions for some time and return with the execution results, perhaps by producing AAI reports for the executions. With those results, developers can make changes and allow operations to retest the jobstreams.

Depending on their problem analysis, developers have a few main options when a process does not fulfill the aspirational goals:

• As with any program or script, modify the jobs within the process, or restructure the process
• If resources are an issue, move the execution to a time when scheduler load is lighter
• Change the jobstream Late Criterion settings to be more realistic

  As always, taking the system-calculated setting is the most likely to be realistic.

This use of AAI jobstreams would be for internal, temporary jobstream definitions. For example, this can be helpful before you commit to a customer SLA or before you release a process modification.

When the test process definition is performing satisfactorily or the problem is resolved, would you apply the settings to a jobstream that is in effect with external or internal customers.