Business Service. Front cover. ibm.com/redbooks. All you need to understand Business Service Management

(1)

Business Service

Management Best

anagement Best

Practices

ctices

Budi Darmawan

Kimberly Cox

All you need to understand Business

Service Management

Business process mapping to

monitoring and service level

Integration of IBM TBSM

and IBM TSLA

(2)

(3)

Business Service Management Best Practices

June 2004

(4)

First Edition (June 2004)

Note: Before using this information and the product it supports, read the information in

(5)

Notices

This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to:

IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.

The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES

THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you.

Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.

This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental.

COPYRIGHT LICENSE:

This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,

(10)

Trademarks

The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both:

Eserver® Eserver® Redbooks (logo) ™ e-business on demand™ ibm.com® z/OS® AIX 5L™ AIX® CICS® Database 2™ Domino® DB2 Universal Database™ DB2® IBM® IMS™ Lotus Notes® Lotus® NetView® Notes® Redbooks™ Redbooks (logo)™ Tivoli Enterprise™ Tivoli Enterprise Console® Tivoli®

TME® WebSphere®

The following terms are trademarks of other companies:

Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation in the United States, other countries, or both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries. Other company, product, and service names may be trademarks or service marks of others.

(11)

Preface

This IBM® Redbook discusses Business Service Management best practices. Business Service Management is a key component of IBM’s on demand Automation Blueprint. It is the top layer of the system management discipline, enabling IT management to be related to the business.

The ultimate goal of the IT infrastructure is to leverage its value to support the business. IT infrastructure management should then be aimed at minimizing disruption to the business processes and functions. This goal is realized with the Business Service Management (formerly also called Business Impact

Management).

Using Business Service Management, IT resources management is aligned with the business processes and functions:

򐂰 Establishing a Service Level Agreement with IT users 򐂰 Understanding how IT resources impact business processes

򐂰 Ensuring IT resources fulfill the Service Level Agreement and minimizing disruption to business functions

This redbook describes the relevant concepts, as well as planning for and implementing Business Service Management. The implementation is described using a sample business function of an e-business solution.

The team that wrote this redbook

This redbook was produced by a team of specialists from around the world working at the International Technical Support Organization, Austin Center.

Budi Darmawan is a Project Leader at the International Technical Support

Organization, Austin Center. He writes extensively and teaches IBM classes worldwide on all areas of systems management. Before joining the ITSO four years ago, Budi worked in IBM Global Services in IBM Indonesia as Lead Implementer and Solution Architect. His areas of expertise include Tivoli® core product implementation, database systems and business intelligence, z/OS® systems management and general performance management. He currently specializes in Business Service Management.

(12)

Masters degree in Computer Science and Engineering from Pennsylvania State University. Her areas of expertise include the architecture and implementation of IBM Tivoli Business Systems Manager / Distributed. She has also developed and taught a course for training services in the deployment of IBM Tivoli Business Systems Manager / Distributed.

Bahaeldin Ragab is a Tivoli Certified Enterprise Consultant for the IBM/IT

Service and Solution in Germany. He has six years of experience in the area of Information Technology. He holds a degree in Electrical-Biomedical Engineering from Dresden University of Technology. His areas of expertise include designing, implementing and troubleshooting systems management solutions. In the last five years, he has implemented more that 20 Tivoli deployments for most of the big business companies in Germany and Austria.

Thanks to the following people for their contributions to this project: Editor, Edson Manoel

International Technical Support Organization, Austin Center Debbie Bandera, Mark Masercola, JB Baker, Marianne Haerdth

(13)

Become a published author

Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You'll team with IBM technical professionals, Business Partners and/or customers.

Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you'll develop a network of contacts in IBM development labs, and increase your productivity and marketability.

Find out more about the residency program, browse the residency index, and apply online at:

ibm.com/redbooks/residencies.html

Comments welcome

Your comments are important to us!

We want our Redbooks™ to be as helpful as possible. Send us your comments about this or other Redbooks in one of the following ways:

򐂰 Use the online Contact us review redbook form found at:

ibm.com/redbooks

򐂰 Send your comments in an Internet note to:

redbook@us.ibm.com

򐂰 Mail your comments to:

IBM Corporation, International Technical Support Organization Dept. 0SJB Building 003 Internal Zip 2834

11400 Burnet Road Austin, Texas 78758-3493

(14)

(15)

Chapter 1.

Introduction to Business

Service Management

This chapter provides an introduction to Business Services Management and describes how IBM Tivoli answers this challenge with the IBM Tivoli products portfolio. The following topics are discussed in this chapter:

򐂰 1.1, “IT organization evolution” on page 2 discusses the changes in the IT organization over time from the traditional glass house to the on demand environment

򐂰 1.2, “The IBM on demand Automation Blueprint” on page 4 shows the on demand infrastructure components and the automation blueprint as one of its main structure

򐂰 1.3, “Business Service Management” on page 8 introduces the Business Service Management definition and concepts

򐂰 1.4, “Discussion scope” on page 9 details the structure and scope of the discussion in this redbook

(16)

1.1 IT organization evolution

As shown in the IBM automation blueprint, Business Service Management is the top level of the necessary automation platform that delivers the on demand operating environment.

The IT organization is an evolutionary journey from a technology focused organization to a business driven organization. IT organizations have

implemented several management models to increase their productivity. These models have always been somewhat driven by market development and the need for more productivity. The mainframe era was about administrative productivity while the PC and client-server era was about personal productivity. Increasing productivity has always meant more complexity for both business management and IT service delivery. This complexity has introduced rigid business processes, proprietary and fragmented applications and under-utilized, inflexible IT infrastructures. Both IT service delivery and Business Process Management were focused on technology and technology trends; the results were complexity, autonomy, redundant capabilities and fragmented management views with no integration between enterprises resources.

Figure 1-1 shows the IT organization evolution path.

Figure 1-1 IT service delivery evolution

Fragmented infrastructure Integrated infrastructure Dynamic infrastructure Process optimized Enterprise optimized Value-net optimized IT Infrastructure Bu si ness Val u e FUTURE Orga nizati onal Prod uctivity PRESENT PAST

