SLAs

Service level agreement (SLA) fulfillment is the key metric for measuring the success of IT operations. Every jobstream has at least one system-assigned and system-calculated SLA. For a jobstream run, the SLA is the deadline that must be met for the run to have completed successfully. If the SLA deadline is exceeded, the jobstream run might be complete but it is not considered a success. AAI tracks jobstream performance by the success of jobstreams runs to complete within the SLA deadline. 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.

An SLA Is a Deadline

Basically, an SLA is a deadline by which a process, defined in AAI with a jobstream, must complete. A jobstream exists primarily to track the success of the process against its SLA deadline. When you create a jobstream in AAI, a system-calculated SLA deadline is added to the jobstream definition. You can edit it but you cannot delete it.

Every jobstream must have at least one SLA defined. That SLA is used to measure whether the runs of the jobstream complete on time or late. This is why in AAI, the status Early or Late (as well as Not Predicted to Finish) are called the SLA Status of a jobstream run. The whole idea of "late" is based on the SLA.

Multiple SLAs for a Jobstream

You can define more than one SLA for a jobstream to have different deadlines for the runs depending on which day of the week the jobstream runs on. Although the jobstream definition can have more than one SLA, a jobstream run has exactly one SLA definition. If the jobstream has multiple SLAs the one that applied to the start time of a jobstream run is the run's SLA, its deadline.

For example, you might have a retail sales reconciliation process that always starts later and runs longer on Saturdays than on other days of the week. You can define two SLAs for the jobstream, one for most of the week where the reconciliation runs in a similar way and one for Saturdays to reflect its typical runs.

Business versus Technical SLAs

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. 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 each of the SLAs.

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 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:

• An SLA deadline is specified for every jobstream.

  Because when you create jobstream AAI adds an initial system-calculated SLA that is based on historical execution data, you can trust that the late deadline is a realistic and reliable metric of the process execution time. Later, if you see differences in patterns of jobstream's execution runtimes over the weeks, you can configure additional SLAs for different days of the week.

• Various alert types can be defined for a jobstream to be triggered at runtime during a jobstream's execution to notify operations staff of delays or run progress.

  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.

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 SLA deadline 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 SLA deadline 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.