Autonomic computing embodies a progression toward self-managing IT systems. The autonomic computing adoption model defines an evolutionary path for increasing autonomic maturity, from completely manual processes to fully autonomic processes. This column describes that evolutionary path and discusses how to set and achieve goals for autonomic capabilities, with a focus on the fully autonomic level, called Level 5. The article presents a scenario that shows how Level 5 might be achieved in the future, while noting that Level 5 is not the goal in all cases. Don't miss other Autonomic computing edge articles.
The previous Autonomic computing edge column, the fourth in a series that focuses on the autonomic computing architecture, discussed the role of humans in autonomic systems. This Edge article continues the architecture series by examining the autonomic computing adoption model. In particular, I will address steps along the path from manual systems management, performed entirely by humans, to more automated administration associated with fully autonomic self-managing systems.
I'll describe the autonomic computing adoption model, with a focus on a fully autonomic Level 5 system of the future. We'll see that there are various ways to progress toward Level 5 and also consider whether or not Level 5 is the final edge of autonomic computing.
The autonomic computing adoption model
As described in the "Autonomic Computing Blueprint" (see Resources for a link):
[The] evolution toward more highly autonomic capabilities can be described using the autonomic computing adoption model, discussed next. Figure 1 depicts the autonomic computing adoption model.
Figure 1. The autonomic computing adoption model
The autonomic computing adoption model, developed by IBM Global Services, provides a methodology for businesses to calibrate the degree of autonomic capability that their current infrastructure and organization has and to develop action plans to increase the autonomic potential.
Note that the adoption model has three axes: the x-axis describes increasing autonomic functions; the y-axis describes increasing scopes in which the autonomic function is applied; and the z-axis describes different service flows, such as incident management and change management, to which the autonomic function can be applied. Each of these is detailed in the "Autonomic Computing Blueprint;" in this article, I will focus on the x-axis, with its five levels of automation. As described in the "Autonomic Computing Blueprint":
The "functionality" dimension, along the x-axis of Figure 1, characterizes the extent of automation of the IT and business processes. Five levels of automation are defined:
- At the manual level, IT professionals perform the management functions.
- At the instrument and monitor level, systems management technologies can be used to collect details from managed resources, helping to reduce the time it takes for the administrator to collect and synthesize information as the IT environment becomes more complex.
- At the analysis level, new technologies are introduced to provide correlation among several managed resources. The management functions can begin to recognize patterns, predict the optimal configuration and offer advice about what course of action the administrator should take. As these technologies improve and as people become more comfortable with the advice and predictive power of these systems, the technologies can progress to the closed loop level.
- At the closed loop level, the IT environment can automatically take actions based on the available information and the knowledge about what is happening in the environment.
- At the closed loop with business processes level, business policies and objectives govern the IT infrastructure operation. Users interact with the autonomic technology tools to monitor business processes, alter the objectives or both.
This final level ("closed loop with business processes") is the one called Level 5, as depicted in Figure 1. The key differentiator between Level 4, which designates a fully automated control loop in which autonomic managers can sense and respond to changes in the environment, and Level 5 is the addition of policies that govern business processes. At Level 5, management functions are not only automated, but the focus is on achieving business goals and managing business processes, not just managing the IT infrastructure that supports those business processes.
Level 5 is a future vision, but by incorporating it in the adoption model, it is possible to plan for the eventuality of fully autonomic systems, in those cases in which Level 5 capability is desirable, and to take steps today to increase autonomic maturity along a path that can lead to Level 5 in the future. The Level 5 scenario outlined later in this article also describes the advances that are necessary to achieve such scenarios.
Before I delve further into if, when, and how to achieve Level 5, let's first briefly explore policies.
In the autonomic computing architecture, a policy is a set of considerations designed to guide decisions on courses of actions. Policies consist of scope, conditions, business value, and decisions. A brief description follows; for more information about policies in the context of autonomic computing, see "An introduction to policy for autonomic computing".
Policy scope describes a context or domain within which the Policy applies (that is, what is subject to the intent of the policy), expressed as a resource type. Examples of policy scope include "DB2®", "Storage Devices", "Edge Servers", and "All the routers of manufacturer X".
Policy conditions specify attributes for when a policy is to be applied (that is, when its decision portion, described next, is to be acted upon). Policy conditions can be considered to be the predicates, or "if clauses," of a policy. When these conditions are met, the policy decision is enacted (although business value, described later, also must enter into the equation). Examples of policy conditions include "when average response time is greater than 2 seconds" or "if this operational request is made between 8:00 a.m. and 5:00 p.m.".
A policy decision is an objective, observable property or result. Policy decisions can be considered to be the conclusions, or "then clauses," of a policy. Policy decisions can be expressed as a result, action, configuration profile, or goal. An example of a policy result decision is "Allow DB2 Shutdown?" An example of a policy action decision is "Shutdown DB2 now". An example of a policy goal decision is "Reduce CPU utilization to no more than 80%". A policy configuration profile decision can return a set of name/value pairs that represent a desired configuration set for a managed resource.
A policy business value is a statement of business priority; that is, how much value is derived from executing the policy decision. Policy business value is used when there are conflicts between related policies and it is necessary to calculate economic tradeoffs. Examples of policy business value include "the cost of non-compliance is $3 per failure" and "the consequence of more than three failures is that the customer will leave the Web site forever."
Policies are the key to achieving Level 5 function. Policies provide the information used to accomplish business objectives in a self-managing autonomic system. Later, I will describe how this is accomplished, but first, let's examine how I might make decisions about the evolution to Level 5.
Not every enterprise will employ autonomic computing with a goal of reaching a state where all management tasks in the enterprise are completely automated. As described in the "Autonomic Computing Blueprint:"
Incorporating self-managing capabilities into an IT environment is an evolutionary process. It is ultimately implemented by each organization through the adoption of self-managing autonomic computing technologies, supporting processes and skills. Throughout this evolution, the computer industry will further develop self-management technologies to help continue to improve staff productivity, reduce operating costs and ultimately, increase business resiliency.
The previous Edge column noted that many IT service management tasks call for human intervention to approve actions, interpret reports, and communicate with other people involved in those processes, including other IT professionals in the enterprise, suppliers, and customers. These and other activities may best be handled in many enterprises with human involvement.
Level 5 (and Level 4, for that matter) both describe fully automated processes. Level 5 adds business policy-driven behavior to the automation to achieve fully autonomic self-managing behavior for some aspect of the system.
However, enterprises may not choose to strive for fully automated systems management, or at least not for the entirety of their IT infrastructure and business and IT service management processes. It is more likely that customers will select particular areas of their IT infrastructure, business processes, or IT service management processes that are candidates for eventual attainment of Level 5, whereas other areas might continue to operate at levels 2, 3, or 4, with varying degrees of human involvement, for quite some time. These selections will be made based on the value and feasibility of automating the tasks.
Attaining Level 5 autonomic capability is not simply a matter of purchasing and deploying a product. Level 5 is a result of a standards-based IT infrastructure with autonomic capabilities, applied to business and IT service management processes governed by business policies, in conjunction with best practices and IT skills. The path to Level 5 is a journey that is expected to last several years.
Next I will examine different paths that that journey might take.
Recall from Figure 1 that the autonomic computing adoption model has three dimensions. Although I focus on the x-axis dimension in this article, richer autonomic capabilities also can be attained by progressing along the y-axis (control scope) and z-axis (service flows). Examples of different paths through the adoption model include:
- Increasing scope: A business might choose to focus on deploying similar autonomic capabilities, say at Level 2 (instrument and monitor) or Level 3 (analysis) to broader parts of their IT and business systems. For example, analysis capabilities might first be deployed to single resources, such as a database or a server, and then to a server pool, and then to both server pools and database clusters, and finally to applications and business solutions that employ those server pools and database clusters. In this case, the level of automation remains constant but that automation is applied more broadly.
- Additional service flows: An enterprise might choose to selectively delegate tasks from a particular service flow, say change management, and focus on further automating that service flow until a desired automation level is achieved. After that has been accomplished, the business might then repeat this process for other service flows, such as incident management, problem management, or release management. In this case, the level of automation remains constant but that automation is applied to more IT service management processes.
Both of these approaches, in addition to increasing levels of function and automation, can achieve increased business value, and progressions along any axis of the adoption model can prepare customers for Level 5 functions. Depending on the path taken, Level 5 capabilities might be applied only to a single resource (such as a server) or only to a selected set of service flows; or they could be realized in broader scopes or larger sets of service flows. The path taken will vary by customer installation; the adoption model offers the flexibility for customers to choose the path -- and the destination -- that is right for them.
The key to increasing the overall level of autonomic maturity is to establish where in the adoption model you are and where you would like to be. This applies whether the goal is Level 5 or any other point within the adoption model. The key to achieving Level 5 automation is the introduction of business policy. Next I will describe a Level 5 scenario.
Level 5 scenario with business policy
To illustrate a Level 5 scenario, I first describe how policy-based management could be applied by human administrators.
Figure 2. Manual business policy scenario
As shown in Figure 2, a policy is included in a service level agreement (SLA) for the overall service. It is generated and passed to the system administrator. This SLA might specify an agreement of the form:
- From 9:00 a.m. - 5:00 p.m., users of the trading application "MyApp" will not average more than 1 second response time
- The application "MyApp" is always available
- I can run reports without interrupting MyApp
From this SLA, the system administrator produces a goal policy for the overall system. This policy might take the following form:
- Goal (from SLA): On average, users will not wait more than 1 second
- Policy Scope: trading application "MyApp"
- Policy Condition: 9:00 a.m. to 5:00 p.m.
- Policy Decision: Average Response Time < 0.9 second
- Policy Business Value: 500
Notice that the administrator changed the policy decision goal from 1 second to 0.9 seconds to insert a 10% margin, to help ensure that the goal is met. The system administrator then produces individual goal policies for each of the three components involved in the "MyApp" trading application and passes these to the individual administrators of those three resources. These individual goal policies might represent performance goals for storage, network, and application components, perhaps of these forms:
- Policy Scope: Storage
- Policy Condition: Average CPU utilization > 66%
- Policy Decision: Increase cache allocation for MyApp by 10%
- Policy Business Value: 500
- Policy Scope: Application
- Policy Condition: Average Response Time > 200 ms
- Policy Decision: Reduce priority of all low priority queries
- Policy Business Value: 600
- Policy Scope: Network
- Policy Condition: Network Response Time > 100 ms
- Policy Decision: Increase Quality of Service parameters for MyApp's IP address
- Policy Business Value: 400
Notice that the administrator decomposed the overall goal policy into constituent parts that were developed specifically for the individual resources. The conditions and decisions for these individual goal policies were developed to achieve response times for each resource that, when summed together, will achieve the overall goal of 0.9-second response times.
This business policy-driven scenario is not automated, but by incrementally delegating the policy generation and policy enforcement to autonomic managers that have the requisite knowledge (that is, in this case, the policies), the automated Level 5 scenario depicted in Figure 3 can be realized (refer to "The autonomic computing edge: The role of humans in autonomic systems" for a more detailed discussion of delegation).
Figure 3. Level 5 scenario
This is just one example of a Level 5 scenario that illustrates just one path for achieving it. In a similar fashion, resource management that has already been automated but does not use business policies could be evolved to a Level 5 scenario by incorporating policy management into the three individual resource autonomic managers and adding the orchestrating autonomic manager depicted in Figure 3.
In any case, though, such Level 5 scenarios are not generally available today. To achieve scenarios such as the one described here, advances such as standards for policy expression, autonomic managers that can enforce goal policies for resources, and orchestrating autonomic managers that can enforce system-wide goal policies and generate the individual resource goal policies necessary to achieve the system goal are all needed.
The autonomic computing adoption model provides a framework for assessing and increasing autonomic maturity. In the adoption model, Level 5 represents the highest level of automation, closed loop with business priorities. Business policies are required to achieve Level 5 maturity.
Level 5 is not the end goal of autonomic computing for all enterprises, or for all of the systems and processes in an enterprise. It is, however, a level of autonomic maturity that, in the future, can provide significant business value by introducing business policies that govern the behavior of the automated system management tools (autonomic managers).
True Level 5 self-managing autonomic capabilities in any significant scope probably are several years away, but this column expands on the autonomic computing vision by offering a sketch of a scenario that demonstrates how Level 5 might be achieved.
The next installment of The autonomic computing edge will depart from the architectural topics that have been addressed in the last few columns and will focus on how autonomic computing concepts can be fodder for an entirely new domain.
Special thanks to my IBM Autonomic Computing architecture colleague David Kaminsky, who developed some of the material (especially the figures) on which this article is based and provided valuable review and feedback.
Learn
-
"An introduction to policy for autonomic computing" (developerWorks, March 2005) offers an overview of policies for autonomic computing.
-
"The autonomic computing edge: The role of humans in autonomic systems" (developerWorks, November 2005) describes automating management tasks through delegation by IT professionals.
- The series of Autonomic computing edge articles covers many topics related to the Autonomic Computing Blueprint and how humans interact with autonomic technology.
Get products and technologies
-
Build your next development project with
IBM
trial software, available for download directly from developerWorks.
