The previous column was the third in a series that focuses on the autonomic computing architecture. That article discussed the role of knowledge in autonomic systems. This column continues the autonomic architecture series by examining the role of humans in self-managing autonomic systems, including the architectural building block called a manual manager.
I'll describe how IT professionals can automate management tasks by delegating them to the system, how people decide the degree of automation that is right for them and how manual managers and autonomic managers work together. Let's see how IT professionals can give themselves the edge with autonomic computing.
It's not about replacing people with machines
Automation can free people from performing tedious and repetitive tasks. Managing today's complex IT systems often involves many of these tedious and repetitive tasks, such as adding and removing users and their credentials and associated access controls, deploying and provisioning new servers to match increased workload, and adjusting configuration parameters to attempt to optimize performance. Knowledge and expertise is required on the part of IT professionals to keep systems up and running to meet the requirements of the business applications that run on the IT infrastructure.
IT administrators often are specialists who manage a particular part of an enterprise system -- databases, application servers, networks, or applications. Using administrative consoles, they constantly monitor the state of the resources they manage and react to conditions observed in those resources.
A completely manual management system is prone to human errors, such as missing important situations that can occur in the managed resources or mistakenly taking the wrong actions in response to those situations. Moreover, it is difficult for multiple administrators to collaborate so as to manage all of their various resources in concert with one another, thus optimizing the overall system availability and performance to achieve the business's goals.
Automating some of these activities -- such as autonomic monitoring using appropriately instrumented resources, recognizing symptoms based on information reported from the resources, and determining appropriate corrective actions to perform on those resources -- can improve the efficiency and effectiveness of systems management.
Does that mean that autonomic computing can obviate the need for all human intervention? As I will show in this article, that is hardly the case. Instead, by automating the tedious, repetitive, and error-prone tasks, the IT professionals can begin to focus on higher-value tasks. For example, when self-managing autonomic systems take on much of their own routine management tasks, the administrators can focus on collaborating with other administrators and with business managers to optimize the "big picture" view of the overall system, rather than focusing solely on their "silo" (the limited set of resources they directly manage). The IT professionals can concern themselves less with tweaking their managed resources to keep things running and more with developing policies and other forms of knowledge that the system can use to automate some management tasks. This helps to ensure that the resources that the IT professionals manage are contributing to the overall robustness of the system to achieve business goals, such as meeting service level agreements with customers, in a cost-efficient manner.
It's not about automating everything
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 "An Architectural Blueprint for Autonomic Computing" (see Resources):
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.
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.
The autonomic computing architecture enables management tasks to be automated when the humans responsible for those tasks choose to delegate them to the system. The automation is intended to improve the efficiency and effectiveness of the IT professionals who manage the system; it is not automation for automation's sake that is intended to replace those IT professionals.
It is about delegating IT service management tasks
As described in "An Architectural Blueprint for Autonomic Computing:"
[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.
The service flows shown in Figure 1 represent IT service management tasks such as incident management, problem management, change management, and others. These processes are made up of activities, and the activities in turn are made up of tasks. The IT professionals responsible for managing these processes can choose to delegate tasks to the autonomic system, as described in the previous section.
But how do the IT professionals choose which tasks to automate (and hence, to delegate)? Each process and each customer installation will vary, but in general, the IT professional must consider the value and feasibility of automating the task. The value, of course, is determined by the business based on the improvements that can be realized with automation; the feasibility is based on whether the appropriate instrumentation is in place to monitor the data necessary to automate the task and whether relevant knowledge exists that can be used by an appropriate autonomic manager (knowledge was detailed in the previous Autonomic computing edge article.)
To see how the process of delegating an IT service management task might work, consider this example from "An Architectural Blueprint for Autonomic Computing" that describes how the "implement change" task in a change management process might be automated in some circumstances:
One type of change that might be affected on a system is to provision new resources. The IT professional might choose to delegate some such tasks to a provisioning system. This system could automate the provisioning of servers and network resources, as well as the distribution and installation of software, and hence could automate the "implement change" task in the change management process. For an IT professional to be willing to delegate management tasks to the system, he or she must have a high degree of trust in the autonomic management functions. ... if the autonomic manager consistently recommends actions that the IT professional routinely performs, then the IT professional is likely to become willing to automate those actions by delegating the corresponding tasks to the autonomic manager.
So it's very much about delegating IT service management tasks. Next, I'll examine how the autonomic computing architecture enables this delegation.
The manual manager building block
According to "An Architectural Blueprint for Autonomic Computing:":
A manual manager is an implementation of the user interface that enables an IT professional to perform some management function manually. The manual manager can collaborate with other autonomic managers at the same level or orchestrate autonomic managers and other IT professionals working at "lower" levels. The manual manager building block is the architectural representation of the human activity and typically involves a human using a management console ... A manual manager can enable an IT professional to delegate management functions to autonomic managers.
So, in a way, one can think of autonomic managers and manual managers performing the same sorts of functions, but with potentially different qualities of service. For example, an autonomic manager can monitor managed resources by subscribing to events reported by those resources; a manual manager could do the same. Given the requisite knowledge and logic, an autonomic manager can correlate those events to recognize symptoms in an automated manner. A manual manager also could perform this function, but the manual manager might rely on a human administrator looking at the events on the console and mentally correlating them -- using knowledge present in the human's head -- to determine the resulting symptom. In both cases, the result might be the same, but the manual manager could take longer to arrive at this result. Conversely, if the requisiste knowledge for an autonomic manager is not yet developed, delegation by the manual manager may not be appropriate. As noted previously, there are some tasks that are not well suited for automation and are best performed by humans, or in other words, are architecturally best suited for a manual manager.
The iconic representation for a manual manager and an autonomic manager is illustrated in Figure 2.
Figure 2. Manual manager and autonomic manager building block icons
Notice that both icons include a blue oval at the bottom. This blue oval represents a management service interface. The intent of the autonomic computing architecture is that conceptually (and to the extent possible, when instantiated in an implementation), these two blue ovals are equivalent. That is, the interface and operations used by a manual manager to manage a resource or to manage an autonomic manager should be the same as the interface and operations used by an autonomic manager to manage resources or other autonomic managers. This enables transparent delegation -- resources need not be concerned with whether they are being managed by a manual manager (a human administrator) or an autonomic manager (automated management of tasks that the IT professional has delegated).
This common management interface enables manual managers to manage autonomic managers, choosing at any time which IT service management tasks they wish to delegate to those autonomic managers. The autonomic computing architecture enables this delegation in a seamless manner by using the same standard management interface in all cases, rather than treating manual management differently from automated management -- after all, autonomic managers are simply automating those management tasks that the human chooses to delegate.
Autonomic computing is not about replacing humans with automation, but rather providing a standards-based architecture that enables certain management tasks to be delegated to the system so that self-managing autonomic systems can be realized. This allows for IT professionals to be freed from mundane tasks and instead focus on higher-value tasks that are more directly coupled with accomplishing the business's goals.
Future installments of The autonomic computing edge will explore other forward-looking aspects of autonomic computing that are enabled by the architectural building blocks that have been detailed in this article and the preceding three installments of The autonomic computing edge.
-
The paper An Architectural Blueprint for Autonomic Computing (IBM Corporation, October 2004) provides an overview of the autonomic computing architecture, including more information about manual managers and other architectural building blocks.
-
Read more about knowledge in the previous issue of The autonomic computing edge columns on developerWorks.
-
Don't miss the other articles in this series.
