Skip to main content

skip to main content

developerWorks  >  Autonomic computing | SOA and Web services | Tivoli  >

Combine autonomic computing and SOA to improve IT management

Learn how to incrementally delegate human-powered activities to automation

developerWorks
Document options

Document options requiring JavaScript are not displayed


Rate this page

Help us improve this content


Level: Introductory

Christine Draper (cdraper@us.ibm.com), Senior Technical Staff Member, IBM

04 Apr 2006

For architects and designers who want to know how to apply autonomic computing and Service-Oriented Architecture (SOA) to management systems, this article introduces key concepts in autonomic computing and SOA and shows you how they combine to deliver autonomic management systems that address the challenging complexities within the IT organization. Learn how to incrementally automate IT management processes that might span organizational boundaries, and how to integrate an independent autonomic manager into IT management processes.

The goal of autonomic computing is to hide the complexity of managing IT systems and reduce the need for human intervention by automating routine infrastructure configuration and management activities that today require a lot of attention from IT professionals. IBM's autonomic computing architecture is a Service-Oriented Architecture (SOA) that defines a set of architectural building blocks for constructing autonomic management systems (see "An architectural blueprint for autonomic computing" in Resources).

SOA is an architectural approach to aligning information technology with the needs of the business by:

  • Identifying the services that the business delivers
  • Defining how those services are delivered through a set of human or automated activities and tasks
  • Determining how those activities and tasks should be realized using reusable SOA services and service components

This approach is described further in "Elements of Service-Oriented Architecture and Design" (see Resources).

The combination of SOA and autonomic computing concepts provides a powerful approach to designing and developing IT management solutions that are aligned with the needs of the business. This is an approach that is flexible, robust enough for changing business and technical drivers, and can be automated in an effective and incremental manner.

To understand the role of SOA and autonomic computing in IT management, you first need to recognize that IT management is a business function and should be viewed as such (see "Transforming the 'business of IT'" in Resources). IT management systems should therefore be designed to meet the needs of the "business of IT." This is a fundamental tenet of IT Service Management (ITSM), an approach to running an IT organization based on standards and frameworks such as the IT Information Library (ITIL). (See Resources for more on ITIL and ITSM.)

In this context, the goal of autonomic computing is to improve the effectiveness and efficiency of IT management processes by allowing an IT professional to automate activities normally performed manually. The role of the autonomic computing architecture is to provide the structure to accomplish this in an integrated and incremental way. SOA provides the underlying approach to designing and implementing the set of technical services that automate the activities, based on a business design that maps from a business model into technology.

Autonomic managers and the autonomic computing architecture

The autonomic computing architecture defines a set of building blocks whose purpose is to:

  • Provide the basic elements from which an autonomic management system can be constructed
  • Define how these elements should interact to achieve autonomic function
  • Identify the standard interfaces and models that will allow integrated solutions

The centerpiece of the autonomic computing architecture is the autonomic manager; it is responsible for automating the IT management functions that make a system self-managing. Each autonomic manager automates one or more management functions, and externalizes this function according to the behavior defined by management interfaces. The four primary functions of an autonomic manager, shown in Figure 1, are:

Monitor
Collects, aggregates, correlates, and filters details from managed resources until it recognizes a symptom that needs to be analyzed. The details can include topology information, metrics, configuration property settings, and so on. Logically, this symptom is passed to the analyze function.
Analyze
Provides the mechanisms to observe and analyze symptoms to determine if some change needs to be made. For example, symptoms about increased transaction time and unavailable servers might be analyzed to determine that more servers are needed to avoid violating a response time policy. In this case, a change request for "three more servers to be assigned to the degraded business application" might be generated to avoid a response time violation and reduce the growing backlog. The change request is logically passed to the plan function.
Plan
Creates or selects a procedure to enact a desired alteration in the managed resource. The plan function can take on many forms, ranging from a single command to a complex workflow for a release plan. The plan function generates the appropriate release plan that represents a desired set of changes for the managed resource and logically passes that change plan to the execute function.
Execute
Provides the mechanism to schedule and perform the necessary changes to the system. After an autonomic manager has generated a release plan that corresponds to a change request, some actions might need to be taken to modify the state of one or more managed resources. The execute function of an autonomic manager is responsible for carrying out the procedure that was generated by the plan function through a series of actions. Part of the execution of the change plan could involve updating the knowledge that is used by the autonomic manager.

