Front cover Business Service Management anagement Best Practices ctices All you need to understand Business Service Management Business process mapping to monitoring and service level Integration of IBM TBSM and IBM TSLA Budi Darmawan Kimberly Cox Bahaeldin Ragab ibm.com/redbooks International Technical Support Organization Business Service Management Best Practices June 2004 SG24-7053-00 Note: Before using this information and the product it supports, read the information in “Notices” on page vii. First Edition (June 2004) This edition applies to IBM Tivoli Business Systems Management V2.1.1 and IBM Tivoli Service Level Advisor version 1.2.1. © Copyright International Business Machines Corporation 2004. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Chapter 1. Introduction to Business Service Management. . . . . . . . . . . . . 1 1.1 IT organization evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 The IBM on demand Automation Blueprint . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Business Service Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.4 Discussion scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Chapter 2. Business Service Management concepts . . . . . . . . . . . . . . . . 11 2.1 Business Service Management concept . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.1.1 Service Level Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.1.2 Implementation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2 IBM Tivoli product mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.3 Overview of IBM Tivoli Business Systems Manager . . . . . . . . . . . . . . . . . 20 2.3.1 IBM Tivoli Business Systems Manager components . . . . . . . . . . . . 21 2.3.2 IBM Tivoli Business Systems Manager servers . . . . . . . . . . . . . . . . 22 2.3.3 Important concepts in IBM Tivoli Business Systems Manager . . . . . 24 2.3.4 IBM Tivoli Business Systems Manager distributed object types . . . . 27 2.4 Overview of Tivoli Data Warehouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.4.1 Benefits of using Tivoli Data Warehouse . . . . . . . . . . . . . . . . . . . . . 30 2.4.2 Tivoli Data Warehouse structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.4.3 Tivoli Data Warehouse components . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.5 Overview of IBM Tivoli Service Level Advisor . . . . . . . . . . . . . . . . . . . . . . 36 2.5.1 How IBM Tivoli Service Level Advisor works . . . . . . . . . . . . . . . . . . 37 2.5.2 Inside the IBM Tivoli Service Level Advisor . . . . . . . . . . . . . . . . . . . 38 2.5.3 IBM Tivoli Service Level Advisor databases . . . . . . . . . . . . . . . . . . . 40 2.5.4 The Service Level Management life cycle with TSLA . . . . . . . . . . . . 41 Chapter 3. Planning for Business Service Management . . . . . . . . . . . . . . 43 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.2 Sources of information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.3 Information collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.3.1 Business process decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 © Copyright IBM Corp. 2004. All rights reserved. iii 3.3.2 Documentation of Service Level objectives . . . . . . . . . . . . . . . . . . . 54 3.3.3 Understanding the current monitoring environment . . . . . . . . . . . . . 56 3.4 Designing the solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 3.4.1 Solution structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.4.2 Hardware and software configuration . . . . . . . . . . . . . . . . . . . . . . . . 63 3.4.3 Monitoring standard and required modification . . . . . . . . . . . . . . . . . 68 3.4.4 IBM TBSM object type selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.4.5 Business System View design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 3.4.6 Data collection design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 3.4.7 Service Level management design . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Chapter 4. Business Service Management sample implementation . . . . 87 4.1 Sample environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 4.2 Constructing the solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 4.2.1 Solution structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.2.2 Solution configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.2.3 Monitoring architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 4.2.4 Object class selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 4.2.5 Business System View design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 4.2.6 Data collection design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 4.2.7 Service Level monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 4.3 Implementation overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 4.4 IBM Tivoli Monitoring profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 4.4.1 Profile Managers and IBM Tivoli Monitoring profiles. . . . . . . . . . . . 101 4.4.2 Detailed profile setting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 4.5 IBM Tivoli NetView monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 4.6 Web transaction response time monitoring . . . . . . . . . . . . . . . . . . . . . . . 120 4.6.1 Quality of Service monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 4.6.2 Synthetic Transaction Investigator monitoring . . . . . . . . . . . . . . . . 126 4.7 Defining TEC rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 4.7.1 Adding IBM Tivoli Monitoring rules . . . . . . . . . . . . . . . . . . . . . . . . . 132 4.7.2 IBM Tivoli Monitoring for Transaction Performance rules . . . . . . . . 133 4.7.3 IBM Tivoli NetView rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 4.7.4 Assembling a new TEC rule base . . . . . . . . . . . . . . . . . . . . . . . . . . 139 4.7.5 IBM Tivoli Business Systems Manager customization . . . . . . . . . . 140 4.7.6 Defining TBSM object types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 4.7.7 Setting object hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 4.7.8 Defining business systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 4.7.9 Defining TBSM operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 4.8 Configuring Tivoli Data Warehouse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 4.8.1 Collecting information from IBM Tivoli Monitoring. . . . . . . . . . . . . . 152 4.8.2 Collecting information from Web Services Courier . . . . . . . . . . . . . 153 4.8.3 Enabling ETL in Tivoli Data Warehouse . . . . . . . . . . . . . . . . . . . . . 154 iv Business Service Management Best Practices 4.9 Customizing IBM Tivoli Service Level Advisor . . . . . . . . . . . . . . . . . . . . 160 4.9.1 Defining the operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Contents v vi Business Service Management Best Practices 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, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. 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 IBM's application programming interfaces. © Copyright IBM Corp. 2004. All rights reserved. vii 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. viii Business Service Management Best Practices 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. Kimberly Cox is a Senior IT Specialist for the US IBM Tivoli Business Systems Manager services team. She has worked at IBM for five years. She holds a © Copyright IBM Corp. 2004. All rights reserved. ix 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 Tivoli Systems x Business Service Management Best Practices 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: [email protected] Mail your comments to: IBM Corporation, International Technical Support Organization Dept. 0SJB Building 003 Internal Zip 2834 11400 Burnet Road Austin, Texas 78758-3493 Preface xi xii Business Service Management Best Practices 1 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 © Copyright IBM Corp. 2004. All rights reserved. 1 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. FUTURE Business Value Value-net optimized Or a PAST Fragmented infrastructure Integrated infrastructure IT Infrastructure Figure 1-1 IT service delivery evolution 2 on ati y vit cti du PRESENT Enterprise optimized Process optimized niz ga ro lP Business Service Management Best Practices Dynamic infrastructure 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 adapts to packaged application Full value chain visibility Account-specific services Composite software and Web Services tie together cross-function processes and workflow Dynamic, flexible business processes Business Process Business processes operate independently Viable application providers rare Highly efficient but very rigid processes prevail Re-engineering movement takes some hold Heavy focus on common IT-driven enterprise processes to drive standards Optimization at division level - selective trading partner collaboration efforts Chapter 1. Introduction to Business Service Management 3 Past Present Future 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 Leading application functionality delivered online, as needed Bias toward “own and operate” majority of core applications; limited/no outsourced management Smart business integration applications provide alerts, monitoring, triggers and trade partner orchestration Architecture will enable application flow and logic to uncoupled Open and core data standards adopted universally Importance of data integrity and management sophistication Radio Frequency identifier standards adopted & operational Data and insights shared internally and with partners Standards movement emerging 360° view of consumer, value chain Intelligent infrastructure with enhanced remote data centers capabilities Partnership between IT environment and business requirements; rapid adoption of emerging technologies On demand services 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 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 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 cost structure need to be flexible with unparalleled connectivity. Also required is the ability to adapt to changes in the marketplace quickly and without a huge 4 Business Service Management Best Practices 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. Chapter 1. Introduction to Business Service Management 5 Business Service Management Policy Based Orchestration Availability Assurance Optimization Provisioning Virtualization Software Resources System Resources 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. 6 Business Service Management Best Practices 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. Now the new servers should be available to handle the additional load from the Web requests. Chapter 1. Introduction to Business Service Management 7 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. 8 Business Service Management Best Practices These Resources combined DB2 WebSphere = CICS Web Catalog Order Processing 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 Business Service Management. Full implementation of Business Service Management takes a long period of time and typically is implemented gradually, Chapter 1. Introduction to Business Service Management 9 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. 10 Business Service Management Best Practices 2 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. © Copyright IBM Corp. 2004. All rights reserved. 11 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 status or historically. The achievement of the IT operation for the line-of-business executives is their attainment of the Service Level Agreement. 12 Business Service Management Best Practices 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. 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 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 iterative, disciplined, proactive methodology and procedures used to ensure that Chapter 2. Business Service Management concepts 13 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 expectations, customers can clearly see their expectations are being met and confidence increases. 14 Business Service Management Best Practices 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 business system from a business process is rarely complete nor accurate. The decision and reasoning behind the component selection and criteria should be documented so that perfecting the implementation into a complete, Chapter 2. Business Service Management concepts 15 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. Service Level Agreement Components DB2 Database Monitors Real time status Event based Aggregated business system Metrics Target Availability 98% # of transaction 100/sec response time < 2sec Database availability Transaction rate Response time Ensure SLA Attainment Historical data Collected in database Measured against SLA Measure SLA Attainment 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: Business process decomposition 16 Business Service Management Best Practices 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 should also be included in the detailed design. – TBSM configuration (Business System Views) – SLM configuration details (offerings, order, ETLs, peak time) Chapter 2. Business Service Management concepts 17 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. Business Service Management Real time Management Predictive Management IBM Tivoli Business Systems Manager IBM Tivoli Service Level Advisor Tivoli Data Warehouse Availability Event Correlation and Automation IBM Tivoli Enterprise Console IBM Tivoli NetView Monitor Systems and Applications IBM Tivoli Monitoring IBM Tivoli Monitoring for 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 18 Business Service Management Best Practices 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: Chapter 2. Business Service Management concepts 19 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. 20 Business Service Management Best Practices Table 2-1 The benefits and advantages of TBSM features 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 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 – Serves IBM Tivoli Business Systems Manager workstation for operators to manage the business systems Chapter 2. Business Service Management concepts 21 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. 22 Business Service Management Best Practices 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. Chapter 2. Business Service Management concepts 23 z\OS Source/390 Tivoli Data Warehouse Tivoli NetView for z\OS TBSM Servers Host Integration Server Event Handler Server History Server Web Console Propagation Server Console Server Database Server Web Console Server Console Agent Listener Common Listener Service Health Monitor Server Health Monitor Client Tivoli Management Region Task Server TEC Event Enablement Distributed Data Source. ( Netview, ITM) 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 functionality. These resources can include applications or other resources that are distributed over different networks and installed on different platforms. 24 Business Service Management Best Practices 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. Additionally, you can invoke the following views from any resources in the Business System View: Chapter 2. Business Service Management concepts 25 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. Depending on their priority, exceptions can be processed to affect the object alert state. If the exception threshold for the object in a specific priority bucket is exceeded, the object alert state is changed and child events are generated. 26 Business Service Management Best Practices 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 DM object instances can only be discovered by a Tivoli Distributed Monitoring or IBM Tivoli Monitoring event, or to put it more precisely, can only be discovered by events forwarded to Event Enablement using the binary ihstztec. In addition to Tivoli Distributed Monitoring or IBM Tivoli Monitoring events, generic events can Chapter 2. Business Service Management concepts 27 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. Systems management data from third party applications can also be easily integrated. This architecture is shown in Figure 2-4 on page 29. 28 Business Service Management Best Practices Customers / Partners Business Intelligence Front End Service Level Management Out-of-the-box Report Templates 3rd Party Applications TWH DB SAP Lotus Xchg MGR etc... TEC TAPM DM (monitors) INV Framework Net View TWSM TWSM TWSA TWSA Security Security Storage 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. Chapter 2. Business Service Management concepts 29 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. 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 Web-based reporting front end, called the Report Interface, but the open 30 Business Service Management Best Practices architecture provided by the Tivoli Data Warehouse allows other BI front ends to be used to access the data in the central warehouse. The value here is flexibility. Customers can use the reporting application of their choice, and are not limited to any application. All Tivoli applications will provide standard out-of-the-box reports. All Tivoli applications will provide standard out-of-the-box reports and report templates, utilizing the Tivoli Data Warehouse’s common central warehouse. These reports will provide similar information to those provided by many of the TDS guides today. As mentioned earlier, Tivoli will also develop and provide (as separate products) high value, cross-product reporting applications or killer applications such as Tivoli Service Level Advisor. Tivoli Data Warehouse provides robust security mechanism. Tivoli Data Warehouse provides a robust security mechanism by allowing data marts to be built with data from subsets of managed resources. By providing database level authorization to access those data marts, Tivoli Data Warehouse can address most of the security requirements related to limiting access to specific data to those customers/business units with a need to know. Tivoli Data Warehouse provides a scalable architecture. Since Tivoli Data Warehouse depends on the proven and industry standard relational database management system (RDBMS) technology, it provides a scalable architecture for storing and retrieving data. 2.4.2 Tivoli Data Warehouse structure The Tivoli Data Warehouse is an application used to collect and manage data from various Tivoli and non-Tivoli system management applications. The data is imported from the source applications, stored centrally, and further processed to fit the needs of the end users. Here we describe the basic components of the Tivoli Data Warehouse in the logical order of the data flow. Chapter 2. Business Service Management concepts 31 Tivoli Warehouse Control Server: IBM DB2® DWC Warehouse Metadata Tivoli Reporting Services Source Apps DM ETL Inventory ETL TEC Source App ETL Tivoli Reporting Interface Central Data Warehouse ETL Data Marts Data Marts Data Marts Data Marts Data Marts Data Marts ETL Business Intelligence Tools IBM Cognos Brio Business Objects Figure 2-5 Components of the Tivoli Data Warehouse The first step to introduce Tivoli Data Warehouse is to enable the source applications. This means providing all tools and customization necessary to import the source operational data into the central data warehouse. All components needed for that task are collected in so-called warehouse packs for each source application. One important part of the warehouse packs are the ETL programs. The abbreviation ETL stands for extract, transform and load data. In principle, ETL programs process data in three steps. First, they extract the data from a data source. Then the data is validated, transformed, aggregated, and/or cleansed so that it fits the format and needs of the data target. Finally, the data is loaded into the target database. In Tivoli Data Warehouse, there are two types of ETLs. The central data warehouse ETL pulls the data from the source applications and loads it into the central data warehouse (see Figure 2-5). The central data warehouse ETL is also known as source ETL or ETL1. The second type of ETL is the data mart ETL, which is discussed later. 32 Business Service Management Best Practices The central data warehouse (CDW) is the database that contains all enterprise-wide historical data (with hour as the lowest granularity). This data store is optimized for the efficient storage of large amounts of data and has a documented format that makes the data accessible to many analysis solutions. The database is organized in a very flexible way, which lets you store data from new applications without adding or changing tables. The data mart ETL extracts a subset of historical data from the central data warehouse that contains data tailored to and optimized for a specific reporting or analysis task. This subset of data is used to create data marts. The data mart ETL is also known as target ETL or ETL2. A data mart is a subset of the historical data that satisfies the needs of a specific department, team, or customer. A data mart is optimized for interactive reporting and data analysis. The format of a data mart is specific to the reporting or analysis tool you plan to use. Each application that provides a data mart ETL creates its data marts in the appropriate format. Tivoli Data Warehouse provides a Report Interface (RI) that creates static two-dimensional reports of your data using the data marts. The RI is a role-based Web interface that can be accessed with a simple Web browser without any additional software installed on the client. You can also use other tools to perform OLAP analysis, business intelligence reporting, or data mining. The Control server is the system that contains the control database which itself contains metadata for Tivoli Data Warehouse and from which you manage your data warehouse. The Control server controls communication between the Control server, the central data warehouse, the data marts, and the Report Interface. The Control server uses the Data Warehouse Center to define the ETL processes and the star schemas used by the data marts. You use the Data Warehouse Center to schedule, maintain, and monitor these processes. 2.4.3 Tivoli Data Warehouse components A distributed installation is recommended for most production systems and for customers who already run their database servers on UNIX® systems. Each of the aforementioned components of Tivoli Data Warehouse can exist on a separate machine. Such a configuration is illustrated in Figure 2-6 on page 34. Chapter 2. Business Service Management concepts 33 Figure 2-6 A distributed Tivoli Data Warehouse configuration We will provide further information about the four components, including prerequisites such as DB2 installations and supported operational systems. However, always first thoroughly review Tivoli Data Warehouse Release Notes, GI11-0857, before planning your installation. The Control server is the system that contains the control database for Tivoli Data Warehouse and from which you manage your data warehouse. Supported operating systems are Windows NT® and Windows 2000. Before you install the Tivoli Data Warehouse component on the Control server, you have to install IBM DB2 Universal Database™ Enterprise Edition on this machine first. The Control server uses the DB2 Server, the Data Warehouse Center, and the warehouse agent. 34 Business Service Management Best Practices The Data Warehouse Center on your Control server automates the data warehouse processing. You can use it to define the ETL processes that move and transform data into the central data warehouse and the star schemas used by the data marts. Then you can use the Data Warehouse Center to schedule, maintain, and monitor these processes. The warehouse agent is a part of the DB2 Warehouse Manager. In this configuration, the warehouse agent runs only on the Control server. The system on which you install the Control server must connect to the operational data stores of your enterprise, which potentially reside on other systems and in relational databases other than DB2. To enable the Control server to access these data sources, you must install the appropriate database client for each data source on the Control server system. The central data warehouse server contains the DB2 databases only. In this configuration, no pieces of the Tivoli Data Warehouse software or DB2 Warehouse components are needed on this server. Supported operating systems are Windows NT, Windows 2000, AIX®, and Solaris. The same applies to the Data mart server. For this reason, in a typical configuration, the central data warehouse and the data marts will be on one database server. The Report Interface server (or Report server) provides tools and a graphical user interface to create and display reports that help you analyze the data in your warehouse to answer questions that are important to your business. The Report Interface uses Tivoli Presentation Services. If it is already installed in your enterprise, you must install the Report Interface component on the system that hosts the server for IBM Console. The Report Interface requires a DB2 runtime client to access data in the DB2 instances on the central data warehouse, data mart, and Control servers. You must manually install the IBM DB2 product before installing the Report Interface component. When installing the IBM DB2 product from the CDs provided with Tivoli Data Warehouse, any one of the following components is sufficient: DB2 Enterprise Edition DB2 Application Development Client DB2 Administration Client (this component has the smallest footprint) Supported operating systems for the Report server are Windows NT, Windows 2000, AIX, Solaris, and Linux. It performs best on Windows NT and Windows 2000 systems. Chapter 2. Business Service Management concepts 35 2.5 Overview of IBM Tivoli Service Level Advisor For more information of IBM Tivoli Service Level Advisor, refer to Introducing IBM Tivoli Service Level Advisor, SG24-6611. This section provides a basic overview of the product, its components and functions as needed to understand and implement Business Service Management. IBM Tivoli Service Level Advisor is a Service Level Management product that helps IT Service delivery organizations to increase the business value of their delivered service, understanding the measurement and Service Level attainment within their organization. This Service Level understanding can helps them to do the following: Maintain productivity and customer satisfaction Verify end user Service Levels Analyze historical data to predict future Service Levels Manage costs, and improve planning by assuring offered services Measure, manage, and report on availability and performance Automate Service Level Management based on Service level objectives Evaluate service delivery based on business schedules Provide Web-based customer report Directly associate IT operations with business requirements Table 2-2 emphasizes the features of the IBM Tivoli Service Level Advisor while focusing on the advantages and benefits associated with them. Table 2-2 The IBM Tivoli Service Level Advisor summary 36 Features Advantages Benefits Automated Service Level agreement evaluation Eliminates the process of manually reviewing and correlating component-level reports against customer Service Level agreements Improves IT resource productivity, and reduces education and training costs required to support component Service Level management products IBM patent-pending trend analysis Identifies IT service delivery problems before they occur, allowing you to take action to maintain Service Levels rather than simply report them Maintains customer productivity and satisfaction with the services they depend on to meet business objectives Business Service Management Best Practices Features Advantages Benefits Manage Service Level definition and business schedules across existing IT infrastructure Leverages existing systems management applications, and associates service delivery with business operations Provides business level management of IT infrastructure and increases return on investment of existing systems management tools Flexible, Web-based reporting Identifies problem areas, providing executive summary, and detailed operations status of Service Level agreements Helps communicate the business value of IT resources and can justify cost expenditures Tivoli Data Warehouse Provides open, extensible aggregation point for all systems management data (including non-Tivoli data), as well as cross-domain reporting Leverages business intelligence tools for data mining, and provides an open interface to include additional monitoring data in Service Level agreements 2.5.1 How IBM Tivoli Service Level Advisor works The IBM Tivoli Service Level Advisor depends on the collected performance and availability data from a variety of monitoring and performance tools to deliver SLA reports and SLA trends identification. This flow is shown in Figure 2-7 on page 38. Chapter 2. Business Service Management concepts 37 ITSLA Environment Source Applications Environment Source Appl 1 So Source Appl 2 Sourc urc e SLM Server ET L1 e ETL n ETL tratio Regis 2 TEDW Central Warehouse Source Appl N ce ur So L ET SLM Reports Server ITSLA Database Pr o ces N s ET L ITSLA Measurement Data Mart ITSLA Database Server SLM Task Drivers and IBM Console Figure 2-7 Data flow in the IBM Tivoli Service Level Advisor Enterprise Monitoring tools and Business System monitoring tools basically store their availability and performance data in their own databases, the source database. This data is then moved into the central data warehouse using Tivoli Data Warehouse at a regular scheduled interval using an Extract Transform Load (ETL) program. After all the source ETLs have written the latest data into the central data warehouse, the IBM Tivoli Server Level Advisor ETL moves a subset of this data into the SLM Measurement Data Mart, where they can be processed and analyzed against defined Service Level objectives. 2.5.2 Inside the IBM Tivoli Service Level Advisor IBM Tivoli Service Level Advisor components are shown in Figure 2-8 on page 39. 38 Business Service Management Best Practices Evaluation data SLM Server offering and orders Trend analysis SLM Task Drivers ITSLA Database Registration ETL ITSLA Database Server Reporting data SLM Reports Server TEDW Control Center Figure 2-8 ITSLA Database component access The SLM Server The SLM Server is the main administration component. It performs the following tasks: – – – – Order creation and processing Performance evaluation and trends analysis of the measurement data Storing the results of the analysis Notification on trends toward SLA violation The Report Server The Report Server is a Web application based on standard Java™-based servlets. The Report Server is hosted on an IBM WebSphere application server. The servlet summarizes the results of the TSLA Measurement Data Mart evaluation process and stores them in table and graph form. Information can then be displayed, such as: – Actual Service Level – SLA violations statistics – Trends toward SLA violation The SLM Task Drivers The SLM Task Drivers are a Web-based user interface which utilizes the IBM Console for all its tasks. It uses the Java console for all its tasks except for viewing of message logs and tracing enablement. This can be done with the help of the Java-based console. The core function of the SLM Task Drivers can be summarized with the following: Chapter 2. Business Service Management concepts 39 – – – – Service level offering and orders creation Definition of peak times, off hour, down times and orders Managing active orders Specifying breach values for metrics associated with offerings IBM Tivoli Service Level Advisor database server The database server hosts the IBM Tivoli Service Level Advisor databases. Tivoli Data Warehouse control center Data warehouse ETL scheduling and management is performed from this machine. 2.5.3 IBM Tivoli Service Level Advisor databases IBM Tivoli Service Level Advisor uses the following data repositories for getting the SLA-related data: The central data warehouse of the IBM Tivoli Data Warehouse (TWH_CDW) The central data warehouse is the single point of data integration for all systems management data. This includes data from the entire distributed IT environment Tivoli products. Tivoli Data Warehouse provides an open integration point for Data-to-Business transformation. Moreover, the Tivoli Data Warehouse provides the following features: – Foundation for Business Service Management – Single place for IT management data consolidation – Open repository for all management data from any vendor, Industry standard warehouse – The warehouse is bundled with and automatically populated by all Tivoli products – Analysis for predictive management and continuous IT improvements – Scalable solution The SLM Database (DYK_CAT) The SLM Database is the configuration repository of the IBM Tivoli Service Level Advisor. It holds the configuration and definitions data, such as resource types and metrics that can be referenced during the creation of offerings and orders. In addition, all the offerings and orders that are already created are stored in the SLM Database. Moreover, all analysis and trend evaluation results are stored in this database. The SLM Database is updated on a regular basis with the latest resource types and metrics data from the central data warehouse using the Registration ETL. The SLM Measurement Data Mart (DYK_DM) This data repository stores all performance and monitoring data collected from IBM Tivoli Data Warehouse upon the execution of the Process ETL. The 40 Business Service Management Best Practices Process ETL moves a subset of the central data warehouse to this repository for processing and analysis. The SLM Measurement Data Mart is updated on a regular basis with the latest metric data from the central data warehouse using the Process ETL. 2.5.4 The Service Level Management life cycle with TSLA Service Level Management is an ongoing process. Both the service provider and customer must adjust the Service Level objectives to achieve the best Service Level with reasonable costs and efforts regularly. The following summarizes the Service Level Management life cycle: 1. Service Level Agreement creation a. Negotiate with your customer to determine the Service level objectives b. Create a draft Service Level agreement c. Review the defined Service Level agreement with your customer d. Agree on the final Service Level agreement 2. Monitor and report the Service Level. The IBM Tivoli Service Level Advisor steps in the Service Level game, as a monitoring and management tool. The overall Service Level management process of the IBM Tivoli Service Level Advisor can be summarized as such: – Configure the IBM Tivoli Data Warehouse to move SLA-related data from the data provider local database into its central data warehouse. – Populate SLM database with the source applications resource types and metrics. This is done with the Registration ETL, manually or by schedule. – Create an offering with the SLA-related objectives. – Associate the offering with your target customer and thereby create an order. – Schedule and populate the SLM Measurement Data Mart with the source application SLA-related data. – Analyze and evaluate the data, notify of SLA violations and potential trends of SLA violations. – Deliver SLA reports. 3. Review the Service Level results with your customer based on the SLA reports. 4. Start with Step 1 again. Chapter 2. Business Service Management concepts 41 42 Business Service Management Best Practices 3 Chapter 3. Planning for Business Service Management In this chapter, we will cover the principles behind Business Service Management to assist in planning for a successful implementation. We discuss many useful tips and techniques based on actual implementations. This chapter includes the following sections: 3.1, “Overview” on page 44 lays down the important planning objectives for Business Service Management implementation. 3.2, “Sources of information” on page 45 lists the personnel or roles that need to be interviewed to get the information about Business Service Management solution. 3.3, “Information collection” on page 47 describes the information collection process, tips and samples. 3.4, “Designing the solution” on page 61 explains the solution design, once the information is collected. © Copyright IBM Corp. 2004. All rights reserved. 43 3.1 Overview A common challenge with Business Service Management is the starting point. Everyone wants to have a successful implementation, but it can be difficult to define. The most important is to start with the basics; you must collect business information and IT information. This information collection and analysis is the scope of this chapter discussion. We categorize this phase as planning the implementation. Planning for Business Service Management involves a thorough understanding of the business structure of the enterprises that need Business Service Management. The business structure includes the positioning of business processes. These business processes need to be understood and associated with the IT resources to see the implications of an IT resource outage to the business process, since this will affect the Service Level. The planning process is performed in a collaborative effort by the implementers and various personnel from the enterprise, including application sponsors, operations control and those responsible for individual component monitoring. The process is mainly performed using interviews and discussions to collect necessary information for the implementation. In this chapter, we describe the person roles that we recommend for gathering the information, provide sample questions to ask, and show sample spreadsheet templates to fill out. The main goal of the planning phase is a robust representation of all relevant business process components, with measurable Service Level objectives. The interim goals of the project that also need to be satisfied are as follows: Manage services at the business level – Relate IT infrastructure to business requirements – Historical, real-time, and predictive analysis and reporting Improve IT resource productivity – Prioritize management based on business impact – Reduce SLA evaluation and SLA reporting time and cost Communicate IT value and delivery of service – Provide Web-based customer reports – Directly associate IT operations with business requirements Maintain high customer satisfaction – Manage Service Levels proactively – Prove Service Levels are met 44 Business Service Management Best Practices The basic steps of planning for Business Service Management are described in more detail in 3.3, “Information collection” on page 47. 3.2 Sources of information This section discusses the people that should be contacted during the planning stages of a Business Service Management implementation. The contact can be in the form of interviews or a moderated discussion so that information can be verified on the spot. Table 3-1 lists the roles that need to be contacted and the information that can be gathered. It is useful to start with a moderated discussion to level set the Business Service Management expectations. Interviews are then useful for following up and gathering more specific requirements. Table 3-1 Personnel roles Role Description Information Business Process Owner The Business Process Owner is typically the head of the line of business who runs the business process. As the owner, this individual understands the overall picture of the business process and is able to state the purpose of the business service. Scope and purpose of the business process Identify stake holders Get Service Level Agreement information Business process manager Some enterprises have a different custodian who is responsible for the business process and a manager who is responsible for the business process. Identify stake holders Get Service Level Agreement information Business process users The typical business users are the end-users of the business components. They use the IT applications for the business process. Describe the business components Identify vital components for them Get user view of the process Who are the users of the business service? Who are the customers of this business service? Application developer and system analyst Developers and system analysts understand the application system that makes up the business components. They design and customize the code. Identify critical transaction Identify databases and application components and their connections Understand the impact of an outage Chapter 3. Planning for Business Service Management 45 Role Description Information Business component owner The individuals responsible for the components of the business process. Contrary to the Business Process Owner, the business component owner is responsible for part of the overall business process. Scope and purpose of the business process Identify stake holders Business support This group is responsible for monitoring availability of the business components. Know the how monitoring is performed Understand the groups that are responsible for the support System operator The system operator manages day-to-day operations of IT components. Important components that need monitoring Most likely spot where problems can occur Business structure insight Helpdesk personnel First level problem determination personnel Primary communication with business users Able to state where the business service is deployed Heavily relies on the use of tools for Business Service Management Problem and change coordinators They manage and monitor the problem management and change management processes To provide the business impact of problems and change. Tivoli Framework administrator Personnel that manage the Tivoli Management Framework structure and define profiles Current monitoring structure Network/LAN administrator They ensure that the corporate network is running securely and optimize its performance Current and recommended network structure Windows system administrator Manage Windows domain structure and users Domain administration, hostnames, naming convention structure Future TBSM administrator Person roles that will use the IBM Tivoli Business Systems Manager console What resources are important to them How they want the BSV to be impacted Service Level coordinator Person who manages Service Level Agreements and measure its attainment Understand what and how Service Levels are measured and monitored 46 Business Service Management Best Practices 3.3 Information collection As discussed in 2.1.2, “Implementation considerations” on page 15, the basic steps of Business Service Management information collection are: Performing business process decomposition as detailed in 3.3.1, “Business process decomposition” on page 48 – Identifying the business process – Identifying the components of the business process – Identifying the component relationships Documenting Service Level objectives as discussed in 3.3.2, “Documentation of Service Level objectives” on page 54 Current monitoring environment evaluation s detailed in 3.3.3, “Understanding the current monitoring environment” on page 56 These steps are expanded in the sub-sections. Some of the information given in 3.2, “Sources of information” on page 45 is necessary for the sections mentioned above. This is shown in Figure 3-1. Business Process Decomposition Service Level documentation Current Environment Analysis Business Process Owner Business Process Manager Network administrator Windows Administrator Business Component Owner Tivoli administrator End-user SLA Coordinator CIO / IT Manager System Analyst Application Developer Helpdesk System Operator Figure 3-1 Personnel roles and information collected Now let’s go into more detail about the information that needs to be collected. Chapter 3. Planning for Business Service Management 47 3.3.1 Business process decomposition This stage of planning includes an analysis of business processes and its components. A business process, from an IT perspective, consists of a set of applications that serve a specific business objective. Each application can also be broken down into components made up of IT resources. The decomposition of a business process in this context consists of mapping business processes to the IT resources that affect it. The impact of a certain IT resource also needs to be evaluated to define its role in the overall business process. This mapping is illustrated in Figure 3-2. Business Process: Corporate Email Business Process: e-Business Application: Email Server C Server D Server Z RouterA Hub1 Hub2 Application: Online Store Application: Intranet Server 1 Server 2 Server 3 Server A Server B Server C Email Servers WebServer WebServer Backup Servers Application Server Application Server Network Infrastructure Firewalls Firewalls Network Infrastructure Network Infrastructure Authentication service Authentication service Firewall 1 Firewall 2 RouterA RouterB Hub1 ISP conn LDAP server Policy Server Web Seal Figure 3-2 Business process decomposition As shown in Figure 3-2, the decomposition process breaks down business processes into applications and then into specific components. These components then relate to the IT resources. Some IT resources may be used by multiple business processes; for example, in Figure 3-2, Server C is a WebSphere Application Server and also a Domino® server. The major decomposition steps are: “Identifying the business process” on page 49 “Defining the applications” on page 50 48 Business Service Management Best Practices “Identifying the components of an application” on page 51 “Identifying the component relationships” on page 53 Identifying the business process A business process is a logical group of applications that together deliver a specific function to one or more users. Examples of business processes include: A corporate e-mail system A payroll system An online banking application An e-business application The business process definition contains: High-level description Information about functions provided by the business process Description of the contribution to the business mission Information about impact to the business mission if it becomes unavailable Schematic description of the business process, which typically resides in a separate document. It should describe how each application is integrated to create this business process. Relationship to other business processes. Some of these relationships are straightforward since the business processes have an impact on each other, while others may be abstract because resources are shared. In the Business Service Management implementation, these business processes are the entity that will be managed. The overall business processes build the structure of the enterprise. Each business processes should have specific Service Level objectives to which the IT department should adhere. Thus, the performance of IT is measured by the attainment of these Service Level objectives for each business process. As the managed entity, the list of business processes is used to form the basic measurement and monitoring object. The business processes will be decomposed into IT resources that can effectively monitor them to attain Service Level objectives. In the course of listing the business processes, it may be beneficial to consider the following questions: Have all department or divisions been represented in the business processes? Are there any business processes that cannot be allocated on the organization chart? Chapter 3. Planning for Business Service Management 49 Sometimes you may find a business process that is nmapped to a much different level than a corporate division, but it makes sense to categorize it as a business process since it needs to have a Service Level Agreement for IT usage, such as the Help desk and IT operation staff. After collecting and validating this information from the Business Process Owners or Business Process Managers, the list of these business processes should be filed. A sample is provided in Table 3-2. Table 3-2 Business Process definition table Name Finance Supplier management Web Store Description Manage financial asset Contact goods provider Online ordering Contribution General services Getting in-flow of goods Generate revenue Impact of outage Unable to process ledger Late fulfillment Loss of revenue Structure Account Receivable; Account Payable; General Ledger EDI transaction to suppliers Web server farm Relationship Corporate wide services Functions Note: We will show the decomposition of these three business processes as an example in this section. This is by no means a complete business process list for an enterprise. Defining the applications Now that we have the list of business processes, we can start the decomposition process to understand how IT resources affect business processes. In this stage, typically, you inventorize the application that is used by the business process to perform its function. These applications can then be evaluated further for the detailed components that make them up. The application list contains the following attributes: The purpose of the application The users and/or customers of the application The owner of the application Platform deployed Custodian of these applications 50 Business Service Management Best Practices Current support structure (is the application supported as a whole or are the piece parts supported by different groups?) First in finding the applications that make up a business process, we need to collect information from the Business Process Owner or manager, such as: What are the applications within the business process? Is there any application to be used with a real customer? Which application(s) do you consider critical in the business process? An interview with the business process users will be useful, with question such as: What application are you using to perform your day-to-day work? Further qualification of the applications found needs to be performed. This qualification usually goes to the Business Process Owner and later to the application owner or business component owner. Some questions may also be asked to the system analyst or application developer to get a better idea of how the application is structured and what the components within the application are. Are there business flow diagrams for this application? Are there data flow diagrams for this application? Is there an architecture document for this application? A sample application list is shown in Table 3-3. Table 3-3 Application list Name Business process User Support structure Account Receivable Finance accounting; cashier in-house Account Payable Finance accounting; cashier in-house General Ledger Finance accounting in-house EDI transaction system Supplier Management supplier; purchasing in-house EDI provider Web store application Web store External in-house Identifying the components of an application Each application to be managed comes with a different set of components. We have broken down business processes into the applications that make up the Chapter 3. Planning for Business Service Management 51 business process. We have also collected information about the application structure. We can now identify the components of the application. From the application business flow or data flow, components can be identified. Further discussion with the application developer, system analyst and application owner can be beneficial. Information about the components of an application should include the following: Machine or server name that hosts the application Operating system name and version of the server Application process running; this can be a transaction system, application server or any entity that made up the application Data access information, such as database name and database machine A sample set of components is shown in Table 3-4 Table 3-4 Application components Name Server Operating System Application processes Data access Account Receivable finar.mycorp.com AIX WebSphere AS FIN_AR@findb finweb.mycorp.com Linux RH 7.3 Apache - findb.mycorp.com AIX DB2 UDB Batch - finap.mycorp.com AIX WebSphere AS FIN_AP@findb finweb.mycorp.com Linux RH 7.3 Apache - findb.mycorp.com AIX DB2 UDB Batch - fingl.mycorp.com AIX WebSphere AS FIN_GL@findb finweb.mycorp.com Linux RH 7.3 Apache - findb.mycorp.com AIX DB2 UDB Batch - Account Payable General Ledger 52 Business Service Management Best Practices Name Server Operating System Application processes Data access EDI transaction system spl1.mycorp.com Win2K Server SP4 EDI client SP1@spldb spl2.mycorp.com Win2K Server SP4 In-house application server SP1@spldb ORDER_DB@we bi spldb.mycorp.com Win2K Server SP4 DB2 UDB - webi.mycorp.com AIX 5L™ V5.1 DB2 UDB webs.mycorp.com AIX 5L V5.1 WebSphere AS CUST_DB ORDER_DB PRODUCT_DB (all at webi) webo.mycorp.com AIX 5L V5.1 IBM HTTP Server - webi.mycorp.com AIX 5L V5.1 DB2 UDB Batch - webf1.mycorp.com AIX 4.3.3 Firewall - webf2.mycorp.com AIX 4.3.3 Firewall - Web store application Further information is needed for each IT component to get a detailed understanding of each component and the necessary information for the monitoring evaluation. This information needs to be obtained either from the application owner or the application programmer. The questions are: What are the availability measures of the particular component? What is the mission critical nature of the component? What is the application failure and recovery information? What are the daemons and processes that are essential to the applications? Identifying the component relationships When the components of a business process have been identified, within an application context or not, we need to figure out the relationship between the components. This relationship information is needed to understand the interaction and impact of an outage that may happen for a single component. The relationship is typically derived from a business flow diagram and data flow diagram. Other relationships that represent categorization of resources may also be useful as the management of these resources is typically also categorized in Chapter 3. Planning for Business Service Management 53 certain ways that may be different than the business process boundary. For example: Grouping by function: alll Web servers (for e-commerce, intranet, supply-chain) Grouping by location: all servers in Latin America (for finance, human resources and so on) Grouping by support team: all Windows servers A dependency relationship must also be built. This will allow identification of a potential bottleneck or Achille’s heel of the business process. A table such as Table 3-5 may help to define these relationships. Table 3-5 Business components relationships Business Component Depends On Impacts Comments 3.3.2 Documentation of Service Level objectives When the enterprise already has a Service Level Agreement between the IT producer and IT consumer, these pieces of information are important to get up-front. The Service Level Agreement can be formal (a signed document) or informal. The informal Service Level Agreement is harder to manage because it relies mostly on the expectations of both sides. However, it is obvious that the IT producer will try to maximize the service with a constraint on budget (resources or personnel), while the IT consumer will insist on maximum service to get their work done. A Service Level Agreement defines the following: Definition of the involved parties, IT producer and IT consumer Definition of the Service Level objectives and metrics Definition of the measurement mechanism on the service metric Definition of the data collection and processing of the measurement data Optionally, definition of the constraint boundaries of the defined Service Level In the implementation of Business Service Management, a Service Level Agreement serves as the base for building the solution for business processes. The Service Level Agreements are established for every business process. The IT producer creates monitoring in the context of attaining the Service Level 54 Business Service Management Best Practices objective. Historical information from the monitoring system is collected and summarized into the Service Level measurement database to be compared with the documented objective. Constrain condition need to be included in the measurement. Service level objectives are the primary focus of the Service Level Agreement since they are the negotiable piece of information. Service Level objectives are defined for each critical application in the business process, and sometimes for all applications. An effective Service Level objective must be: Understood and agreed upon by both parties Achievable by controlling and managing service elements and IT resources as needed and consistent with business needs and budget for delivery cost Measurable, so that it can be evaluated and reported Able to represent the overall health of the business process When the enterprise does not have a Service Level Agreement, implementation of Business Service Management can be done from the reactive implementation of the Service Level. The monitoring is implemented without any specific target, the objective being to maximize the availability. Sometimes, the Service Level Agreement is defined later, using the output of the monitoring as the IT producer understands what Service Level it can achieve. Table 3-6 on page 56 shows sample Service Level objectives for our example. Note: Here we put the constraint on the business process level; some put the constraint on the application level. Chapter 3. Planning for Business Service Management 55 Table 3-6 Service level objective Business process Application Metric Objective Measurement Finance Account Receivable ARposting response time Less than 2 secs on backend processing for 95% of transactions Quality of Service monitoring for specified Web intranet transaction Account Payable APposting response time Less than 2 secs on backend processing for 95% of transactions Quality of Service monitoring for specified Web intranet transaction General Ledger GLposting response time Less than 2 secs on backend processing for 95% of transactions Quality of Service monitoring for specified Web intranet transaction Reconcile batch run time Less than 90 minutes for weekly job and less than 120 for monthly job Batch report Constraint: Less than 50 transaction per minute Supplier Manageme nt EDI transaction system Order submission response time Less than 5 seconds for 95% of the transactions Robot simulated transaction to a dummy vendor Constraint: Less than 100 transactions per hour Web store Web store application Search transaction Less than 7 secs on backend processing for 95% of transactions Synthetic transaction measurement with a set of agreed keyword searches Add to basket transaction Less than 3 secs on backend processing for 95% of transactions Synthetic transaction measurement with 1 to 10 items in the basket Check out transaction Less than 10 secs on backend processing for 95% of transactions Synthetic transaction measurement with 10 items in the basket Constraint: Hit rate for less than 20 hit per seconds 3.3.3 Understanding the current monitoring environment The monitoring subsystem needs to be evaluated to be able to support the Business Service Management. From the Business Service Management’s perspective, the monitoring subsystem goals are as follows: 56 Business Service Management Best Practices To know when an outage or a potential outage of a business process component occurs so that the IT personnel can proactively fix the problem or potential problem so it will not disrupt the Service Level. To record the measurement of an IT component metric for Service Level attainment. This monitoring is tightly coupled with automation. A potential outage needs to be fixed as soon as possible to keep Service Level Agreement attainment. This fix can be performed by the system (automatically) using an automation or event processing subsystem or manually. It is not within the scope of this redbook to discuss event automation. The current monitoring environment is compared to the monitoring requirement for the IT components in the business system to find what needs to be monitored that is not already being monitored and what is monitored that does not need to be. Or in other words, we are comparing the current monitoring system against what is required for accurate and efficient Business Service Management. We need to inventorize the monitors and match the result against the monitoring requirement for the IT resources for the business process. Such a listing of monitoring inventory should include the following: What is currently monitored? Are all components that make up the applications in business systems monitored? Are there any monitors that do not correspond to a component? The monitoring list may include the following items: – – – – – Application or service availability System availability End-to-end transactions response time Network components monitoring Log files monitoring What type of monitoring is deployed? – Unsatisfactory only: monitoring for unsatisfactory condition to alert the operator. This type of monitoring is very hard to integrate in an automated Business Service Management solution. – Unsatisfactory/Satisfactory: when resources get back to a satisfactory level, an additional event is generated to notify the management system that the resource has recovered. It need to be ensured that all pairs of events are generated and can be correlated. – Levels of performance: this kind of monitoring deals with different levels of unsatisfactory performance. Chapter 3. Planning for Business Service Management 57 – Heartbeats: keeps monitoring subsystems aware of resources that are satisfactory; when a heartbeat fails to come, it may be that the resource is becoming unavailable or the monitoring subsystem is unavailable. What information is provided in the event? For each monitoring tool, we need to evaluate the event structure, such as: – Event format (SNMP, TEC event or other) – Severity information levels – Sender identifier and granularity, by hostname, process, application instance and so on – Additional descriptive information formats Is there any metric collection mechanism? What is the data format: text file, binary file, RDBMS? Monitoring can be performed by an IBM/Tivoli software or by a third party monitoring tool. We will discuss these requirements in the following sections. Tivoli monitoring solution consideration The Tivoli monitoring solution is based on either Tivoli Distributed Monitoring product or IBM Tivoli Monitoring product families. Additionally, network monitoring is based on IBM Tivoli NetView and IBM Tivoli Switch Analyzer. Most of these products are based on Tivoli Management Framework. Additional information of the Tivoli management environment is recommended, such as: What type of Tivoli Infrastructure is there? Is it a single TMR or multiple TMRs? Are they configured as hub and spoke; multiple separate TMRs; or fully interconnected TMRs? How are monitoring profiles defined? How is the Profile Manager hierarchy defined? Are profiles created by a certain grouping (by system; application; specific server)? Are multiple profiles pushed to a server to represent the different functions of that server? Are Tivoli Tasks implemented? For multiple TMRs, where are the Task Libraries defined? Is there automation in IBM Tivoli Enterprise Console? What events trigger automation? What is the current IBM Tivoli Enterprise Console event load? Who owns the monitoring/who can change it if the need arises? Are all TMR functions controlled by a single group? How is the separation of duty achieved? 58 Business Service Management Best Practices The information in Table 3-7 lists the Tivoli event management applications that can be present in your environment. Typically, the events generated by these applications may be forwarded directly to IBM Tivoli Enterprise Console or can be processed using the Common Listener interface. It is recommended that you use IBM Tivoli Enterprise Console for forwarding since it is much more flexible and versatile. Table 3-7 Tivoli event management application checklist Product Version Event to TEC Comments Tivoli Framework N/A Provides number of test and production TMRs Describes setup (for example: hub-spoke) IBM Tivoli Enterprise Console N/A Provides number of test and production IBM Tivoli Enterprise Consoles and describe setup (such as standalone or hub-spoke) Tivoli Distributed Monitoring (DM) These events must be forwarded to IBM Tivoli Enterprise Console. IBM Tivoli Monitoring (ITM) Resources can be discovered and monitored through the Common Listener without requiring IBM Tivoli Enterprise Console but it is recommended that monitoring events be forwarded to IBM Tivoli Business Systems Manager through IBM Tivoli Enterprise Console. IBM Tivoli NetView Resources can be discovered and monitored through the Common Listener without requiring IBM Tivoli Enterprise Console but it is recommended that monitoring events be forwarded to IBM Tivoli Business Systems Manager through IBM Tivoli Enterprise Console. Tivoli Workload Scheduler (TWS) This does not include TWS on the mainframe. Resources are discovered using Common Listener Tivoli Manager for * Discuss each separate Tivoli Manager for products in its own line IBM Tivoli Monitoring for * Discuss each separate IBM Tivoli Monitoring for products in its own line The Tivoli Manager for * and IBM Tivoli Monitoring for * products need to be individually specified on their own rows. They identify the additional canned monitor supplied by IBM Tivoli. Chapter 3. Planning for Business Service Management 59 Non-Tivoli monitoring applications Non-Tivoli monitoring and event generator applications to be integrated with a Tivoli solution for Business Service Management need to be able to interact with the Tivoli solution. The following needs to be true: Event monitoring must interface using either of these two methods: – Events are being sent to IBM Tivoli Enterprise Console. – There is a Common Listener feed. Historical information for the metric must be stored. The information in Table 3-8 can assist in identifying this and other required setups for non-Tivoli monitoring applications. Add additional non-Tivoli products that are used to manage the customer distributed environment to the table as appropriate. Table 3-8 Non-Tivoli event management applications checklist Product Version Event to TEC Comments BMC PATROL Resources can be discovered and monitored through the Common Listener without requiring IBM Tivoli Enterprise Console but it is recommended that monitoring events be forwarded to IBM Tivoli Business Systems Manager through IBM Tivoli Enterprise Console. Computer Associates Unicenter TNG List resource types monitored. Resources can be discovered and monitored through the Common Listener without requiring IBM Tivoli Enterprise Console but it is recommended that monitoring events be forwarded to IBM Tivoli Business Systems Manager through IBM Tivoli Enterprise Console. NetIQ AppManager Resources can be discovered and monitored through the Common Listener without requiring IBM Tivoli Enterprise Console but it is recommended that monitoring events be forwarded to IBM Tivoli Business Systems Manager through IBM Tivoli Enterprise Console. HP OpenView These events must be forward to IBM Tivoli Enterprise Console prior to the start of the project. Getting these events to IBM Tivoli Enterprise Console is outside the scope of this proposed project. 60 Business Service Management Best Practices Product Version Event to TEC Candle Command Center Comments These events must be forward to IBM Tivoli Enterprise Console prior to the start of the project. Getting these events to IBM Tivoli Enterprise Console is outside the scope of this proposed project. 3.4 Designing the solution When most of the information collection has been performed, the next planning phase is the solution design. The design uses the information collected from 3.3, “Information collection” on page 47 and continuously interacts with the involved parties as discussed in 3.2, “Sources of information” on page 45. Restriction: The design discussed here only involves a IBM Tivoli based solution. A different configuration and structure may be needed to accommodate non-Tivoli monitoring tools. A Business Service Management solution design starts with the decomposition of business processes and the Service Level objectives. The individual breakdown of IT components that needs to be monitored to guarantee Service Level attainment provides the base on the overall solution design. There are several design sections detailing the implementation of Business Service Management. Those are: 3.4.1, “Solution structure” on page 62 provides the big picture of what software product can be used in the solution. 3.4.2, “Hardware and software configuration” on page 63 lists a detailed view of servers and required software to implement the functions; specific considerations are provided for major elements. 3.4.3, “Monitoring standard and required modification” on page 68 discusses the creation of a monitoring standard based on the information input. 3.4.4, “IBM TBSM object type selection” on page 69 provides some considerations on deciding what objects needs to be defined in IBM Tivoli Business Systems Manager and how these objects will be monitored. 3.4.5, “Business System View design” on page 74 discusses the translation of the business process decomposition into impact monitoring using the Business System View. Chapter 3. Planning for Business Service Management 61 3.4.6, “Data collection design” on page 80 3.4.7, “Service Level management design” on page 82 3.4.1 Solution structure The software structure for an IBM Tivoli solution is shown in Figure 3-3. IBM Tivoli Monitoring Operating System Monitors ITM for Database ITM for Messaging ITM for Trans. Performance ITM for Web Infrastructure ITM for Application ITM for Business Integration Application, Middleware, Database and Performance Monitors Network Monitors IBM Tivoli NetView Tivoli Data Warehouse Batch Management IBM Tivoli Enterprise Console IBM Tivoli Service Level Advisor IBM Tivoli Business Systems Manager IBM Tivoli Workload Scheduler Figure 3-3 Solution structure As shown in Figure 3-3, the solution includes the following components: Operating system, application, middleware, database and response time monitoring using the IBM Tivoli Monitoring product family Network monitoring using IBM Tivoli NetView Batch management using IBM Tivoli Workload Scheduler Automation and initial correlation through IBM Tivoli Enterprise Console Historical data collection through Tivoli Data Warehouse Real-time business system management using IBM Tivoli Business Systems Manager Service level management using IBM Tivoli Service Level Advisor 62 Business Service Management Best Practices Although the number of software elements to be implemented seems daunting, it should be understood that implementation should be done in stages. It is true, though, that the initial implementation is the longest and most complicated since it encompasses the most software to be implemented and also the largest changes in the operation paradigm. 3.4.2 Hardware and software configuration The complete hardware configuration environment is shown in Figure 3-4. It shows one of the possible configurations. Depending on system load and bandwidth constraint, it may require more or fewer machines. Tivoli Management Region Gateways TWS Domain Manager NetView Tivoli Internet Management TMR Server RIM host TEC Server Web Services Courier TIMS Server QoS endpoint STI endpoints Tivoli Data Warehouse IBM Tivoli Service Level Advisors TDW Database TDW Control TSLA Database TSLA Admin Server Center Server Server IBM Tivoli Business Systems Manager TBSM Console & TBSM Database Propagation Server Server TSLA Reporting Server Figure 3-4 Overall hardware solution Table 3-9 on page 64 discusses the role of each machine in Figure 3-4 for the solution and the requirement. Chapter 3. Planning for Business Service Management 63 Table 3-9 Software configuration list Machine role Suggested OS Software list TMR Server UNIX based Tivoli Management Framework 4.1 IBM Tivoli Monitoring 5.1.1 IBM Tivoli Monitoring Component Services 5.1 IBM Tivoli Monitoring for * Control the overall operation of the Tivoli Management Framework. This example indicates a single TMR solution. Depending on your structure requirement, you may need multiple TMRs in your environment. A TMR can typically manage several hundreds thousands endpoints. Gateways Windows or UNIX based Tivoli Management Framework 4.1 IBM Tivoli Monitoring 5.1.1 IBM Tivoli Monitoring Component Services 5.1 IBM Tivoli Monitoring for * These are endpoint communication gateways. The operations to the endpoints are managed by these gateways. You need a gateway for up to 1000 endpoints. You want the communication from the endpoints to a gateway to be secure. Each gateway will also be responsible for uploading data through Common Listener and the data warehouse for the endpoints for which it responsible. RIM host UNIX based Tivoli Management Framework 4.1 DB2 Universal Database 7.1 The RIM host and database server for the Framework environment will host the data for IBM Tivoli Enterprise Console and historical data for IBM Tivoli Monitoring. It is also a good place to put MDist distribution status database. As a RIM host, it must be a managed node. It contains the DB2 database server code. TEC Server UNIX based Tivoli Management Framework 4.1 IBM Tivoli Enterprise Console 3.8 IBM Tivoli Business Systems Manager distributed edition 2.1.1 This server performs event analysis and correlation. There may only be a single Event Server in a TMR. If this is an existing Tivoli installation, you may want to evaluate the current Event Server load and estimate whether you need another TEC server. NetView server UNIX based Tivoli Management Framework 4.1 IBM Tivoli NetView 7.1.3 IBM Tivoli NetView monitors and manages network communication and devices. It alerts the operator of network outages, such as a failing router or hub. 64 Business Service Management Best Practices Machine role Suggested OS Software list TWS Domain Manager UNIX based Tivoli Management Framework 4.1 Tivoli Job Scheduling Services 8.2 TWS connector 8.2 IBM Tivoli Workload Scheduler 8.2 IBM Tivoli Workload Scheduler manages, schedules and monitors batch jobs. The domain manager performs the primary control over the scheduling network. Typically, you would use multiple domain manager to enable local job dependency resolution in each domain. TIMS server UNIX based IBM Tivoli Monitoring for Transaction Performance 5.2: Internet Management Server The Tivoli Internet Management Server control Internet management portion of IBM Tivoli Monitoring for Transaction Performance. The admin function is based on a Web browser interface. QoS endpoint Windows IBM Tivoli Monitoring for Transaction Performance 5.2: QoS Endpoint The Quality of Server endpoint performs response time measurement of incoming traffic to a Web server. STI endpoint Windows IBM Tivoli Monitoring for Transaction Performance 5.2: STI endpoint STI (Synthetic Transaction Investigator) investigates and performs Web transaction to ensure the transaction is available and monitors the response time. TBSM database server Windows 2000 Advanced Server Windows 2000 Resource Kit Windows Support Tools MKS Toolkit V8 Microsoft SQL Server 2000 IBM TBSM Base Services IBM Tivoli Business Systems Manager central component using Microsoft SQL Server as the data repository. It requires a very powerful Windows Intel machine such as dual Pentium® 4 - 2 GHz with 2 GB of RAM. Dual network adapters are also recommended. TBSM console and propagation server Windows 2000 Advanced Server Windows 2000 Resource Kit Windows Support Tools MKS Toolkit V8 IBM TBSM Base Services IBM Tivoli Business Systems Manager console and propagation server. It requires a powerful Windows intel machine such as a single Pentium 4 - 2 GHz with 1 GB of RAM. Dual network adapters are also recommended. Chapter 3. Planning for Business Service Management 65 Machine role Suggested OS Software list TDW database server AIX 5L on 375 MHz DB2 Universal Database Server v7.1 FixPack 5 IBM Console Presentation Services Tivoli Data Warehouse enablement packs This machine hosts the Central Data warehouse (TWH_CDW) database, star schema (TWH_MART) database as well as the metadata (TWH_MD) database that contains the ETL information. This is a mostly read-only database for reporting; update happens only during scheduled ETL runs. At least 1 GB of memory and 100 GB of disk are recommended. TDW Control Server Windows 2000 Server DB2 Universal Database v7.1 FixPack 5 Administrative Client This machine serves as the administration console for Tivoli Data Warehouse. It runs the Java interface for DB2 Warehouse Control Center. It requires 1 GB of memory. TSLA database server AIX 5L on 375 MHz TSLA admin server Windows or UNIX based DB2 Universal Database Server v7.1 FixPack 5 This machine hosts the DYK_CAT and DYK_DM databases for IBM Tivoli Service Level Advisor. Depending on the load of the system, this machine can be merged with the TDW database server as they both are primarily read-only except for scheduled ETL runs. At least 1 GB of memory and 100 GB of disk are recommended. DB2 Universal Database v7.1 FixPack 5 Client IBM Tivoli Service Level Advisor 1.2 Server This machine runs the administration server for IBM Tivoli Service Level Advisor. Administrator connects to this machine using a Web browser to administer SLA, metrics, offering and so on. TSLA reporting Server Windows or UNIX based DB2 Universal Database v7.1 FixPack 5 Client IBM Console Presentation Services IBM Tivoli Service Level Advisor 1.2 Task Drivers IBM Tivoli Service Level Advisor 1.2 Reports This machine monitors Service Level attainment from the data in the database against the expected Service Level threshold and generates reports using the reporting interface. Refer to the documentation in “Related publications” on page 165 for sizing information and installation procedures for the software mentioned in Table 3-9 on page 64. Tivoli Management Framework considerations There may be some modification to the structure of the Tivoli Management Framework for the Business Service Management implementation. The following needs to be considered: 66 Business Service Management Best Practices Gateway placement: each gateway is responsible for inserting monitoring data in the Tivoli Data Warehouse, and if you are using the Common Listener, the gateway sends status information to the IBM Tivoli Business Systems Manager server. IBM Tivoli Enterprise Console’s Event Server structure, whether there is any forwarding rule to collect events from various areas in the enterprise or there is only one central Event Server. If events are forwarded from various Event Servers, the event analysis needs to be performed from all the Event Servers, not the central Event Server, although it is most likely that IBM Tivoli Business Systems Manager will get the events from the central Event Server. Monitoring profiles and Profile Manager structure. The monitors need to be inventorized and listed so that they are easy to analyze. The analysis of the Tivoli Management Framework structure may prove the need for an additional server, such as RIM data collection servers for collecting historical data or additional Event Servers should the load of the current Event Server not prove adequate. IBM Tivoli Business Systems Manager considerations The IBM Tivoli Business Systems Manager implementation in the distributed area requires two physical servers. These servers should be defined using static IP addresses and reside in the same Windows domain. It is recommended that you have these servers connected in a full-duplex redundant fast Ethernet. We will now list some important questions for designing the configuration for IBM Tivoli Business Systems Manager: What is the estimated number of events that the customer will be sending to IBM Tivoli Business Systems Manager? What is the break down of those events that go through the IBM Tivoli Enterprise Console? Will firewalls exist between IBM Tivoli Business Systems Manager servers and any of the management applications that will be sending or receiving events to or from it? Does the facility to execute Tivoli Tasks or open URLs from IBM Tivoli Business Systems Manager need to be configured? Will IBM Tivoli Business Systems Manager be integrated with a Problem management application? Will IBM Tivoli Business Systems Manager be integrated with a Change Management application? Will a failover environment for IBM Tivoli Business Systems Manager be configured? Chapter 3. Planning for Business Service Management 67 Will a history server for archival information and reporting be used in IBM Tivoli Business Systems Manager? Tivoli Data Warehouse and IBM Tivoli Service Level Advisor It is not recommended that you merge all processing into one machine. Most of the processes use Java heavily, therefore the memory requirement is quite high. The recommended configuration consists of: IBM Tivoli Service Level Advisor server that hosts administration of the Service Level processing. IBM Tivoli Service Level Advisor reporting server that reports the Service Level attainment. Tivoli Data Warehouse control server this is the management server for the data warehouse. Tivoli Data Warehouse database server and IBM Tivoli Service Level Advisor database server; these servers may be separate or merged since the processing is mostly scheduled for running the ETL programs. 3.4.3 Monitoring standard and required modification Based on the monitoring input that has been collected, a monitoring scheme standard needs to be developed. This monitoring scheme standard is beneficial in re-aligning existing monitors and in the creation of new monitors. Our environment mainly uses the IBM Tivoli Monitoring product family and IBM Tivoli NetView for the monitoring. Events are pooled through IBM Tivoli Enterprise Console instead of using the Common listener interface. If the events come from a non-Tivoli application, events can be received through the Common Listener. One must also understand the change management procedures. Not all monitors might be in place, or they might be in place, but not sending enough information to the IBM Tivoli Enterprise Console. Monitors need to provide the following: Ability to log and collect historical data when required. This collection should have a minimal impact on the overall system and monitoring application’s performance. Each alert event must have a clearing event associated with it. If the clearing event cannot be produced, a mechanism should be in place to synchronize the object states. Event management policies should be in place: how long are events kept, do archives exist, and so on. 68 Business Service Management Best Practices Event automation, correlation and forwarding rules need to be documented as appropriate One step of the planning is to collect all the generated events and historical metrics, either from a log file or a database table, and try to match the rules above with the current settings to see the discrepancy. Here are some typical situations: A non-Tivoli product does not have interface to the data warehouse. Most products do collect data into a historical database for analysis. An interface for these monitoring products needs to be developed and coded so that data feed from this history can be collected into the Tivoli Data Warehouse. Tivoli Distributed Monitoring is typically not set to collect historical information. This can be enabled individually in the Sentry profile setting. Furthermore, an alert resolution is not provided by default; a specific resolution (HARMLESS event) must be sent when the metric goes below threshold. Monitoring lapses with Tivoli Distributed Monitoring are easy to deal with by clearing or restarting the monitoring engine. This will re-send all valid alerts or resolutions. IBM Tivoli Monitoring implementation provides an automatic clearing event called TMW_Clearing with a reference to the actual alert. This is very useful in matching events. Historical collection for IBM Tivoli Monitoring needs to be enabled manually in the Tmw2k profile dialog. Resynchronizing the status with the IBM Tivoli Monitoring resources needs to be developed by the installation. When the monitoring engine restarts, the resolution is not automatically sent (since it does not remember previous states); only alerts will be sent when the threshold is exceeded again. 3.4.4 IBM TBSM object type selection From IBM Tivoli Business Systems Manager, object types or classes need to be defined and event feeds enabled for the class. This decision is related to: Types of interface that will be used to feed IBM Tivoli Business Systems Manager, whether events will come from IBM Tivoli Enterprise Console or from Common Listener. See “Interface selection” on page 70. The object type selection; basically, there are two types of dynamic objects that can be used: the DM object type and Generic object type. See “Object type selection” on page 71. Chapter 3. Planning for Business Service Management 69 Granularity of the object representation, having the whole database instance level, the database level, the tablespace level or the table level. See “Object class granularity” on page 73. All these decisions are influenced by the business process decomposition result and performance trade-offs that should be inspected with care. The following section discusses these selections in detail. Interface selection There are two ways to bring events from the distributed monitoring environment into IBM Tivoli Business Systems Manager: the Common Listener or the Agent Listener. The Common Listener is a generic interface; it can send bulk discovery, delta discovery and event information to IBM Tivoli Business Systems Manager as needed. This interface is coded as in the monitoring subsystem to send specific information to IBM Tivoli Business Systems Manager as specified by the interface. The Agent Listener receives events from IBM Tivoli Enterprise Console through the Event Enablement subsystem. These events are processed by the IBM Tivoli Enterprise Console engine before being sent to the Agent listener. Table 3-10 lists the considerations regarding the IBM Tivoli Business Systems Manager distributed interface selections. Advantages Table 3-10 IBM Tivoli Business Systems Manager distributed interface 70 through IBM Tivoli Enterprise Console through the Common Listener Event correlation in IBM Tivoli Enterprise Console Built-in bulk and delta discovery for object instance creation Lots of field experience means higher reliability No IBM Tivoli Enterprise Console rule work You can handle ITM events with either the DM Classic EE binary ihstzIBM Tivoli Enterprise Console, or the generic EE binary ihsttIBM Tivoli Enterprise Console. Note that ihsttIBM Tivoli Enterprise Console is probably best for new deployments. Clearing events handled automatically Business Service Management Best Practices Event rate higher at IBM Tivoli Business Systems Manager than with IBM Tivoli Enterprise Console -> IBM Tivoli Business Systems Manager Disadvantages Initial discovery possible only by running scripts. Discovered objects don't have an endpoint name in the label, so when you drag them into a BS you don't know which one is which. Requires rules to forward clearing events Limited field experience means lower reliability Event rate lower at IBM Tivoli Business Systems Manager than with Common Listener Tip: Most implementation is currently done using the IBM Tivoli Enterprise Console feed because it is more flexible to accommodate changes and customization based on the customer’s requirements. You can map a IBM Tivoli Enterprise Console event to a Common Listener discovered object because the SQL stored procedure that processes IBM Tivoli Enterprise Console events will pass the event to the Common Listener if it doesn't recognize the object class. The challenge for Common Listener discovered objects is that you need to know the instance ID used when the object was discovered. This is very important if you mix IBM Tivoli Enterprise Console events with Common Listener-discovered objects; be very careful not to duplicate through IBM Tivoli Enterprise Console what you are going through the Common Listener feed. An example may be an IBM Tivoli NetView implementation that met with duplicate status and timing problems; the status may never be right. As long as what is coming through IBM Tivoli Enterprise Console are completely different events, you should be fine. Object type selection In the implementation of IBM Tivoli Business Systems Manager, new objects need to be defined for custom interfaces through IBM Tivoli Enterprise Console. These custom interfaces typically fall into a Generic object type of DM object type as discussed in 2.3.4, “IBM Tivoli Business Systems Manager distributed object types” on page 27. Each object type can have a set of automated tasks or URLs associated with it. These tasks and URLs are typically used to perform further investigation and problem resolution. The URLs are easy to define since they are static URLs. Automated tasks are defined in a Tivoli Management Framework’s Task Libraries. These tasks must be executed at a target endpoint or managed node. The Task Library and the execution target must be known in the local Tivoli Management Region (TMR) where the Event Server that forwards the discovery event resides or be registered using a wupdate command from the remote TMR. Chapter 3. Planning for Business Service Management 71 If necessary, the IBM Tivoli Business Systems Manager’s tgmtaskconfig command can be used to redirect task execution requests to alternate task servers. This tgmtaskconfig command is effective for each IBM Tivoli Enterprise Console basis. The target endpoint name is retrieved from the hostname slot of the event. Table 3-11 shows some considerations for selecting the object class. Table 3-11 Object class selection consideration DM Object class Generic Object class One object per server limit Enforced Does not exist Clearing event Must be defined in the profile of the DM monitor or automatic for ITM monitor Must be coded using TEC rules that correlate events Status discovery Only from a DM event, Generic events that are forwarded to a DM object type will not cause an instance icon to appear on the IBM Tivoli Business Systems Manager console. Any event forwarded using the Generic event exit will trigger discovery. TEC integration DM or ITM monitor will provide the necessary information on identifying the object type and instance. Generic events must have information in them to be able to uniquely identify an object type and instance. If necessary, a generic event source may need to be modified. To ensure that generic events that map to a DM object type will always appear on the IBM Tivoli Business Systems Manager console, there are a few techniques that can be used: For each generic event that IBM Tivoli Enterprise Console receives, the IBM Tivoli Enterprise Console can forward two events to the IBM Tivoli Business Systems Manager. The first event will be a DM event to create the instance icon if it is not already there; the second event will be the generic event that will now appear on the console. If the list of all possible instances is known, a script can be created to draw the initial view on the IBM Tivoli Business Systems Manager console. Subsequently, when the generic event arrives at the IBM Tivoli Enterprise Console, the instance icon that it should map to would already be drawn. Note that when new servers enter the IBM Tivoli Business Systems Manager managed environment, initial instances will need to be created for them. 72 Business Service Management Best Practices An alternative to creating a script is to add a heartbeat monitor to each DM profile related to IBM Tivoli Business Systems Manager. This heartbeat monitor would ensure that the initial instance is drawn. When the event source can be customized, it may be beneficial to add slots such as TBSM_class and TBSM_object_name slots so the object mapping can be made much simpler. Object class granularity An object type should represent a machine or an application, with, possibly, multiple event sources mapping to that object type. The object type can be defined as granular if you want. Typically, an object type that represents a single monitor is discouraged. For example, let’s say you are monitoring a relational database management system. What are the object types that you can make? You can make a single database object per server; this means that all kinds of events from the database monitoring will be fed into that object. You can make an object type for each different instance of the database. The instances are more granular than just a database system. This allows differentiation of each database instance. Typically, there are one to three instances defined in a machine. You can define additional object types for the content of each instance such as for each tablespace and for the bufferpools and other pools within the database instance that can be monitored. It will be easier to see which object is the cause of the outage when an event is received, but the downside is that there may be too many objects on the screen for an operator to manage; a typical database instance may have hundreds of tablespaces. Events and monitors overhead may be too much to monitor at this level of detail. An object type may have multiple event sources mapping to the object type. This will help to narrow down the number of object types to be created. For example, a Server object type may be getting events from an IBM Tivoli Monitoring monitor, from IBM Tivoli NetView and a log file adapter on that machine. Another example is a Web Server getting events from IBM Tivoli Monitoring monitor, from IBM Tivoli NetView, a log file adapter monitoring access.log file and an IBM Tivoli Monitoring for Transaction Performance Site Investigator. In IBM Tivoli Business Systems Manager, these events can be viewed as distinct events from the Event Viewer by clicking View -> Event instead of the Property page; the Property page retrieves much more information, so it is is slower and has more of an impact on the system. For each object type, custom modifications should be listed, such as tasks and URLs that should be defined. Table 3-12 on page 74 is a sample table that is Chapter 3. Planning for Business Service Management 73 useful to fill out after deciding on IBM Tivoli Business Systems Manager object types. The table will help summarize the objects and its event sources. Table 3-12 Lists of IBM Tivoli Business Systems Manager object types Object Type Event Source Association of event to object Class ID Tivoli Task Libraries URL(s) 3.4.5 Business System View design The design of the Business System View relates to translating the business process decomposition into a usable view. The view should show the correlated status of the business entity (business processes or applications) as a Business System View object affected by real IT objects that it contains with respect to their priority. The Business System Views also allows the enterprise to know what caused a problem and see which business processes are impacted. A Business System View represents a collection of IT objects and components. It should be designed and built by considering the business requirements and operational needs. In this way, the Business System Views can quickly alert an operator of the impact of a specific component outage with respect to the business processes as a whole. These components can reside on mainframes, distributed systems, or both. They can span all technologies and all organizations of a company. This redbook deals with a distributed application, however, the concepts can also be applied to a mainframe implementation. The primary input of the Business System View structure should come from the business process decomposition information. Most of the business processes and the critical applications identified previously are likely candidates to be a Business Systems View. These business processes and critical applications represent a valid business entity that is comprised of IT components. The status of the Business System View represents the operational status of the business process or critical application. Any indication of outage may compromise the Service Level attainment of the business entity, and therefore needs to be resolved. Additional Business System View requirements come from the future operator of the IBM Tivoli Business Systems Manager console. They need to be able to 74 Business Service Management Best Practices quickly pinpoint problems or potential outages quickly and effectively within the vast number of devices and IT components that they are responsible for. These requirements may indicate the need for specialized Business System Views that allow resource assignment and fast action on outage or potential outage by alerting the correct personnel. You need to ensure that all Business System Views have a potential user (operator) and all users (operators) have all the Business System Views they need. This Business Systems View information should be documented in a spreadsheet. Information that is needed in the spreadsheet should include: Business System View name and description Business System View purpose Business System View user (stake holder) Members information: – Component type – Selection rule – Relative priority Alerts and events that affect each members A good Business System View should represent the business entity correctly and effectively. For the stake holder, an IBM Tivoli Business Systems Manager Business System View should accurately display the logical cause/effect relationship between components. Ask yourself whether the following questions have been answered: Does the Business System View correctly show the effect of an outage? Does the Business System View assist one in quickly finding the source of the problem? Does the Business System View quickly identify the impact of the outage to other business entities? Business System Views A business system is a group of diverse but interdependent applications and other system resources that interact to accomplish specific business functions. A business system can contain applications or other resources that run on a variety of platforms, including host, distributed, and network environments. For example, a banking business system designed to support transactions over the Web typically includes a Web server running outside the company’s intranet that is connected directly to the Internet and a firewall that provides secure connectivity to a machine running a custom business component; an example might be loan processing. The loan processing business component usually runs on a distributed platform and interfaces to business components running on a host computer. The host handles all bank transactions. This business system Chapter 3. Planning for Business Service Management 75 presents challenges to a system manager because it crosses the typically isolated environments of the host and distributed systems. Another example of a business system is an e-mail system. E-mail business systems include all instances of e-mail business components that are being used in your network. You might have a mix of Lotus® Notes® servers and clients, POP mail or Microsoft Exchange servers and clients, and other e-mail business components. An e-mail business system includes definitions that can tell whether each of its entities is a server, a client, or both. It also includes definitions of the monitors that collect status information for each component in the business system, as well as definitions of the relationships between the components in the business system. Business System View structure The key to designing the Business System Views is to understand the business process structure and the availability of the monitors that will be needed. From the previous planning stages, we should have the following information: Business process lists Critical applications for business processes IT components for each application that reflect the health of the application Monitors for the IT components It is beneficial to document all the above information in a spreadsheet so that they are easily referred to and understood. There should be a documented method on how the relationship of the IT components should be shown to a Business System View. There are several ways that the components can be shown in a Business System View. Let’s use an example to illustrate this. A Web-based application contains the following: BSM2 and BSM8 are the servers; these are where the HTTP Server and WebSphere Application Server reside. IBMTIV2 is the database server; this is where the DB2 database server runs. The IT components that affect Web application BSV are: 76 BSM2 HTTP Server BSM8 HTTP Server BSM2 WebSphere Application Server BSM8 WebSphere Application Server IBMTIV2 DB2 database BSM2 Operating System health BSM8 Operating System health Business Service Management Best Practices IBMTIV2 Operating System health BSM2 Network interface BSM8 Network interface IBMTIV2 Network interface Router1 router The following shows how Business System Views can be built. The possible views are shown in Figure 3-5. Web application Web application BSM2 HTTP Server BSM8 HTTP Server BSM2 WebSphere BSM8 WebSphere IBMTIV2 DB2 BSM2 Network card BSM8 Network card IBMTIV2 Network card BSM2 OS Web application BSM2 Network card BSM2 OS BSM2 HTTP Server BSM2 WebSphere BSM8 Network card BSM8 OS BSM8 HTTP Server BSM8 WebSphere IBMTIV2 Network card IBMTIV2 OS BSM8 OS IBMTIV2 DB2 IBMTIV2 OS BSM2 HTTP Server BSM2 Network card BSM2 OS BSM8 HTTP Server BSM8 Network card BSM8 OS BSM2 WebSphere BSM2 Network card BSM2 OS BSM8 WebSphere BSM8 Network card BSM8 OS IBMTIV2 DB2 IBMTIV2 Network card IBMTIV2 OS Web application BSM2 HTTP Server BSM8 HTTP Server BSM2 WebSphere BSM8 WebSphere IBMTIV2 DB2 Networking BSM2 Network card BSM8 Network card IBMTIV2 Network card Operating Systems BSM2 OS BSM8 OS IBMTIV2 OS No Hierarchy Original Hierarchy Inverted Hierarchy Grouped Resources Figure 3-5 Possible Business System Views Let’s discuss the Business System Views structure shown in Figure 3-5. No hierarchy: using this method, all resources that the BSV depends on are laid out flat under the BSV object. Original hierarchy: using this method, all resources are laid out under the BSV according to its physical tree hierarchy. The objects that affect the BSV directly are listed as the leaf node of the BSV tree. Inverted hierarchy: using this method, all resources that a BSV depends on are listed as the first-level BSV, and each resource that indirectly affects the BSV is placed under the resource it affects. This method provides the best cause/effect relationship of the objects. Grouped resources: using this method, all resources that a BSV depends on are made first-level dependants of the BSV. Other resources on which the BSV is not directly dependent are grouped in one or more sub-BSVs. Chapter 3. Planning for Business Service Management 77 Table 3-13 shows the pros and cons of each method. The following criteria were evaluated: Logical cause/effect relationship of the object: does the causal relationship of the objects in the view generate the correct propagation behavior? For example, if the host cannot be pinged, then it causes the server application to be unavailable. Ease of identifying a problem: determine whether a problem is directly caused by the BSV component or by something else the component is dependent on. This can be seen from a tree view or a hyperview. Ease of maintenance: as with automatic placement of an object under the BSV view, automatic instance filtering can only be implemented for objects under BSV folder objects, not a BSV logical object from a physical object. Effect on the business impact view: we call this a fan effect because the business impact view looks like a fan with many parents for an object; thus, we cannot really perform a business impact analysis. Based on Table 3-13, we decided to use the separate BSV design for implementing our BSV. Table 3-13 Pro and cons of BSVs creation Type Cause effect Identification Maintenance Business impact No hierarchy No No Automated Not affected Original hierarchy Some Yes No Not affected Inverted hierarchy Yes Yes No Great impact Separate BSV Some Yes Automated Not affected There are two methods for creating Business Systems Views: Drag and drop – This method involves dragging objects from the All Resources tree and dropping them into a Business Systems View. Automated (dynamic) – Objects registered using the IBM Tivoli Business Systems Manager discovery process can be included in a dynamically created Business Systems View. 78 Business Service Management Best Practices Important: The two methods for creating Business Systems Views cannot be used in conjunction to create a single Business Systems View. You need to choose which method to use. When naming convention do exist, it is preferable to use the Automated method. Additional considerations Additional considerations for the Business System View design are as follows: Naming convention: a key aspect of defining an automated business system. An automated business system allows association between discovered objects in IBM Tivoli Business Systems Manager to Business System Views. This will allow low maintenance of the Business System View creation. Priority determination: each object in the Business System View has a priority to determine how much effect its outage has on the Business System View’s status. This status needs to be evaluated and determined carefully to allow the Business System View status to reflect an actual business process or application status. Change management for Business System Views operation changes needs to be established. What happens if a machine is reallocated to a different function, or maybe additional capacity is added or removed for a certain on demand function? – Maintenance considerations: • • • Components that go away Components that change function Components that are added – How do you know about changes in the infrastructure that impact the application? – How do you know about changes to the application? Reporting – Who will be the target(s) for the view(s)/report(s)? – How do reports need to be made available, and how often? – Is reporting required for every view? Build small reusable business systems. Limit the number of resources and nested business systems. Limit to 10 000 within each business system. Considerations for operators: IBM Tivoli Business Systems Manager operators need to be listed and categorized. You need to decide the roles they will be assuming in the IBM Chapter 3. Planning for Business Service Management 79 Tivoli Business Systems Manager structure. There are four roles in IBM Tivoli Business Systems Manager: – – – – Super Administrator Administrator Operator Restricted Operator Additionally, for each group of operators, you need to gather their usage requirements, such as: – What are the relevant Business System Views? – What are the required actions that they will perform? – Do all the components they are responsible for belong in the Business System Views that are relevant? Additional Business System Views may be needed for certain operators. 3.4.6 Data collection design The historical monitoring design for the Business Service Management implementation relates to the implementation of IBM Tivoli Service Level Advisor with its underlying product, Tivoli Data Warehouse. Data source and ETL planning For each data source, Tivoli Data Warehouse loads the data using an ETL (Extract-Transform-Load) program. These are typically called Source ETLs. Measurement data sources need to be identified and listed. Appropriate ETL programs need to be installed or developed for non-standard monitoring tools. Data is initially loaded into the Central Data Warehouse (CDW); this needs to be completed before the second batch of ETL needs to be dealt with. The second set of ETLs are called Target ETLs. The ETLs that load data into IBM Tivoli Service Level Advisor database are considered target ETLs. ETL programs perform data collection in a scheduled manner. You define the schedule according to which ETLs should be run. You need to understand how data is collected for the data source to define the schedule. Figure 3-6 on page 81 shows the data flow for Tivoli Data Warehouse. 80 Business Service Management Best Practices ITM_DB TWH_MART Target ETL Source ETL Objects TWH_CDW DYK_MART DYK_CAT WSC_DB Figure 3-6 Tivoli Data Warehouse data flow The following are specific considerations for some of the data sources: The IBM Tivoli Monitoring historical database is only loaded at midnight each day. Therefore, the most effective load of IBM Tivoli Monitoring data will be after midnight. The IBM Tivoli Business Systems Manager objects database is extremely busy, so it is preferable to perform the ETL load in an off-peak period. The WSC_DB from the IBM Tivoli Monitoring for Transaction Performance is loaded with a schedule that is specified from the Web interface. Sizing estimate The primary concern of a data warehousing application is sizing. Refer to the redbook Planning a Tivoli Enterprise Data Warehouse Project, SG24-6608 to get sizing and other planning information. A Microsoft Excel spreadsheet is provided as a part of the redbook above at: ftp://www.redbooks.ibm.com/redbooks/SG246608/SG246608.zip When completed, it shows important aspects of database size and expected ETL runtime. The input parameters include: Enabled application Estimated machine processing throughput Measurement collected per hour Time to keep the history data A sample sizing spreadsheet window is shown in Figure 3-7 on page 82. Chapter 3. Planning for Business Service Management 81 Figure 3-7 Sizing spreadsheet 3.4.7 Service Level management design From the Service Level objective list that you acquired from 3.3.2, “Documentation of Service Level objectives” on page 54, you can start building the components of the Service Level Advisor. The building blocks of IBM Tivoli Service Level Advisor are shown in Figure 3-8 on page 83. 82 Business Service Management Best Practices Schedule: Prime Time M - F: 8 - 18 EST S - Su: 8 - 12 EST Offering: Web performance -Gold Schedule: Continuous All days 0 - 24 EST Offering: Web performance -Silver Order Finance Intranet Performance Realm: Corporate Customer: Finance Order Web Store Internet Performance Customer: Web Store Customer: Supplier Mgmt Schedule: Workdays M - F 9 -17 EST Offering: Application performance Order EDI Performance Figure 3-8 IBM Tivoli Service Level Advisor components Data feeds Historical data needs to be collected. This information is mainly coming from the monitoring subsystems. Defining the realms and customers The different business processes that the IT department serves can be broken down into realms and customers. Realm In IBM Tivoli Service Level Advisor, a grouping of customers is used to organize customer information and, in some cases, to control access to that information. Customers might be grouped by region, by company, by divisions within a company, or using some other logical grouping. Customers can be assigned to one or more realms. Customer A party that enters into a Service Level Agreement with the provider of a particular service is a customer. Customers are associated with available Service Level Agreement orders. Customers can be given access to the results of Service Level Agreement evaluations and trend analyses to validate their Service Level Agreements. Customers can be internal (members of a department within the enterprise) or external (a member, department, or company), associated with a service provider. Chapter 3. Planning for Business Service Management 83 Defining service offerings A service offering is a set of definitions of which IT services are grouped together. Typically, an offering consists of a set of IT component definitions that can be mapped later to one or more customers. This component selection reflects a certain type of customer. Offering In IBM Tivoli Service Level Advisor, this describes a service with guaranteed Service Levels. Offerings are associated with business schedules and form the building blocks for customer orders and Service Level Agreements. Offerings can be differentiated to provide Service Level choices to customers (like "Gold," "Silver," and "Bronze" levels of service). An offering must be in the Published state to be included in a Service Level Agreement order. Offering component This supplies the metrics for offerings and customer orders. At the time of an offering creation, one or more offering components are selected. IBM Tivoli Service Level Advisor checks to determine the number of measurement sources for a component. For example, a Web Services service offering contains the following information: Transaction response time Server availability Database availability HTTP Server availability WebSphere application server availability Overall Business System View availability The above information is often referred to as components and metrics: Component The basic unit of service used to create a service offering. A component is an entity about which measurements are collected for reporting purposes. For example, a component can be a specific Web site or a particular application running on a Web application server. Measurement and metric A standard of measurement or a measurable quantity, associated with guaranteed Service Levels to create Service Level objectives. Metrics evaluate performance, availability, or utilization of resources, for example, response time, CPU and disk utilization. The whole offering can be defined to several business processes as long as they are all using Web-based applications with a database back office. 84 Business Service Management Best Practices Time-wise, an offering is qualified with a period and schedules. Business schedule or schedule A timeline of the operations of a business, with the timeline segmented into different operational states. Valid states include peak, off-hours, and no-service (scheduled downtime for maintenance). Period A component of a business schedule that divides the timeline into named intervals, such as critical, peak, prime, standard, low impact, off-hours, and no-service. The general meaning of those intervals is defined by the customer during Service Level Agreement negotiations. For example, you may define different Service Level objectives (thresholds) for each period, depending on how critical that particular period is for the business. Mapping customers with offering After the customers and the offerings are defined, you must deal with the mapping process. In IBM Tivoli Service Level Advisor terms, this is called creating an order. In IBM Tivoli Service Level Advisor, the order is the process by which an SLA is entered into the IBM Tivoli Service Level Advisor. It includes customer information, a service offering, and the specific elements that make up the SLA. For example, customer Accounting signs up for the Gold offering for the www.000.com/accounting Web site. Chapter 3. Planning for Business Service Management 85 86 Business Service Management Best Practices 4 Chapter 4. Business Service Management sample implementation In this chapter, we describe the details of the implementation step for Business Service Management in a sample environment. We will walk through the major implementation tasks and show how certain actions can be achieved. The discussion is divided into the following sections: 4.1, “Sample environment” on page 88 presents the sample environment in which we will work 4.2, “Constructing the solution” on page 90 details the creation of the solution. 4.3, “Implementation overview” on page 99 outlines the implementation steps. © Copyright IBM Corp. 2004. All rights reserved. 87 4.1 Sample environment A typical implementation for Business Service Management is usually performed in stages. Stages are chosen based on the business function that needs to be implemented first. You need to choose the most important business function in your enterprise to implement first because this accelerates usage and buy-in for the application. Implementation starts when the planning tasks described in Chapter 3, “Planning for Business Service Management” on page 43 are completed. You are then ready to start the actual work. The sample environment which we manage is a simple e-business situation with two sets of Web and Web application servers with a single database. This is a very simplified case since we are constrained by time to implement the environment. The environment used is shown in Figure 4-1. BSM2 IBMTIV2 IBM HTTP Server WebSphere Apps Server BSM7 DB2 database IBM HTTP Server WebSphere Apps Server Figure 4-1 Sample application environment We assume that this Web application is part of a Web store business process. We have performed the decomposition as discussed in 3.3.1, “Business process decomposition” on page 48 and the result is shown in Figure 4-2 on page 89. 88 Business Service Management Best Practices Business Process: Web Commerce Application: Web Store Application: Customer Service BSM2 - IBM HTTP Server BSM7 - IBM HTTP Server BSM2 - WebSphere BSM7 - WebSphere IBMTIV2 - DB2 - ITSOBAN1 BSM2 - IBM HTTP Server BSM7 - IBM HTTP Server WebServer WebServer Application Server Application Server Database Database BSM2 - WebSphere BSM7 - WebSphere IBMTIV2 - DB2 - ITSOCS Figure 4-2 Business process decomposition Note: The application environment which we discuss here is a very simplified Web environment. We have put aside the fact that a true e-business application will contain at least a firewall and authentication system. The Service Level Agreement for the Web Commerce business process is described in Table 4-1 on page 90. Chapter 4. Business Service Management sample implementation 89 Table 4-1 Service level objective for Web Commerce business process Application Metric Objective Measurement Web Store Transfer transaction Less than 3 secs on backend processing for 95% of transactions Quality of Service monitor samples every 5 transactions Availability 98% available for standard time of 6AM to 11PM 90% available for the rest Synthetic transaction samples every minutes Constraint: Hit rate for less than 10 hit per seconds Customer Service e-Ticket open transaction Less than 3 secs on backend processing for 95% of transactions Quality of Service monitor samples every 5 transactions Availability 98% available for standard time of 6AM to 11PM 90% available for the rest Synthetic transaction samples every minutes Constraint: Hit rate for less than 10 hit per seconds In this sample implementation, we will define the environment from scratch, assuming there is no current monitoring scheme and all monitoring is performed using IBM software. Now we will go through the design phase that is discussed in 3.4, “Designing the solution” on page 61 to construct the result. 4.2 Constructing the solution In this section, we will assign the appropriate solution for the design phases discussed in 3.4, “Designing the solution” on page 61. The design is performed in the following stages: 4.2.1, “Solution structure” on page 91 is where we select the products to be used 4.2.2, “Solution configuration” on page 91 lists a detailed view of servers and required software to implement the functions 4.2.3, “Monitoring architecture” on page 93 discusses the creation of a monitoring standard based on the information input 4.2.4, “Object class selection” on page 94 provides some considerations for deciding what objects needs to be defined in IBM Tivoli Business Systems Manager and how these objects will be monitored 90 Business Service Management Best Practices 4.2.5, “Business System View design” on page 95 discusses the translation of the business process decomposition into impact monitoring using the Business System View 4.2.6, “Data collection design” on page 96 4.2.7, “Service Level monitoring” on page 98 4.2.1 Solution structure Based on the discussion in 3.4.1, “Solution structure” on page 62, we determine the necessary software for our solution. For the monitoring function, we make use of the following products: – – – – IBM Tivoli Monitoring IBM Tivoli Monitoring for Databases: DB2 IBM Tivoli Monitoring for Web Infrastructure: Apache Web Server IBM Tivoli Monitoring for Web Infrastructure: WebSphere Application Server – IBM Tivoli Monitoring for Transaction Performance: Web Performance – IBM Tivoli NetView For the real-time monitoring of the Business Service Management: – IBM Tivoli Enterprise Console – IBM Tivoli Business Systems Manager For the historical reporting and Service Level management, we use: – Tivoli Data Warehouse – IBM Tivoli Service Level Advisor 4.2.2 Solution configuration From the discussion in 3.4.2, “Hardware and software configuration” on page 63, we select the machines that we will use in our solution. The resulting environment is shown in Figure 4-3 on page 92. Chapter 4. Business Service Management sample implementation 91 IBMTIV1 IBMTIV5 Tivoli Framework 4.1 IBM Tivoli Monitoring 5.1.1 IBM Tivoli Enterprise Console 3.8 Tivoli Management Agent Web Services Courier TBSM Event Enablement BSM6 IBM Tivoli Service Level Advisor 1.2 Tivoli NetView V7.1.3 TBSM Adapter BSM9 BSM5 Tivoli Internet Management Server BSM4 IBM Tivoli Data Warehouse 1.1.1 BSM2 BSM1 IBMTIV2 Quality of Service endpoint Browsers BSM8 IBM HTTP Server WebSphere Apps Server TMA + ITM Web Infrastructure BSM7 DB2 database TMA + ITM Databases Quality of Service endpoint IBM Tivoli Business Systems Manager BSM3 IBM HTTP Server WebSphere Apps Server TMA + ITM Web Infrastructure Figure 4-3 Sample application environment with monitoring function In our sample environment, the management machines are more than the actual managed environment. Most of the infrastructure that we use here is scalable to manage a very large number of servers, but we use it to manage a very simple environment. In a real-world implementation, these are the changes that we recommend for the management environment: Separate the IBM Tivoli Enterprise Console server from the Tivoli Management Framework server Use a dedicated endpoint for the Web Services Courier endpoint, instead of having it reside on the Tivoli Management Framework Consider dedicating a separate database server instead of using the Tivoli Management Framework Server 92 Business Service Management Best Practices Use a separate administration server and runtime server for the IBM Tivoli Service Level Advisor Other servers, such as the Tivoli Data Warehouse server, IBM Tivoli Business Systems Manager servers, IBM Tivoli NetView server and Tivoli Internet Management Server have been configured on their own machines, appropriately. 4.2.3 Monitoring architecture The monitoring implementation uses the following three different schemas: “IBM Tivoli Monitoring profiles” on page 93 “Internet monitoring jobs” on page 94 “IBM Tivoli NetView network monitoring” on page 94 IBM Tivoli Monitoring profiles The monitoring approach that we use is a minimalist approach. We will only monitor resources to fulfill the Service Level Agreement. Therefore, it is important to make the SLA as comprehensive as possible for the business user, while retaining the flexibility for the IT department to fulfill it. IBM Tivoli Monitoring has provided several built-in functions for our purposes, such as: An automated resolution event called TMW_Clearing for any outstanding event A heartbeat function for the monitoring engine Recording of historical data into RDBMS IBM Tivoli Monitoring profiles need to be synchronized whenever the monitoring engine is stopped. When the monitoring engine restarts, it is not aware of its last state and does not send any resolution events. This should be addressed using a script that triggers events when a monitoring engine starts. Our naming convention uses Profile Manager with the suffix PM and Profiles with the suffix Pr. We implement the Profile Manager structure as shown in Figure 4-4 on page 94. Chapter 4. Business Service Management sample implementation 93 ITM_PM ITM_Apache_Pr ITM_WAS_Pr ITM_DB2_Pr ITM_Win_Pr ITM_UNIX_Pr Apache_PM WAS_PM DB2_PM WinSrv_PM UNIXSrv_PM Figure 4-4 Profile Manager structure As shown in Figure 4-4, we created a Profile Manager container for each category of subscribers. These subscribers then map to the IBM Tivoli Monitoring profiles in the ITM_PM Profile Manager. Note that ITM_PM is a database Profile Manager, while the other Profile Managers are dataless Profile Managers. Internet monitoring jobs For Internet monitoring using the IBM Tivoli Monitoring for Transaction Performance, we use the Quality of Service function to monitor the back-end response time and the Synthetic Transaction Investigator to measure the Web site availability. This is the primary indicator of the Service Level that we will use. IBM Tivoli NetView network monitoring As with any Web-based solution, network monitoring is critical. The network has to be up and available for the components to function. We use IBM Tivoli NetView to monitor the network part of the solution. 4.2.4 Object class selection Details for this are given in 3.4.4, “IBM TBSM object type selection” on page 69. For flexibility and customizable features, we decided to use the IBM Tivoli Enterprise Console interface instead of the Common Listener. While the Common Listener function has fewer implementation tasks, it also has fewer customization options. 94 Business Service Management Best Practices For granularity of objects, we decided to use the default object types provided by the IBM Tivoli Monitoring solutions. These objects have been configured using the IBM Tivoli Enterprise Console and evaluated for performance and granularity. 4.2.5 Business System View design Details for this are given in 3.4.5, “Business System View design” on page 74. We decided to use the separate Business System View because it can easily be automated in its creation and also because it provides an easy configuration for the resources that directly affect the business process and those that do not. The business system configuration is shown in Figure 4-5. Online Store Customer Service Web Store Account Payable All Systems Networking Windows Machines IT Resources UNIX machines Account Receivable Finance Web resources General Ledger Supplier EDI Databases Figure 4-5 Business System View design The expected users of IBM Tivoli Business Systems Manager and the Business System Views that they will use are listed in Table 4-2. Table 4-2 Business System View assignment User Role BSV Business Process Owners Restricted Operator Business process BSVs Application owners Restricted Operator Application BSVs UNIX administrator Operator UNIX machines Windows administrator Operator Windows Machines Network administrator Operator Networking Chapter 4. Business Service Management sample implementation 95 User Role BSV Web administrator Operator Web resources Database administrator Operator Databases IT manager Administrator IT resources TBSM administrator Super Administrator All BSVs; All resources view Helpdesk Operator IT resources CEO Restricted Operator All systems 4.2.6 Data collection design For data collection design, as discussed in 3.4.6, “Data collection design” on page 80, we used the planning spreadsheet. First, we entered the necessary information for our environment in the App Properties tab, as shown in Figure 4-6 on page 97. 96 Business Service Management Best Practices Figure 4-6 Tivoli Data Warehouse planning spread sheet We also changed the throughput for the ETL because it depends a good deal on the performance of the machine hosting the databases. In our environment, all databases reside in the same machine source, so we have quite a low throughput; also, the IBM Tivoli Business Systems Manager source resides in a Microsoft SQL Server database. We changed the throughput into 1000 rows for most of the sources and 500 rows for the IBM Tivoli Business Systems Manager source. We also modified the target ETL throughput into 2000 rows. The resulting sizing information is shown in Figure 4-7 on page 98. Chapter 4. Business Service Management sample implementation 97 Figure 4-7 Result of the sizing database Based on the results shown in Figure 4-7, the total processing of the ETL programs is estimated at 1 hour and 23 minutes. Therefore, the window to run the ETL can be allocated from midnight to 2 a.m. A sample run schedule is shown in Figure 4-8. 23:00 24:00 1:00 2:00 AMY_m10_build StarSchema_Pro cess ITM_DB collection GWA_m10_ETL 2_ Process AMX_c05_ETL1_ Process WSC_DB collection BWM_c10_Load _Warehouse_ Process DYK_m05_ Populate_ Registration_ Datamart_Proces DYK_m10_ Populate_ Measurement_ Datamart_Proces IZY_m05_Dimen sion_Process IZY_m10_Fact_P rocess CTD_m05_ETL2 _ Process GTM_c05_ LOBState_ Process Timeline Figure 4-8 Collection schedule 4.2.7 Service Level monitoring For the Service Level monitoring solution, as discussed in 3.4.7, “Service Level management design” on page 82, we use the following scheme. 98 Business Service Management Best Practices The Service Level structure for the IBM Tivoli Service Level Advisor can be summarized to monitor the following: Business System status for the related business system (a green percentage) WebSphere transaction rate Transaction response time from the QoS system 4.3 Implementation overview In this redbook, we will not discuss installation steps and processes for the software product that we use. Refer to the product documentation for installation instructions. Other references are provided in “Related publications” on page 165. This implementation also starts after the design process which we discuss in 4.2, “Constructing the solution” on page 90. The implementation procedure consists of the following high-level steps: 1. The first step is to implement the server with all its prerequisite software and management software. These steps will not be discussed in this redbook. A summary of the installed software is provided in Table 4-3 on page 100. 2. We define the monitors; this includes configuring IBM Tivoli NetView maps, defining IBM Tivoli Monitoring profiles and defining Tivoli Internet Management jobs. The discussion is provided in 4.4, “IBM Tivoli Monitoring profiles” on page 101, 4.5, “IBM Tivoli NetView monitoring” on page 112 and 4.6, “Web transaction response time monitoring” on page 120. 3. For the real-time monitoring section, you need to monitor and collect all the metrics from the installed monitors. In our environment, these metrics are collected, analyzed and applied using the IBM Tivoli Enterprise Console. See 4.7, “Defining TEC rules” on page 132. 4. We configure IBM Tivoli Business Systems Manager object types as shown in 4.7.6, “Defining TBSM object types” on page 140. 5. For the real-time monitoring section, you create the business systems that represent the business functions. These business systems must be defined with flexibility to adapt to the changing environment. See 4.7.8, “Defining business systems” on page 144. 6. Operator defininition is discussed in 4.7.9, “Defining TBSM operators” on page 147. 7. For historical data collection, we need to set up Tivoli Data Warehouse to collect data from the monitoring application. See 4.8, “Configuring Tivoli Data Warehouse” on page 151. Chapter 4. Business Service Management sample implementation 99 8. For Service Level monitoring, we need to set up IBM Tivoli Service Level Advisor offerings, customers and orders. See 4.9.1, “Defining the operation” on page 160. The installed software shown in Table 4-3 is a subset of the overall software configuration shown in Table 3-9 on page 64. Table 4-3 Software configuration list Machine name Operating System Software list IBMTIV1 TMR Server Gateway RIM host AIX 5L Tivoli Management Framework 4.1 IBM Tivoli Monitoring 5.1.1 IBM Tivoli Monitoring Component Services 5.1 IBM Tivoli Monitoring for * DB2 Universal Database Version 7.1 IBM Tivoli Enterprise Console 3.8 IBM Tivoli Business Systems Manager distributed edition 2.1.1 IBM Tivoli Monitoring for Transaction Performance: Web Service Courier endpoint IBMTIV5 Windows 2000 Server Tivoli Management Framework 4.1 IBM Tivoli NetView 7.1.3 BSM9 TIMS Windows 2000 Server IBM Tivoli Monitoring for Transaction Performance 5.2: Internet Management Server BSM4, BSM8 QoS endpoint Windows IBM Tivoli Monitoring for Transaction Performance 5.2: QoS Endpoint STI endpoints Windows IBM Tivoli Monitoring for Transaction Performance 5.2: STI endpoint BSM1 TBSM database server Windows 2000 Advanced Server Windows 2000 Resource Kit Windows Support Tools MKS Toolkit V8 Microsoft SQL Server 2000 IBM TBSM Base Services BSM3 TBSM console and propagation server Windows 2000 Advanced Server Windows 2000 Resource Kit Windows Support Tools MKS Toolkit V8 IBM TBSM Base Services BSM5 TDW database server TDW Control Server Windows 2000 Server DB2 Universal Database Server V7.1 FixPack 5 IBM Console Presentation Services Tivoli Data Warehouse enablement packs 100 Business Service Management Best Practices Machine name Operating System Software list BSM6 TSLA database server TSLA admin server TSLA reporting Server Windows 2000 Server DB2 Universal Database Server V7.1 FixPack 5 IBM Tivoli Service Level Advisor 1.2 Server IBM Console Presentation Services IBM Tivoli Service Level Advisor 1.2 Task Drivers IBM Tivoli Service Level Advisor 1.2 Reports BSM, BSM7 Web and Web Application Servers Windows 2000 Server DB2 Universal Database Server V7.1 FixPack 5 IBM HTTP Server V1.3.16 WebSphere Application Server V4.0.3 Tivoli Management Agent IBMTIV2 Database Server AIX 4.3.3 DB2 Universal Database Server V7.1 FixPack 5 Tivoli Management Agent 4.4 IBM Tivoli Monitoring profiles IBM Tivoli Monitoring profiles are Tivoli Management Framework based profiles. These profiles are created using the Tivoli Desktop interface. Each profile is created inside a container called a Profile Manager. The Profile Manager lists the potential subscribers for the profile. The IBM Tivoli Monitoring profile object is called Tmw2kProfile. 4.4.1 Profile Managers and IBM Tivoli Monitoring profiles A Profile Manager window is shown in Figure 4-9 on page 102. Chapter 4. Business Service Management sample implementation 101 Figure 4-9 Profile Manager We created a Tmw2kProfile for each type of monitoring that we use. The profile consists of the list of resource models contained within it. For each resource model, the following information is specified: The indications or metrics that are evaluated in the resource models The threshold of each indication and how many violations cause an alert (see Figure 4-12 on page 105) The responses that can be triggered The logging option for the resource model The window to define the Tmw2kProfile object is shown in Figure 4-10 on page 103. 102 Business Service Management Best Practices Figure 4-10 Creation of Tmw2kProfile Click Add. We will then add a new resource model to the Tmw2kProfile object. The Add resource model window is shown in Figure 4-11 on page 104. Chapter 4. Business Service Management sample implementation 103 Figure 4-11 Resource model configuration window These are the descriptions of the fields and buttons for the Add Resource Model window shown in Figure 4-11: 104 Category Lists the existing resource model categories depending on the installed products. Resource Model Lists the resource models in the selected category. Cycle time Determines the interval at which the resource model will check its indications. Threshold list Lists possible indications and their thresholds; when selected, the threshold entry is shown. Indication button Opens the indication setting dialog. Parameters button Sets monitoring filters and logging parameters. Business Service Management Best Practices Schedule button Determines the time interval within which this profile can be active. Logging button Offers a selection of logging options to use. The Indication window is shown in Figure 4-12.. Figure 4-12 Indication setting In Figure 4-12, the following can be configured: Occurences and holes setting Event triggering setup Action tasks In Figure 4-13 on page 106, the parameter dialog is shown. Chapter 4. Business Service Management sample implementation 105 Figure 4-13 Parameter setting The parameter setting window in Figure 4-13 allows you to select which metrics will actually be logged in the historical database and also the monitoring filter, in this case the Application Names to monitor for SQL statement activity. The logging option is shown in Figure 4-14 on page 107. 106 Business Service Management Best Practices Figure 4-14 Logging option You should specify the logging option to log TEDW data for collection to Tivoli Data Warehouse. After you have all the resource models defined, back in the Tmw2kProfile window (as shown in Figure 4-10 on page 103), click Edit -> Properties and enable the event forwarding function, as shown in Figure 4-15 on page 108. Chapter 4. Business Service Management sample implementation 107 Figure 4-15 Event setting You also need to enable the forwarding setting. Either forward to IBM Tivoli Enterprise Console or to IBM Tivoli Business Systems Manager directly using Common Listener. We decided to use the interface to IBM Tivoli Enterprise Console. 4.4.2 Detailed profile setting In this section, we show the detailed settings of the Resource Models in our Tmw2kProfiles objects. The settings are selected based on the monitoring need. All these events are sent to IBM Tivoli Enterprise Console. Apache Web Server monitoring Apache Web Server monitoring provides the following functions: Makes sure that the process is always running; the operator needs to be notified when the process is not running and cannot be started automatically. Counts the hit rate for reporting, then reports any exceptionally high hit rate. Reports excessive numbers of error requests, perhaps resulting from a Denial of Service attack. 108 Business Service Management Best Practices Note: Depending on the setup of your environment, you may want to have the authentication fail if it is performed by the Web server; a typical implementation performs authentication outside of the Web server itself. We create the profile ITM_Apache_Pr with the content shown in Table 4-4. Table 4-4 Monitoring resource models Resouce model Indication and threshold Logging attribute Apache_ Performance Apache_THR_FailedLoginPerSec 5.000000 Apache_THR_ServerFailuresPerSec 5.000000 Apache_THR_FailedPagesPerSec 20.000000 Apache_THR_KBytesPerSec 70.000000 Apache_THR_RequestsPerSec 50.000000 Server.ServerName,WebSiteName GWA_Server_failures_count GWA_Failed_pages GWA_Failed_connections_count GWA_Hit_count GWA_Requests_rate GWA_Successful_login_count GWA_Failed_login_count GWA_Kbytes_rate Apache_ WebSiteAvailability N/A Server.ServerName,WebSiteName GWA_Website_running GWA_Website_stopped WebSphere Application Server monitoring WebSphere Application Server is a critical piece of the application. All the transactions are handled there. The monitoring aim is to maximize the availability and performance of the Web transaction. Therefore, the following monitoring is performed: Monitor and log the status of the WebSphere Application Server Monitor and log the JVM memory usage to ensure that there is enough storage available for the application Note: Our application runs as servlets, without EJB; therefore, we only use the WebApplication monitor, without the EJB monitor or transaction monitor. Monitoring for DB2 connection contention Monitoring for number of HTTP sessions The ITM_WAS_Pr profile that we define to address the WebSphere component is summarized in Table 4-5 on page 110. Chapter 4. Business Service Management sample implementation 109 Table 4-5 Monitoring resource models Resouce model Indication and threshold Logging attributes WebSphereAS_ ApplicationServer _ 10 N/A Name,AdminServerName: WebSphere_server_state_up WebSphere_server_state_down WebSphere_server_state_initializing WebSphere_server_state_unknown WebSphereAS_ JVMRuntime_10 WebSphereAS_high_JVMRuntime_ usedMemory 95.000000 Name,ApplicationServer.Name,Admin Server.Name Total_JVM_memory Used_JVM_memory WebSphereAS_ ThreadPool_10 WebSphereAS_high_ThreadPool_ activeThreads 95.000000 Name,AdminServer.Name,ApplicationS erver.Name Active_threads_to_pool_size_ratio WebSphereAS_ WebApps_10 WebSphereAS_high_Servlet_errors 0.000000 WebSphereAS_high_Servlet_response _time 750.000000 "Name,AdminServer.Name,Application Server.Name,WebApplication.Name Name,AdminServer.Name: Servlet_request_rate Average_servlet_response_time Concurrent_servlet_requests Servlet_error_rate WebSphereAS_ HTTP_Sessions_ 10 WebSphereAS_high_HTTPSessions_ liveSessions 1000 Name,ApplicationServer.Name,Admin Server.Name Live_servlet_sessions DB2 monitoring The database monitoring needs to ensure the performance of the database to fulfill requests from the WebSphere Application Server. This result in the following monitoring: Monitoring and logging of the availability of the DB2 instance Monitoring of the Buffer Pool hit ratio, one of the most important parameters of DB2 performance Monitoring of the DB2 subsystem connection and tablespaces status Monitoring of locks and deadlocks The DB2 monitoring details are shown in Table 4-6 on page 111. 110 Business Service Management Best Practices Table 4-6 Monitoring resource models Resouce model Indication and Threshold Parameters DB2 Buffer Pools High_AvgPoolReadTime 200 High_AvgPoolWriteTime 200 Low_PctBufferPoolHits 90 High_AvgSyncReadTime 200 Low_AvgAsyncWritesPerPoolWrite 30 Low_PctIndexHits 90 High_AvgSyncWriteTime 200 High_AvgPoolIOTime 200 Low_AvgAsyncReadsPerPoolRead 50 High_AvgSyncIOTime 200 High_AvgPoolWritesPerPoolRead 100 N/A DB2 Activity Old_LastBackupTimestamp 2 High_PctConnectionsUsed 80 High_ConnectionErrors 100 High_CurrentConnections 50 High_SpaceUsedDMSTablespace 85 High_SpaceUsedSMSTablespace 0 High_MostRecentConnectResponse 5 High_ConnWaitingForHost 30 N/A DB2 Instance Status High_PctConnectionsExecuting 75 DB2 locks and Deadlocks High_AppPctLockListUsed 50 High_AvgLockEscalationConn 5 High_AvgLocksHeld 5 High_AppDeadlocks 6 High_DeadlocksDelta 4 High_AppLockEscalations 6 High_PctIntDeadlockedRollbacks 80 High_DBPctLockListUsed 50 High_PctDeadlockRollbacks 80 High_LockEscalationsDelta 3 High_LockTimeoutsDelta 10 N/A Windows server monitoring For Windows server, we monitor the following attributes: CPU utilization Memory usage Free disk space Network card activity The contents of the ITM_WinOS_Pr profile are shown in Table 4-7 on page 112. Chapter 4. Business Service Management sample implementation 111 Table 4-7 Monitoring resource models Resouce model Indication and Threshold Parameters Memory PctMemoryFree 10 - Network Interface Card Utilization 90% Physical Disk Free space 50 MB Processor CPU utilization 95% C:\ UNIX server monitoring For the UNIX server, we monitor the following attributes: CPU utilization Memory usage Free disk space Network card activity The contents of the ITM_UNIXOS_Pr profile are shown in Table 4-8. Table 4-8 Monitoring resource models Resouce model Indication and Threshold Parameters CPU Utilization 95% File System Free space 50 MB /var, /home/db2inst1 Memory PctMemoryFree 10 - Network Interface Utilization 90% - 4.5 IBM Tivoli NetView monitoring To enable access to NetView from a remote Web console (either with the Web Console Application or from within a browser applet), be sure to register and start the netviewd daemon. You can do this by issuing \usr\OV\bin\ovaddobj \usr\OV\lrf\netviewd.lrf from a command line. Next, define at least one user by using the nvsetup application in order to gain access to NetView through the Web console. You will need a user definition to access NetView data from within IBM Tivoli Business Systems Manager. To add a user, execute the \usr\OV\bin\nvsetup utility or click Tivoli NetView -> Administration -> Server Setup to display the setup dialog as shown in 112 Business Service Management Best Practices Figure 4-16. In this dialog, select Web Server from the drop-down list and click Configure Web Console Security. Figure 4-16 Invoking Web console Security from nvsetup Alternatively, you can start the configuration utility from the native NetView console by clicking Administer -> Security Administration -> Web Console Security. In both cases, the Java-based Web Console Security application opens with the initial dialog box shown in Figure 4-17 on page 114. Chapter 4. Business Service Management sample implementation 113 Figure 4-17 The Web Console Security dialog box In this dialog, you can add and edit users, roles, and views. Clicking Selected -> Add or selecting the Add icon in the button row will open the Add User dialog shown in Figure 4-18. Figure 4-18 The Add User dialog box 114 Business Service Management Best Practices Enter a user name and a password. For now, assign the SuperUser role to the new user. Because an IBM Tivoli Business Systems Manager user might need to access all of the network topology, select No scoping restrictions for the Scope field. Click OK to close the dialog box, then click File -> Save to save the new user definition. You will be asked to restart the Web server to activate the changes. Reply Yes to restart the Web server. Now from the NetView setup window, go to the Discovery tab and click Edit for the seed file. The seed file editor is shown in in Figure 4-19. Figure 4-19 NetView seed file editor We want to limit the discovery to our environment only, as shown in Figure 4-20 on page 116. Chapter 4. Business Service Management sample implementation 115 Figure 4-20 Adding discovery filter to our subnet only Configuring IBM Tivoli Enterprise Console forwarding is done by clicking Tivoli NetView -> Administration -> Configure IBM Tivoli Enterprise Console Adapter. The following configuration assumes that we have a Managed Node installed in the ibmtiv5 where we run NetView. Without this, you would need to use a connection that is not secure by specifying the IP address of the IBM Tivoli Enterprise Console, its operating system, and its port. The configuration of the adapter is done through the dialog shown in Figure 4-21 on page 117. 116 Business Service Management Best Practices Figure 4-21 Configuring TEC adapter As shown in Figure 4-21, the only events that we will send are the Link_Down and Link_Up events and those will be sent for all the SmartSets. Because commands launched from IBM Tivoli Business Systems Manager to NetView are executed locally, the NetView Web console must be installed on all workstations that will be used to access IBM Tivoli Business Systems Manager and its Java console. NetView provides a download page with install images of the NetView Web console for various platforms. You can access this download page by connecting to NetView Server using a Web browser. In our case, the download page is: http://ibmtiv5:8080/download and 8080 is the default port on which the NetView Web server listens. A download page is shown in Figure 4-22 on page 118. Chapter 4. Business Service Management sample implementation 117 Figure 4-22 The NetView Web Console download page For a Windows-based workstation, select nvwcinstal.exe and download the file. This is a Windows install image which you can install on the target workstation. Note: With the current implementation of the NetView IBM Tivoli Business Systems Manager adapter, a launch of the NetView Web Console from the IBM Tivoli Business Systems Manager Java console will not work with the default path the Web Console installer suggests. One component installed on the IBM Tivoli Business Systems Manager side, nvlaunch.jar, only supports file paths in the classic 8.3 notation. We recommend that you change the install directory during the NetView Web Console install to something like c:\NVWC, as shown in Figure 4-23. 118 Business Service Management Best Practices Figure 4-23 Changing the default path for the NetView Web Console The install procedure creates an object on your Windows desktop. Double-click that icon to launch the Web Console and open the login window as shown in Figure 4-24. ibmtiv5 Figure 4-24 Web Console login window Chapter 4. Business Service Management sample implementation 119 Type in your user ID, password, the hstname of your NetView sever, and the port on which the NetView Web Console is listening. After a successful logon, select File -> Open from the menu to display a map inside the Web Console as shown in Figure 4-25. Figure 4-25 Open a map 4.6 Web transaction response time monitoring We need to define and manage the response time for the Web Services transactions. We capture this information using the IBM Tivoli Monitoring for Transaction Performance: Web Performance. This product used to be called the Tivoli Web Services Manager. 120 Business Service Management Best Practices There are two tools that we used: The Quality of Service monitor, which collects a sample response time of actual end-user experiences for browsing the Web site The Synthetic Transaction Investigator monitor, which monitors the availability and response time for a certain transaction The IBM Tivoli Monitoring for Transaction Performance uses the Web browser to administer its function. We log in to the Internet Management Server as shown in Figure 4-26. The URL for us is http://bsm9/. Figure 4-26 Log in to the Tivoli Internet Management Server The initial menu that we were presented with is shown in Figure 4-27 on page 122. Chapter 4. Business Service Management sample implementation 121 Figure 4-27 Initial TMTP menu 4.6.1 Quality of Service monitoring We create Quality of Service jobs to monitor the critical transaction response time on our Web servers. The jobs are called: QOS_bsm2_transfer_01QOS job for bsm2 endpoint with transaction transfer QOS_bsm7_transfer_01QOS job for bsm7 endpoint with transaction transfer QOS_bsm2_eopen_01QOS job for bsm2 endpoint with transaction eopen QOS_bsm7_eopen_01QOS job for bsm7 endpoint with transaction eopen The following steps are taken to create the QOS jobs: 1. From the menu, select Quality of Service -> Create Quality of Service Job. 2. Assign the endpoint for the job as shown in Figure 4-28 on page 123. Click Next. 122 Business Service Management Best Practices Figure 4-28 QOS job - choose endpoint 3. Assign the Schedule for the job as shown in Figure 4-29; the definition shown is for a continuous job. Click Next. Figure 4-29 QOS job - define schedule Chapter 4. Business Service Management sample implementation 123 4. Assign the parameters for the job; we select the target URI condition for the transaction that we want to monitor, as shown in Figure 4-30 on page 124. Click Next. Figure 4-30 QOS job - job parameter 5. Define the monitoring constraint (threshold) and event severity to be generated, as shown in Figure 4-31 on page 125. Click Next. 124 Business Service Management Best Practices Figure 4-31 QOS job - define constraint 6. Save the job as shown in Figure 4-32. Click Save. Figure 4-32 QOS job - saving 7. Click Quality of Service -> Configure Events to configure event forwarding to IBM Tivoli Enterprise Console. We only want to forward the response time events that we want to be forwarded to IBM Tivoli Enterprise Console. The result is shown in Figure 4-33 on page 126. Chapter 4. Business Service Management sample implementation 125 Figure 4-33 QOS events configuration 4.6.2 Synthetic Transaction Investigator monitoring We also create Synthetic Transaction Recording for both the transfer and eopen transactions using the STI Recorder, as follows: 1. Download the STI Recorder from the Web interface by clikcing Synthetic Transaction Investigator -> Download Transaction Recorder. 2. Start the Recorder by selecting Programs -> Tivoli -> Synthetic Transaction Investigator Recorder. The login dialog is shown in Figure 4-34 on page 127. It is the Web target realm login, not the Management Server login. 126 Business Service Management Best Practices Figure 4-34 Login to STI Recorder 3. Record the sample transaction flow and save it to the Management Server by clicking the Save Transaction button. Authentication to the Management Server is now required. The Save Transaction dialog is shown in Figure 4-35 on page 128. Chapter 4. Business Service Management sample implementation 127 Figure 4-35 Save a transaction The STI jobs that we create are called: STI_bsm2_transfer_01STI job for transfer to bsm2 endpoint STI_bsm7_transfer_01STI job for transfer to bsm7 endpoint STI_bsm2_eopen_01STI job for eopen to bsm2 endpoint STI_bsm7_eopen_01STI job for eopen to bsm7 endpoint The following procedure creates the STI jobs: 1. Click Synthetic Transaction Investigator -> Create Transaction Playback. 2. Specify the endpoint to use as shown in Figure 4-36 on page 129. Click Next. 128 Business Service Management Best Practices Figure 4-36 STI job - specify endpoint 3. Specify the schedule to use as shown in Figure 4-37. Click Next. Figure 4-37 STI job - continuous schedule 4. Specify the transaction to play back as shown in Figure 4-38 on page 130. Click Next. Chapter 4. Business Service Management sample implementation 129 Figure 4-38 STI job - recorded transaction 5. Specify the proxy information as shown in Figure 4-39. Click Next. Figure 4-39 STI job - proxy 6. Specify the constraint as shown in Figure 4-40 on page 131. Click Next. Here you can define the response time measurement, HTTP return code and content evaluation. 130 Business Service Management Best Practices Figure 4-40 STI job - constraint definition 7. Specify the job name to use as shown in Figure 4-41. Click Save. Figure 4-41 STI job - saving Chapter 4. Business Service Management sample implementation 131 8. Configure STI events by clicking Synthetic Transaction Investigator -> Configure Events. The events that we choose for forwarding are shown in Figure 4-42. Figure 4-42 STI events configuration 4.7 Defining TEC rules Since we decided to use IBM Tivoli Enterprise Console to transfer all events from the monitoring systems to IBM Tivoli Business Systems Manager, we need to prepare the IBM Tivoli Enterprise Console. The IBM Tivoli Enterprise Console is based on a set of definitions called a rule base. A rule base contains event format definitions in a format called baroc and processing logic written in the Prolog language called rulesets. This information needs to be customized to be able to send events to IBM Tivoli Business Systems Manager. 4.7.1 Adding IBM Tivoli Monitoring rules For the IBM Tivoli Monitoring product modules, there are default tasks, baroc files and rulesets that are supplied by IBM. These supplied baroc files and rulesets are listed in Table 4-9 on page 133. 132 Business Service Management Best Practices Table 4-9 Files to be imported to rule base IBM Tivoli Monitoring for Baroc and ruleset files location Task or script IBM Tivoli Monitoring for Apache HTTP server generic_unix/TME/Apache/tec/ itmapache_tec_config_evtsvr.sh CREATE “new_rule_base path rule_base_activation” IBM Tivoli Monitoring forWebSphere Application Server generic_unix/TME/WSAPPSVR/tec / WebSphere Event Tasks -> Configure_Event_Server IBM Tivoli Monitoring forDB2 database generic/ITM/DB2/TECClasses/ DB2ManagerAdminTasks -> ECC_Configure_TEC_Classes IBM Tivoli Business Systems Manager aix4-r1/TDS/EventService/config/tb smstatus/tbsmstatus.baroc ihsttec.sh IBM Tivoli Monitoring aix4-r1/TMNT_TEC/ - The tasks or scripts provided in Table 4-9 allow the creation of new rule bases with the necessary baroc and ruleset files. Warning: Be sure to evaluate the final rule to ensure that all necessary rulesets are included in the Event Server target rules. Some of the tasks and scripts actually left out rulesets for other modules. 4.7.2 IBM Tivoli Monitoring for Transaction Performance rules For IBM Tivoli Monitoring for Transaction Performance, a baroc file is supplied in the Internet Management Server, at $INSTHOME/TIMS/lib/TranPerf.baroc. You need to include this baroc file in the final rule base manually. There are no default processing rulesets for these events. From 4.6, “Web transaction response time monitoring” on page 120, we forward the following events to the IBM Tivoli Enterprise Console (both the violation and recovery events): QoS Backend Service Time QoS Page Display Time QoS Round Trip Time STI Round Trip Time STI Overall Transaction Time STI Undesired Content found STI URL not available Chapter 4. Business Service Management sample implementation 133 Violation events are sent as Critical, while recovery events are sent as Harmless. There are rules to apply these events to our business system objects, so we need to do the following: 1. To indicate the event type in the event, we use the sub-origin slot, which is originally empty. A rule excerpt for this is shown in Example 4-1. We create similar rules for all event classes that we want to work on. Example 4-1 Rule to set sub-origin field rule: rule_WSM_QOS_Round_Trip_Time_Violation: ( description: 'WSM-QOS-Round-Trip-Time-Violation', event: _event of_class 'WSM-QOS-Round-Trip-Time-Violation', reception_action: ( bo_set_slotval(_event, sub_origin, 'WSM-QOS-Round-Trip-Time-Violation') ) ). 2. For failure events of Critical severity, we must indicate forwarding using the IBM Tivoli Business Systems Manager exit ihstttec. However, since we want to indicate to IBM Tivoli Business Systems Manager that the event actually belongs to the Web server engine, instead of to the endpoint engine, we need to perform some mapping. The forwarding rule is similar to that shown in Example 4-2. The rule invokes a shell script in $BINDIR/TME/TEC/scripts/TMTP_to_TBSM.sh. Example 4-2 Forwarding rule - violation rule: rule_TMTP_Critical: ( description: 'TMTP violation events', event: _event of_class within ['WSM-Quality-Of-Service', 'WSM-Synthetic-Transaction-Investigator'] where [ severity: equals 'CRITICAL' ], reception_action: ( exec_program(_event, 'scripts/TMTP_to_TBSM.sh’, ‘’, [ ], 'YES'), ) ). 3. We also need to indicate that a recovery event must be sent to IBM Tivoli Business Systems Manager. The rule to do this is shown in Example 4-3 on page 135. You will notice that this rule is similar to the one shown in 134 Business Service Management Best Practices Example 4-2. However, we prefer to split the rule to accomodate any different processing that may be needed for the violation and recovery events. Example 4-3 Forwarding rule - recovery rule_TMTP_Harmless: ( description: 'TMTP recovery events', event: _event of_class within ['WSM-Quality-Of-Service', 'WSM-Synthetic-Transaction-Investigator'] where [ severity: equals 'HARMLESS' ], reception_action: ( exec_program(_event, 'scripts/TMTP_to_TBSM.sh’, ‘’, [ ], 'YES'), ) ). 4. Now we need the script TMTP_to_TBSM.sh. When a script is invoked by an IBM Tivoli Enterprise Console rule, it has access to the event’s information slots in environment variables. The following translation is used for mapping slot values to IBM Tivoli Business Systems Manager attributes: -b (TBSM class) TMTP;5.1 -m (message) from msg slot -h (hostname) parsed from jobName slot -i hostname -d hostname -p from sub-origin slot contain class name -s (severity) from severity slot Example 4-4 on page 136 shows the excerpt from TMTP_to_TBSM.sh. Chapter 4. Business Service Management sample implementation 135 Example 4-4 TMTP_to_TBSM.sh #!/bin/sh if [ "$severity" = "CRITICAL" ]; then $TEC_BIN_DIR/../../TDS/EventService/ihstttec -b "TMTP;5.1" -i "$hostname" -p "$EVENT_CLASS" -s "$severity" -t "EXCEPTION" -q "$origin" -m "$msg" else $TEC_BIN_DIR/../../TDS/EventService/ihstttec -b "TMTP;5.1" -i "$hostname" -p "$EVENT_CLASS" -s "HARMLESS" -t "EXCEPTION" -q "$origin" -m "$msg" fi fi 4.7.3 IBM Tivoli NetView rules Class files for NetView related events are provided from IBM Tivoli Enterprise Console by default. We need to define forwarding rules to IBM Tivoli Business Systems Manager. As discussed in 4.7.2, “IBM Tivoli Monitoring for Transaction Performance rules” on page 133, rules are coded to forward events using ihstttec exit. A sample NetView event is shown in Figure 4-43 on page 137. 136 Business Service Management Best Practices Figure 4-43 Detailed NetView event The NetView event that we want to forward only relates to Server interface events. These events have a class of TEC_ITS_NODE_STATUS. The mappings that we perform from the ihstttec exit are: -b (TBSM class) NetView;7.1.4 -m (message) from msg slot -h (hostname) parsed from jobName slot -i hostname -d hostname -p from sub-origin slot contain class name -s (severity) from severity slot Chapter 4. Business Service Management sample implementation 137 The mapping is performed using the rules shown in Example 4-5. Example 4-5 NetView interface rule rule: forward_netview_event_to_tbsm: ( event: _event of_class within ['TEC_ITS_NODE_STATUS'], reception_action: ( exec_program(_event, 'scripts/netview_tbsm_forward.sh', '', [], 'YES') ) ). rule: forward_netview_manage_event_to_tbsm: ( event: _event of_class within ['TEC_ITS_INTERFACE_MANAGE'], reception_action: ( exec_program(_event, 'scripts/netview_tbsm_forward.sh', '', [], 'YES') ) ). The NetView forwarding script netview_tbsm_forward.sh is shown in Example 4-6. Example 4-6 Sample netview_tbsm_forward.sh #!/bin/sh set -x if [ "$EVENT_CLASS" = "TEC_ITS_INTERFACE_MANAGE" ]; then $TEC_BIN_DIR/../../TDS/EventService/ihstttec -b "NetView Interface;7.1.4" -i "$hostname" -p "DISCOVER" -s "HARMLESS" -t "MSG" -q "$origin" -m "DISCOVER" else if [ "$ifstatus" = "DOWN" ]; 138 Business Service Management Best Practices then $TEC_BIN_DIR/../../TDS/EventService/ihstttec -b "NetView Interface;7.1.4" -i "$hostname" -p "$EVENT_CLASS" -s "$severity" -t "EXCEPTION" -q "$origin" -m "$msg" else $TEC_BIN_DIR/../../TDS/EventService/ihstttec -b "NetView Interface;7.1.4" -i "$hostname" -p "$EVENT_CLASS" -s "HARMLESS" -t "EXCEPTION" -q "$origin" -m "$msg" fi fi 4.7.4 Assembling a new TEC rule base There are default tasks that are set up to customize IBM Tivoli Enterprise Console related to the IBM Tivoli Monitoring, as shown in Table 4-9 on page 133. However, since this process is quite cumbersome, and some of those tasks modify the rule base, ignoring other modifications, we found it is better to include them manually using the following steps. Tip: The steps here present the command line approach. It is possible to use the Tivoli Desktop to perform these steps. 1. Define a new rule base; we call it BSM_rb and allocate the directory under /tivoli/db/rb/BSM_rb: wrb -createrb BSM_rb -d /tivoli/db/rb/BSM_rb 2. Copy the default rule base into BSM_rb: wrb -copyrb BSM_rb Default 3. Import new baroc class files into BSM_rb: wrb -imprbclass <baroc file> BSM_rb 4. Import the new ruleset files into BSM_rb: wrb -imprbrules <rls file> BSM_rb 5. Activate the rule base target domain for the rules: wrb -imptgtrule <rls file> BSM_rb 6. Compile the new rule base: wrb -comprules BSM_rb 7. Load the rule base: wrb -loadrb BSM_rb Chapter 4. Business Service Management sample implementation 139 8. Restart the Event Server: wstopesvr wstartesvr 4.7.5 IBM Tivoli Business Systems Manager customization This section discusses customization for IBM Tivoli Business Systems Manager in this sample Business Service Management implementation. 4.7.6 Defining TBSM object types New objects needs to be defined in IBM Tivoli Business Systems Manager for collecting events from the IBM Tivoli Enterprise Console. For some of the default objects, this can be achieved using the standard installation program provided by IBM Tivoli Monitoring modules. In our configuration, we need to run the installation programs for the following modules in the IBM Tivoli Business Systems Manager database server: IBM Tivoli Monitoring for Database: DB2 IBM Tivoli Monitoring for Web Infrastructure: Apache Web Server IBM Tivoli Monitoring for Web Infrastructure: WebSphere Application Server When the installation program for these products has been run, the table GEM_LookupCID is shown, as in Figure 4-44 on page 141. 140 Business Service Management Best Practices Figure 4-44 GEM_LookupCID Additionally, we need to define custom objects that are not implemented from the IBM Tivoli Monitoring modules. The following objects are not defined by default: Windows Operating System health UNIX Operating System health IBM Tivoli Monitoring for Transaction Performance: QOS objects IBM Tivoli Monitoring for Transaction Performance: STI objects We define generic objects to represent these objects and place them under the appropriate network node object. Here is how we define the additional object types: 1. Define the product structure: gemgenprod.sh gemgenprod.sh gemgenprod.sh gemgenprod.sh -S -S -S -S BSM1 BSM1 BSM1 BSM1 -U -U -U -U sa sa sa sa -P -P -P -P sa sa sa sa -m -m -m -m ITSO ITSO ITSO ITSO -p -p -p -p WinOS -v 1.0 UNIXOS -v 1.0 TMTP -v 5.1 NetView -v 7.1.4 Chapter 4. Business Service Management sample implementation 141 2. Define the icon: gemimageimport.sh gemimageimport.sh gemimageimport.sh gemimageimport.sh gemimageimport.sh gemimageimport.sh gemimageimport.sh gemimageimport.sh -S -S -S -S -S -S -S -S BSM1 BSM1 BSM1 BSM1 BSM1 BSM1 BSM1 BSM1 -U -U -U -U -U -U -U -U sa sa sa sa sa sa sa sa -P -P -P -P -P -P -P -P sa sa sa sa sa sa sa sa -p -p -p -p -p -p -p -p UNIXOS -v 1.0 -l -i UNIXOSl.jpg UNIXOS -v 1.0 -s -i UNIXOSs.jpg WinOS -v 1.0 -l -i WinOSl.jpg WinOS -v 1.0 -s -i WinOSs.jpg TMTP -v 5.1 -l -i TMTPl.jpg TMTP -v 5.1 -s -i TMTPs.jpg NetView -v 7.1.4 -l -i NVl.jpg TMTPSTI -v 7.1.4 -s -i NVs.jpg 3. Restart the services using the svc_control -s and svc_control -g commands. 4.7.7 Setting object hierarchy Initial configuration of the IBM Tivoli Business Systems Manager enterprise definition for the Agent listener interface is also recommended to get a consistent result. GEM_EEhostToEnterprise Maps the event enablement host name to the Enterprise object. We map our machine ibmtiv1 to ITSO enterprise. GEM_LocationToRegion The Network Region object name is derived from the location. The default derivation is to take the second qualifier of the location name. GEM_HostnameToLocation The TCP/IP host name is used to obtain the Network Location parameter. The default location is derived from the second and third part of the TCP/IP host name. The contents of these tables are shown in Figure 4-45 on page 143. 142 Business Service Management Best Practices Figure 4-45 Name mapping tables With that structure in place, and our IP domain called itsc.austin.ibm.com®, the final structure of the object will be: ITSO enterprise -> austin -> itsc.austin as shown in Figure 4-46. Figure 4-46 IBM Tivoli Business Systems Manager hierarchy Chapter 4. Business Service Management sample implementation 143 4.7.8 Defining business systems Tip: Although we showed our approach using a step-by-step definition and opening up all event flows at once, most of the time it is much better to let the event flow gradually and just build from there. Once all the definitions are in place, you can stop the event flow and delete all object instances in the IBM Tivoli Business Systems Manager database, then start the discovery process again. Since we used only the IBM Tivoli Enterprise Console interface, this approach is possible. If you are also using a Common Listener interface, you need to synchronize the status with the discovery status in the Common Listener. Also note that the IBM Tivoli Monitoring module stores discovery states in a file; this file needs to be adjusted. We create the business system definition using the Automated Business System function of IBM Tivoli Business Systems Manager. The ABS processing schematic is shown in Figure 4-47. Config file absConfig.ksh alobListPattern alobListCriteriaAlob dynamic_object_create_path_detail dynamic_object_create_path Update ObjPathCache ABS Discovery Process ABS Creation Process evQueueObject alobQueueCreateLOB ev_auto_create_object_parm ObjPathCache Object creation or update triggers tI_EV<cid>_C tU_EV<cid>_C tU_EV<cid>_A ABS Table Purge Figure 4-47 ABS processing 1. A trigger captures the modification, and the new or changed attribute data is queued in the table evQueueObject. 2. The UpdateObjPathCache job runs as scheduled (15 minutes by default) and updates the resource relationships in the table ObjPathCache. 3. The ABS Discovery Process job, scheduled every minute, checks the evQueueObject table and, if the criteria provided in the last configuration file have been met, populates the tables alobQueueCreateLob and ev_auto_create_object_param with the new data. This job processes only the 144 Business Service Management Best Practices events with a ctime lower than or equal to the start time of the last successful completion of the UpdatePathCache job. Events created after this time will be queued until the next successful running of the UpdateObjPathCache job. 4. The ABS Creation Process job, scheduled every minute, processes the data stored in the tables populated by the ABS Discovery Process job and creates or updates the BSV. 5. The ABS Table Purge job, scheduled to run occasionally, removes data older than 30 days from the tables used by the automated BSV processing system. The configuration file for this Automated Business System is shown in Example 4-7. Example 4-7 Automated Business System configuration PatternList ListName Operand Pattern Pattern 1 2 3 4 5 6 7 8 9 10 11 12 13 Class G02U G029 G02G G02W WNPC G02G G02G G02W NODE G02U G029 G02D G02G Attribute TCPHost TCPHost name TCPHost name name name name name name name name name CriteriaToPattern Criteria Pattern 1001 1 1002 2 1003 3 1004 4 1005 5 1006 6 1007 7 1008 8 1009 9 1010 10 1011 11 1012 12 1013 13 When Current Current Current Current Current Current Current Current Current Current Current Current Current Operator LIKE LIKE LIKE LIKE LIKE LIKE LIKE LIKE LIKE LIKE LIKE LIKE LIKE Operand1 Operand2 % BSM% TRADE3% BSM% BSM% TEC% ITM% % % % % % % PatternRelated 1 2 3 4 5 6 7 8 9 10 11 12 13 Chapter 4. Business Service Management sample implementation 145 Path Path PP_0_0 PP_0_1 PP_0_2 PP_0_3 PP_0_4 PP_0_5 PP_0_6 PP_0_0 PP_0_1 PP_0_2 PP_0_3 PP_0_4 PP_0_0 PP_0_1 PP_0_2 PP_0_3 PP_0_4 PP_0_3 PP_0_4 PP_0_5 PP_0_5 PP_0_6 PP_0_6 PP_1_0 PP_1_1 PP_1_2 PP_1_3 PP_1_4 PP_1_5 PP_1_0 PP_1_0 PP_1_1 PP_1_1 PP_1_2 PP_1_3 PP_1_2 PP_1_3 PP_1_4 PP_1_5 PP_1_4 PP_1_5 Level 1 1 1 1 1 1 1 2 2 2 2 2 3 3 3 3 3 4 4 2 3 2 3 1 1 1 1 1 1 2 3 2 3 2 2 3 3 2 2 3 3 CriteriaToPath Criteria Path 1001 PP_0_0 1002 PP_0_1 146 Name All systems All systems All systems All systems All systems All systems All systems Web Store Web Store Web Store Web Store Web Store Servers Servers Finance Supplier IT Resources IT Resources IT Resources IT Resources IT Resources IT Resources Networking Servers Web resources Web resources Databases Databases Level 3 3 Pattern 1 2 Business Service Management Best Practices Variable Value name <1:name> name <2:name> 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 PP_0_2 PP_0_3 PP_0_4 PP_0_5 PP_0_6 PP_1_0 PP_1_1 PP_1_2 PP_1_3 PP_1_4 PP_1_5 3 4 4 3 3 3 3 3 3 3 3 3 4 5 6 7 8 9 10 11 12 13 name name name name name name name name name name name <3:name> <4:name> <5:name> <6:name> <7:name> <8:name> <9:name> <10:name> <11:name> <12:name> <13:name> The configuration file can be defined manually or using the Java tool as discssed in the redbook Tivoli Business Systems Manager V2.1 End-to-end Business Impact Management, SG24-6610. The tool can be downloaded from: ftp://www.redbooks.ibm.com/redbooks/sg246610/ABSjava.zip We load the Automated Business System configuration using the following procedure: 1. Load the Automated Business System definition using the command: sh absconfig.ksh -SBSM1 -Usa -Psa -iBSMBSV.txt 2. Activate the SQL Server Agent jobs from the Enterprise Manager for the following jobs: – UpdateObjPathCache – ABS Discovery Process – ABS Creation Process 3. As an IBM Tivoli Business Systems Manager Super Administrator, open the Business System View and close all other views except All Business Systems. Select Console -> Save Workspace to save the workspace. 4.7.9 Defining TBSM operators IBM Tivoli Business Systems Manager operators are defined using Windows user definitions from the IBM Tivoli Business Systems Manager Console Server. The user definition is then connected to an IBM Tivoli Business Systems Manager specific Windows group to get the appropriate roles. We define operators by using the following steps: 1. From the My Computer icon, right-click and select Manage; alternatively, you can click Administrative Tools -> Computer Management. Chapter 4. Business Service Management sample implementation 147 2. In the Computer Management Window, select Local User and Group -> Users in the tree view, then select Action -> New User; this is shown in Figure 4-48. Figure 4-48 Defining a new user 3. Specify the new user’s attributes as shown in Figure 4-49. Figure 4-49 Defining a user 148 Business Service Management Best Practices 4. Click Create; the user will be created. You are still in the New User dialog and can create another user. 5. When you are done creating users, go to the Groups folder. Select the IBM Tivoli Business Systems Manager groups (TBSM_Operators) , right-click and select Properties as shown in Figure 4-50. Figure 4-50 Group list 6. The group property dialog is shown in Figure 4-51 on page 150. Click Add and specif y the users that should be in the group. Chapter 4. Business Service Management sample implementation 149 Figure 4-51 Group property dialog 7. Associating Business System View with operators is done by authorizing the operator to use a Workspace. As a IBM Tivoli Business Systems Manager super administrator, open the Console. Click Console -> Open Workspace and you will be presented with the workspace list as shown next. Figure 4-52 Open workspace list 8. Click Edit and the list of available users with the role of operator or restricted operator will be shown, as in Figure 4-53 on page 151. 150 Business Service Management Best Practices Figure 4-53 Selecting users for the workspace 4.8 Configuring Tivoli Data Warehouse Data needs to be collected into the Tivoli Data Warehouse. This data is extracted from the source databases, which are product-specific databases from each of the products. The data collection that we perform is shown in Figure 4-54. ITM_DB AM GW W, A, AMX IZ , A Y, CT MY D DYK_CAT GTM Objects DYK TWH_CDW M BW DYK_DM WSC_DB Figure 4-54 Data collection Chapter 4. Business Service Management sample implementation 151 As shown In Figure 4-54 on page 151, the collection is performed from our data sources: ITM_DB: historical database from IBM Tivoli Monitoring; since this database contains all IBM Tivoli Monitoring data, information from IBM Tivoli Monitoring for Database and IBM Tivoli Monitoring for Web Infrastructure products are also stored here. Objects: IBM Tivoli Business Systems Manager objects database in Microsoft SQL Server contains data about Business System Views states. WSC_DB: Web Services Courier contains response time information from the Web-based transaction. The data collection is performed using the Extract-Transform-Load (ETL) programs supplied with each product. These ETLs are indicated using three-letters AVA codes as shown in Figure 4-54 on page 151. These AVA codes represent the products, like so: AMX IBM Tivoli Monitoring based components AMY IBM Tivoli Monitoring for Operating Systems IZY IBM Tivoli Monitoring for Web Infrastructure: WebSphere Application Server GWA IBM Tivoli Monitoring for Web Infrastucture: Apache HTTP Server CTD IBM Tivoli Monitoring for Databases: DB2 GTM IBM Tivoli Business Systems Manager BWM IBM Tivoli Monitoring for Transaction Performance: Web Performance DYK IBM Tivoli Service Level Advisor 4.8.1 Collecting information from IBM Tivoli Monitoring IBM Tivoli Monitoring data collection needs to have the data collection feature installed in the Tivoli Framework. The data collection collects data in the historical database, typically called ITM_DB, using a set of RIM objects. A RIM object is a Tivoli Management Framework resource used to communicate with a relational database. The IBM Tivoli Monitoring data is collected from the Tivoli Management Framework gateway. The gateway collects historical information from the endpoints and stores them locally. Every midnight, it loads the historical data into the ITM_DB using a RIM object called itm_rim_<nodename>. For example, our gateway ibmtiv1 collects data using RIM itm_rim_ibmtiv1. For IBM Tivoli Monitoring, we need to enable the data collection feature to start collecting historical data. This is achieved using the following procedure: 152 Business Service Management Best Practices 1. Define the database schema using the files under $BINDIR/TME/Tmw2k/TDS/rdbcfg; the files are: cr_db cr_tbl twh_enabl_update Creating the database Creating the schema Enabling update for warehouse database 2. Define the RIM object using the wcrtrim command. For our DB2 UDB in the AIX environment, we run the following command: wcrtrim -v DB2 -h ibmtiv1 -d ITM_DB -u db2inst1 -H /usr/lpp/db2_07_01 -I /home/db2inst1 itm_rim_ibmtiv1 3. Define data collection parameters using the wdmconfig command: wdmconfig -m ibmtiv1 -D datacollector.db_purge_interval = 40 -D datacollector.rim_name = itm_rim_ibmtiv1 -D datacollector.delay = 1 -D datacollector.sleep_time = 1 The configuration is stored in the file $DBDIR/dmml/.config. 4. Initiate data collection using the wdmcollect command; to initiate collection from endpoint BSM2 every two hours, use the command: wdmcollect -e BSM2 -s 2 You can see the XML file result under $DBDIR/dmml/tedw/datacollector.status. 4.8.2 Collecting information from Web Services Courier Data collected by the IBM Tivoli Monitoring for Transaction Performance can be collected into the historical database hosted by the Web Services Courier. The collection set up is performed using the Web browser interface. Use the following procedure: 1. Use a Web browser and log on to the IBM Tivoli Monitoring for Transaction Performance’s Internet Management Server. Supply the appropriate user ID and password; click Logon. 2. From the portfolio menu, select Historical Data Collection -> Configure Data collection. 3. Set the time that the data collection job will run and load the relational database into the Web Services Courier, then click Save. See Figure 4-55 on page 154. Chapter 4. Business Service Management sample implementation 153 Figure 4-55 Configure Data collection for Internet Management function 4.8.3 Enabling ETL in Tivoli Data Warehouse The ETL programs are installed using the Tivoli Data Warehouse installation programs. ETL programs and processes are managed using the IBM DB2 Data Warehouse Center. Data Warehouse Center is launched from the DB2 control center. You start the DB2 control center using the command db2cc. From the DB2 control center, select Tools -> Data Warehouse Center. The following steps need to be followed after the ETLs have been installed. 1. Setting up ODBC connection to data sources – For the DB2 database, use the DB2 Client Configuration Assistant. Issue the command db2cca to start it. Click the Add button to start the Add database wizard. Our DB2 Client Configuration Assistant window is shown in Figure 4-56 on page 155. 154 Business Service Management Best Practices Figure 4-56 DB2 Client Configuration Assistant – For the IBM Tivoli Business Systems Manager Objects database in Microsoft SQL Server, use the ODBC Connection Manager applet under Administrative Tools -> Data Sources (ODBC). The ODBC applet is shown in Figure 4-57. Figure 4-57 ODBC System DSN list 2. Start DB2 Control Center using the command db2cc. From the DB2 control center, select Tools -> Data Warehouse Center as shown in Figure 4-58 on page 156. Chapter 4. Business Service Management sample implementation 155 Figure 4-58 DB2 Control Center to invoke Data Warehouse Center 3. Enter your DB2 administrator user ID and password. Select the Advanced button and ensure that the control database name is TWH_MD instead of DWCTRLDB. Click OK and then OK again. This is shown in Figure 4-59. Figure 4-59 Login to Data Warehouse Center 4. From the Data Warehouse Center, expand the Warehouse Sources and Warehouse Targets folders and update all the database definitions. Right-click each definition and select Properties as shown in Figure 4-60 on page 157. 156 Business Service Management Best Practices Figure 4-60 Opening database property 5. Change the database property pages for all the database sources and targets under the folders Warehouse Source and Warehouse Target. Enter the appropriate user ID for the databases. A sample property page for a source database is shown in Figure 4-61. Figure 4-61 Data source properties Chapter 4. Business Service Management sample implementation 157 6. Now expand the Subject Areas folder. It will show the ETL processes. Expand the processes until you reach the specific steps. Right-click and select Schedule as shown in Figure 4-62. Figure 4-62 Defining schedule 7. Put in the daily schedule with a specific start time. The overview schedule is shown in Figure 4-8 on page 98. Since it is based also on the time estimate in Figure 4-7 on page 98, we will use the schedule in Table 4-10. The table only contains processes necessary for IBM Tivoli Service Level Advisor. Table 4-10 Time schedule for collection process Process name Start time AMX_c05_ETL1_Process 00:20 BWM_c10_Load_Warehouse_Process 23:40 DYK_m05_Populate_Registration_Datamart_Process 01:00 DYK_m10_Populate_Measurement_Datamart_Process 01:30 GTM_c05_LOBState_Process 23:00 The schedule definition dialog is shown in Figure 4-63 on page 159. 158 Business Service Management Best Practices Figure 4-63 Schedule definition dialog 8. Back in the ETL processes, now we can promote the mode of processing to Production. Setting the mode to Production means that all the changes are final and the ETL will be processed by schedule. The promote menu is shown in Figure 4-64 on page 160. Chapter 4. Business Service Management sample implementation 159 Figure 4-64 Promoting ETL process 4.9 Customizing IBM Tivoli Service Level Advisor This section discusses customization for IBM Tivoli Service Level Advisor in our Business Service Management implementation. 4.9.1 Defining the operation Administrative functions for IBM Tivoli Service Level Advisor are performed through the IBM Console. The IBM Console interface is typically installed in the SLA Server. Point your Web browser to the IBM Tivoli Service Level Advisor server; we use port 9008 with the URL http://bsm6:9008/IBMConsole as shown in Figure 4-65 on page 161. 160 Business Service Management Best Practices Figure 4-65 Login to IBM Console The main window of IBM Tivoli Service Level Advisor is shown in Figure 4-66. Figure 4-66 Main window of IBM Tivoli Service Level Advisor Chapter 4. Business Service Management sample implementation 161 The menu items (or portfolio) in Figure 4-66 on page 161 include the following functions: User and roles administration IBM Console Work with report Administer Service offering Administer customer Administer SLM The following users need to be defined: Service Level Manager Business process owners or Business process managers IT manager(s) Chief Information Officer 162 Business Service Management Best Practices Abbreviations and acronyms ABS Automated Business Systems TDS Topology Display Services AIX Advanced Interactive Executive TDW Tivoli Data Warehouse TEC IBM Tivoli Enterprise Console BSV Business System View TEDW CDW Central Data Warehouse Tivoli Enterprise Data Warehouse CIO Chief Information Officer TMR Tivoli Management Region CPU Central Processing Unit TMTP DB2 Database 2™ IBM Tivoli Monitoring for Transaction Performance EJB Enterprise Java Bean TSLA ETL Extract Transform Load IBM Tivoli Service Level Advisor HTTP Hypertext Transfer Protocol UDB Universal Database IBM International Business Machines Corp. URI Universal Resource Identifier URL Universal Resource Locator ITSO International Technical Support Organization JVM Java Virtual Machine LOB Line of Business ODBC Open Database Connectivity OLAP Online Analytical Processing QOS Quality of Service RDBMS Relational Database Management Systems RIM RDBMS Interface Module SLA Service Level Agreement SLM Service Level Management SNMP Simple Network Management Protocol SQL Structured Query Language STI Synthetic Transaction Investigator TBSM IBM Tivoli Business Systems Manager TCP/IP Transmission Control Protocol Internet Protocol © Copyright IBM Corp. 2004. All rights reserved. 163 164 Business Service Management Best Practices Related publications The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook. IBM Redbooks For information on ordering these publications, see “How to get IBM Redbooks” on page 166. Note that some of the documents referenced here may be available in softcopy only. 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 Tivoli Business Systems Manager V2.1 End-to-end Business Impact Management, SG24-6610 Introducing IBM Tivoli Service Level Advisor, SG24-6611 Introduction to Tivoli Enterprise Data Warehouse, SG24-6607 Planning a Tivoli Enterprise Data Warehouse Project, SG24-6608-00 Other publications These publications are also relevant as further information sources: Release notes: – Tivoli Management Framework Release Notes v4.1, GI11-0890-00 – IBM Tivoli Monitoring Release Notes v5.1.1, GI10-5797-02 – IBM Tivoli Enterprise Console Release Notes v3.8, GI11-0777-02 © Copyright IBM Corp. 2004. All rights reserved. 165 – IBM Tivoli NetView 7.1.3 for UNIX Release Notes, GI11-0927-02 – IBM Tivoli Workload Scheduler Release Notes v8.2.0, SC23-1277-00 – IBM Tivoli Business Systems Manager Release Notes v2.1.1, SC23-4841-01 – Tivoli Enterprise Data Warehouse Release Notes v1.1, GI11-0857-00 – Release Notes for IBM Tivoli Service Level Advisor v1.2.1, SC09-7777-02 Installation guides: – Tivoli Management Framework Enterprise Installation Guide v4.1, GC32-0804-00 – IBM Tivoli Enterprise Console Installation Guide v3.8, GC32-0823-00 – IBM Tivoli Monitoring Road Map Typical Installation v5.1, GI11-0938-00 – IBM Tivoli Monitoring for Databases Installation and Setup Guide v5.1.1, SC23-4854-00 – IBM Tivoli Business Systems Manager Installation and Configuration v2.1, GC32-0800-00 – Tivoli Enterprise Data Warehouse Installing and Configuring v1.1, GC32-0744-00 – Administrator's Guide for IBM Tivoli Service Level Advisor v1.2.1, SC32-1250-00 How to get IBM Redbooks You can search for, view, or download Redbooks, Redpapers, Hints and Tips, draft publications and Additional materials, as well as order hardcopy Redbooks or CD-ROMs, at this Web site: ibm.com/redbooks Help from IBM IBM Support and downloads ibm.com/support IBM Global Services ibm.com/services 166 Business Service Management Best Practices Index A ABS 74 ABS Creation Process job 145 ABS Discovery Process job 144 ABS Table Purge job 145 absconfig.ksh 147 access.log 73 AIX 35 AMX 152 AMY 152 Apache 108 applications 50 automated business system 74 automation 5 Automation Blueprint mapping 18 automation blueprint 4 availability 6 B baroc files 132 base services 21 book organization 10 BSV 74 BSV structure grouped resources 77 inverted hierarchy 77 no hierarchy 77 original hierarchy 77 Business Driven organization 2 business intelligence reporting 33 business process decomposition 48 business processes 50 business schedule 85 Business Service Management 8 concepts 12 deployment option 16 design 61 implementation consideration 15 information collection 47 planning overview 44 business system 75 Business System View 24 © Copyright IBM Corp. 2004. All rights reserved. Business System View design 74 Business System View structure 95 BWM 152 C CDW See central data warehouse commands gemgenprod 141 gemimageimport 141 nvwcinstal 118 svc_control 142 wcrtrim 153 wdmcollect 153 wdmconfig 153 wrb 139 wstartesvr 140 wstopesvr 140 Common Warehouse Metadata 30 component 84 component relationship 53 Console server 23 Control server 33 correlation 30 Crystal Decisions 30 CTD 152 current monitoring environment 56 customer 83 D data collection design 80, 96 Data mart 33 data mining 33 data warehouse sizing 81 database monitoring 110 Database server 22 DB2 Administration Client 35 DB2 Application Development Client 35 DB2 database 35 DB2 Enterprise Edition 35 decomposition 48 deployment option 16 discussion scope 9 167 Distributed resource feeds 22 DM object 27 download page 117 DYK 152 E end-to-end view 30 environment 88 ETL 152 ETL programs 32, 80 ETL run schedule 98 Event Handler server 23 Event propagation 26 evolution 2 Extract 32 Extract, Transform and Load See ETL Extract-Transform-Load 152 L F forwarding 116 G gemgenprod 141 gemimageimport 141 Generic object types 28 Graphical report 29 GTM 152 GWA 152 H hardware configuration 63 Health Monitor Server 23 historical data 30 History server 22 Host Integration server 23 hostname 30 I IBM Tivoli Business Systems Manager 20 Base Services 21 components 23 consideration 67 object types 27 overview 20 servers 22 IBM Tivoli Monitoring for Transaction Performance 168 121 IBM Tivoli Service Level Advisor 36 components 38 data repositories 40 databases 40 flow 37 overview 36 ihstttec 28 ihstztec 27 Indication window 105 informal SLA 54 information collection 47 information provider 45 integration 5 interview roles 45 IP address 30 IT organization 2 IZY 152 Business Service Management Best Practices lines of business 14 Load 32 LOB 14 logging option 106 M Mainframe resources feeds 22 Managed Node 116 measurement 84 metadata interchange 30 metric 84 monitoring implementation 93 monitoring scheme 68 monitoring solution consideration 58 monitoring standard 68 N NetView commands nvsetup 112 ovaddobj 112 NetView console 113 non-Tivoli applications 31 nvsetup 112–113 nvwcinstal.exe 118 O Object discovery 26 Object Management Group 30 object type granularity 73 object type selection 69 offering 84 offering component 84 OLAP analysis 33 OLAP tools 29 on demand environment 4 open interface 30 optimization 6 order 85 ovaddobj 112 P parameter setting 106 period 85 personnel roles 45 product mapping 18 Profile Manager 93, 101 Profiles 93 profiles 93 Propagation server 23 provisioning 6 Q Quality of Service 121 quantifiable objective 13 R raw data 30 Realm 83 real-world implementation 92 recorder 126 Redbooks Web site 166 Contact us xi relationship 53 reliance 6 Resource Model 104 RI See Report Interface roles 114 rule base 132 rulesets 132 S scalable architecture 31 schedule 85, 98 Service Level Agreement 54 Service Level Management 13, 41 life cycle 41 Service Level monitoring 98 Service Level objective 13, 54 Service Management 7 Site Investigator 73 sizing 81 sizing information 97 SmartSets 117 Solaris 35 solution design 61 standard RDBMS technology 31 STI recorder 126 svc_control 142 Synthetic Transaction Investigator 121 T Tabular report 29 TBSM commands absconfig 147 TBSM tables GEM_EEHostToEnterprise 142 GEM_HostnameToLocation 142 GEM_LocationToRegion 142 TEC forwarding 116 Tivoli Data Warehouse 28 benefit 30 components 31 overview 28 Tivoli Enterprise Data Warehouse data mart 33 ETL processes 33 ETL programs 32 source applications 32 warehouse packs 32 Tivoli Management Framework consideration 66 TMW_Clearing 93 Tmw2k profiles 93 top-down deployment 16 Transform 32 Types of ETLs Central Data Warehouse 32 data mart 32 sample environment 88 Index 169 U UNIX Server 112 UpdateObjPathCache 144 V virtualization 5 W warehouse pack 32 wcrtrim 153 wdmcollect 153 wdmconfig 153 Web Console application server 23 Web Console Security 113 Web Server monitoring 108 WebSphere Application Server 109 Windows 2000 35 Windows NT 35 Windows Server 111 wrb 139 wstartesvr 140 wstopesvr 140 170 Business Service Management Best Practices Business Service Management Best Practices (0.2”spine) 0.17”<->0.473” 90<->249 pages Back cover ® Business Service Management Best Practices All you need to understand Business Service Management Business process mapping to monitoring and service level Integration of IBM TBSM and IBM TSLA 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 which enables IT management to be related to the business. INTERNATIONAL TECHNICAL SUPPORT ORGANIZATION The ultimate goal of the IT infrastructure is to leverage its value to support the business. The IT infrastructure management should then be aimed at minimizing disruption to business processes and functions. This goal is realized with the Business Service Management (formerly also called Business Impact Management). BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE 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. IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment. For more information: ibm.com/redbooks SG24-7053-00 ISBN 0738497975
© Copyright 2024