(17)

Recently, e-business has changed the rules for Business Process Design and IT Service Delivery. Boundaries between systems and applications have begun to correspond with the business boundaries in the extended enterprise. This offers the opportunity to understand the dependency between business and system and increase flexibility and dynamics in each area to improve the organizational productivity.

Successful IT service organizations have changed the way they are running their business accordingly. They are now focused on business responsibilities, dependencies and measurement systems. This enables them to align their management approach with the next era, the e-business on demand™ era. The trends of business organization, business process, application, data and infrastructure in comparison to the aforementioned business and IT service delivery approaches is summarized in Table 1-1.

Table 1-1 Business evolution

Past Present Future

Organization/ Business Design 򐂰 Independent operation of

divisions and business processes

򐂰 Limited coordination with supplies or partners 򐂰 Constant reinvestments in

skills with lower ROI on resources

򐂰 Targeted global

brand/customer coordination

򐂰 Bias toward “own and operate” for majority of processes; limited/no outsourcing

򐂰 Shared services for

back-office activities such as IT, HR and procurement

򐂰 Cross division & geographic harmonization of critical processes

򐂰 Focus on core business processes; outsource non-core (process, applications. and infrastructure

Business Process 򐂰 Business processes operate

independently

򐂰 Viable application providers rare

򐂰 Re-engineering movement takes some hold

򐂰 Heavy focus on common IT-driven enterprise

processes to drive standards

򐂰 Business process adapts to packaged application 򐂰 Highly efficient but very rigid

processes prevail

򐂰 Optimization at division level - selective trading partner collaboration efforts

򐂰 Full value chain visibility 򐂰 Account-specific services 򐂰 Composite software and

Web Services tie together cross-function processes and workflow

򐂰 Dynamic, flexible business processes

(18)

1.2 The IBM on demand Automation Blueprint

In the e-business on demand environment, enterprises need to shift their operation to the on demand state. Resource allocation, process modelling and

Applications 򐂰 Applications focused on

“spot solutions”

򐂰 Limited cross-application integration

򐂰 Highly inefficient to operate or change

򐂰 Process logic limited to specific applications

򐂰 Wide-scale adoption of packaged solutions designed to meet the business needs 򐂰 Bias toward “own and

operate” majority of core applications; limited/no outsourced management

򐂰 Leading application

functionality delivered online, as needed

򐂰 Smart business integration applications provide alerts, monitoring, triggers and trade partner orchestration 򐂰 Architecture will enable

application flow and logic to uncoupled

Data 򐂰 Data is isolated in individual

areas with limited functional communication

򐂰 Duplicate systems and multiple versions and copies of non-shared data

򐂰 No standards or common structures

򐂰 Incomplete view of consumer behavior

򐂰 Harmonization of customer and product data (for example, master files) driven by applications and

cross-divisional efforts 򐂰 Importance of data integrity

and management sophistication 򐂰 Standards movement

emerging

򐂰 Open and core data standards adopted universally

򐂰 Radio Frequency identifier standards adopted & operational

򐂰 Data and insights shared internally and with partners 򐂰 360° view of consumer, value

chain Infrastructure

򐂰 Internal data centers support each division within an enterprise

򐂰 Bias toward own vs. rent capabilities

򐂰 In-house technical

management; inflexible and cost inefficient

򐂰 Remote data centers support divisions

򐂰 Limited outsourcing of some IT capabilities such as legacy applications.

򐂰 Lack of open, adaptable and flexible operability to accommodate complex IT

򐂰 Intelligent infrastructure with enhanced remote data centers capabilities 򐂰 Partnership between IT

environment and business requirements; rapid adoption of emerging technologies 򐂰 On demand services

(19)

investment in time, money and resources. Operations needs to be streamlined to achieve lower costs and improved quality of service.

The on demand operation needs the IT operation to be managed as one cooperative entity. IT operations need to align with business strategy and to be more responsive, to focus on core competencies, to benefit from variable cost structures and to be resilient to external threats. The value within the IT infrastructure is unlocked to be applied to solving business problems. It is an integrated platform, based on open standards, to enable rapid deployment and integration of business applications and processes. Combined with an

environment that allows true virtualization and automation of the infrastructure, the on demand operating environment enables delivery of IT capability on demand.

The on demand solution offerings can be categorized to address three main capabilities:

򐂰 Integration: the efficient and flexible combination of resources to optimize operations across and beyond the enterprise

򐂰 Virtualization: the pooling of IT resources for simplified access and improved utilization

򐂰 Automation: the capability to reduce the complexity of management to enable better use of assets, improve availability and resiliency and reduce costs based on business policy and objectives.

The IBM Tivoli solution is the base of providing the automation. Automation is extremely critical to allow businesses to achieve resiliency, efficiency,

responsiveness and flexibility. The IBM automation platform shows the structure of the automation component in providing on demand automation capability. The IBM automation blueprint is shown in Figure 1-2 on page 6.

(20)

Figure 1-2 IBM automation blueprint

The IBM Automation Blueprint is a game-changing plan for reducing the complexity of technology to allow focus on the business goals, allowing the application of resources to business objectives rather than the management of technology. The blueprint enables enterprises to implement automation in an evolutionary fashion that acknowledges the heterogeneous nature of the infrastructure.

At the bottom of the blueprint is the foundation – the software and system resources with native automation capabilities required for higher level

automation functions. Many of these resources may be virtualized to the other capabilities. Here, the key point is that in order to achieve the highest levels of on demand automation, resources need to be virtualized so that they can be dynamically provisioned as business policies require.

Above the resources are the key automation capabilities: 򐂰 Availability helps ensure that systems are available 24x7.

򐂰 Reliance or security keeps your systems protected from threats and provides the functions for a great user experience in accessing applications and data they need, while keeping out unwelcome users.

Business Service Management

Policy Based Orchestration

Availability

Assurance

Optimization

Provisioning

Virtualization

(21)

򐂰 Optimization provides tools to make the most of the resources you have, so that they are running at peak performance and efficiency and providing you with the maximum return on your investment.

򐂰 Provisioning focuses on the self-configuring, dynamic allocation of individual elements of your IT infrastructure, so that identities or storage or servers are provisioned as business needs dictate.

The next layer, Policy-Based Orchestration, helps customers automatically control all the capabilities of the four areas we just discussed so that the entire IT infrastructure is responding dynamically to changing conditions according to defined business policies. This orchestration builds on the best practices of the customer’s collective IT experience, and helps to ensure that complex

deployments are achieved with speed and quality – on demand.

Finally, Business-driven Service Management capabilities provide the tools you need to manage Service Levels, meter system usage and bill customers for that usage, as well as model, integrate, connect, monitor and manage your business processes end-to-end for complete linkage of IT and business processes. Being able to view IT resources in the context of business systems is a unique

capability that we need.

Now let’s understand how the Business Service Management relates to other components of the IBM Automation Blueprint. The Business Service

Management manages Service Level attainment and uses the Policy-Based Orchestration to modify the environment should there be any potential that the Service Level cannot be met with the current configuration. Let’s use an example.

򐂰 A Web Services environment, a configuration with a set of Web servers and Web application server, working with a load balancer.

򐂰 Due to a very popular seasonal offering, it is experiencing a large number of additional requests.

򐂰 When it has detected that the number of requests are high enough to warrant new servers, the Policy Based Orchestration requests those from the

resources pool.

򐂰 The new servers resource is initialized using the Provisioning tower and configured by the Optimization tower.

򐂰 The Policy-Based Orchestration should also modify security from the

Reliance tower and initiate monitoring of the new servers from the Availability tower.

(22)

򐂰 Business Service Management measurement indicates that the surge of requests can now be handled within the promised Service Level.

The basic implementation of Business Service Management that we cover in this redbook basically involves the Availability monitoring tower and the Business Service Management layer. We do not cover the Policy-Based Orchestration or the other tower that is needed to present a fully autonomic computing.

1.3 Business Service Management

Service Management is defined as the management of an IT infrastructure of hardware, software, communications equipment and facilities, documentation, and skills used to provide the required service at the required level of quality. Business Service Management is an application of service management principles to manage the Service Levels for a business function. IT operations should manage IT infrastructure to support the business functions as dictates by the application of Service Level Agreements.

The Service Level Agreement is the key factor in Business Service Management. It addresses the business consumer of IT resources and also dictates the scope of IT systems management. A Service Level Agreement is defined as an

agreement or contract between a service provider and a customer of that service, which sets expectations for the level of service with respect to availability, performance, and other measurable objectives.

The business entity is typically responsible for a business process. A business process can be perceived as a collection of IT resources that make up the business process. Each IT resource in the business process may belong to one or more business processes. Each IT resource needs to be monitored and measured in order to ensure its availability and calculate the Service Level attainment. Figure 1-3 on page 9 shows a sample business process.

(23)

Figure 1-3 Defining Business Systems

Thus, Business Service Management can be viewed as the task to manage the Service Level with the business consumer for a specific business process to ensure that the Service Level Agreement is fulfilled. The following are several aspects of Business Service Management:

򐂰 It consists of identifying the components of a business system

򐂰 It involves measuring the performance and availability of those components 򐂰 It ensures that the components are performing within the Service Level

objective

򐂰 It alerts to any deviation or potential deviation from the Service Level objective

1.4 Discussion scope

This redbook discussion will cover concepts, planning and implementation samples of Business Service Management. The ultimate objective of Business Service Management is to have a defined Service Level Agreement (SLA) with all IT consumers; the IT systems management tools are then geared toward achieving and measuring it.

The concept and planning discussion presents a generic discussion of the

These Resources combined

CICS WebSphere DB2 CICS CICS WebSphere DB2

=

Web Catalog

Order Processing

Web Catalog

Order Processing

Web Catalog

Order Processing

These Resources combined

CICS WebSphere DB2 CICS CICS WebSphere DB2

=

Web Catalog

Order Processing

Web Catalog

Order Processing

Web Catalog

(24)

one business element at a time. However, in our implementation discussion, due to time constraints, we show a single business element implementation.

Also, the implementation of Business Service Management in this redbook is geared towards a distributed environment instead of a mainframe-centric environment. There are some differences in the mainframe environment on the basis of the products and components used.

This book is divided into the following chapters:

򐂰 Chapter 1, “Introduction to Business Service Management” on page 1 introduces Business Service Management and provides a general introduction to this book.

򐂰 Chapter 2, “Business Service Management concepts” on page 11 explains the basic concepts of the Business Service Management: the scope and reach of the Business Service Management, what its components are, its implication on your business.

򐂰 Chapter 3, “Planning for Business Service Management” on page 43 shows some important aspects of planning the implementation of Business Service Management: what is the necessary information that you need to gather? Who are the important source of information that you need to talk to? How do you process these pieces of information and select the important ones? 򐂰 Chapter 4, “Business Service Management sample implementation” on page 87 illustrates a sample implementation of an e-business system’s implementation of Business Service Management. The implementation spans the Service Level commitment and further use of the tools.

(25)

Chapter 2.

Business Service

Management concepts

This chapter discusses concepts, design considerations and implementation of Business Service Management. The discussion is based on the following: 򐂰 2.1, “Business Service Management concept” on page 12 defines Business

Service Management. We also describe Service Level Management issues and show a glimpse of the planning and implementation process.

򐂰 2.2, “IBM Tivoli product mapping” on page 18 shows the available IBM software that delivers Business Service Management today and how it maps to the IBM on demand Automation Blueprint.

򐂰 2.3, “Overview of IBM Tivoli Business Systems Manager” on page 20 provides an overview of IBM Tivoli Business Systems Manager.

򐂰 2.4, “Overview of Tivoli Data Warehouse” on page 28 provides an overview of Tivoli Data Warehouse.

򐂰 2.5, “Overview of IBM Tivoli Service Level Advisor” on page 36 provides an overview of IBM Tivoli Service Level Advisor.

(26)

2.1 Business Service Management concept

In Chapter 1, “Introduction to Business Service Management” on page 1, we have seen that Business Service Management is the top level of the IBM Automation Blueprint. Business Service Management aligns IT operations with business objectives. It gives business functions the maximum leverage from IT resources.

Business Service Management includes the following components: 򐂰 Business: The term business or business process has relative scope

depending on the person that uses it. Typically, it represents the process or processes that someone has a stake in. For a Sales Manager, business may mean the sales quota calculation; for a Warehouse Supervisor, the inventory application may be his or her business.

򐂰 Service: The term

service

in this context means Service Level. It is the level of service that needs to be maintained for the business so it can operate optimally. It guarantees that the business process is available when it is needed.

򐂰 Management: The term

management

indicates that the Service Level for the business process must be planned, monitored, measured and maintained. Business Service Management integrates systems management information from heterogeneous environments and different technologies in the overall business context to be consistent with the mental models used to make decisions about the direction and operation of the business. This means that every piece of the delivered IT services and resources should be manageable, measurable and defined in a business context.

A holistic Business Service Management must deliver a solution that helps organizations to gain the following:

򐂰 Align IT-infrastructure with business goals

򐂰 Leverage the existing systems management infrastructure 򐂰 Simplify end-to-end management

򐂰 Reduce support and licensing costs

򐂰 Satisfy line of business customers with quality service delivery 򐂰 Meet Service Level commitments and ensure peak business system

performance

With Business Service Management, the value of IT can be communicated to line-of-business executives to enable them to know exactly how well their business function performs from the IT perspective, either using a real-time

(27)

In order to understand more about Business Service Management, let’s put the basic concept in place. The next section will discuss Service Level Management.

2.1.1 Service Level Management

Service Level Management is the process of negotiating, defining, and managing the levels of IT Service that are required and cost-justified. The Service Level Management goal is important because it emphasizes quantification of services. Therefore, the objectives of the Service Level must be quantifiable, measurable and realistic.

The definition of Service Level objectives requires that: 򐂰 IT Services be catalogued.

򐂰 IT Services be quantified in terms that both customer and IT provider understand.

򐂰 Internal and external targets of IT Services be defined and agreed upon. 򐂰 Achievement of agreed service targets be reached.

The quantification of objectives applies to all aspects of the management of IT Services between:

򐂰 The customer organization and the IT Services organization 򐂰 The IT Services organization and its external suppliers 򐂰 The IT Services organization and its internal departments

According to this, Service Level Management (SLM) can also be thought of as an

Important: It is not enough to define a Service Level as:

A “good” response time on transaction A The following definition is more suitable:

90% of the response time of transaction A, measured from the Quality of Service endpoint, should be below 3 seconds

The latter definition:

򐂰 Is quantifiable, 3 seconds response time 򐂰 Identifies the measurement method

򐂰 Is realistic as it accommodates small deviations only: measures 90% of transactions

(28)

adequate levels of service are delivered to all IT users in accordance with business priorities and at acceptable cost.

A key to the success of Service Level Management is correctly quantifying the services being provided. Unless there is an agreed-upon method of how services are to be measured, there is no way of knowing whether targets have been met or not. Service Level Management is responsible for understanding and

documenting the customer requirements and translating them into a set of understandable measures.

Service Level Management is a means for the lines of business (LOB) and IT organization to explicitly set their mutual expectations for the content and extent of IT Services. It also allows them to determine in advance what steps will be taken if these conditions are not met. The concept and application of Service Level Management allows IT organizations to provide a business-oriented, enterprise-wide service by varying the type, cost, and level of service for the individual LOB.

In order to accomplish Service Level Management and really manage the quality of service provided by an internal IT organization or by an external service provider, establishing Service Level Agreements is a must.

Depending on the maturity of the IT organization, SLA may be formally defined and signed since SLA exists as an objective for the IT provider team to maximize its service. It is imperative in the full implementation of Business Service

Management that SLA be formally defined.

For the context of this redbook, we define Service Level Agreement (SLA) as follows: an agreement or contract between a service provider and a customer of that service, which sets expectations for the level of service with respect to availability, performance, and other measurable objectives.

Service Level Management is the key factor in a successful Business Service Management solution for the following reasons:

򐂰 Client satisfaction measures

The IT Service provider must understand what the customer perceives as good service. The customer must understand what it is reasonable to expect from the IT Service provider given limitations in hardware, network

performance, staff, and so on. Communication between an IT service provider and a customer is an essential part of Service Level Management. There must be an agreement of what constitutes acceptable service against which Service Levels can be measured. When IT service providers meet

(29)

򐂰 Managing expectation

Often, customers who were satisfied with service yesterday want better service today, and even better tomorrow. Some savvy ones may just want to maintain Service Levels knowing that more users are receiving IT services. To manage such a situation, an IT service provider and customer must negotiate an SLA. Both parties may later renegotiate the agreement as needed.

򐂰 Regulating resources

When both the IT service provider and customer monitor Service Levels closely, they can become aware of developing problems in overcapacity or lack of resources and can be proactive by taking corrective actions. 򐂰 Marketing for IT services

In the old days, the only contact between the IT service provider and customer happened when something went wrong. This situation was always seen as a roadblock to achieving business goals. With a Service Level Management process in place, an IT service provider can document the fact that it is providing good services, supporting the business.

򐂰 Controlling costs

With a Service Level Management process in place, IT service providers can clarify which areas if of its services need improvement and requires

investment, and which areas still perform at satisfactory levels. This helps with the decision-making process and justification as to whether investments are necessary to upgrade Service Levels.

2.1.2 Implementation considerations

Deploying Business Service Management solution is a big challenge that can be achieved using several different approaches. The following are some important implementation considerations:

򐂰 Implementation is performed in stages. This means that you implement Business Service Management for critical business processes first and build on that for other business processes. The first part of the implementation typically take longer as users are getting used to the concepts and

requirements. The critical business processes are implemented first to get a larger participant to the project that can accelerate the acceptance of the solution and building the mindshare of how the solution should be configured. 򐂰 Implementation is performed in iteration. The first take of designing a

(30)

accurate and usable solution can be done without destroying what has been considered before.

򐂰 The Business view of IT resources is dynamic since the resources are allocated and re-allocated every day or every hour. Change management must be considered in the implementation process. Depending on the nature and scale of the business, some change process can be a manually initiated operation or an automatic one.

Business Service Management solution are driven by the Service Level Agreements. IT service delivery goals should be aligned with the SLA. The Business Service Management solution should start with the consolidation of Service Level Agreements.

Figure 2-1 shows the conceptual components of Business Service Management.

Figure 2-1 Business Service Management components

Implementation of Business Service Management includes a lot of planning and data gathering. This planning and data gathering relates to understanding the business systems and its interaction and how IT resources are used within the business system. Also, the planning needs to collect and consolidate Service Level Agreements (if they exist) to understand how the business systems metrics are committed from both the IT organization and users.

We found it useful in planning for the deployment Business Service Management solution to use the following top-down approach:

Monitors

Database availability Transaction rate

Response time

Service Level Agreement

Components Metrics Target

DB2 Database Availability 98% # of transaction 100/sec response time < 2sec

Real time status

Event based Aggregated business system

Ensure SLA Attainment

Historical data

Collected in database Measured against SLA

(31)

Identifying in the customer environment how business processes are structured is key to performing the Business Service Management implementation. Hence, the first phase is to understand the business processes and try to decompose it into its components:

– Components that are business critical for the service delivery process (databases, application server)

– Critical sub components (business critical Servlets or JSPs) 򐂰 Service Level Agreement analysis and consolidation

A key to the success of Business Service Management implementation is precisely quantifying all (internal and external) delivered services. Once we get the business process structure and its components, the Service Level needs to be analyzed and consolidated. The Service Level information needs to be documented. The documentation must reflect a clear description of the following:

– Delivered services and their components – Service level objectives

– Measurement metrics and method

򐂰 Current system monitoring environment and historical data collection The current environment needs to be evaluated for monitoring reuse, excessive monitoring and for identifying additional monitoring requirements. Historical data is needed to perform Service Level reporting; this data needs to be collected from the monitoring subsystem.

򐂰 Detailed design

The most critical factor to the design of a Business Service Management solution is the monitoring and event management design. A failure in the implementation can be caused by a design flaw in the monitoring and event management level due to lack of information about the target business functions.

The component decomposition level provides you with the appropriate information that helps you to get around such drawbacks. Equipped with component decomposition data, you can now proceed to a level of detail that supports you to select the appropriated monitors and events. Once you have determined the appropriate monitors, you have to find out which events can deliver precise information about the health and performance of the target business system. You must also define correlation matrixes and rules to route these events to the right destinations (TEC, TBSM). In addition, each event should unambiguously be associated with clear defined actions, so that your help desk can easily execute the appropriate tasks. The following details

(32)

The above steps are discussed in more detail in Chapter 3, “Planning for Business Service Management” on page 43. Once all the necessary planning information is received, we are ready to deploy the solution. This solution deployment is discussed in Chapter 4, “Business Service Management sample implementation” on page 87. The deployment of Business Service Management includes the deploy Service Level Management components and the business monitoring components.

2.2 IBM Tivoli product mapping

From the Automation Blueprint, let’s see what products we can use to achieve the Business Service Management. The IBM Tivoli product for the Business Service Management is shown in Figure 2-2.

Figure 2-2 Product mapping

The Business Service Management layer contains solutions that help organizations more closely align IT with business goals, meet Service Level commitments and ensure peak business system performance while reducing support and licensing costs. This helps customers increase their ability to

Availability

Business Service Management

Event Correlation and Automation

IBM Tivoli Enterprise Console IBM Tivoli NetView

Monitor Systems and Applications

IBM Tivoli Monitoring IBM Tivoli Monitoring for

Real time Management

IBM Tivoli Business Systems Manager

Predictive Management

IBM Tivoli Service Level Advisor Tivoli Data Warehouse

(33)

execute by ensuring that they can focus their limited resources on the most important areas of their business. There are two groups of products in this layer: 򐂰 Real-time monitoring group, which evaluates the business function health in

real time to alert operation personnel of any degradation. The product in this group is:

– IBM Tivoli Business Systems Manager

򐂰 Predictive monitoring group, which collects performance metrics from the Availability subsystem and measures them against the Service Level. The products in this group are:

– IBM Tivoli Service Level Advisor – Tivoli Data Warehouse

The Availability layer contains a solution that performs the monitoring of Software and System resources to ensure their availability. There are two groups of products in this layer:

򐂰 Event Correlation and Automation group consolidates tools that work across multiple environments to identify the root cause of problems, based on the information gathered across individual systems and platforms, and either notify support staff or correct the problem automatically. IBM Tivoli has developed the following products to address this layer:

– IBM Tivoli NetView® Family – IBM Tivoli Enterprise™ Console

򐂰 Monitor System and Application group provides tools that help continuously gather information about, configure, and monitor individual middleware elements, applications and the supporting IT infrastructure, which includes hardware, databases, software and networks. Some examples are:

– IBM Tivoli Monitoring

– IBM Tivoli Monitoring for Database – IBM Tivoli Monitoring for Application

– IBM Tivoli Monitoring for Business Integration – IBM Tivoli Monitoring for Web Infrastructure

To understand the Business Service Management implementation further, we will present important concepts for the IBM Tivoli Business Systems Manager, Tivoli Data Warehouse and IBM Tivoli Service Level Advisor in the following sections since they hold key concepts on the solution that we deploy later.

More information on other Availability layer product that we used can be read about in the respective product documentation or the following Redbooks:

(34)

򐂰 IBM Tivoli Monitoring Version 5.1: Advanced Resource Monitoring, SG24-5519

򐂰 IBM Tivoli Monitoring for Databases Database Management Made Simple, SG24-6613

򐂰 IBM Tivoli Monitoring for Business Integration, SG24-6625

򐂰 Introducing IBM Tivoli Monitoring for Web Infrastructure, SG24-6618 򐂰 Unveil Your e-business Transaction Performance with IBM TMTP 5.1,

SG24-6912-00

򐂰 Tivoli NetView 6.01 and Friends, SG24-6019

򐂰 Early Experiences with Tivoli Enterprise Console 3.7, SG24-6015

2.3 Overview of IBM Tivoli Business Systems Manager

For detailed information on IBM Tivoli Business Systems Manager, refer to Tivoli Business Systems Manager V2.1 End-to-end Business Impact Management, SG24-6610. This section only discusses the major product features that we use in the Business Service Management implementation.

IBM Tivoli Business Systems Manager is a real time, event-driven systems management product that can be use for Business Service Management. IBM Tivoli Business Systems Manager can manage and monitor systems,

applications, middleware and other related systems management component on the context of their related line of business. While traditional systems

management tools are focused on technology and deliver only fragmented views of the enterprise infrastructure health, IBM Tivoli Business Systems Manager works with these legacy tools to view outages as they relate to the impact of the overall line of business.

There is an out-of-the-box integration for IBM Tivoli products with IBM Tivoli Business Systems Manager. Automatic resource discovery is provided to register existing resources and adopt the Business System Views for dynamic environment changes. IT personnel can then customize their own views in relation to the resources under their responsibility, a line of business, a

department, a vertical area of responsibility, a geographical area or a specific set of resources.

Table 2-1 on page 21 emphasizes the features of Tivoli Business Systems Manager with focus on the advantages and benefits associated with them.

(35)

Table 2-1 The benefits and advantages of TBSM features

2.3.1 IBM Tivoli Business Systems Manager components

IBM Tivoli Business Systems Manager is made up of three major components: 򐂰 Base Services, which is the main component for IBM Tivoli Business Systems

Manager. It contains the following functions:

– Stores objects and events data in a relational database

– Receives events from the z/OS sources for insertion into the database – Receives distributed systems events using either the Enterprise Console

listener or the Common Listener

– Processes events and applies them to monitored objects, enables event propagation up the monitoring hierarchy for business system monitoring

Features Advantages Benefits

Provides business context for IT, enables greater accountability to business user needs and improves ability to prioritize and optimize

Allows IT staff to view IT resources in the context of critical business services and to prioritize actions based on business impact and make intelligent trade-off

Provides business context for IT. Enables greater accountability to business user needs. Improves ability to prioritize and optimize

Shows the relationship between applications

Allows IT staff to make intelligent trade-off, to easily spot inefficiencies and problems, and to quickly diagnose the root cause of complex failure scenarios

Increases availability (uptime) of critical business systems

Automatically discovers and builds graphical views of applications

Allows for the placement of discovered resources into containers that represent critical Business Systems and Applications

Speeds implementation time and reduces errors and ensures the currency and accuracy of

management view Dynamically adjusts the

Business System View for components added, modified, or deleted

Automatically keeps the Business System View up-to-date by avoiding the problem of manual entry leading to obsolete information displays

Reduces errors and improves productivity

(36)

򐂰 Mainframe resources feeds: this provides support for the z/OS resources for IBM Tivoli Business Systems Manager. It processes events from various z/OS applications and subsystems. The following z/OS resources are supported:

򐂰 z/OS operating systems

򐂰 Batch jobs and scheduler systems

򐂰 Online transaction systems such as IMS™, CICS® and DB2® 򐂰 Storage systems

򐂰 Application such as WebSphere® and HTTP Server

򐂰 Distributed resource feeds: this provides the support for distributed

environments. The following distributed resources can be managed by IBM Tivoli Business Systems Manager:

– IBM Tivoli Enterprise Console® 3.6.2, or later – IBM Workload Scheduler 8.1

– IBM Tivoli NetView – IBM Tivoli Monitoring

– IBM Tivoli Monitoring for Database, Application, Business Integration, Web Infrastructure, and Collaboration

– BMC Patrol 3.4

– CA TNG 2.1, 2.2 and 2.4 – NetQ AppManager 4.02

2.3.2 IBM Tivoli Business Systems Manager servers

A typical IBM Tivoli Business Systems Manager implementation uses a set of Intel® servers running Windows® 2000 or NT. The following lists the functionality of these servers:

򐂰 Database server

This server runs Microsoft® SQL Server. It hosts the data repository for the IBM Tivoli Business Systems Manager. This machine performs a central role in IBM Tivoli Business Systems Manager.

򐂰 History server

This server is where all the actions and events processed are archived for reporting and auditing purposes. It contains a physical copy of the database server database. The contents of the active database are replicated regularly to the History Server to maintain a history of all the collected events.

(37)

򐂰 Console server

This server provides support and functionality for Console-based IBM Tivoli Business Systems Manager Clients.

򐂰 Propagation server

This server processes events and calculates propagation actions. 򐂰 Event Handler server

This server receives and processes events from z/OS. SNA clients or Host Integration client software is required, even when only TCP/IP communication is used.

򐂰 Host Integration server

This server enables Windows-based applications to communicate with z/OS based applications. This server was called SNA server in the previous versions of IBM Tivoli Business Systems Manager. This server is only used for SNA based communication so there is no need for it on TCP/IP based installations.

򐂰 Web Console application server

This server handles requests associated with the IBM Tivoli Business Systems Manager Web-based clients. This component provides a lighter client with just a Web browser interface. It provides somewhat less functionality than the regular console.

򐂰 Health Monitor Server

This server monitors the health and availability of the other IBM Tivoli Business Systems Manager servers and their related components.

The overall flows of IBM Tivoli Business Systems Manager components is shown in Figure 2-3 on page 24.

(38)

Figure 2-3 TBSM flowchart

2.3.3 Important concepts in IBM Tivoli Business Systems Manager

In IBM Tivoli Business Systems Manager, there are several concepts that you should be familiar with to work with the product. Understanding the following concepts helps you get a better understanding of the product:

򐂰 Business Systems Views 򐂰 Object discovery processing 򐂰 Event propagation

Business Systems View

A Business System View is a representation of a group of diverse but

interdependent enterprise resources that are used to deliver specific business z\OS TBSM Servers Tivoli Management Region Source/390 Host Integration

Server Event HandlerServer

Propagation Server Database Server History Server Console Server Common Listener Service Agent Listener Tivoli Data Warehouse Web Console Console Distributed Data Source. ( Netview, ITM)

Task Server _{Event Enablement}TEC

Web Console Server Health Monitor Server Tivoli NetView for z\OS Health Monitor Client

(39)

For example, a Web banking application that is distributed over database mainframe systems, application servers, firewall, intranet and Internet can be considered a Business System View.

IBM Tivoli Business Systems Manager provides a flexible user interface that enables viewing resources that are of interest to a user (such as a Manager of the Web Services group) or a group of users (such as the Web banking support team) in a way that reflect the business process that is monitored, the so-called Business System View. A Business System View is a hierarchical view that displays IT resources that relate to a business process.

A Business System View consists of the following:

򐂰 The system resources that provide the business function

򐂰 The appropriate prioritization of resources used to determine the health of the business system

򐂰 The relationship between system resources may be shown

A Business System View can be created from the console or automatically upon receiving events. Effective Business System Views consider only resources important to the target business systems. An important factor in defining Business System Views is who will actually use the business system. A help desk may need a Business System View based more on the physical

organization of systems and applications. A CIO, on the other hand, may want a Business System View that shows all the business processes in the enterprise, but not at the level of detail needed by the help desk.

Business System Views can be built according to the following aspects: 򐂰 An application or a set of applications (Web Banking)

򐂰 A department (Accounting department) 򐂰 A vertical area of responsibility (ITSO) 򐂰 A geographic region (EMEA)

Resources are represented as icons within the Business System View. To easily determine the root causes of a business system outage, IBM Tivoli Business Systems Manager provide you with three viewing perspectives.

򐂰 Tree View, which lists the hierarchy of all resources

򐂰 Hyper View, which is best viewing option for displaying large number of resources at one glance.

򐂰 Table view, which shows resources in a table format. This view is equipped with column filtering and sorting capabilities.

(40)

򐂰 Business impact view, which shows resources that are affected and their relation to the impact causing resource.

򐂰 Event view, which displays the events that triggered the resource state change.

Object discovery processing

Before IBM Tivoli Business Systems Manager can monitor resources and their performance characteristics, its object type must be registered to IBM Tivoli Business Systems Manager, as discussed in 2.3.4, “IBM Tivoli Business

Systems Manager distributed object types” on page 27. The object must then be discovered in the discovery process. This enables the Tivoli Business Systems Manager to identify and classify these resources. Distributed resources can be discovered and monitored through the following interface:

򐂰 Agent Listener

IBM Tivoli Enterprise Console events can be forwarded through this interface. IBM Tivoli Enterprise Console rules can be developed to forward events to the IBM Tivoli Business Systems Manager database. The first event from a resource triggers the creation of the object as the discovery process. 򐂰 Common Listener

The Common Listener transport provides bulk and delta transactions. The bulk transaction populates the IBM Tivoli Business Systems Manager database with snapshots of the instrumented environments. The delta transaction keeps the IBM Tivoli Business Systems Manager database updated as new resources are introduced or removed from the instrumented environments.

Event propagation

Event processing is the process of capturing business-critical events from IBM Tivoli Enterprise Console or Common Listener and routing them to IBM Tivoli Business Systems Manager. This events are then processed and stored in the IBM Tivoli Business Systems Manager database.

Basically, events affect the status of a resource. State changes are propagated upward to affect the resource's parents; to facilitate the determination of the status of Business System Views. Propagation is the process that allows events to escalate or propagate up the All Resources view or Business System Views. Propagation is implemented by generating a child event to the parent resources. In the distributed implementation, all events are of the type Exceptions.

(41)

2.3.4 IBM Tivoli Business Systems Manager distributed object types

In IBM Tivoli Business Systems Manager, an object type represents an IT component class, such as a machine, database or application. The object type can have multiple event sources mapped to that object type. Examples of object types can include Node, WindowsServer, OracleDatabase, CustomApp, Hub, NetworkDevice, and so on.

Each object type can have: 򐂰 An icon associated with it 򐂰 Events that can show up under it 򐂰 A set of tasks associated with it 򐂰 One or more URLs associated with it

򐂰 One or more local applications associated with it

An object type can have multiple instances. Each actual IT component will be an instance of that object type. For example, if you have an object type of NTServer and you have three NT servers called ServerA, ServerB, and ServerC, then you would have three instances of NTServer, which are NTServer on ServerA, NTServer on ServerB, and NTServer on ServerC. The Properties Page for each object instance lists the events that have been received for that object instance. Object types can be as granular as desired. One should consider the following: 򐂰 All instances of a given object type will have the same icon, tasks, and URLs 򐂰 Each instance will only display the events that have come in for that instance

(even though the object type will have to have all possible events types for that object type defined to it)

򐂰 An instance of any given object type can appear in any or all Business System Views

򐂰 Multiple DM profiles can map to the same object, but a single DM profile can only map to one object type

In an IBM Tivoli Business Systems Manager distributed implementation, there are two kinds of object types:

򐂰 Distributed Monitoring (DM) objects that receive events from the Tivoli Distributed Monitoring product

򐂰 Generic objects

DM object types

(42)

appear under a DM object instance once the object instance has been discovered.

When DM object types are defined, they are associated with one or more Tivoli Distributed Monitoring or IBM Tivoli Monitoring profiles. Any given Tivoli

Distributed Monitoring or IBM Tivoli Monitoring profile name can be associated with only one object type, yet multiple Tivoli Distributed Monitoring or IBM Tivoli Monitoring profile names can be associated with the same DM object type in IBM Tivoli Business Systems Manager. When a Tivoli Distributed Monitoring or IBM Tivoli Monitoring event reaches IBM Tivoli Business Systems Manager, the profile name is used to determine the IBM Tivoli Business Systems Manager object class.

Object instances will not appear on the IBM Tivoli Business Systems Manager console until a Tivoli Distributed Monitoring or IBM Tivoli Monitoring event associated with that object instance has been received by IBM Tivoli Business Systems Manager. Scripts can be used to send artificial events to IBM Tivoli Business Systems Manager if you want to populate it ahead of time with object instances.

Generic object types

Generic object types are usually defined for events that are coming from sources other than Tivoli Distributed Monitoring or IBM Tivoli Monitoring, or to put it more precisely, when the event is forwarded to Event Enablement with the binary

ihstttec. Only generic events can show up under generic object types – the only way to post a DM event to a generic object instance is to treat the event as a generic event.

In order for an instance of a generic object type to appear on a IBM Tivoli Business Systems Manager console, a generic event must be forwarded to IBM Tivoli Business Systems Manager for the given instance. Scripts can be used to send artificial events to IBM Tivoli Business Systems Manager if you want to populate it ahead of time with object instances.

2.4 Overview of Tivoli Data Warehouse

For more information on Tivoli Data Warehouse, refer to Introduction to Tivoli Data Warehouse, SG24-6607.

The key point of Tivoli Data Warehouse is that all historical data from different management applications is collected in one centralized database, the Tivoli Data Warehouse. The schemas of this database are open and published.

(43)

Figure 2-4 Reporting with Tivoli Data Warehouse

In the Tivoli Data Warehouse, all data is aggregated and correlated for use by reporting and third party OLAP tools and also by planning, trending, analysis, accounting, and data mining tools.

Tivoli Data Warehouse applications also provide static standard reports using a Web console reporting tool. In Release 1 of Tivoli Data Warehouse, the following classes of reports are supported:

򐂰 Two-dimensional representation of measurements versus components/groups of components

– Graphical report – Tabular report

򐂰 Measurements versus time

We will discuss the architecture of Tivoli Data Warehouse in more detail in 2.4.3, “Tivoli Data Warehouse components” on page 33.

Customers / Partners Business Intelligence Front End

Service Level Management Out-of-the-box Report Templates

TWH

3rd Party Applications Net View TWSM TWSA

Framework

TAPM DM (monitors) INV TEC

SAP Lotus XchgDBMGR etc...

Security

TWSM

(44)

2.4.1 Benefits of using Tivoli Data Warehouse

Customers can benefit from using Tivoli Data Warehouse in various ways: 򐂰 Tivoli Data Warehouse collects historical data from many Tivoli applications

into one central place.

Tivoli Data Warehouse collects the underlying data about customers’ network devices/connections, desktops/servers, applications/software, and the problems and activities that have gone on to manage the infrastructure. This allows the customers to construct an end-to-end view of their enterprise and view the components independent of specific applications used to monitor and control resources.

򐂰 Tivoli Data Warehouse adds value to raw data.

Tivoli Data Warehouse performs data aggregation (for example, daily or weekly) and allows the user to restrict the amount of data stored in the central data repository. The data is also cleaned and consolidated in order to allow the data model of the central repository to share common dimensions. For example, Tivoli Data Warehouse ensures that time, hostname, and IP address are the same dimensions across all the applications.

򐂰 Tivoli Data Warehouse allows the correlation of information from many Tivoli applications.

Tivoli Data Warehouse can be used to derive added value by correlating data from many Tivoli applications.

򐂰 Tivoli Data Warehouse uses open, proven interfaces for extracting, storing, and sharing the data.

Tivoli Data Warehouse can extract data from any application (Tivoli and non-Tivoli) and store it in a common central database. The Tivoli Data Warehouse application also provides transparent access for third party BI solutions (CWM standard), such as IBM DB2 OLAP, Crystal Decisions, Cognos, Business Objects, Brio Technology, and Microsoft OLAP Server. CWM stands for Common Warehouse Metadata, an industry standard specification for metadata interchange defined by the Object Management Group (see http://www.omg.org). Tivoli Data Warehouse provides a

Important: Tivoli Data Warehouse is not an independent product. It is

delivered free with all Tivoli Data Warehouse-enabled applications. All enabled Tivoli source applications will be shipped with the necessary Tivoli Data Warehouse components to import their data into the central data warehouse.

Business Service. Front cover. ibm.com/redbooks. All you need to understand Business Service Management

Business Service

Management Best

anagement Best

Practices

ctices

Budi Darmawan

Kimberly Cox

All you need to understand Business

Service Management

Business process mapping to

monitoring and service level

Integration of IBM TBSM

and IBM TSLA

Business Service Management Best Practices

June 2004

Contents

Notices

Trademarks

Preface

The team that wrote this redbook

Become a published author

Comments welcome

Introduction to Business

Service Management

1.1 IT organization evolution

1.2 The IBM on demand Automation Blueprint

Business Service Management

Policy Based Orchestration

Availability

Assurance

Optimization

Provisioning

Virtualization

1.3 Business Service Management

1.4 Discussion scope

=

Web Catalog

Order Processing

Web Catalog

Order Processing

Order Processing

Web Catalog

Web Catalog

Order Processing

=

Web Catalog

Order Processing

Web Catalog

Order Processing

Order Processing

Web Catalog

Web Catalog

Business Service

Management concepts

2.1 Business Service Management concept

service

management

2.1.1 Service Level Management

2.1.2 Implementation considerations

2.2 IBM Tivoli product mapping

Availability

Business Service Management

2.3 Overview of IBM Tivoli Business Systems Manager

2.3.1 IBM Tivoli Business Systems Manager components

2.3.2 IBM Tivoli Business Systems Manager servers

2.3.3 Important concepts in IBM Tivoli Business Systems Manager

Business Systems View

Object discovery processing

Event propagation

2.3.4 IBM Tivoli Business Systems Manager distributed object types

DM object types

Generic object types

2.4 Overview of Tivoli Data Warehouse

TWH

Framework

2.4.1 Benefits of using Tivoli Data Warehouse