When these functions can be automated, an intelligent control loop is formed that automates a set of activities commonly performed by professionals in an IT organization. Autonomic managers use policies (goals or objectives) to govern how the four functions are accomplished.


Figure 1. Autonomic manager
Autonomic manager

To deal with the practical reality that the control loop functions need to be delivered and deployed incrementally, the architecture formally addresses the need for autonomic computing systems to have autonomic managers that perform a subset of the control loop. This is because:

  1. the implementation supports a subset
  2. the IT professional responsible for the deployed autonomic manager has only activated a subset of the function. This can happen when the professional's job responsibility does not include all the functions or they decide not to take advantage of all the function.

The need for partial autonomic managers is described in more detail in "Can you CHOP up autonomic computing?" in Resources.

SOA

As described in "Service-oriented Architecture and Integration" (see Resources), there are several approaches to SOA:

  • Top-down approaches start with modeling the business and the services that it provides.
  • Bottom-up approaches start with modeling existing assets and identifying how they may be exposed as reusable services.

Although I'll focus on the top-down approach to SOA in this article, both approaches are applicable to autonomic computing. (For more on using SOA to provide standard interfaces to manageable resources, see "Web Services Distributed Management (WSDM)" in Resources. It is a good example of the bottom-up approach.)

Figure 2 represents an SOA.


Figure 2. The Service-Oriented Architecture
The Service-Oriented Architecture

Service consumers use applications that have been created by combining services together to support the consumers' business processes. Alignment of IT with the business is achieved by matching the granularity and function of the top-level of provided services to the activities and tasks in the business processes.

Services are provided by service components, which may be stand-alone or may be composed from the services offered by other service components. Service components also provide the means to leverage the functions in existing operational systems, integrating them into solutions within the SOA context.

A set of cross-cutting concerns -- security, data architecture, integration and governance -- apply across this architecture.

To achieve the best possible match between existing assets and the top-down decomposition from business services, a method such as service-oriented modeling and architecture, or SOMA (see Resources), can be adopted. With SOMA, the starting point for the top-down identification of services is a model of the business's:

  • Organizational components
  • Services they provide
  • Processes used to deliver those services

Other services are identified bottom-up from existing assets. Analysis is performed to identify mismatches or missing services and to group services into sensible service components for realization.

Following the above approach along with an appropriate governance model (see "A case for SOA governance" in Resources), you can develop SOA solutions that integrate a set of functions across organizational boundaries. The functions deliver services to the organization's customers while allowing different parts of the organization to retain independence in the way those functions are delivered. This promotes flexibility and agility and provides the necessary coordination to meet the overall goals of the organization.

Applying SOA and autonomic computing architecture to IT processes

An SOA approach to IT management starts with a model of the business of IT, as shown in Figure 3. This model identifies the:

  • Logical components of the IT organization, such as change planning or change implementation
  • Services those components offer to the IT organization's customers and to other parts of the IT organization
  • Processes the organization uses to run its business

As mentioned, a standard for IT management processes is provided by the IT Information Library (ITIL). IBM has developed a series of "Component Business Models" (see Resources) for various industries, including a model for the business of IT compatible with ITIL.


Figure 3. Component business model and process definitions for the business of IT
Component business model and process definitions for the business of IT

The IT services and processes may then be decomposed into workflows of activities and tasks that are used to realize them. "IBM Tivoli's Unified Process" (see Resources) comprises a set of workflows that are compatible with the ITIL process definitions.

In terms of an SOA approach, the IT services offered by the IT organization are consumed by end-users outside of the IT organization, such as by a line-of-business within the overall organization. Figure 4 illustrates an example of this.


Figure 4. Automating IT services using an SOA model
Automating IT services using an SOA model

The IT services may be consumed directly through a self-service portal offered by the IT organization or they may be integrated into business applications in that line-of-business. For example, an application to on-board an employee in the HR department might initiate requests for user IDs and passwords using IT services.

The IT services that are automated using SOA are realized by service components that implement the IT service and process workflows within the IT organization. Therefore, the activities performed by IT staff and the automated tasks performed by management tools are coordinated.

Some IT services might not be automated, in which case an end-user may interact directly with IT staff to initiate the service.

Figure 5 shows the next level of IT service automation using SOA. Selected tasks within the IT service and process workflows are mapped to the monitor, analyze, plan, or execute functions of an autonomic manager. This provides the service component for these automated tasks. The autonomic manager will typically be realized using functions of existing management tools.


Figure 5. Automated tasks and autonomic managers
Automated tasks and autonomic managers

In reality, an IT organization is typically not a single monolithic unit; it has internal organizational boundaries and those internal organizational units may interact with each other using defined services. This leads to a more complex picture, as shown in Figure 6.


Figure 6. External IT services are realized using internal IT services
External IT services are realized using internal IT services

Autonomic managers in the context of IT processes

In this section, I'll describe two architecture patterns for using autonomic managers in the context of IT processes: incremental process automation and process integration through shared data.

Pattern: Incremental process automation

Problem
Process integration and automation allow IT professionals to delegate activities to automation and to automate the flow of work between professionals.

How can IT management processes that might span organizational boundaries be incrementally automated?

The goal of process automation is to reduce the effort that professionals invest in routine management of systems, letting them focus on the business-specific aspects of IT management. In many IT organizations, the monitor, analyze, plan, and execute activities cross organizational boundaries. Often, this will imply the use of different technologies and procedures. There's a need to "link" together the work performed by IT professionals in different parts of the IT organization.

Solution
IT management processes are integrated using process integration technologies. Selected activities within those processes are incrementally delegated to autonomic managers, as shown in Figure 7.

Figure 7. Automation of activities in IT processes by partial autonomic managers
Automation of activities in IT processes by partial autonomic managers

The workflows associated with IT management processes can be automated and these flows integrated across the organizational boundaries by linking together the services provided by each business component.

Within each workflow, activities implementing the monitor, analyze, plan, and execute functions of a control loop can be identified. These activities can be incrementally delegated to partial autonomic managers, which results in the implementation of a control loop that crosses organization boundaries and is integrated by a workflow. As the number of automated activities increases and the IT organization gains trust in the automation technologies, the conditions under which manual intervention (for example, approval steps) is not required can be increased by changing the policies that control the workflow.

By clearly defining the services that a particular business component provides and by making this the integration point at organizational boundaries, automation decisions can be made without needing cross-organizational agreement, provided the required services are maintained and cross-organizational policies are upheld.

By using this integration pattern, an IT organization can incrementally introduce autonomic capabilities into their management systems. They can do so in a way that lets different parts of the organization retain a level of control over the degree of automation and the selection of automation technology.

Pattern: Process integration through shared data

Problem
A variation of the process integration scenario involves an independent autonomic manager that provides a full control loop.

How can an independent autonomic manager be integrated into IT management processes?

For IT management processes to work effectively, key information (such as planned and actual changes) must be kept current in a timely manner even if they are being initiated by a completely independent autonomic manager. Without this information, IT professionals cannot understand the overall performance and state of the system. Worse, actions initiated manually may be erroneous or conflict with actions taken by the autonomic manager because the data (such as policies) on which it is based is inaccurate.

Solution
An independent autonomic manager can be integrated into IT management processes by sharing data, as shown in Figure 8.

An independent autonomic manager that performs functions that must be visible to the IT organization through management processes must contribute the necessary data (such as detected symptoms or changes needed) to allow the reporting and oversight processes in the IT organization to function. You can achieve this by using application integration techniques to extract the necessary information from the autonomic manager, then use it to populate the knowledge sources.


Figure 8. Integrating independent autonomic managers into IT processes through shared data
Integrating independent autonomic managers into IT processes through shared data

This lets independent autonomic managers be integrated into IT management processes. Conversely, it allows process-level control loops that over time have become completely automated to be removed from the normal management workflow, becoming independent autonomic managers.

In conclusion

In this article, you've learned how autonomic computing architecture and SOA can be combined in an organizational context to deliver IT management systems that are aligned to the needs of the business, a combination that allows incremental delegation to automation so IT professionals can spend more time focusing on business-specific needs and not the routine management of the infrastructure.



Resources

Learn

Get products and technologies
  • IBM Tivoli Unified Process Demo: Download this demo, which details how IT Service Management can be achieved through the use of current management applications and the integration of new process-oriented products.

  • IBM trial software: Build your next development project with trial software, available for download directly from developerWorks.


Discuss


About the author

Christine Draper is a member of the IBM Autonomic Computing Architecture team, where she leads the work on solution deployment architecture and is actively involved in IT service management and SOA activities. She has previously worked as an architect in solution management, business process integration, and security.




Rate this page


Please take a moment to complete this form to help us better serve you.



YesNoDon't know
 


 


12345
Not
useful		Extremely
useful
 


Back to top