A design and implementation guide for tivoli decision support sg245499

SG24-5499-00

International Technical Support Organization

www.redbooks.ibm.com

A Design and Implementation Guidefor Tivoli Decision Support

Edson Manoel, Fernando Bergamo, Dave Hulse, Rakesh Parshotam

A Design and Implementation Guidefor Tivoli Decision Support

October 1999

SG24-5499-00

International Technical Support Organization

© Copyright International Business Machines Corporation 1999. All rights reserved.Note to U.S Government Users – Documentation related to restricted rights – Use, duplication or disclosure issubject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

First Edition (October 1999)

This edition applies to Tivoli Framework Version 3.6.1, Tivoli Enterprise Console Version 3.6.1, TivoliDistributed Monitoring Version 3.6.1, Tivoli Service Desk Version 5.02, Tivoli Decision Support Version2.0 for use with the AIX Version 4.3 and Windows NT 4.0 Operating Systems

Comments may be addressed to:IBM Corporation, International Technical Support OrganizationDept. OSJB Building 003 Internal Zip 283411400 Burnet RoadAustin, Texas 78758-3493

When you send information to IBM, you grant IBM a non-exclusive right to use or distribute theinformation in any way it believes appropriate without incurring any obligation to you.

Before using this information and the product it supports, be sure to read the general information inAppendix D, “Special notices” on page 191.

Take Note!

Contents

Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xi

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiThe team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiComments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 From fire fighting to business intelligence . . . . . . . . . . . . . . . . . . . . . . . 11.2 The desired solution for business information. . . . . . . . . . . . . . . . . . . . 31.3 Decision Support Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Positioning Tivoli Decision Support in the decision making process . . . 51.5 Our approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Chapter 2. Tivoli Decision Support general overview . . . . . . . . . . . . . . 92.1 Overview of Tivoli Decision Support . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Tivoli Decision Support product components . . . . . . . . . . . . . . . . . . . 10

2.2.1 Tivoli Decision Support Discovery Administrator . . . . . . . . . . . . . 112.2.2 Tivoli Decision Support Server component . . . . . . . . . . . . . . . . . 122.2.3 Tivoli Decision Support Discovery Interface . . . . . . . . . . . . . . . . 122.2.4 Cognos PowerPlay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.5 Crystal Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.6 Tivoli Decision Support Discovery Guides . . . . . . . . . . . . . . . . . 12

2.3 Tivoli Decision Support implementation modes . . . . . . . . . . . . . . . . . 142.4 Supported platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.5 Concepts and terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.6 How Tivoli Decision Support works. . . . . . . . . . . . . . . . . . . . . . . . . . . 192.7 Who is making use of Tivoli Decision Support? . . . . . . . . . . . . . . . . . 21

Chapter 3. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.1 Tivoli Implementation Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2 Implementing Tivoli Decision Support. . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.1 Requirements gathering phase . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.2 Systems analysis phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2.3 Project planning phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.2.4 Deployment phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2.5 Testing phase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.2.6 Documentation phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Chapter 4. TDS architecture and design considerations . . . . . . . . . . . 594.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

© Copyright IBM Corp. 1999 iii

4.2 Integrating Decision Support with Tivoli Enterprise applications . . . . . 604.3 Tivoli Decision Support components. . . . . . . . . . . . . . . . . . . . . . . . . . 614.4 Integrating Tivoli Decision Support components . . . . . . . . . . . . . . . . . 63

4.4.1 The cube-building process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.4.2 The Discovery Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.5 Stand-alone vs. network architecture . . . . . . . . . . . . . . . . . . . . . . . . . 704.6 Suggested architecture and design solutions . . . . . . . . . . . . . . . . . . . 72

4.6.1 Tivoli Service Desk environment - Case study . . . . . . . . . . . . . . 724.6.2 Single TMR environment - Case study . . . . . . . . . . . . . . . . . . . . 744.6.3 Multiple TMR environment - Case study . . . . . . . . . . . . . . . . . . . 77

4.7 Troubleshooting tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814.7.1 ODBC source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814.7.2 Cube building . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814.7.3 Discovery interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Chapter 5. Case study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.2 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.2.1 Requirements gathering phase . . . . . . . . . . . . . . . . . . . . . . . . . . 865.2.2 Systems analysis and design . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.2.3 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

5.3 The existing Tivoli environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.3.1 Tivoli general architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.3.2 TMR servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.3.3 Endpoint gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.3.4 TEC server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.3.5 RDBMS and RIM hosts configuration . . . . . . . . . . . . . . . . . . . . . 905.3.6 Tivoli DM and monitors for performance and capacity trend data 90

5.4 Identifying the reports requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 925.4.1 Customer reporting requirements . . . . . . . . . . . . . . . . . . . . . . . . 935.4.2 The SDC actual solution for reporting . . . . . . . . . . . . . . . . . . . . . 935.4.3 The Reports of the NCO account . . . . . . . . . . . . . . . . . . . . . . . . 97

5.5 Customer objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1135.6 Mapping Tivoli Decision Support Discovery Guides . . . . . . . . . . . . . 114

5.6.1 Detailed reports mapping workshop . . . . . . . . . . . . . . . . . . . . . 1145.7 Tivoli Decision Support reports and business information . . . . . . . . . 116

5.7.1 Server Performance Prediction Guide. . . . . . . . . . . . . . . . . . . . 1165.7.2 Event Management Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1255.7.3 Domino Management Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . 1285.7.4 Network Element Performance Guide . . . . . . . . . . . . . . . . . . . . 137

5.8 Suggested architecture and solution design . . . . . . . . . . . . . . . . . . . 1405.9 Tivoli Decision Support deployment process . . . . . . . . . . . . . . . . . . 144

5.9.1 Hardware and Software prerequisites installation . . . . . . . . . . . 145

iv A Design and Implementation Guide for TDS

5.9.2 Installation of the Tivoli Decision Support server components. . 1455.9.3 Installation of the Tivoli Decision Support Administrator . . . . . . 1535.9.4 Installation of the Tivoli Decision Support client components . . 1545.9.5 Deploying TDS for server performance prediction. . . . . . . . . . . 1545.9.6 Deploying the Event Management Guide . . . . . . . . . . . . . . . . . 161

5.10 Future reporting requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1625.10.1 Additional reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1625.10.2 Additional recommended TDS Discovery Guides . . . . . . . . . . 163

Chapter 6. Reports and decision information usage . . . . . . . . . . . . . 1676.1 The scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1686.2 The roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

6.2.1 The systems analyst role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1686.2.2 The IT manager role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1696.2.3 The Chief Executive Officer role . . . . . . . . . . . . . . . . . . . . . . . . 169

6.3 The discovery process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1696.3.1 The system analyst discovery process . . . . . . . . . . . . . . . . . . . 1696.3.2 IT manager discovery process . . . . . . . . . . . . . . . . . . . . . . . . . 1776.3.3 CEO’s discovery process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

6.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Appendix A. Tivoli Implementation Methodology (TIM) 3.6. . . . . . . . . 185A.1 Target market . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185A.2 Customer profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185A.3 The top three things to remember. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185A.4 What is new with TIM? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186A.5 What is unique? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186A.6 Where can I find information on TIM?. . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Appendix B. Tivoli Decision Support customer support . . . . . . . . . . . 187B.1 The support process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Appendix C. Tivoli Decision Support Discovery Guides availability . 189

Appendix D. Special notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Appendix E. Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195E.1 International Technical Support Organization publications. . . . . . . . . . . 195E.2 Redbooks on CD-ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196E.3 Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

How to get ITSO redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197IBM Redbook fax order form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

v

List of abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

ITSO redbook evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

vi A Design and Implementation Guide for TDS

Figures

1. The evolution to business intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22. The challenge of a better solution for business information. . . . . . . . . . . . . 43. TDS in the decision making process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64. Tivoli Decision Support components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115. Tivoli Decision Support in stand alone implementation mode . . . . . . . . . . 146. Tivoli Decision Support network implementation mode . . . . . . . . . . . . . . . 157. The operation of Tivoli Decision Support . . . . . . . . . . . . . . . . . . . . . . . . . . 208. TIM schematic overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249. Requirements gathering process flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2610. Systems Analysis process flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3111. Typical architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3512. File server information example form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3713. TDS administrator PC information example form . . . . . . . . . . . . . . . . . . . 3814. TDS client PC information example form. . . . . . . . . . . . . . . . . . . . . . . . . . 3815. Database server information example form . . . . . . . . . . . . . . . . . . . . . . . . 3916. Network information example form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4017. Project planning process flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4118. Sample project plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4419. Deployment process flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4820. Testing process flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5221. Documentation process flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5522. Tivoli Decision Support functionality diagram . . . . . . . . . . . . . . . . . . . . . . 6023. Decision Support components integration . . . . . . . . . . . . . . . . . . . . . . . . . 6324. Cube-building process - Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6525. Cube-building process - Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6626. Cube-building process - Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6627. Cube-building process - Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6728. Viewing the multidimensional reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6829. Viewing Crystal Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6930. TDS in stand-alone mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7031. Network installation architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7132. Tivoli Service Desk environment case study . . . . . . . . . . . . . . . . . . . . . . . 7333. Single TMR environment case study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7534. Single TMR environment with Tivoli Decision Support . . . . . . . . . . . . . . . 7635. Multiple TMR environment case study. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7836. Multiple TMR environment with Tivoli Decision Support . . . . . . . . . . . . . . 7937. Service Delivery Center - West architecture . . . . . . . . . . . . . . . . . . . . . . . 8838. Tivoli Distributed Monitoring object relationships. . . . . . . . . . . . . . . . . . . . 9239. The Problem for reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9440. The in-house process for reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

© Copyright IBM Corp. 1999 vii

41. The SRM method for reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9742. In-house performance and capacity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9843. Detailed report - CPU utilization by server. . . . . . . . . . . . . . . . . . . . . . . . . 9944. Detailed report - process memory and paging utilization by server . . . . . 10045. Detailed report - network I/O utilization . . . . . . . . . . . . . . . . . . . . . . . . . . 10146. Detailed report - DASD usage by server . . . . . . . . . . . . . . . . . . . . . . . . . 10247. Percentage availability by server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10348. Detailed alert summary by server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10349. Lotus Notes - Monthly mail server statistics report . . . . . . . . . . . . . . . . . 10450. Lotus Notes - Monthly database server report. . . . . . . . . . . . . . . . . . . . . 10551. Lotus Notes - Daily mail hub report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10652. Lotus Notes - Daily MTA server report. . . . . . . . . . . . . . . . . . . . . . . . . . . 10653. Lotus Notes - Hourly response time report . . . . . . . . . . . . . . . . . . . . . . . 10754. Lotus Notes - Hourly concurrent users report . . . . . . . . . . . . . . . . . . . . . 10755. Lotus Notes - Hourly sessions-per-minute report . . . . . . . . . . . . . . . . . . 10856. Lotus Notes - Hourly mail box size report . . . . . . . . . . . . . . . . . . . . . . . . 10857. Lotus Notes - Hourly SMTP transferred messages report . . . . . . . . . . . . 10958. AIX servers - CPU utilization reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 11059. AIX servers - Hard disk and file systems utilization report . . . . . . . . . . . 11160. AIX servers - Account summary report . . . . . . . . . . . . . . . . . . . . . . . . . . 11161. NT servers - CPU, memory, and disk utilization report. . . . . . . . . . . . . . 11262. NT servers - Account Summary Report . . . . . . . . . . . . . . . . . . . . . . . . . 11363. All System Metrics report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11864. CPU utilization by server report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11965. Memory utilization report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12066. Network I/O utilization report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12167. CPU utilization memory page rates by operating system . . . . . . . . . . . . 12268. Summary report by operating system . . . . . . . . . . . . . . . . . . . . . . . . . . . 12369. CPU average forecast by system purpose . . . . . . . . . . . . . . . . . . . . . . . 12470. Under-provisioned/Over-provisioned servers report . . . . . . . . . . . . . . . . 12571. SLA statistics by event class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12672. Which events take the longest to fix? report . . . . . . . . . . . . . . . . . . . . . . 12773. Event source volume by hour report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12874. Domino network traffic report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13075. Domino server statistics - Mail routed by server report . . . . . . . . . . . . . . 13176. Domino statistics - Total KB transferred report . . . . . . . . . . . . . . . . . . . . 13277. Domino statistics - Number of users report . . . . . . . . . . . . . . . . . . . . . . . 13378. Domino statistics - Mail average delivery time report . . . . . . . . . . . . . . . 13479. Domino statistics - Replication statistics report . . . . . . . . . . . . . . . . . . . . 13580. Domino statistics - Server average delivery time by hour report . . . . . . . 13681. Domino statistics - Mail box file size by server report . . . . . . . . . . . . . . . 13782. Network Element Performance Guide - Cisco CPU utilization report . . . 13883. Network Element Performance Guide - Name server speed by hour . . . 139

viii A Design and Implementation Guide for TDS

84. Network Element Performance Guide-Top ten nodes by transition count14085. Recommended architecture in network mode . . . . . . . . . . . . . . . . . . . . . 14186. The update procedure first script - transfer.cmd . . . . . . . . . . . . . . . . . . . 14787. The update procedure second script - copycubes.cmd . . . . . . . . . . . . . . 14888. The Transfer_Cubes task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14989. Defining the Transfer_Cubes task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14990. The Transfer_Cubes job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15091. Defining the Transfer_Cubes job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15092. The Copy_Cubes task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15193. Defining the Transfer_Cubes task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15194. The Copy_Cubes job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15295. Defining the Transfer_Cubes job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15296. Scheduling the jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15397. Scheduled jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15398. Lotus Notes mail servers by CPU utilization . . . . . . . . . . . . . . . . . . . . . . 17199. Lotus Notes Mail Servers daily average run length cue. . . . . . . . . . . . . . 172100.Lotus Notes mail servers by memory utilization . . . . . . . . . . . . . . . . . . . 173101.Lotus Notes mail servers that need more memory . . . . . . . . . . . . . . . . . 174102.Lotus Notes mail servers by network utilization . . . . . . . . . . . . . . . . . . . 175103.Lotus Notes mail server - forecasted average mail delivery time . . . . . . 176104.Under-provisioned and over-provisioned Notes servers . . . . . . . . . . . . . 178105.Performance anomalies by server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179106.Lotus Notes server approaching critical thresholds. . . . . . . . . . . . . . . . . 180107.Lotus Notes server daily average performance trends . . . . . . . . . . . . . . 182

ix

x A Design and Implementation Guide for TDS

Tables

1. Requirements gathering phase items . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262. Systems analysis phase items. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313. Minimum configuration table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364. Project planning phase items. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405. TDS workshop summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466. Deployment phase items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477. TDS deployment guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488. Testing phase items. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529. Documentation phase items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5510. The TDS Discovery Guides mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11411. Detailed mapping reference table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11512. Macro procedure for deploying TDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14413. Minimum hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14514. TDS file server deployment steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14615. SPP Discovery Guide installation steps. . . . . . . . . . . . . . . . . . . . . . . . . . 15416. DM Roll-up installation steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15617. Event Management Discovery Guide installation steps. . . . . . . . . . . . . . 16118. Future requirements reference table . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16319. TDS Discovery Guides general availability . . . . . . . . . . . . . . . . . . . . . . . 189

© Copyright IBM Corp. 1999 xi

xii A Design and Implementation Guide for TDS

Preface

Deploying a Tivoli Decision Support solution requires careful planning andincludes numerous activities.

The primary objective of this redbook is to describe the methodology used todeploy and migrate from the current reporting tools to Tivoli Decision Supportby using an IBM service delivery center as a case study. In addition, we willdescribe how decision makers with different roles and responsibilities canbenefit from Tivoli Decision Support and make better decisions by simulatingtypical problems in IT business.

This redbook is targeted at the technical professional responsible formigrating from the current reporting tools used in his or her organization toTivoli Decision Support and will be available as a reference book upon thedeployment of Tivoli Decision Support.

This redbook is a valuable addition to existing product documentation and isaimed at both architects and implementors of enterprise systemsmanagement solutions.

This redbook should be read in conjunction with the product documentation,which complements some of the concepts explained in this book.

The team that wrote this redbook

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

Edson Manoel is an Advisory ITSO representative working as a projectleader at the International Technical Support Organization, Tivoli Group,Austin Center. He applies his extensive field experience as an I/T TivoliSpecialist to his work at the ITSO where he writes extensively on all areas ofsystems management. Prior to joining the ITSO, Edson worked in IBM Brazil’sProfessional Services Organization as an I/T Architect where he was involvedin numerous projects designing and implementing systems and networkmanagement solutions for major IBM Brazil customers.

Fernando Bergamo is an I/T Specialist working in the Technology andAutomation Group at the IBM Technology Center, Brazil. He holds aComputer Engineering degree from the State University of Campinas(UNICAMP). His areas of expertise include system management, networking,database administration, data warehousing, and all Tivoli core applications.

© Copyright IBM Corp. 1999 xiii

He is currently working on deploying Tivoli enterprise solutions for severalIBM customers in Brazil.

Dave Hulse is an Advisory IT Specialist working at IBM Global ServicesJohannesburg, South Africa. He has over 20 years of experience in the ITindustry. He has been with IBM for 18 months and, during that time, wasproject leader responsible for the design and deployment of the largest Tivoliimplementation in Southern Africa. His areas of expertise include designingcustomer IT solutions, and he has extensive experience in the field ofsystems management.

Rakesh Parshotam is an Advisory IT Specialist working as a Tivoli Architectat IBM Global Services in South Africa. He holds a degree in ComputerScience and is a Certified Tivoli Consultant and Microsoft Certified SystemsEngineer. He has been working with Tivoli for the past three years and hasheld various positions including Technical Team Leader for major Tivolisystems management deployment projects in South Africa.

The team would like to express special thanks to Ling Tai, Senior SoftwareEngineer working for Tivoli in Raleigh, for her major contribution to this book.

Thanks also go to the following people for their invaluable contributions to thisproject:

Kim QuernerTivoli Systems, Austin

Bill MelolingTivoli Systems, Raleigh

Lisa Chaves, Axel ElfnerIBM, Tucson

Shawn Eldridge, Douglas FuzieTivoli Systems, Indianapolis

Temi RoseInternational Technical Support Organization, Austin Center

Milos RadosavljevicInternational Technical Support Organization, Austin Center

xiv A Design and Implementation Guide for TDS

Comments welcome

Your comments are important to us!

We want our redbooks to be as helpful as possible. Send us your commentsabout this or other redbooks in one of the following ways:

• Fax the evaluation form found in “ITSO redbook evaluation” on page 209to the fax number shown on the form.

• Use the online evaluation form found at http://www.redbooks.ibm.com/

• Send your comments in an internet note to [email protected]

xv

xvi A Design and Implementation Guide for TDS

Chapter 1. Introduction

This redbook was written with the input and experience of many people, andthe result is a suggested approach that may apply directly to your situation orcan be a guide to anyone involved in implementing Tivoli Decision Support ina large-scale environment.

Enterprises usually have some reporting tools that assist in the performanceof daily tasks. Very often, these tools are neither well-integrated with thebusiness of the enterprise nor are they able, for example, to providepredictable information about growth or change. In addition, these toolsgenerally do not provide a good and easy way of interpreting information thathelps to make better decisions because they are normally designed for andused by technical people (who often make the interpretation of information aseasy as reading and understanding hieroglyphics).

Decision making often requires the analysis of large amounts of data,complex relationships, and abstract correlations. Decision support systemsusually help in the evaluation of consequences (the what if) of givendecisions and may advise which decisions are best for achieving particulargoals.

We will move towards a real scenario explaining the methodology used, thearchitecture and design considerations, and all phases of deployment of theTivoli solution for the decision-making process. Furthermore, we will simulatea typical problem showing how decision makers with different roles andresponsibilities can benefit from the business information provided by TivoliDecision Support in order to make more efficient decisions.

We do not explain the product details of Tivoli applications in this book, butwe assume that the reader is reasonably familiar with Tivoli architecture andTivoli applications. We have dedicated Chapter 2, “Tivoli Decision Supportgeneral overview” on page 9 to providing the reader with a brief introductionto Tivoli Decision Support.

1.1 From fire fighting to business intelligence

The Information Technology (IT) business is changing. An evolution is inprogress, a paradigm shift that is changing the way we do business.Customers are demanding end-to-end solutions tied to Service LevelAgreements (SLAs). The challenge for technology is to manage and deliverthese services, such as availability, performance, and capacity management

© Copyright IBM Corp. 1999 1

across the entire enterprise as e-Business spawns more and more devicesthat are connected to it.

A few years ago, it was sufficient for service providers (IT Departments) tomanage and plan business operations using monthly batch reports. Changesin the organizations took a long time to be implemented. After that, with theimplementation of some management tools, we were able to execute queriesfrom the historical operational data in order to get reports or charts that onlyallowed us to be reactive to problems.

Today, enterprises need to provide decision makers with fast and easy accessto information that reflects the constant changes in the environment. Decisionmakers and customers need to have access to tools that provide them withthe ability to identify trends and model relationships in the data to findbehavioral anomalies in the business environments.

Figure 1. The evolution to business intelligence

Large amounts of data are stored in your enterprise. This data containsprecious information about the way the enterprise does business, its process,and customers. In these competitive days, using the knowledge provided by

IT Investments

Business Drivers

Fire FightingNo Tools

No Process

ReactiveFew Defined

Process

ManagedEnvironmentMonitoring &

DefinedProcess

ProactiveInter

ManagementPlatform

Exception andPredictive

ManagementBased on SLA

Customer Satis

faction

2 A Design and Implementation Guide for TDS

this data in order to make strategic business decisions can often move theenterprise ahead of the competition.

Business intelligence is what we are describing in this section; It is the abilityto be proactive to problems, leverage the assets in our business to gain profitfrom available data, and provide the know-how needed to make well-informeddecisions for our business.

As e-business drives the need for more network devices, we will needtechnologies that enable us to manage resources across the entireenterprise, end-to-end, not only by exception but by predictive analysis aswell. One such technology is Tivoli Decision Support, soon people will ask:

How did we manage without it?

1.2 The desired solution for business information

Historically, both Network and Systems Management tools have focused onthe state and function of individually managed elements or groups of similardevices. However, these tools, with their incompatible and independent data,do little to help those who must manage based on a broader vision of thebusiness and its supporting services, a capability that is now essential inenterprise distributed systems management.

The challenge is to view systems and network management from theperspective of the business as a whole. End-to-end service delivery andreporting has become the model for distributed management. This model iscommonly called service management or service level agreementmanagement. The question facing IT managers is whether there are tools andproducts that are up to the challenge.

The greatest obstacle to full end-to-end service level agreement managementis not the lack of but the abundance of management tools. If you think of yourown organization, there are probably numerous tools for managing theenterprise. Some are vendor-specific, and others are produced in-house,each defining its own standard for data formats and reporting. Every tool hasbeen optimized to address a specific or limited set of management functions.

Introduction 3

Figure 2. The challenge of a better solution for business information.

As shown in Figure 2, the challenge is to find a complete solution thatprovides an integrated framework or platform offering multiple managementfunctions across multiple vendor applications, services, or devices across theentire enterprise collecting the data and storing it in a standard format thatcan be processed and transformed into meaningful business information.

Attempts to provide this capability are not new. One such solution is Tivoli,which offers centralized policy-based functions, such as user management,software distribution, and services accessible to third party vendors.

1.3 Decision Support Systems

The concept of a Decision Support System (DSS) is widely used in bothresearch and in many different applications, but it has not yet been uniquelydefined.

In order to avoid possible misunderstandings, it is necessary to present thebasic characteristics of the class of DSS we will define. Let us start with abrief discussion of the environment in which a DSS will be used. The keyperson in this consideration is an individual who uses a DSS in real lifesituations. By convention, such a person is called a Decision Maker (DM). Bythis term, we mean both a person who makes real decisions (depending on

... into Business Information

Standard Format

Monitor A

Monitor B

.

.

..

Monitor Z

Multiple ManagementFunctions

Transformingthe Data ......


an application, this person may be a manager, engineer, or operator) and anexpert who may that person’s supervisor. Decisions are made within aDecision Making Process (DMP), which, in situations that justify the use of aDSS, is a complex sequence of tasks. We assume that a final decision is tobe made by the Decision Maker, and a Decision Support System does notserve as a replacement or control of a DM. In other words, a DSS is notaimed at the automatic selection of decisions.

The following are characteristics of a DSS:

• Systems that facilitate/extend knowledge management capabilities.

• Systems that coordinate distributed decision making.

• Systems that offer advice, expectations, facts, analyses, and so on.

• The user interface of a DSS is designed in such a way that a DM mayobtain, from the DSS, information and answers for questions that she orhe considers to be important for a DMP.

• DSS are interactive by nature.

• Even though a DSS might be unable to solve a problem facing DM, it canbe used to stimulate the DM’s thoughts about the problems.

The following DSS definition is the one that can better explain the class ofDSS we will work with:

DSS DSS is a supportive tool for the management and processing oflarge amounts of information and logical relations that helps a DMextend his or her habitual domain and, thus, helps him or herreach a better decision. In other words, a DSS can be considereda tool that, when under the full control of a DM, performs thedifficult tasks of data processing and provides relevant informationthat enables a DM to concentrate on this part of the DMP.

1.4 Positioning Tivoli Decision Support in the decision making process

Tivoli Decision Support (TDS) is designed to provide the best possibleenvironment for facilitating the Decision Making Process and helps you to bepro-active, planning future changes and determining their impact on theorganization.

The better the measurements and feedback regarding business processes,the better a decision maker can adjust for changes and maximize the resultsin the decision making process. In addition, when decisions are not made in a

Introduction 5

timely manner, windows of opportunity can close, and business is usually notdone.

Tivoli Decision Support as a technology is best known for dynamicallyproviding the decision maker with interactive business indicators and thenallowing the user to look at those indicators from many different perspectives.For example, let us suppose that a product manager wants to know how wellthe product is being supported in South America this month and compare therates with the same month the previous year. Once she or he views thehigh-level report, she or he may drill into the region to only look at how Brazilis doing. Moreover, she or he may drill into the southeast region and look athow a particular city is doing. This technology is called On-line AnalyticalProcessing (OLAP) or multidimensional analysis.

In addition, Tivoli Decision Support allows us to benefit from informationcollected by the customer’s Tivoli solution. For example, the support centerscollect a large quantity of transactional data from their customers, whichcontains valuable information about the way they interact with the business.With Tivoli Decision Support, Decision Makers have a way to manage thisdata and convert it into useful information providing a way to evaluate andidentify trends, to gain insight into the way customers do business, and tomake better decisions.

Figure 3. TDS in the decision making process

TivoliDecisionSupport

Data processing andManagement of logicalrelationship

Decision

TivoliApplications

RDBMS

Decision Maker

Accessing businessrelevant information


As shown in Figure 3 on page 6, Tivoli Management Applications, such asEnterprise Console, Service Desk, Inventory, Distributed Monitoring, and soon collect the data and store it in databases. Tivoli Decision Support selectsmanagement data from these databases, performs calculations, and addsvalue to the data by managing the natural relationship in the data. At thispoint, only business relevant information is offered to the Decision Maker whois in charge of the decision.

With Tivoli Decision Support, Tivoli Enterprise solution has moved a stepforward to reach the desired solution for Business Decision Informationproviding the ability to:

• Measure the effectiveness of your operation

• Gain insight into the potential satisfaction level of customers

• Gain insight into the value of your customer relationships

• Further leverage your investment in technology and automation

• Identify areas of weakness to convert from reactive activities to proactiveplanning

• Discover patterns that influence your decision making and future planning

• Become more efficient and effective

• Gain control over your business faster

1.5 Our approach

The remaining sections of this redbook are divided into the followingchapters:

• Chapter 2, “Tivoli Decision Support general overview” on page 9

This chapter provides information about the product describing theconcepts and terminology used by Tivoli Decision Support. In addition, weprovide basic information about the Tivoli Decision Support components.

• Chapter 3, “Methodology” on page 23

In a generic form, this chapter is intended to provide the reader with basicinformation about the methodology used to plan, deploy, and migrate toTivoli Decision Support:

• Requirement Gathering phase

• Systems Analysis phase

• Project Planning phase

Introduction 7

• Deployment phase

• Testing phase

• Documentation phase

Chapter 4, “TDS architecture and design considerations” on page 59

In this chapter, we will describe some considerations for the TivoliDecision Support architecture/topology/design solution, such as:

• How Tivoli Decision Support integrates with the Tivoli architecture

• How the Tivoli Decision Support components integration works

• Tivoli Decision Support architectures based on case studiesenvironments

• Troubleshooting tips

Chapter 5, “Case study” on page 85

This chapter exercises the knowledge acquired from the previouschapters performing an example by exploring one of the IBM ServiceDelivery Centers as a customer presenting a structured Tivoli DecisionSupport deployment solution.

Chapter 6, “Reports and decision information usage” on page 167

This chapter demonstrates how Tivoli Decision Support can supportthe decision making process by describing a simple scenario andoutlining the steps used to find and analyze critical data in order tomake a well-informed decision.


Chapter 2. Tivoli Decision Support general overview

In the context of delivering services in a complex IT environment, toaccomplish a high level of customer satisfaction requires the IT function of anorganization to have a full understanding of and insight into the differentaspects of its operation and performance in terms of efficiency andeffectiveness. For example, for the network analyst of an organization toconduct network performance tuning, he or she may need to find out not onlywhich portion of the corporate network has the most traffic, but also why,when, and which systems cause the most traffic. Similarly, for the ITmanager, the network analyst may need to know how well his help deskoperation performs not only in terms of, for example, how many problemswere resolved within the SLA, but also in terms of what problems wereresolved, by whom, and over a series of time intervals.

Despite the high volume of data being collected by the different systems in anorganization, without a suitable tool, it is increasingly difficult for technicalanalysts and IT managers alike to obtain answers to business-relevantquestions, such as those discussed above. As a result, resolutions anddecision making are frequently conducted using only a subset of theinformation stored in the organization.

It is the goal of Tivoli Decision Support to maximize the value of the Tivolidata being collected across the various systems in organizations by makingthem available to aid analysis and decision making.

2.1 Overview of Tivoli Decision Support

Tivoli Decision Support provides a powerful mechanism to aid its users todive into complex database structures and explore them in different scopes,levels of detail, and from different perspectives. It also allows its users toanalyze data in multiple dimensions. Collectively, these features enable theuser to gain a deeper understanding of and insight into the relationshipbetween the data stored in different systems that affect the businessoperation and performance of an organization.

Because of its flexibility in handling data in different scopes, levels of details,perspectives, and dimensions, Tivoli Decision Support addresses theinformation need of different users for conducting analyses and decisionmaking - from technical analysts, through line managers, to executives.

Finally, Tivoli Decision Support handles the delivery of and access to thedata. It facilitates knowledge discovery and user access to information. Data


collected can be shared with others in the organization using deliverymechanisms including hard copy printouts, files, and push content. In thelatter case, content that has been collected by one user can be sent to acentral repository on a company’s intranet from which other users can gainaccess to the content.

2.2 Tivoli Decision Support product components

Tivoli Decision Support can be categorized into two main parts:

• Tivoli Decision Support Base Product

• Tivoli Decision Support Discovery Guides

The base product provides functions that are necessary to configure,administer, and operate Tivoli Decision Support and is the prerequisite forusing the TDS Discovery Guides. The base product is composed of thefollowing components:

• Discovery Administrator

• TDS Server component

• Discovery Interface

• Cognos PowerPlay

• Crystal Reports

The TDS Discovery Guides are software add-on modules that put theapplication of TDS in context. For example, the Call Center ManagementGuide deals with issues related to the decision making process associatedwith support requests, resolution rates, and so on.

Figure 4 on page 11 shows the relationship between the Tivoli DecisionSupport Base Product and Tivoli Decision Support Discovery Guides.


Figure 4. Tivoli Decision Support components

The following sections are dedicated to explaining each of the Tivoli DecisionSupport components. For further information, refer to the productdocumentation.

2.2.1 Tivoli Decision Support Discovery AdministratorThe Discovery Administrator helps you ensure that Tivoli Decision Supportfunctions correctly within your organization and information is kept up to date.The Discovery Administrator performs the following tasks:

• The Discovery Administrator has access to the database in order to gatherand maintain all data used by Tivoli Decision Support. The DiscoveryAdministrator can be customized to automatically gather the data, which isstored in special files (it populates these special files with current datafrom your organization’s databases) at pre defined intervals or it canenable you to perform such operations manually.

• It provides specific parameters you can set when building or customizingcubes. These parameters affect the operation of specific cubes andenable you to customize the behavior of views in the Discovery Interface.

Tivoli Decision Support Discovery Guides:

Ready-to-use Solutions

Tivoli Decision Support general overview 11

• It enables you to set parameters that are specific to your enterprise’soperation. These parameters, such as severity level thresholds andbusiness hours, determine how Tivoli Decision Support interprets dataand makes calculations when generating views.

2.2.2 Tivoli Decision Support Server componentThe TDS Server component, best known as TDS File Server, acts as arepository for TDS. This component contains TDS related models, queries,templates, and other information required to generate views for the DiscoveryInterface.

2.2.3 Tivoli Decision Support Discovery InterfaceThe Discovery Interface is the client component of TDS. This is the interfaceto Decision Support. It provides all the tools needed to open and work withviews of data from your organization’s enterprise databases.

2.2.4 Cognos PowerPlayCognos PowerPlay is a third-party application from Cognos Inc. It is amulti-dimensional analysis and reporting tool that is included in TivoliDecision Support. Cognos PowerPlay can generate customized views basedon queries to the databases in your enterprise. It can also display views in avariety of graphical styles including bar, line, and pie charts.

Using the tools provided by Tivoli Discovery Interface and PowerPlay, you canturn low-level detailed data into useful business knowledge. After a view isopened in PowerPlay format, you can analyze many dimensions of the data todetermine relationships, trends, effects, and so on. PowerPlay also gives youthe option of further accessing view details so that you can break out andanalyze the data behind it.

2.2.5 Crystal ReportsCrystal Reports is a third-party reporting application from Seagate SoftwareInc. This application generates text-based views from standard databasequeries. Tivoli Decision Support uses many views in Crystal Reports formatin the TDS Discovery Guides.

2.2.6 Tivoli Decision Support Discovery GuidesA Tivoli Decision Support Discovery Guide is a TDS module that groupsenterprise data into specialized categories. Each category contains a seriesof topics that correspond to the different aspects of that category. Each topic


contains a number of views that are associated with the data elements beingexamined.

Tivoli Decision Support uses the Discovery Guides to aid in discovering keyinformation. With this information, Tivoli Decision Support becomes apowerful end-user solution. This solution provides users with acomprehensive set of views into their enterprise’s data. Along with the viewsare methods (including algorithms, queries, and reports) for abstracting keybusiness indicators from the business data. Managers can use theseindicators as key business information to improve efficiency, performance,and profitability.

TDS includes several Discovery Guides. Other Guides are available asadditional options. Appendix C, “Tivoli Decision Support Discovery Guidesavailability” on page 189, offers a complete list of the Tivoli Decision SupportDiscovery Guides including those that are shipped with TDS Version 2.0.

TDS Discovery Guides contain algorithms, queries, reports, views, andbusiness models that best represent a business concept. Guides can be veryrobust and contain several hundred views and multiple business models.Along with the views, guides have embedded contextual informationassociated with views. The context helps users identify, discover, andunderstand what the view has to offer. For example, as the user views andinterprets data in Tivoli Decision Support, the Tivoli Discovery Interfaceprovides several features to facilitate the user. These features include hints,related views, and keyword searches.

No customization, analysis, or programming is required to use Tivoli DecisionSupport guides. By selecting guides in the Discovery Interface, managers candefine the scope of their data searches to yield the most relevant results fortheir needs. A call center manager, for instance, may want to see only datathat pertains to his or her area of the business. He or she may not need toreview data that another department manager needs to review. It is onlynecessary to activate all relevant TDS Discovery Guides and turn off all otherguides. The views shown in the Tivoli Discovery Interface topic map are onlythose associated with the Call Center Management Discovery Guide.

Managers can select as many Guides as they want to expand the scope oftheir data search, for instance, if the call center manager wants to review notonly relevant call center data, but also data collected about the health of hisor her business’ contacts. The call center manager selects the Call CenterManagement Discovery guide as well as the Relationship ManagementDiscovery Guide. Now, the views available to the call center manager in the


topic map are a combination of the two guides he or she selected. The callcenter manager’s scope has changed to encompass more views.

2.3 Tivoli Decision Support implementation modes

Tivoli Decision Support can be implemented in either Stand-alone or Networkmode.

• Stand-alone mode

All the TDS components are installed and run on one machine. The standalone machine also requires the installation of the database clientsoftware and the ODBC driver in order to have access to the databasesfrom which one or more cubes are built. This database connection alsoallows report generation by running database queries against theindividual databases.

Figure 5 shows an example of a Tivoli Decision Support implementation instand alone mode:

Figure 5. Tivoli Decision Support in stand alone implementation mode

• Network mode

Only TDS Discovery Interface and Cognos PowerPlay are installed on theclient machine. In addition, the client requires the installation of both theClient Database and the ODBC Driver, in order to have access to the datastored in the database server, when generating Crystal reports. The TDSVersion 2.0 installation CD contains the Intersolv 3.01 32-bit ODBC Driverfor Oracle and Sybase.

The TDS Server component is installed on a file server which the clientmachines have access to a shared drive that will contain all the cubesgenerated.

A separate machine is used as the administrator system where theDiscovery Administrator module is installed along with PowerPlay. The

INVENTORY

DM

TEC

DATABASESMachine running TDSin stand alone mode

ODBC Connection


Administrator system should access the shared drive in the TDS FileServer. In addition, it also requires the database client and the ODBCdriver in order to have a connection to the database from which the cubesare built. The cube files created by the Discovery Administrator are storedon the TDS File server.

The diagram in Figure 6 on page 15 shows an example of a Tivoli DecisionSupport in the network mode:

Figure 6. Tivoli Decision Support network implementation mode

2.4 Supported platforms

The following software platforms are supported by Tivoli Decision SupportVersion 2.0:

Operating Systems:

• Windows NT 4.0

• Windows 95

TDS DiscoveryInterface

TDS File Server

TDS DiscoveryAdministrator


Database Server

accessthe Cubes

accessthe Cubes

ODBCconnection

storesthe Cubes

Crystal Reports Crystal Reports

buildsthe Cubes


Database Management Systems:

• Oracle

• Sybase

• SQL Server

• Informix

• DB2

2.5 Concepts and terminology

This section provides some important Tivoli Decision Support concepts andterminology.

Category

A Category is a major division of data in the Tivoli Decision Support topicmap. The enterprise data is grouped according to concepts, such asproductivity or interaction trends. Within a Category, the user can find morespecifically-related types of data. See also Topic and View.

Cubes

A cube is a data container used by PowerPlay. PowerPlay is amulti-dimensional reporting and analysis tool packaged with Tivoli DecisionSupport.

As opposed to a flat two-dimensional table of rows and columns, amulti-dimensional array can be visualized as a cube with many sides, witheach dimension forming a side. The cube is arranged so that every data itemis located and accessed based on the intersection of the dimension membersthat define it.

Cubes are built by the TDS Discovery Administrator, which runs a queryagainst the database and executes the Cognos Transformer. CognosTransformer is a component of Cognos PowerPlay. The function of theCognos transformer is to input the queries and summarize the data (bycounting, averaging, calculating percentage, and so on) and pack thisinformation into a compressed cube file (*.MDC). The TDS DiscoveryInterface executes PowerPlay reports that look at these cube files forhistorical data rather than live data.


Dimensions

A dimension refers to a broad grouping of descriptive data about an aspect ofa business, such as software products and dates. Each dimension includescategories in one or more drill-down paths and an optional set of specialcategories. See also drill-up and drill-down.

Dimension line

The dimension line shows the dimensions in the cube and the categorieswithin each dimension currently being examined.

Drill-up and Drill-down

Drill-up refers to looking at data in a progressively more general way whereasdrill-down refers to looking at data in a progressively more detailed way.

Drill-through

Drill-through is more detailed than drill-down. While drill-down stops at thelower level of consolidated data, drill-through goes one step further by lookingat the actual data records themselves. For example, if the breakup of thetypes of problems resolved by a particular analyst is the lowest level ofconsolidation, drill-through looks at the actual records that correspond to theproblem descriptions themselves.

Filter

A filter is a means of ensuring that a data search yields the most relevantresults. In Tivoli Decision Support, the user can specify data selectioncriteria, such as data ranges or severity levels, that restrict the data searchand result in only relevant data.

Layer

Layer is the third set of dimension categories, along with rows and columns,that you can add to the views in TDS. Layers offer details for anotherdimension to provide a new perspective on your views. A view can containseveral layers, but you can look at only one at a time.

Measures

Measures refer to indicators you use to gauge the performance of yourorganization. For example, measures can be the number of problem requestsreceived and the average time taken to resolve a problem.


Models

A model contains definitions of queries, dimensions, and measures as well asobjects for one or more cubes that Cognos Transformer creates via the TDSDiscovery Administrator for viewing and reporting in PowerPlay.

Profile

A profile is a feature in the Discovery Interface that enables each user toconfigure settings and views that pertain only to him or her. The DiscoveryInterface can contain several profiles.

Related view

A related view is a view that is different from the current view but may containadditional relevant data. Tivoli Decision Support automatically suggests viewsthat are related to the current view. These additional views are listed in theRelated Views tab in the hint pane.

Role

A role is a user-selected description that describes the user’s position in allareas of the business. A user can select one or more roles based on thescope of his or her position. By specifying one or more roles, the userestablishes the scope of the information contained on the topic map. Themore roles are specified, the greater the scope of the data searchesdisplayed on the topic map.

Selection criteria

Selection criteria are the parameters specified by the user when conducting adata search. Selection criteria act as filters ensuring that only relevant data isyielded by a data search. See also Filter.

Slicing and Dicing

Slicing and Dicing refers to the process of extracting information for viewingfrom the cube file by selecting different dimensions. This process can bethought of as constructing a multi-dimensional space by using the selecteddimensions for its constituent axes or as looking at the same data from avariety of angles.

Topic

A topic is a subcategory of data in the Tivoli Decision Support topic map.Within each category of enterprise data, data is subdivided into related


topics. Within each topic, the user can choose an individual type of data forviewing. See also Category and View.

Topic Map

Topic map is the user’s primary means of navigating Tivoli Decision Support.In the topic map, the user can choose specific categories, topics, and views.When a view is selected, a specially-configured view appears in the viewpane. See also View.

View

A view is the most detailed type of question in the topic map. A view providesthe user with an outlook of the data stored in the cube file or the dataretrieved from a special database query.

2.6 How Tivoli Decision Support works

The Tivoli Discovery Administrator module, which is installed on your systemif you run in stand-alone mode or on the system administrator’s system if yourun in network mode, connects to your enterprise’s databases. When youissue a request for information in the Tivoli Discovery Interface, TivoliDecision Support either reads the information from the database directly (ifthe report requested is a Crystal report) or reads the cube file created by theTivoli Discovery Administrator (if the report requested is a multi-dimensionalreport). The cube is summarized data that is read from the database whenthe cube is built by the Tivoli Discovery Administrator. The information is thenreturned to the Discovery Interface and presented to you.


Figure 7. The operation of Tivoli Decision Support

Because of its integration with PowerPlay and Crystal Reports, TivoliDecision Support provides snapshot-style views of data that are displayed inthe Discovery Interface. The data can be viewed in one of several formats: astext, a bar chart, a line chart, or some other graphical format. The defaultformat depends on the type of data you are viewing, but you can selectdifferent formats for some types of views. These views allow you to:

• Analyze data from different perspectives

• Compare current activities to historical records

• Spot trends

• Troubleshoot

• Evaluate resource allocation

• Make projections and forecasts

• Perform other management tasks

The Discovery Interface also provides features that can automate yoursearch for data. For example, you can use bookmarks to collect your favoriteviews; so, they are instantly available. Instead of manually browsing for data,you can use the Search tool to find information based on keywords. The

Crystal ReportsTDS Discovery Interface

EnterpriseDatabases

Multi-dimensional Reports

Cubes

TDS DiscoveryAdministrator


Discovery Interface’s History feature tracks your most recently used views;so, you can quickly return to them.

2.7 Who is making use of Tivoli Decision Support?

Tivoli has identified three distinct groups of users for Tivoli Decision Support:Explorers, Tourists, and One-minute managers. Each group defines a set ofneeds unique to the group:

• Explorers use existing Tivoli Decision Support metrics and reports as astepping stone to discover additional trends and views. After they notice atrend in the data, they investigate why the trends occur. Mostorganizations have a limited number of employees devoted to the task ofexploring, but they are typically required to continually research theeffectiveness of their organization. The information they gather is funneledto other employees in the organization.

• Tourists want to explore, but they do not want to go into areas that aredead ends or areas that do not quickly meet their needs. Typically, touristswant as much freedom as possible to follow their touring needs as long aseach step meets their needs. They spend time looking for data, but theywant a high success rate in finding what they want when they want it.There are usually more tourists in an organization than there areexplorers.

• One-minute managers do not want to spend their time exploring. Theywant to continually review a set of views that allow them to know what theyneed to know. One-minute managers need a fixed set of views they canreference, and they want views customized to their specific needs. Forexample, analysts may only want to look at their open calls. This view canbe set in the Discovery Interface; so, it is readily accessible to theOne-minute manager.

Tivoli Decision Support satisfies the needs of different types of users withan environment that is highly-customizable.

The customizable nature of Tivoli Decision Support lends itself well toexplorers who are continually viewing the enterprise’s data sources todiscover trends and views.

Tourists also benefit from the customizable features of Tivoli DecisionSupport, which enable them to expand or limit the number ofpre-packaged views. Finally, One-minute managers appreciate theuser-friendly Discovery Interface, which assists them in locating the viewor sets of views they want to reference. Also, Tivoli Decision Support’s


push-delivery feature enables all users to receive updated views but isparticularly helpful to the One-minute manager.


Chapter 3. Methodology

This chapter provides the reader with the recommended methodology thatthey should conform to in order to successfully plan, install, and configure theTivoli Decision Support product. This chapter kicks off with an overview of theTivoli Implementation Methodology (TIM), which has been branded as Tivoli’sbest practice for identifying, designing, planning, installing, testing, anddocumenting a Tivoli Enterprise solution. Following the introduction to TIM, arecommended Tivoli Decision Support deployment process incorporating thestructured procedure driven by the implementation methodology that TIM isbased on will be presented to the reader.

3.1 Tivoli Implementation Methodology

The Tivoli Implementation Methodology (TIM) constitutes the methodology forsuccessful deployments of Tivoli management software solutions. TIM usesstructured, predictable, and repeatable processes, which result in efficientand effective deployments. Through the use of a set of documentation,guidelines, templates, and tools used to plan, develop, test, implement, andmaintain Tivoli solutions, TIM is Tivoli’s best practice standard to:

• Understand a customer's system-management needs

• Select Tivoli management software that best addresses those needs

• Enable the sales team to use the consultant organization's experience toobtain accurate estimates of the effort required to implement the solution

• Assist Tivoli Certified Consultants and project managers in planning,designing, and implementing Tivoli solutions that meet customer needs

• Test Tivoli Solutions

• Document Tivoli Solutions, thus, enabling customers to independentlymanage their systems

• Assist the customer support team in supporting the deployed TivoliSolutions.

TIM is used by sales teams, project managers, architects, consultants, andaccount managers from both Tivoli Systems and approved Tivoli BusinessPartner consultant organizations.

TIM was developed by Tivoli consultants, architects, project managers,support staff, and developers. It captures the best practices framework-widedeployments of Tivoli Management Software. TIM provides standarddeployment processes and offers best-of-breed procedures continuously


refined by Tivoli Professional Services and selected Business Partners. TIMis organized according to the Software Engineering Life Cycle model. Thismodel addresses each element that is critical to the implementation of anysoftware development activity. In Figure 8, a schematic overview of TIM isgiven.

Figure 8. TIM schematic overview

TIM provides standard verified methods for use by project managers andTivoli-certified consultants to execute each phase of a Tivoli implementation.With this common deployment strategy, Tivoli and Tivoli’s business partnerscan provide:

• Accurate and complete requirements definitions for Tivoli solutions


• Efficient requirements analysis to generate an architecture and design fora solution

• Complete project planning and detailed design for a solution

• Accelerated deployment of Tivoli solutions

• Detailed solution verification that lends itself to customer regression testactivities

• Completed solution documentation that can be used by the customer,consultants, Tivoli support staff, and Tivoli development to ensure thelong-term success of that solution

To find information on TIM, refer to the instructions in Appendix A, “TivoliImplementation Methodology (TIM) 3.6” on page 185.

3.2 Implementing Tivoli Decision Support

In order to ensure that the process of deploying Tivoli Decision Support is inline with TIM, we will follow the process flow defined in the TIM methodologyto detail each phase of the TDS implementation. Since our main focus in thischapter is the implementation, the methodology detailed below will onlyhighlight those procedures that are significant to TDS. It is assumed that TDShas already been identified as the solution that the customer requires; so, wewill not go into detail about the pre-sales and best-fit Tivoli product analysisexercises, which are part of the Sales Engagement phase.

3.2.1 Requirements gathering phaseRequirements gathering, as it relates to Tivoli Decision Support, is asystematic process of identifying a customer's reporting requirements inorder for us to deliver a well-thought-out implementation of Tivoli’sdecision-making software. With the aid of detailed questionnaires, theconsultant services organization works with the customer to identify completeand accurate requirements for their reporting solution. This activity also helpsthe customer establish the proper expectations of the breadth and scope ofthe TDS solution.

In order to deliver a definitive TDS requirements document, we will tailor thisrequirements gathering phase to provide only the information necessary todefine the scope, architecture, and estimated hours that will be required toimplement the customer’s TDS solution. The objective of this segment is,therefore, to gather requirements that enable the following:

Methodology 25

• A system architect to analyze the information and successfully create aSystem Architecture and Design document

• The consultant, business operations, project management, sales team,and the deployment team to work together, led by business operations, todevelop a technical proposal

• A deployment project team to create a detailed project plan

Table 1 shows the input and output items, which highlight the components ofthe requirements-gathering phase:

Table 1. Requirements gathering phase items

Figure 9 outlines the process flow of the requirements-gathering phase:

Figure 9. Requirements gathering process flow

We will now take a look at the questionnaires shown in Figure 9.

3.2.1.1 QuestionnairesQuestionnaires serve as the main tool for gathering a detailed description andlogical picture of the customer’s environment. It is a tool that portrays thecustomer’s environment and high-level goals for reporting on his or her ITenvironment.

Gathering the customer-specific TDS requirements is the focal point of thisexercise and will be investigated shortly. First, however, we must take a lookat the systems management requirements of the customer in the form of theCustomer Requirements Questionnaire.

Requirements gathering phase

Input Initial customer requirements questionnaire

Output Tivoli decision support requirements questionnaires

Requirements Gathering Flow

INPUTCustomer

RequirementsQuestionaire

TDSRequirementsQuestionaire OUTPUT


3.2.1.2 Initial customer requirements questionnaireThe information gathered in this report serves as the single input element ofthe implementation solution. Our aim is to process this information andproduce other questionnaires and reports that will serve as inputs to thesubsequent phases of the implementation cycle.

In this questionnaire, many business-specific questions are answered. Themost important and valuable pieces of information gathered would be thecustomer reporting goals and issues. For example, the answers to thefollowing types of questions will be available to us:

• What are the immediate Tivoli-specific goals of the customer?

• What are the long-term Tivoli-specific goals of the customer?

• What are the customer's general immediate goals with TDS?

• What are the customer's general long-term goals with TDS?

From this information, the TDS consultant will be able to identify the reportingsolution components that are significant to the customer’s business. He orshe can now focus on the implementation of the product functions of TivoliDecision Support and gather all the necessary TDS requirements.

3.2.1.3 Tivoli Decision Support requirements questionnaireHaving manipulated the information received above, we are now ready todraw up a questionnaire to extract the TDS product-specific information. TheTDS provider will set up an interview with the customer requesting therelevant business leaders as well as the IT technical leader to be present.This interview is broken up into four steps, which are shown in the list below.The purpose, requirements, and process of each step will be clearlydistinguished; furthermore, a set of suggested questions for the questionnairewill be proposed.

1. Decision-making/reporting requirements overview:

• Purpose

It is during this step that Tivoli personnel acquire their initial informationon the customer’s reporting requirements. It is assumed that thecustomer has an amateur solution in place and intends to migrate toTivoli Decision Support. The customer will be questioned on his or hercurrent reporting activities, and a document detailing his or herrequirements will be drawn up.

• Required information

Details of what the customer expects from the Tivoli Decision Supportsolution, current process, procedure, service levels, reports, and any

Methodology 27

product(s) associated with accomplishing their current reporting task (ifany) are required information.

• Process

Document all customer expectations and reporting goals. Gather allexisting reporting policies and procedures implemented by thecustomer. Review the customer's existing reporting policies andprocedures to determine how data is collected and manipulated andwhat Tivoli Decision Support specifics need to be presented in order tomigrate to this new reporting strategy.

• Suggested questions:

• What are the customer’s immediate report requirements?

• What report requirements are forecast as future needs?

• What is your current reporting strategy, and what are the shortfalls?

• Are you able to publish content to the Web?

• How often do you run your data mining and database interrogationprocedures?

• Are any Tivoli products used to gather data for the current reportingsolution?

2. Existing Tivoli systems management products installed:

• Purpose

Tivoli Decision Support is dependent on various Tivoli products toperform its reporting task. It is assumed that the customer has eitheran existing Tivoli Systems Management solution implemented, or it is inthe process of implementation in their environment.


Tivoli Servers, Tivoli Products (including patch levels), installed Plusmodules, TMR architecture, and Operating System platforms arerequired.

• Process

It is in the analysis phase that we will investigate how these existingpolicies and procedures can be migrated to Tivoli Decision Support

Note


Gather all existing architecture and deployment documents (ifavailable). Identify process flows, and systems managementprocedures that the business is running with. Identify if Tivoli DecisionSupport dependent Tivoli products are installed for example,Distributed Monitoring, Enterprise Console, Netview, Service Desk etc.


• Which systems management disciplines does your Tivoli solutionintegrate with? Describe the details of that integration including theflow of data and desktop configurations.

• Are there current architecture and deployment summary documentsthat describe the Tivoli deployment?

• If using a Master-Spoke TMR, where are the Spoke TMR Serverslocated? (For example, central data center, different geographiclocations, one per branch office).

3. Determine hardware and operating system information

For this step, we basically need to get an idea of the existing hardware thatis deployed at the customer site. We will use this information in theSystems Analysis to decide if it is possible to share the roles of some ofthese machines with Tivoli Decision Support.

• Purpose

The purpose is to gather a hardware and operating system inventory ofall dedicated Systems Management machines as well as machines thatneed to be monitored.


System-specific information is required.

• Process

Review the Tivoli Decision Support hardware requirements with thecustomer. Processor, memory, monitor, and hard disk space of theexisting hardware are some of the main issues that need to be covered.

4. Determine network-specific information

• Purpose

The purpose is to gather the following information to describe thenetwork communication mechanisms used between the variouscomponents that may be used for the TDS deployment.


Methodology 29

The customer should provide a network topology diagram. If thefollowing information is not on the diagram, annotate the diagram orprovide details:

• Line speed of each network connection.

• Actual network bandwidth. If it varies by time of day, define thetypical averages.

• Each firewall between nodes.

• Each firewall's configuration, monitoring, and policies.

• Socks configuration description.

• Protocols used within the current environment.

• Frame Relay (Committed Information Rate (CIR) and Burst Rate).


• Are all systems reachable via TCP/IP?

• Describe the host and IP address naming conventions and schemeused to identify networking and computer system equipment.

• Is the TCP/IP routing structure static or dynamic?

• If DNS is used, provide a copy of the DNS map configuration. (Notethat the integrity of these maps must be verified.) Describe howreverse lookups are performed.

• If DHCP or WINS is in use, identify the server and describe howthese utilities are configured.

3.2.2 Systems analysis phaseDuring the Systems analysis phase, the TDS requirements that weregathered in the previous stage are processed. The goal of this systemanalysis is to provide a total reporting solution using Tivoli Decision Supportthat meets or exceeds customer expectations.

This solution includes the development and presentation of a proposal forTDS. Furthermore, the architecture and detailed design is completed, and theStatement of Work for the deployment of the solution is developed andpresented to the customer.

The results of the questionnaires are now needed, and they serve as themain ingredient for systems analysis.


The input and output items shown in Table 2 highlight the components of thesystems analysis phase:

Table 2. Systems analysis phase items

Figure 10 outlines The process flow of the Systems Analysis phase:

Figure 10. Systems Analysis process flow

3.2.2.1 Preparing for systems analysisTo create a TDS architecture, begin by translating the customer requirementsand the proposals into a list of what functions and capabilities TDS mustprovide. Document this information so that it can be used to implement thetechnical solution.

As requirements are reviewed, carefully evaluate each customer requirementto ensure they have provided sufficient information to enable the analyst tomeet these requirements using Tivoli Decision Support.

Also, if the customer accepted an action item to provide requirementsinformation during the requirements gathering phase, ensure that thecustomer has supplied this information.

Once all the preparations have been completed, we can now be certain thatfocusing on customer requirements to create an architecture and design willensure that the architecture and design is concise, and, thus, the deploymentof the TDS solution will be successful.

Systems Analysis Phase

InputTivoli Decision Support Requirements Questionnaires

Tivoli Decision Support Installation Guide

OutputTechnical Proposal

System Architecture and Design Document

Systems Analysis Flow

TechnicalProposal OUTPUTINPUT Preparation Mapping TDS

Guides

SystemsArchitecture &

Design

Methodology 31

We will begin with an analysis of the information received and then go on toexplain the documentation or results that must emerge as a consequence ofthis analysis phase.

3.2.2.2 Tivoli Decision Support GuidesA Decision Support Guide is a TDS module that groups the enterprise datainto specialized categories. Each category contains a series of topics thatcorrespond to the different aspects of that category. Each topic contains anumber of views that are associated with the data elements being examined.

The following list provides some examples of Decision Support Guides thatare available:

• Tivoli Decision Support for Server Performance Prediction

This provides capacity planning, forecasting, and trend analysis andidentifies server performance issues using data from Tivoli DistributedMonitoring.

• Tivoli Decision Support for Event Management

This uses information from the Tivoli Enterprise Console to provide anunderstanding of event handling versus service level agreements.

• Tivoli Decision Support for Network Event Analysis

This leverages data captured by Tivoli NetView to indicate theperformance of network devices, the state of network health, and thecontrol of network event management.

• Tivoli Decision Support for Software Deployment Analysis

This helps identify issues that impact software deployment using TivoliSoftware Distribution and Tivoli Inventory.

• Tivoli Decision Support for Information Management

This enables customers to analyze problem and change managementinformation stored in Tivoli Service Desk for OS/390 host databases.

3.2.2.3 Working with Tivoli Decision Support GuidesAs soon as the questionnaires from the requirements gathering phase are ready,they will be used during this next phase to derive a TDS reporting solution thatmeets the customer’s requirements. A TDS analyst will study the reporting anddecision information requirements from the questionnaires and he or she willthen carry out an exercise to deliver a proposal to the customer on how we planto meet their requirements with the use of TDS and TDS Discovery Guides.

This exercise is a two-fold process and is outlined in the following list:


1. Mapping TDS guides to customer requirements

The analyst needs to evaluate the various TDS guides available. He or shewill need to implement a one-to-one mapping between each requiredreport and TDS view, which is made possible by one of many TDS guides.The analyst will need to have detailed information available about the TDSGuides. This information can be obtained from various sources:

• Using Decision 2.0 Support Guides, GC32-0290

• Release Notes Shipped with the TDS Discovery Guides

• Tivoli Website (Overview of Guides capabilities)

In most situations, TDS, with the use of its Drill-Down capabilities, will beable to produce much more detailed information than is required by thecustomer. On the other hand, it is possible that some of the customerreporting requirements will not be provided by TDS. For this reason, thereshould be a second step where a solution for these unmatched reports isdeveloped

2. Determine customization requirements (if necessary)

For this process, the analyst will compare the list of items required by thecustomer (or collected by the current reporting tools), to the list of itemscollected by the TDS Guides. Reports that are required by the customerand are not available to TDS are listed down. A sub-project for deliveringthese reports will now need to be kicked off. This project will investigatethe extent of work required and will produce a customized solution for theoutstanding reports. Customization can include but is not limited to:

• Editing current guides

• Writing custom scripts to populate the DM database

• Creating Custom Crystal reports

• Creating Custom PowerPlay reports

For detailed information, refer to Using Decision 2.0 Support Guides,GC32-0290, which is shipped with the product.

3.2.2.4 System architecture and design documentThe objectives of this process are to design and document the physical andlogical aspects of the customer’s TDS deployment.

The following tasks need to be completed by this activity:

• Design a high-level architecture for TDS layout (Physical Design).

• Define logical architecture for the TDS implementation (Logical Design).

Methodology 33

• Identify and acquire the servers required for implementing DecisionSupport (Resource requirements).

• Document the system architecture and design. (Output Documentation).

The TDS architectureChapter 4, “TDS architecture and design considerations” on page 59 isdedicated to designing solutions and focuses a great deal on variousarchitecture considerations. For this reason, we will not go into too muchdetail here on the TDS physical design. This architecture section willintroduce some TDS architecture concerns and present to the reader astandard design on which the customer’s solution should be based.

The foundation of the physical design depends on the customer requirementsand the answers to the questionnaires presented to the customer in Section3.2.1, “Requirements gathering phase” on page 25. The analysts will need tostudy the customer’s environment and business with the intention ofidentifying suitable TDS hardware components and personnel resources.They will then need to bring these two resources together and apply aprocess to deliver a suitable architecture. Insights into some of the thoughtprocesses that willcome into play are listed below:

• Does my customer require a stand-alone or network installation?

• How many TDS Servers does my customer need?

• How many administrator machines will be required?

• How many client interfaces will be required?

• Does the customer require Crystal Reports to be installed?

Below is a recommended network configuration diagram. The figure depicts atypical TDS implementation in Network Mode. In Network Mode, onlyDecision Support’s client component and PowerPlay are installed on theclient machine. The other components are installed elsewhere. The user ofthe client system only has access to the Discovery Interface. You mustadminister Decision Support for all clients from the system administrator’ssystem.


Figure 11. Typical architecture

As mentioned before, Chapter 4, “TDS architecture and designconsiderations” on page 59, will go into the details of the physical and logicaldesign considerations of a TDS implementation.

Resource availabilityEarly in the process of developing a system architecture and design, a roughdetermination as to what hardware might be required for deployment is made.It is important to generate this information as soon as possible so thathardware can be procured and made available as soon as hands-ondeployment work begins.

The system requirements for Tivoli Decision Support may vary greatly andwill depend on many environmental factors. For the purpose of simplifyingthis exercise, we will assume that a networked topology of clients fed by a fileserver will be the standard workgroup configuration. With that in mind, cubebuild times and view run time will vary based on the following:

• Number of datapoints included in the scope of the analysis

• Performance of the database server

• Demand on the database server

• Throughput of the network

• Performance of the Client

File server runningserver components

including guides,cubes and models

System runningAdministrator and client

Service and supportdatabase system

ODBC

Client systemrunning Discovery

Interface


Interface


Interface

Shared File Access

INVENTORY

DM

TEC

DATABASES

ODBC

Methodology 35

• Performance of the File Server

• Performance of the processor that builds the cubes

The Tivoli Decision Support Installation Guide, GC32-0289, lists theoperating system and suggested hardware requirements for each DecisionSupport component. It differentiates between two classes of machines: alow-end and a high-end machine for each component. Although this servesas a good base, it is often not easy to rank the type of environment that youare in, and it makes the choice very difficult.

Table 3 details the minimum configuration for various business environments.The sizings are based on Tivoli’s experience with the Service Desk productline. This table provides you with an easier method of deciding on theconfiguration that you require.

The business environments are divided into four ranks: Small, Medium,Large, and Mega. The variable that we are interested in is the number ofcontacts, which gives us an idea of how large the business is.

Table 3. Minimum configuration table

The best way to gather the TDS resource mapping information is through asurvey sheet that should be filled in by the customer with help from thesystems analysts. The survey should be structured in such a way that

Size of Center Client PCRequirements

Administrator PCRequirements

File ServerRequirements

Small<10K contacts<50K calls/yr

40 MB disk space100 MHz Pentium32 MB RAMNT 4.0/Win 95

500 MB disk space200 MHz Pentium64 MB RAMNT 4.0/Win95


Medium10-30K contacts50-100K calls/yr


500 MB disk space250 MHz Pentium128 MB RAMNT 4.0


Large30-250K contacts100-500K calls/yr




Mega>250K contacts>500K calls/yr


1 GB disk space300 MHz Dual Pentium512 MB RAMNT 4.0

500 MB disk space300 MHz Pentium256+ MB RAMNT 4.0


emphasis is placed on every machine identified as playing a specific role inthe TDS architecture.

What follows is a description of the machine roles and the accompanyingsurvey sheets.

File server informationThis is the repository for TDS and contains the TDS models, templates,queries, and other information required to generate views for the DiscoveryInterface. It is necessary for this to be reasonably fast to service the files.Every client machine will connect to this server and, thus, the networkconnection must be reasonably fast. These factors need to be investigated atthis point. Figure 12 shows an example file server information form:

Figure 12. File server information example form

TDS Administrator PC informationThis component provides functions for TDS configuration and administration,for example, setting system parameters that control the behavior of TDS. Thismachine requires a fast hard drive and fast network access to the databaseserver. Figure 13 on page 38 shows an example TDS administrator PCinformation form.

Machine Type:________________________________________________

Operating System: _____________________ Version: _____________

Network protocol used between server and workstations (Novell, NT, etc.):_______________________________________________________

Is this file server dedicated to TDS file storage?

Amount of disc space available for TDS files? ___(300+MB recommended)

Do all TDS client and admin machines have READ and WRITE access tothe TDS file service/directory?

Example Form

Methodology 37

Figure 13. TDS administrator PC information example form

TDS Client PC informationODBC connection to the database server, sufficient disk space, and sharedaccess to the file server are some of the main criteria that need to be lookedat in this step. Figure 14 shows an example TDS client PC information form:

Figure 14. TDS client PC information example form

Database server informationIdentify the machine that will host and the type of RDBMS that will retain therespective configuration repositories. The following information is required toset up Tivoli’s RDBMS Interface Module:

• Database Vendor

• Database ID

• Database Home Directory

• Database Server ID

• User name

Is this PC dedicated to Tivoli Decision Support or is it used for otherapplications? If it is used for other applications, what are they?

Machine Type: ________________________

Operating System: _____________________ Version: ___________

Has a drive letter to the server components been mapped on this machine?If yes, what is the drive letter? ______________

Example Form

Machine Type: ___________________________________________

Operating System: _______________________ Version: _______

Free disk space: _________________________ RAM: __________

Number of client workstations for installation: __________________

Number of classroom workstations for installation: ______________

Example Form


• Instance Home Directory (DB2 only)

For database management purposes, identify what the customer wants to dowith the data collected in the configuration repositories; this information willassist in engineering the database by determining the following:

• Structure of the Database

• Size of the Database

• Required Queries by users

• Customized Database tasks, scripts, and reports

• Database clean-up requirements (when and how often)

Figure 15 shows an example database server information form:

Figure 15. Database server information example form

Network informationSince TDS is comprised of three directly-related components functioning ondifferent machines on the network, it is important that all network shortfalls beidentified. Figure 16 on page 40 shows an example network information form.

Is this a dedicated database server or is it used for other applications? If itis used for other applications, what are they?___________________________________________________________

RDBMS: _____________________________ Version: ______________

Is your database backup hot or cold?__________________________

Day(s) and time(s) of database backup __________________________

Example Form

In the example form shown in Figure 15, Hot refers to a backup where thedatabase remains in use while the data is backed up. Cold refers to loggingoff all users, stopping all database activity, and then backing up the data.

A cube build will fail during a cold backup of the data source or if a TivoliDecision Support multidimensional view is open. Cube builds should bedone during business off-hours.

Note

Methodology 39

Figure 16. Network information example form

3.2.3 Project planning phaseThe consultant team uses data generated in previous TDS Methodologyphases to develop the detailed project plan. The plan includes all projectplanning documents, identification of the specific tasks to meet customerrequirements, identification of the consultant resources to perform each task,and a definition of how the consultant team will partner with the customer tofinish the job.

Project planning ensures that each engagement completes on time, stayswithin budget, and produces a TDS solution that satisfies the customer.

Table 4 shows the input and output items, which highlight the components ofthe project planning phase:

Table 4. Project planning phase items

Project Planning Phase

Input

Initial customer requirements

Tivoli Decision Support requirements questionnaires

Technical proposal

System architecture and design document

OutputProject analysis

Detailed project plan

Network protocol used between Database Server and Application Server,Workstations and Servers (i.e. TCP/IP, IPX-SPX, etc.): ________________

Do you use network Login scripts to set application path statements?

Example Form


Figure 17 outlines the process flow of the Project Planning phase:

Figure 17. Project planning process flow

3.2.3.1 Project analysisAt this point in the process, the sales team and the deployment team haveestablished a strong working relationship with the customer and havecompleted a number of tasks.

Project analysis involves reviewing the results of these efforts. Data availablefor review includes:

• Technical Proposal

• Cost Proposal

• Statement of Work

• Results of all requirements gathering activities

• System Architecture and Design Document

For the details of the review and verification process, refer to the TivoliImplementation Methodology. To find information on how to access TIM, referto the instructions outlined in Appendix A, “Tivoli ImplementationMethodology (TIM) 3.6” on page 185.

3.2.3.2 The TDS project planAfter the analysis is complete, the project manager and the consultantservices team consolidates the results of this activity and develops a detailedproject plan for the customer engagement.

The project plan is a collection of the following information:

• TDS Solution Objectives

• Project task plan

• Project Team Phasing Plan

• Project Change Control Plan

• Risk Assessment and Mitigation Plan

INPUTProject

AnalysisDrawing up

the PlanChoosing a

Project Team Training Plan OUTPUT

Project Planning Flow

Methodology 41

• TDS Training Plan

• Status Reporting Plan

The deliverables in the preceding list represent a high-level listing of what isexpected of this TDS project plan. The details of each deliverable are clearlyexplained in TIM and should be referenced directly from TIM. It is however,important that we discuss some of the Decision Support details surroundingsome of these core deliverables, namely, the solution objectives, project taskplan, staff phasing plan, and training.

Decision support solution objectivesA plainly-written document called the Solution Objectives is written by theproject manager that used to establish the scope of the project. The TDSSolution Objectives document summarizes the results of the initial projectreview documented in the project analysis and is created to assist with projecttask plan development.

Elements of the TDS Solution Objective include the following:

• The TDS solution to be developed and the estimated completion date

• The customer’s business and information technology goals for the project

• The number of hours allocated to the consultant team to deliver thisproduct

• A description of the functionality and limitations of the solution

• High-level tasks required to develop the TDS solution

• Assignment of high-level tasks to the customer or consultant organization

• Completion criteria established for each high-level task and for the project

• Key assumptions and risks associated with the project.

Decision Support project task planThe project manager and the services consultant team consolidate theresults of the Analysis and develop a project task plan for the customerengagement. The goal of the project task plan is to identify all project tasks,the duration of each task, and the individual responsible for performing eachtask. The project task plan also presents this data graphically. This plan isused to set customer expectations for consultant services engagements andto track progress and control the scope of these engagements.

In line with the above-mentioned goal, the project task plan is supposed to dothe following:

• Identify the TDS version and patches to be deployed


• List all prerequisite tasks that must be performed in preparation for eachdeployment task

• Define the schedule for the customer to provide consultant services facilityaccess and office materials at the customer location

• Require that all outstanding requirements gathering or system analysisactivities are complete or that tasks are documented in the project taskplan to perform this work

• Define the TDS environment configuration and administrative tasks

• Define the date that the required hardware should be acquired

• Detail the configuration process of TDS hardware

• Identify work to be completed for each task in the project task plan

• Address each reporting requirement identified by the customer

• Identify each task required to implement the TDS architecture

• Identify all configuration and customization tasks not defined by the TDSarchitecture

• Identify each task necessary to perform system testing

• Identify each task necessary to generate deployment documentation

• Identify all management and administrative tasks essential to the successof the project

• Assign each task to an individual

• Specify the duration of each task

For your reference, Figure 18 on page 44 shows a snapshot of a project taskplan.

Methodology 43

Figure 18. Sample project plan

3.2.3.3 Project team phasing planThe formation of the Implementation Project Team is critical to the success ofany project. The roles of the essential team members required for TivoliDecision Support implementation projects are detailed in the followingsections. Keep in mind that one team member may fulfill multiple roles duringthe implementation project.

Implementation project leaderThe Implementation project leader organizes the efforts of the team. His orher responsibilities include project management, direction setting, resourcescheduling, and project acceptance. It is crucial that the customer provide anImplementation project leader. This role is typically filled by someone withauthority to sign off and accept completion of contracted work. The projectleader must be available to verify and accept any work completed by the


implementation consultants. This person will be required to sign theacceptance document as the various project phases are completed.

System administratorThe responsibilities of the Tivoli Decision Support system administratorinclude long-term model administration, parameter administration,configuration changes, usage policies, and so on. If the reports analystposition detailed below is not filled, the system administrator assumes thereports analyst’s responsibilities.

Management teamThe Management team provides the sponsorship necessary to successfullyimplement the products within the business units of the company. Theirresponsibilities will be to aid the team in marketing the application to otherbusiness areas, to provide the resources and funding needed for theimplementation, and to remove organizational roadblocks. Participation isheaviest during the planning phase of the implementation but continuesthroughout the implementation process.

Tivoli product system administratorsDue to the integral nature of Tivoli's products, it may be important for theTivoli system administrators (for those products for which TDS DiscoveryGuides have been purchased) to be on the Tivoli Decision Supportdeployment team. Responsibilities include describing any customizations tothe product databases and determining the overall management objectivesfor the Tivoli Decision Support implementation. Participation is highest duringplanning and the first phase of implementation.

Network administratorSomeone familiar with the corporate network configuration is the best choicefor this role. Responsibilities will be to aid the team in technology decisionsand in the installation of software and the setup of user permissions to thedirectory structures of the applications. Participation is heaviest during theplanning phase and first phase of the implementation.

Database administratorThe Database Administrator's participation is critical to the success of theimplementation. Responsibilities will include team participation in technologydecisions and in optimization of the database prior to deployment.Participation is heaviest during application setup, but will be ongoing as DBAissues arise.

Methodology 45

Web administratorIf your organization would like to take advantage of Tivoli Decision Support'sability to push views to a Web server, you will need a Web administrator. Heor she will be responsible for the Web servers administration in yourenterprise and will make sure that all the users have access to the reportsstored on the Web servers.

Reports analyst (optional)The best choice to fill this role is someone who has experience with astructured programming language and software development and who hasexperience with Crystal Reports. Responsibilities include completing cubecustomizations as defined during the implementation (This role can be filledby a customer resource if available, or by a Tivoli Systems resource).

Trainer (optional)The TDS trainer will be responsible for attending all TDS Workshops and fortraining TDS administrators and users after the deployment.

3.2.3.4 Decision Support training planDuring the services engagement, customer personnel working with Tivolicertified consultants will gain some informal knowledge of the Tivoli DecisionSupport software.

Additional formal training, however, is necessary for all customer personnelinvolved with the development, implementation, testing, transition,administration, or operation of the TDS solution.

The consultant project manager works with the customer project manager toidentify the training needed by each customer staff member and helpsdevelop a training plan based on the individual's responsibilities, thenecessary skills, and available training courses.

At the time this redbook was published, Tivoli developed a series ofworkshops to deliver this necessary training. The training covers the entiredeployment process starting from Installation and Configuration to the use ofthe Discover Interface. Table 5 highlights the content and value of theseworkshops:

Table 5. TDS workshop summary

Workshops Description

Application setup, Configuration,and Administration workshop

Installation and configuration of the TDScomponents. TDS Administration options, cubebuilds, build schedules.


3.2.4 Deployment phaseThe objective of this segment is to bring together the best projectmanagement organizational practices and technical team deploymentknowledge to successfully deploy the customer’s TDS solution. Thedeployment implements the design defined for the solution according to theSystem Architecture and Design Document. The deployment follows thesequence of tasks defined by the project task plan.

The input and output items listed in Table 6 highlight the components of theDeployment phase:

Table 6. Deployment phase items

Figure 19 outlines the process flow of the Deployment phase:

Advanced administration TDS usability, configuring profiles, publishing views,adding components to the topic map

Customization workshop Modifying calculations, adding flex fields, creatingnew cube and report templates

End-user workshop Use of the Discovery Interface includingdrill-through and adding dimensions

Deployment Phase

Input

Tivoli deployment guides

Initial customer requirements questionnaire

Tivoli Decision Support requirements questionnaires

Technical proposal

System Architecture and Design Document

Detailed project task plan

Output Tivoli TDS solution, ready for testing

Workshops Description

Formal Tivoli training is offered by the Tivoli Worldwide Educationdepartment. Information about Tivoli Customer Education is available athttp://www.tivoli.com/services/education/

Note

Methodology 47

Figure 19. Deployment process flow

For most Tivoli product deployments, Tivoli management softwaredeployment guides are provided to the technical consultant to assist with allinstallation, configuration, customization, automation, and maintenancetasks. These guides contain a wealth of information by providing in-line tipsand hints and Web-based links to online documentation, technical papers,and useful Web sites. The important topics of a TDS deployment guide areshown in Table 7:

Table 7. TDS deployment guide

ReferenceType

Subject Information Pointer

ProductVersion,ShippedManuals,Installation

TDS Information Available on TDS CDhttp://www.support.tivoli.com/Prodman/html/AB.html

Release Notes http://www.support.tivoli.com/Prodman/html/RN.html

Patch Number/PatchReferences

Patcheshttp://www.support.tivoli.com/patches/ftp://ftp.tivoli.com/support/

Tivoli ExternalWeb URLPointers

TDS Informationhttp://www.tivoli.com/products/index/decision_support/

White paperReferences,Managed ViewArticles, URLPointers

White Papers http://www.tivoli.com/products/documents/whitepapers/

Managed Viewmagazine

http://www.wellesleyinfo.com/tmv/

Press Release http://www.tivoli.com/teamtivoli/press/

INPUT PreparationTDS

InstallationTDS

ConfigurationTDS

Customization OUTPUTTDS Training

Deployment Phase Flow


The phases of the Deployment Segment include:

• Preparing for deployment

• Installation and customization

• Configuration

• Advanced configuration and customization

• Training

3.2.4.1 Preparing for deploymentA few important steps need to be performed before deployment cancommence.

1. Hardware prerequisites

Prior to deployment, the customer should have all the necessary hardwarein position and ready to be rolled out with the TDS applications. Theconsultant services team should have information on all the machineaccess passwords with appropriate permissions to make configurationchanges.

2. Software prerequisites

It is necessary to verify that all prerequisite software installations andnetwork configurations have been completed prior to the deployment ofTDS. Some of the items to be checked include:

• 32-bit database client software is installed on every TDS client and theTDS Administrator PC.

• 32-bit SQL database connectivity has been verified on each TDS clientand the TDS Administrator PC.

ConfigurationandCustomization

DiscoveryAdministrator

Refer to TDS Administrator Guide, TOC

DiscoveryInterface

Refer to TDS User Guide, TOC

Server Refer to TDS Installation Guide, TOC

Maintenance Troubleshooting& Optimization

Refer to TDS Administrator Guide, TOC

ReferenceType

Subject Information Pointer

Methodology 49

• The shared source path (the file service where the cubes, reports,models, and administrative databases will reside) has been mapped tothe TDS Administrator and client PCs.

• Network connectivity between the TDS Administrator PC, client PCs,and the shared source path has been successfully tested.

• The TDS Administrator PC and TDS Client PCs have READ andWRITE access to the shared source file server.

• In order to optimize SQL processing time, database maintenance andbackup has been recently performed, indices have been rebuilt,inactive records purged, and appropriate data archived.

3. Gathering documentation

The deployment team should have all the necessary documentation onhand. This includes, but is not limited to, the input elements identifiedbelow:

• Tivoli deployment guides

• Initial customer requirements questionnaire

• Tivoli Decision Support requirements questionnaires

• Technical Proposal

• System architecture and design document

• Detailed project task plan

3.2.4.2 Product installationThis section describes the method for an installation in Network Mode. Thefollowing tasks are accomplished in this phase:

Tivoli Decision Support file server example macro-tasks• Installation of the Tivoli Decision Support Server Components on the

Shared Source file server.

• Install the TDS Discovery Guides required to meet customer requirementsas established in the systems analysis

Tivoli Decision Support administrator example macro-tasks• Installation of the following components on the TDS Administrator PC:

• Tivoli Decision Support Administrator components

• Cognos Administrator components - Transformer, On-line Books, andHelp files

• 32-bit Crystal Reports 6.0


• 32-bit ODBC driver (if not already installed)

Tivoli Decision Support client example macro-tasks• Installation of the following Tivoli Decision Support client components:

• Tivoli Decision Support Client

• Cognos Standard - PowerPlay, On-line Books, and Help

• 32-bit ODBC driver (if not already installed)

3.2.4.3 Product configurationThe Discovery Administrator needs some configuration in order to work withthe chosen guides and configured data source. The Discovery client needs tobe configured for each user to enable their job-specific data and views to beavailable to them. The following tasks are accomplished in this phase:

TDS administrator• Importing the required guides

• Adding the respective Data Sources for the cubes associated with theguides that have been imported

• Configuration of TDS Administrator options including cube parameters anddate ranges, as well as other guide-specific parameters for the cubes.

• Review the cube build schedule and use the Tivoli Discovery Scheduler toautomatically build the cubes after business hours as specified in thedesign document.

TDS client• Selecting the Guides that the user will require

• Setting up the appropriate user roles

3.2.4.4 Advanced configuration and customizationThe customer requirements not fulfilled by TDS now need to be integratedinto the solution. This is a technically-intensive stage during which thefollowing customization tasks are accomplished:

• TDS calculations are modified.

• Flex fields are added as dimensions to cubes.

• Flex fields are added as parameters to Crystal reports.

• Terminology in PowerPlay or Crystal reports is changed.

• Existing reports are integrated.

• New Crystal and PowerPlay reports are created.

Methodology 51

3.2.4.5 TrainingCustomer personnel involved with the development, implementation, testing,transition, administration, or operation of the TDS solution require trainingbased on the individual's respective responsibilities.

For details on the type of training available, refer to the workshops identifiedin Section 3.2.3.4, “Decision Support training plan” on page 46.

3.2.5 Testing phaseThe intent of the test segment is twofold:

• To verify the operability of the customer's TDS solution

• To verify the service organization's methodology of deployment andintegration of the TDS solution within the customer's environment

The input and output items shown in Table 8 highlight the components of theTesting phase:

Table 8. Testing phase items

Figure 20 outlines the process flow of the testing phase:

Figure 20. Testing process flow

3.2.5.1 Preparing to testThe customer should be involved with the testing of the TDS solution. Thisenables and encourages the customer to take an active role in the

Testing Phase

Input

Tivoli TDS solution, ready for testing



OutputSystem test plan

Verified TDS deployment

INPUT Preperation IntergrationTesting

SystemTesting

ProductionTesting OUTPUT

Testing Phase Flow


deployment, thus, becoming familiar with the Tivoli solution and more easilyassuming ownership of the solution.

Time and resources should have been allocated to test the TDS solution inthe project task plan throughout the deployment.

3.2.5.2 Testing the solutionEach phase of the deployment should be followed by a functionality testingexercise. It is required that the following set of test cases be applied in orderto verify the TDS solution:

• Integration testing

• System testing

• Production testing

Each of these test case types identifies a unique level of testing to beperformed to verify the solution. This will be made clear in a moment.

Integration testThese test cases verify the connection of the functional elements of the TDSsolution. The following items are tested:

• Network communication between all Decision Support Componentsincluding RDBMS Server

• 32 bit ODBC connection between Decision Support Administrator Serverand RDBMS Server

• The shared source path has been mapped to the TDS Administrator andclient PCs.

• RDBMS Server is up and running and collecting data from the respectivedata sources

• The TDS Server has been installed and configured correctly

• All the Discovery Clients have been installed and configured correctly

• All the Discovery Administrators have been installed and configuredcorrectly

Every product installation and configuration entry in the project task planmust be followed by a functionality test in this segment of the deploymentcycle.

Note

Methodology 53

System testThis suite of test cases is used to verify that each element of the TDS solutionexecutes properly and that all of the solution elements function properly inrelation to one another. System testing verifies that the solutionaccommodates the following defined requirements:

• Installation and Importation of the Decision Support Guides.

• Data Source connections must be tested with the database.

• Manual population of the cubes (.mdc files) with representative sampledata to verify that each cube builds properly and to validate data.

• Monitoring of the time it takes to build the cube and identify any networkbandwidth issues.

• Use the Discovery Interface Client machines to test successful access tothe cube and report directories on the server.

Production testProduction testing is the first time that the TDS solution is subjected to theproduction environment or a production-like environment. The intent ofproduction testing is to verify that the solution performs properly and withacceptable performance under the load of the operational environment.

Production testing can be conducted by mirroring events from the productionsystem so that production-level testing and normal production systemactivities occur concurrently. Alternatively, a period of time may be specifiedduring which the TDS solution utilizes the production system environmentwith concurrence from the customer that the solution is in test mode, and theresults of the solution are not guaranteed. At this time, the following itemsrequire attention:

• Manual cube builds are completed successfully and in a suitable timeperiod.

• Task Server is running and scheduling the builds on time without runninginto any errors.

• All the Administrators and Client operators display a good knowledge ofthe product/s that they handle.

3.2.6 Documentation phaseDocumenting the customer's deployment is essential to the servicesengagement. The Project Deployment Summary addresses each element ofthe customer's TDS solution including installation, configuration,customization, automation, and maintenance scripts and programs.


Each machine, user, group, and application used by TDS is identified. Thisdocument is the complete reference available to the customer after a servicesengagement and enables the customer to independently maintain andoperate the TDS solution.

The Project Deployment Summary also serves as a reference document for aservices organization to perform future enhancements to the customer's TDSsolution.

The input and output items shown in Table 9 highlight the components of thedocumentation phase:

Table 9. Documentation phase items

Figure 21 outlines the process flow of the Documentation phase:

Figure 21. Documentation process flow

3.2.6.1 Preparing for documenting the deploymentDuring the Detailed Project Planning segment and throughout theDeployment segment, elements of the Tivoli solution were documented. Insupport of this, the technical consultant in charge of the project plan has donethe following:

Documentation Phase

Input

Installed, configured, customized, and tested TDS solution



OutputProject deployment summary

A complete and well-documented TDS deployment

Preparation TechnicalOverview

Administrationand

Maintenance

ProblemDetermination

ImplementationDiscussion

INPUT

OUTPUT

SystemOverview

Documentation Phase Flow

Methodology 55

• Allocated a consultant with an additional project librarian role

• Verified and retained all configuration, customization, solutionadministration, and solution maintenance procedures

3.2.6.2 Project deployment summaryThis deployment summary is necessary to document all installation,configuration, customization, automation, maintenance scripts and programsdeveloped for the customer. Each machine, user, group and applicationmanaged by Tivoli Decision Support is identified as well as the versions ofeach product installed. Finally, the Deployment Summary documentsadministration and maintenance tasks necessary to operate the TDSsolution. Properly controlled and updated, the document will provide benefitto the TDS solution developed for the customer. The document is comprisedof the following topics:

System overviewThis section introduces the TDS solution deployed at the customer's site.Using information already created in the System Architecture and Designdocument, a high level overview of the customer's TDS solution is presented.

Technical overviewThe Technical Overview section of the deployment document providesdetailed configuration and customization information for:

• The architecture of the solution

• Automation and maintenance scripts and programs developed for thecustomer

Administration and maintenance proceduresThis section of the deployment document is the most valuable to thecustomer. It documents each Tivoli, system, network, application, anddatabase administrator task necessary to operate and maintain thecustomer's TDS solution.

Problem determinationThis is the section of the deployment guide that provides problemdetermination and analysis information to the customer. Items addressed inthis section include the following:

• Log and Trace file information

• Performance Monitoring tools

• Daemon status information

• Developed script and program error code conditions


• Fail-over analysis

• Security permission failures

• Database failures

• Communications failures

Discussion of implementationThis is a brief project management discussion highlighting the methodologiesused during deployment. This section of the deployment document includesthe project team's recommendations for future enhancements of thecustomer's TDS solution.

Methodology 57


Chapter 4. TDS architecture and design considerations

The design of any solution is part science and part art, and a number ofaspects that need to be considered vary from customer to customer. Onlythrough careful consideration of the receiving information about theorganization’s needs and limitations (obtained during therequirements-gathering phase of the project) and an understanding of thetechnical capabilities and restrictions of Tivoli Decision Support can anoptimal architecture be created.

This chapter describes the detailed design phase of a Tivoli Decision Supportdeployment project. The design issues that face us are explained, designstrategies are presented, and recommendations are made.

4.1 Overview

Section 4.2, “Integrating Decision Support with Tivoli Enterprise applications”on page 60 illustrates how and where Tivoli Decision Support fits into a Tivolienterprise environment.

Section 4.3, “Tivoli Decision Support components” on page 61 describes thevarious Decision Support components and the software with which they arecomposed.

Section 4.4, “Integrating Tivoli Decision Support components” on page 63illustrates how the components fit together, what their roles are, and theirresource requirement needs.

Section 4.5, “Stand-alone vs. network architecture” on page 70 compares theTivoli Decision Support installation modes, Stand Alone mode and DistributedNetwork mode. This section explains the differences and weigh theadvantages and disadvantages of these two installation options.

Section 4.6, “Suggested architecture and design solutions” on page 72presents a set of suggested deployment solutions to common Tivolienvironments.

Section 4.7, “Troubleshooting tips” on page 81 touches on some of thecommon problems experienced with Tivoli Decision Support.


4.2 Integrating Decision Support with Tivoli Enterprise applications

In this section, the integration process will be described to provide the readerwith a clear picture of how Tivoli Decision Support works within a Tivolienvironment, and to gather, manipulate, and present data to the user in aneasy-to-interpret format.

Tivoli Decision Support works in conjuction with Tivoli’s Enterprise software,such as Distributed Monitoring, Enterprise Console, Inventory, NetView,Software Distribution, and so on, in order to perform its role. These variousmanagement applications collect the information and store it in a database.Tivoli Decision Support then accesses these databases through itsproduct-specific TDS Discovery Guides.

Figure 22. Tivoli Decision Support functionality diagram

The above diagram delineates a high-level integration between DecisionSupport and a typical Tivoli Enterprise Environment.

TivoliDecisionSupport

Discovery Interface

Discovery Guides

Endpoints

Gateways

TMR Server

RDBMS

Network


The Decision Support process flow is described in the numbered steps below:

1. At the bottom of the diagram, we have Tivoli Management agents(endpoints), running Tivoli products, such as Distributed Monitoring orInventory.

2. Management Gateways consolidate the data and forward them to TivoliManagement Server.

3. Tivoli applications, such as Software Distribution, Enterprise Console, orDistributed Monitoring, continually update its database or table with datareceived from all the Tivoli Management agents.

4. Tivoli Decision Support accesses this data by means of an ODBCconnection.

5. These data are interrogated by a set of algorithms that are defined by theTivoli Decision Support Discovery Guides, which are available in the TDSenvironment.

6. Tivoli Discovery Administrator then transform this processed data intomultidimensional cubes consisting of business relevant information.

7. This information is then viewed by the Decision Support DiscoveryInterface where the decision maker can perform a drill-down analysis.

4.3 Tivoli Decision Support components

The basic concepts of the Tivoli Decision Support components have beendiscussed in Chapter 2, “Tivoli Decision Support general overview” on page9. This section serves to highlight the technical role(s) that each componentplays as well as the products that must be installed.

• TDS File Server

TDS File Server components include the models, queries, templates, andother information required to build the cubes for the TDS DiscoveryAdministrator and generate views for the TDS Discovery Interface. It isrequired to install the TDS Server Component product.

The following are some important files stored in the TDS File Servercomponent. These files are continually referenced by the other TDScomponents and are either automatically installed with or dynamicallycreated on the TDS File Server machine. These files are located in the$TDS\Data directory.

• Cubes.mdb

This file contains all the SQL queries that are executed during thecube-building process from the Discovery Administrator machine.

TDS architecture and design considerations 61

• Ed.mdb

This file contains all the topic map data. It includes which views are inwhich categories and topic, and the filename for the view. It alsocontains the related views, view hint description, and keywords forsearches.

• DrillThru.mdb

This is created on the fly by TDS Administrator to cache the data usedto create the cube. This data is then read during a drill-throughoperation issued from the Discovery Interface.

• TDS Discovery Administrator

This specialized module enables you to administer Decision Support andto build and customize cubes. This module also assists in theconfiguration of Decision Support.

It is not only required to install the Tivoli Discovery Administratorcomponent on the Discovery Administrator machine, but also the databaseclient component, 32-bit ODBC driver, and Cognos PowerPlay inAdministrator mode. The Database Client and ODBC connection arerequired to access the database during the cube-building process. Thekind of database client and ODBC Driver depends on the specific TDSDiscovery Guide requirements. Always refer to the TDS Discovery Guiderelease notes in order to get specific details.

The Crystal Reports runtime module is installed automatically at the timeof the Discovery Administrator component installation. Note that the fullinstallation of Crystal Reports is optional, and it is required only if thereports need to be changed.

• TDS Client Component

This is the interface to TDS and provides all the tools needed to open andwork with views of the data from your organization’s enterprise databases.

On this component, it is not only required to install the TDS DiscoveryInterface product but also Cognos PowerPlay in Standard mode, thedatabase client, and a 32-bit ODBC Driver. The Database Client andODBC connection are only required to access Crystal Report format datafrom the Repository. This depends on whether the topic structure of yourrespective TDS Guides contain data that uses the Crystal Reporttemplates.


4.4 Integrating Tivoli Decision Support components

Now, we are going to take a close look at the Tivoli Decision SupportComponents and how they integrate with each other. We will discuss thevarious components highlighting the workload and network bandwidth thateach component utilizes in order to perform its tasks successfully.

Figure 23. Decision Support components integration

Figure 23 portrays a high-level view of the components that make up TivoliDecision Support and the integration between them.

The Tivoli Discovery Administrator module, which is installed on the systemadministrator’s machine, connects to your enterprise’s databases through anODBC data source connection and to the TDS File server through a networkconnection. These connections are used to perform the cube-buildingprocess.

To provide the Crystal Reports reports, the Tivoli Discovery Interfaceconnects to the enterprise’s databases through an ODBC data source

INVENTORY

TDS FILE SERVER

DM

TEC

TDS DISCOVERY

ADMINISTRATOR

DISCOVERY INTERFACES

Cube building

PowerPlayreports

Crystal Reportsreports

DATABASES

Network connection

ODBC connection


connection. A network connection to the TDS file server is used to getinformation from the cubes in order to build multidimensional reports.

When you issue a request for information from the Tivoli Discovery Interface,Tivoli Decision Support either reads the information from the databasedirectly, for Crystal Reports reports, or reads the cube file previously createdby the Tivoli Discovery Administrator, for PowerPlay reports. The informationis then returned to the Discovery Interface and presented to the user in agraphical format.

A detailed explanation of the process described above will be discussed inthe subsequent sections of this chapter.

4.4.1 The cube-building processOur explanation of the cube-building process is divided into four steps. Acube can either be built manually or scheduled. A build is normally scheduledto occur on a regular basis depending on the customer’s businessrequirements, and it is preferable that it be done during a period of lownetwork and system usage.

It is necessary to understand what actually gets out during the cube-buildingprocess and the components involved in order to decide on a suitablephysical design.

We will now describe the process used by Tivoli Decision Support at the timeof cube-building highlighting the components involved. We aim to detail theentire process and to make clear that the network traffic that takes placebetween the TDS components is something to be considered when planningyour design solution.


Figure 24. Cube-building process - Step 1

The most bandwidth-intensive task is the cube-building process which isexecuted by the Discovery Administrator. Figure 24 shows step one. Apredefined set of SQL queries are executed on the database from thismachine. All the queries are stored in the Cubes.mdb file. These queriesperform exhaustive interrogation of the database and may take a long time tocomplete.

In step two, as shown in Figure 25 on page 66, the raw data is gathered fromthe database through the SQL queries. The Discovery Administrator thencreates the calculated columns and stores all the data on the TDS File serverin the $TDS\data\export directory.

TDS DISCOVERY

ADMINISTRATOR

SQL Queries

INVENTORY

DM

TEC

DATABASES

Step One



If the query has been designated to export to Drill-through databases, theDiscovery Administrator also writes the processed data to a table of the samename as the query in the DrillThru.mdb file stored in the $TDS\data directoryon the TDS File server. This table will be used during a drill-through operationissued from the Discovery Interface.


TDSDISCOVERY

ADMINISTRATOR

INVENTORY

DM

TEC

DATABASES TDSFILESERVER

RawData ProcessedData

Step Two

TDS DISCOVERY

ADMINISTRATOR TDS FILE SERVER

ProcessedCube

Transformer File

Model

DelimitedText File

ProcessingRaw Data

Step Three


Figure 26 on page 66 shows step three. The Discovery Administrator firstretrieves the information from the model files and the data stored in thedelimited text files. Second, the information is stored into a CognosTransformer file format. The Discovery Administrator then runs CognosTransformer and processes the raw data packing it into a cube. The cube fileis now ready to be transferred to the TDS File server machine. The DiscoveryAdministrator then writes the cube file back to the TDS File server on the$TDS\cubes\temp directory.


As shown in Figure 27, the fourth step is when the Discovery Administratorruns a program called Rover to copy the completed cube from the$TDS\Cubes\Temp directory up to the $TDS\Cubes directory on the TDS Fileserver.

After studying this process, it is evident that there will be quite a bit of networktraffic generated between the Discovery Administrator, TDS File Server, andDatabase repository. It is, therefore, suggested that the DiscoveryAdministrator machine be installed on the same physical network and in thesame location as the other two servers. This will result in faster cube buildtimes and also prevent the process from failing due to packets timing out.

There can be multiple Discovery Administrator machines, each building cubesfor a separate Tivoli Decision Support Discovery Guide. All of them can pointto the server content on the same network TDS File server. A distributedDiscovery Administrator environment is suggested when there is a need tospeed up the cube-building process. Another reason can be for administrativepurposes when there are various people involved with the available guides

TDS DISCOVERY

ADMINISTRATOR TDS FILE SERVER

RoverProgram

Step Four


and there is a need to localize the Discovery Administrator console forspecific users.

4.4.2 The Discovery InterfaceThe Discovery Interface is located on the PC clients and will usually bepointing to the server content located on a TDS File server. The DiscoveryInterface also makes use of an ODBC connection to the database repositoryto pull out data for the Crystal Reports reports.

The Discovery Interface communicates with the TDS file server to access themultidimensional cubes built by the Discovery Administrator. This is madepossible by mapping to a network drive share on the TDS File server.

Figure 28. Viewing the multidimensional reports

Figure 28 shows the process of accessing the cubes in order to make theinformation available on the Discovery Interface. The $TDS\Cubes directoryon the file server contains all of the cubes (.mdc files). They are generatedperiodically through the TDS Discovery Administrator. The PowerPlay report(.ppr) files are also located in the same directory. These are installed byinstalling a new TDS Discovery Guide. Every time the Discovery Interface is

When planning to have two or more Discovery Administrators, install thecomplete TDS Discovery Guide into only one Discovery Administratormachine. Installing separate Discovery Administrator Machines to builddifferent cubes for the same guide IS NOT recommended.

NoteNote

TDS FILE SERVER

Cube,Views,DrillThru ...

DISCOVERYINTERFACE

Accessing the cubes


started and a specific topic selected, these files are pulled over the networkto produce the multidimensional views. In addition, the files Ed.mdb andDrillThru.mdb are also pulled over the network from the TDS File server to theDiscovery Interface machine when using Tivoli Decision Support in a networkmode architecture

Figure 29 highlights the process of accessing the data and the templates inorder to have Crystal Reports reports. The $TDS\Reports directory on the fileserver contains all the Crystal Report files (.rpt). These are also installed byinstalling TDS Discovery Guides. In a network mode architecture, these filesare pulled over the network when a Crystal Report view is selected from thetopic map.

Figure 29. Viewing Crystal Reports

The selection of a Crystal Report identified by a page-like icon in the topicmap performs two network operations. An ODBC connection is establishedwith the database from where the data is collected, and, the respective reporttemplates stored in the $TDS\Reports directory on the file server are pulledover to the client machine where the TDS Discovery Interface is installed. TheCrystal Report is then displayed on the Discovery Interface.

The Discovery Interface also reads information from the $TDS\Data directoryof the TDS File server. The necessary information includes all the topic mapdata, which views are in which Categories and Topics, the related views, theview hint description, and keywords for searches. This information is found inthe Microsoft Access databases (.mdb) files.

TDS FILE SERVER

Templates

DISCOVERYINTERFACE

INVENTORY

DM

TEC

DATABASES

DataCrystal Reports


.

4.5 Stand-alone vs. network architecture

Before you install Tivoli Decision Support, you need to determine whichinstallation method will be most suitable for your environment. The methodyou select depends on the way you run TDS.

In stand-alone mode, Tivoli Decision Support runs on one machine, and noneof its components are shared with anyone else in the entire enterprise. Theuser of the stand-alone system not only has access to the Discovery Interfacebut must also administer Tivoli Decision Support.

When you install Decision Support to run in stand-alone mode, it is assumedthat all Decision Support functions (querying, report generation, andadministration) occur on that system. This means that you must install all theDecision Support components on that system with the possible exception ofCrystal Reports, which is required only if you plan to change some reports.

Figure 30 represents a stand-alone architecture. An installation of this typeshould only be implemented in a very small environment where a singleperson is responsible for the administering and decision-making process.

Figure 30. TDS in stand-alone mode

When a new TDS Discovery Guide is installed on the TDS File server, thefiles Ed.mdb and Cubes.mdb are updated to include the new topic mapsand view information. Both the Discovery Interface and the DiscoveryAdministrator components access the contents of these files at applicationstart-up time.

Note

INVENTORY

DM

TEC

DATABASESMachine running TDSin stand alone mode

ODBC Connection


In network mode, only the Discovery Interface component, PowerPlay inStandard Mode, Crystal Reports (if it is intended to change the Crystalreports), database client, and the ODBC driver are installed on the clientmachine. The other components are installed elsewhere as described below.The user of a client system only has access to the Discovery Interface. TheDiscovery Administrator machine is the only point to administer TivoliDecision Support.

The configuration diagram shown in Figure 31 details the connections madebetween the various components in a Network Mode architecture. This is thearchitecture that should be used for medium to large environments

Figure 31. Network installation architecture

A network mode installation makes it possible for multiple users to accessDecision Support in the various areas of the enterprise. All clients connect tothe file server where the cubes are being updated on an pre scheduled,preferable off hours, basis. This is a more realistic and purposeful deploymentmethod where the various Tivoli Decision Support operations are separated.Only the system administrator will be able to perform the DiscoveryAdministrator tasks, with the client systems only having access to theDiscovery Interface to open and work with the views of data.

A mixture of the two installation methods can also be implemented. However,this will depend on the roles and resource capacity of the machines on whichDecision Support runs. The Discovery Administrator and TDS File server canbe installed on the same machine with multiple clients accessing the shared

File server runningserver components

including guides,cubes and models

System runningAdministrator and client

Service and supportdatabase system

ODBC


Interface


Interface


Interface

Shared File Access

INVENTORY

DM

TEC

DATABASES

ODBC


server component directory. A thing to watch out for, though, is that a cubebuild may severely reduce the responsiveness of a Client Discovery Interfacethat is trying to view and drill down into the data at the same time as the cubebuild.

4.6 Suggested architecture and design solutions

It is clear from Section 4.4, “Integrating Tivoli Decision Support components”on page 63, that both the Discovery Interface and Discovery Administratorare required to communicate extensively with the TDS File Server and theDatabase in order to play their roles.

From Section 4.5, “Stand-alone vs. network architecture” on page 70, welearned that if multiple users want to run Decision Support in the variousareas of their enterprise, they should install the program’s components innetwork mode. This installation method gives each user access to theDiscovery Interface while localizing the TDS Server components on a fileserver and the Tivoli Discovery Administrator on the system administrator’smachine.

Now, we will exercise the lessons learned in this chapter so far. We will takesome typical environments as case studies, and, from there, we will suggest asuitable Tivoli Decision Support Architecture. We will consider the followingthree types of Tivoli business environments:

• Typical Tivoli Service Desk

• Single TMR environment

• Multiple TMR environment

4.6.1 Tivoli Service Desk environment - Case studyFigure 32 on page 73 shows a Tivoli Service Desk Problem Managementenvironment with Tivoli Decision Support installed on a single machine instand-alone mode. This is a call center problem-management solutionincluding servers and networked clients. These machines are all managed byTivoli. The problem management data is stored in a database server on theTEC server.

As in all Tivoli Decision Support deployments, one of the questions we mustanswer is in which architecture mode should TDS be installed? During theRequirements Gathering phase of the project, all information needed toanswer this question should be obtained and analyzed. Such information canbe, but is not limited to, which Tivoli Service Desk databases are required to


be processed by a TDS Discovery Guide, who is going to utilize the TDSDiscovery Interface, who will be responsible for the TDS DiscoveryAdministration machines, and so on. In addition, all Tivoli Service Deskapplications and servers of the customer as well as their physical locationshould be documented.

The situation we are faced with represents an architecture in which all theservers are centrally located in one region running on the same networksegment as the Problem Management databases. There exist norequirements for decision-making personnel at other locations to access theDecision Support business information.

Figure 32. Tivoli Service Desk environment case study

Since TDS will be used by a single user, we can choose to install it instand-alone mode. In stand-alone mode, everything runs on one system, andnone of the modules are shared with anyone else on the network.

In the environment under analysis, this case holds true. We have suggested asingle machine to perform the Tivoli Decision Support functionality. Thisallows for central management and does not put extra traffic on the network.

- Problem, Change andAsset ManagementFile server

- NSM Gateway

- TEC Server- Database Server- Distributed Monitoring

- TMR Server- Distributed Monitoring

- TME Netview- NSM Gateway- Tivoli Inventory

- Problem, Change andAsset Management(Networked Client)

Tivoli Decision SupportStand Alone Mode

- Problem, Change andAsset Management(Stand-Alone Client)

Tivoli Decision Support in a Tivoli Service Desk environment


Communication is only between the Tivoli Decision Support system and theproblem management database.

4.6.2 Single TMR environment - Case studyThe most common Tivoli Decision Support implementations will probably becarried out in this type of environment as illustrated in Figure 33 on page 75.

The Tivoli management environment servers consist of a TMR server, a TECserver and an RDBMS repository (usually on the same machine as the TECserver). There is only one TMR server with distributed gateways at remotesites.

This type of Tivoli Enterprise management environment is usually the casewith a single customer with one or more remote locations aside from the headoffice where the Tivoli Servers are located. It could also be a single locationwith multiple gateways servicing a large number of endpoints.

In either case, systems management functions take place in the centrallocation where the Tivoli management servers are located. The data collectedby the management agents is passed from the endpoints through thegateways to the TMR server from where it will update the various databaserepositories.

For the purpose of this particular exercise, we will assume that the Tivoliinfrastructure sits in the same location down to the endpoint level.


Figure 33. Single TMR environment case study

As before, our first analytical decision is to determine whether we shoulddeploy Tivoli Decision Support in a stand-alone or network mode.

In most business, like the one managed in our example, there will be a needto present reports to various levels of management. These reports mustpresent a wide range of data views filtered to the level of detail required bythe person operating the Discovery Interface client.

There should also be a dedicated systems administrator who is responsiblefor performing all the systems management technical administration for thebusiness. This individual will, most probably, also be responsible formaintaining the entire Tivoli infrastructure.

TMR Server

Gateway

Endpoints

DistributedMonitoring

TEC Inventory

DatabaseRepository

Gateway

Endpoints

TEC Server

SoftwareDistribution

INVENTORY

DM

TEC

Single TMR environment


Figure 34. Single TMR environment with Tivoli Decision Support

The TDS deployment solution shown in Figure 34 will have to be a networkmode installation. The TDS File server, Discovery Interfaces, and DiscoveryAdministrator will be set up to run from the main site along with the otherTivoli enterprise systems.

There will be no clients located at the remote sites (if any) and only oneDiscovery Administrator is required. The solution shown in Figure 34 willintegrate with the database repository where the administrators will runqueries to build its multidimensional cubes and the Discovery Interface canread off the Crystal Reports reports. The Discovery Interface machine willalso make a connection with the TDS file server to access the cubes. Allthese components are located in the same LAN and, thus, the Tivoli DecisionSupport process should function optimally.

TMR Server

Gateway

Endpoints


TEC Inventory

Gateway

Endpoints

TEC Server


TDSAdministrator

TDSFile Server

TDS Clients

DatabaseRepository

INVENTORY

DM

TEC

Tivoli Decision Support in a single TMR environment


4.6.3 Multiple TMR environment - Case studyA typical multiple TMR environment is shown in Figure 35 on page 78. Thisenvironment consists of a Tier 1 TMR Server, a Tivoli Enterprise ConsoleServer used to process events from managed servers and the DatabaseRepository at Site A, and two Tier 2 TMR servers located at Site B and SiteC. For each of these Tier 2 TMR servers, we have distributed gateways withthe endpoints for each specific site.

This type of TME environment is usually the case in a Service DeliveryCenter implementation with many customers at one or more remote locationsand a head office where the Tivoli Tier 1 Servers are located and onto whichthe Tier 2 server is latched.

In this multiple TMR scenario, the key systems-management functions takeplace in the central location where the Tivoli management Tier 1 servers arelocated. The data collected by the management agents is passed from theendpoints to their gateways and then to their Tier 2 TMRs. This data is finallypassed on to the Tier1 TMR server from where it will update the variousdatabase repositories.


Figure 35. Multiple TMR environment case study

For this case, it is very clear that we will need to deploy Tivoli DecisionSupport in a network-mode.

Unlike the single TMR environment, there will be decision makers who needto have access to the business information. This means that we will need tohave Discovery Interfaces installed on the remote sites B and C. As in thesingle TMR environment, there will be a need to present reports to variouslevels of management, but, in this case, access to the TDS system fromremote sites is required.

TMR Server


TEC Inventory

TEC Server


TMRServer

Gateway

Endpoints

Site CGateway

Endpoints

Site B

TMRServer

DatabaseRepository

INVENTORY

DM

TEC

Site A

Multiple TMR environment


Figure 36. Multiple TMR environment with Tivoli Decision Support

As in all other cases, there should be a dedicated Discovery Administratormachine that will be installed on the same network segment as the databaserepository with the intention of improving performance at the time of the cubegeneration process.

If the installation of additional TDS Discovery Guides is required, this will, inturn, result in increased resource utilization on the administration console.Consequently, the cube-building process will take longer to complete. In orderto distribute the work load, it is appropriate to have additional DiscoveryAdministrator machines installed. A scenario where we can have one TDSDiscovery Guide per Discovery Administrator machine would be the bestapproach, but this results in the systems administration tasks beingdistributed. A separate Administrator machine should then only be

TMR Server


TEC Inventory

TEC Server


Gateway

Endpoints

TMRServer

Site BTDSAdministrator

TDS MainFile Server

TDSClients

TDSSecondaryFile Server

TDSClients

DatabaseRepository

INVENTORY

DM

TEC

Tivoli Decision Support in a multiple TMR environment


implemented if the business requires that different people manage the guidesthat are relative to their job roles.

Now, we face the issue of the distributed Discovery Interface clients that areneeded by personnel at the remote sites. Section 4.4.2, “The DiscoveryInterface” on page 68 discusses the operations and the communication thattakes place between the Discovery Interface and all other TDS components.The Discovery Interface will connect to the TDS File Server to retrieve thePowerplay cubes and to the database server to retrieve the data needed tobuild Crystal Reports.

The problem we face is that this connection will now take place over the WAN.This will obviously result in a delayed response while trying to access thevarious views over the network.

To solve this problem, we recommend the implementation of one TDS fileserver per remote site. The main TDS file server will reside in the same LANas the Discovery Administrator machine and will be responsible for servingboth the Discovery Administrator machine and all the Discovery Interfaces inthe main location. On the other sites, the TDS file server will be responsiblefor serving the Discovery Interfaces there. This configuration will have asignificant positive impact on the response times for clients accessinginformation stored in the cubes.

To implement this architecture, some sort of replication needs to take placefrom the main TDS File server to the local site TDS File servers.

One method would be to write a script or program that triggers a file transferfrom the main TDS file server to the remote TDS file servers. This processshould be executed soon after the scheduled cube build takes place. This willensure that cubes at all locations reflect the current environment. Besides thecubes, the TDS drill-through database files also need to be replicated.

The multi-dimensional Powerplay cubes are scheduled to be built on aregular basis. Depending on the number of TDS Discovery Guidesinstalled, the number of cubes will increase. The cube building processoccurs in a sequential order. The addition of more Discovery Administratorsfor different Guides will enable the workload to be shared.

Note


4.7 Troubleshooting tips

This section touches on some of the common problems experienced withTivoli Decision Support.

4.7.1 ODBC sourceTypically, ODBC connectivity errors look like the following example:

Error: 40002 - IM006: [Microsoft] [ODBC Driver Manager] Driver'sSQLSetConnectAttr failed.

Follow the checklist and hints below in order to verify the cause of theproblem:

• Always verify whether you are using the ODBC database driver for theirdatabase platform. The Tivoli Decision Support CD provides ODBC driversfor several database servers.

• Check the ODBC setup in every Discovery Administrator and DiscoveryInterface machine. Notice that not all database platforms are set up thesame way.

• Check to make sure that you have used the correct qualifier.

• Check whether you are able to connect to the database via a client tool,such as SQLplus, isql, command line processor, or other.

• Test the connectivity using the Discovery Administrator application bychoosing Data Sources -> Test Connectivity; choose the specified datasource in the displayed list. The database is pinged to make sure TDS hasa connection with the database. If successful, the data source dialog boxwill appear telling you the connection was successful.

4.7.2 Cube buildingMost customer problems will involve errors encountered when building cubes;therefore, most of the problems will have to do with the TDS administrator orCognos Powerplay.

The script has to perform a similar function to the TDS rover utility thatcopies the cubes from the $TDS/Cubes/Temp directory to the $TDS/Cubesdirectory on the TDS File server. This will ensure that the transfer of cubefiles does not fail if the Discovery Interfaces are using them.

Note


Discovery Administrator errors include, but are not limited to, installationerrors, ODBC connectivity issues, Visual Basic script syntax errors, SQLsyntax errors, runtime errors, and data anomalies. Basically, if the erroroccurs before the data source file is created, the problem lies either with theAdministrator or with the data that is attempting to be exported.

After the transformation process, you can see if a cube does not build byexamining the Rover window. This window appears as an icon on the task barat the time of the cube-building process. One error you may receive is Error53 - Cube did not build. This error is a consequence of a query that returns nodata. Cognos creates a log file called EDAdmin.log in the $TDS directory. Inaddition, you may check the <model>.log file that is created each time a cubeis being built. This file gets saved to the $TDS/Model directory. You shouldlook for the entry (TR3201) update of cube XXX is incomplete and find theproblem.

If a <model>.log file gets created, the cube build has exported the datasuccessfully. The problem then either lies with Cognos or the cube file hasnot been successfully copied from the $TDS\Cubes\Temp directory to the$TDS\Cubes directory.

Another Rover error you may experience is Error 70 - Permission Denied. Inthis case, Rover tried to copy the temporary cube to the $TDS/Cubes folderand a user has a view opened that references the cube that is being built. Thesolution is to either try to build the cube later or ask all users to close theDiscovery Interface. If Rover has timed out, you should copy the cubesmanually. A failed copy message from Rover may also mean one of twothings:

• The user does not have write/execute permissions on the $TDS directory.

• The cube does not contain at least one compressed record.

If you think these two criteria have been satisfied, check the <model.log> fileand the EDAdmin.log to find out why the cube did not generate.

Cognos errors include, but are not limited to, General Protection Fault errors(GPFs), errors resulting from an incorrectly configured model (.pyg file), anddata anomalies. Cognos errors are the opposite of administrator errors andcan only originate once the data source file has been created.

4.7.3 Discovery interfaceThe following are some common problems and error messages you mayreceive when using the Discovery Interface:


• Discovery Interface does not close down properly

If you shut down Windows and the Discovery Interface is still open, youmay receive an error that TDS is not closed. You should always close theDiscovery Interface before shutting down Windows in order to properlyclose the OLE link between the Discovery Interface and CognosPowerPlay.

• Receive load_graph_from_powercube encountered error message

This error is received when you attempt to display a view for which a cubeis not built. You should certify that the cube is built using the DiscoveryAdministrator Component.

• Discovery Interface does not display published tab

To be able to publish push documents from the Discovery Interface, thepublished tab must be available from the Hints pane. If this tab is notavailable, select the Enable ADI Publish option on the Options dialog boxof the Tivoli Discovery Publisher.



Chapter 5. Case study

The purpose of this chapter is to apply all the knowledge gained in theprevious chapters of this redbook in order to present a structured TDSdeployment solution in a real-world customer environment.

This chapter aims to provide a reference to assist in any Tivoli DecisionSupport Implementation. By identifying the similarities between the casestudy environment and the environment of your enterprise, this chapter canalso be used as a guide to estimate time scales, tasks involved, and processflows for deploying a Tivoli Decision Support solution.

For this case study, the customer will be the IBM Service Delivery Center(SDC) West. All the information, ideas, and strategies provided by Chapter 3,“Methodology” on page 23 and Chapter 4, “TDS architecture and designconsiderations” on page 59 will be utilized here to provide a recommendedsolution for the IBM SDC West environment.

For any Tivoli deployment solution, there is normally a group of professionalscomposed of Tivoli Architects, Technical Experts, and others who areresponsible for providing the official and complete Tivoli deploymentarchitecture and solution design for all management products including TivoliDecision Support. All information provided by this chapter should, therefore,only be used as a project guide and not as an official solution.

5.1 Overview

As mentioned above, this chapter suggests a Tivoli Decision Supportimplementation solution for the IBM SDC West Environment. The SDC Westprovides strategic I/T out-sourcing services to over 50 IBM and commercialcustomers all over the United States.

The SDC delivers a broad scope of solutions including server management(from S390 servers to NT servers), desk-side support, and customer careservices. They do this through four teams: Enterprise Services Delivery,Distributed Services Delivery, the Business & Technology office, and theCustomer Service Center. They are one of four geographic service deliverycenters in IBM Global Services.

The purpose of the case study is to detail a Tivoli Decision Support solution,which will be integrated into the IBM SDC West Tivoli architecture with theintention of providing a simple flowing migration from the reporting toolscurrently implemented.


We aim to exploit the Tivoli Decision Support technology using IBM as ashowcase with the goal of reducing IBM IT reporting costs.

This chapter will provide a list of Future Requirements for Tivoli DecisionSupport where ideas for extra features will be presented based on ourexperience with the case study.

5.2 Methodology

Now, we will practice the methodology described in Chapter 3, “Methodology”on page 23. The case study will start with a requirements-gathering phasewhere a survey of reporting requirements and the current SDC Westenvironment will be carried out. We will then use predefined techniques toanalyze all the received information to present a technical proposal to meetthe customer’s requirements. A procedure-driven deployment exercise willthen be presented illustrating the steps and task flow for each phase of theroll out.

5.2.1 Requirements gathering phaseThe requirements gathering phase is split into three sections:

• Section 5.3, “The existing Tivoli environment” on page 87 describes theactual Tivoli environment used by the customer;

• Section 5.4, “Identifying the reports requirements” on page 92 details thecurrent reporting strategy used by the customer and shows reportscurrently used by them to meet their requirements;

• Section 5.5, “Customer objectives” on page 113 describes a set ofcustomer needs and objectives to meet their reporting requirements.

5.2.2 Systems analysis and designIn this phase, all the requirements gathered in the previously-describedsections will be processed.

Section 5.6, “Mapping Tivoli Decision Support Discovery Guides” on page114 will analyze the current reports generated by the customer. Thesereports will be reviewed and a specific TDS Guide will be recommended toproduce similar results. In addition, we will show the corresponding graphic ora combination of graphics that fit the customer requirements.

Section 5.8, “Suggested architecture and solution design” on page 140presents a recommended architecture and design solution for the SDC Westenvironment.


5.2.3 DeploymentSection 5.9, “Tivoli Decision Support deployment process” on page 144delineates the implementation of the design defined in Section 5.8,“Suggested architecture and solution design” on page 140. A high-level taskflow will be presented for each step of the deployment process.

5.3 The existing Tivoli environment

This section provides information about the Tivoli environment deployed inthe customer’s environment. We will discuss TMR servers, TEC servers,Database servers, RIM hosts, and all Tivoli applications that can be apotential source of information for reporting.

5.3.1 Tivoli general architectureAs shown in Figure 37 on page 88, the customer has implemented what theycall a Hub-Spoke TMR architecture. This model consists of a Tier 1 (Hub)TMR server in Boulder, which performs a dual role as the Tivoli EnterpriseConsole (TEC) and the TMR server, and some Tier 2 (Spoke) TMR serverslocated at each site. The Hub TMR server has a two-way connection to eachof the Spoke TMR servers.

All monitors reside on the Hub TMR/TEC and are distributed downward to theSpoke TMR servers and Gateways. This allows SDC West to manage allmonitors in the enterprise from a common repository avoiding duplication andinconsistency, as well as the means to quickly determine exactly whichmonitors are distributed to which systems.

All rules processing of events takes place on the Hub TMR allowing the sameconsistency as with the monitors. In addition, all notifications are initiatedfrom the Hub TMR.

Performance and capacity data collected from servers running TivoliDistributed Monitoring monitors are stored on the Hub TMR server and thenprocessed at the end of the day by scripts and programs.

The customer plans to have two separate Tivoli Management infrastructures.One is planned to manage the servers, and the other will be dedicated tomanaging all desktops.

For this case study, we will focus on the server infrastructure since thedesktop infrastructure has not been completed at the time of thisrequirement-gathering phase. The desktop infrastructure is expected to be

Case study 87

similar to the server infrastructure with the need for fewer high-availabilityfeatures.

Figure 37. Service Delivery Center - West architecture

5.3.2 TMR serversThe customer has a Hub-Spoke model TMR architecture. Due to the numberof desktops and the need for a high-availability environment for the TMRservers, this architecture is considered optimal and can make tuning of theserver and desktop infrastructures easier.

The server infrastructure Hub TMR is located in Boulder, Colorado. SpokeTMR locations were based on analysis of the following criteria: LAN proximityand loading, geographic location, network topology, capacity management ofthe Spoke TMR, and the number of servers in a project or account. Theactual location of the Spoke TMRs are: Two in Boulder, Colorado and one inSan Jose, California.

BoulderHUB TMRTEC / Sybase

BoulderSpoke TMR

BoulderSpoke TMR

San JoseSpoke TMR

BoulderGateways

BoulderGateways

Santa TeresaGateways

San JoseGateways

Endpoints Managed Nodes & Endpoints Endpoints Endpoints

TECConsoles

HUB-Spoke TMR Arquitecture


5.3.3 Endpoint gatewaysGateways are located using a static schema based on analysis of thefollowing criteria: LAN proximity and loading, geographic location, networktopology, capacity management of the Spoke TMR, and the number ofservers in a project or account. Sizing guidelines are one gateway for every500 endpoints. Note that there are two gateways under a spoke TMR, so1000 endpoints can be managed under a particular spoke TMR.

All endpoints have three possible Gateways. The first two are the oneslocated near (network-wise) the endpoints. The third gateway runs on aspoke TMR. The Spoke TMR works as a failover gateway, and no Endpointsare assigned to it.

Two gateways are assigned under each spoke TMR in Boulder and fourgateways are assigned under the spoke TMR in San Jose. Also, SDC Westhas two physical gateway servers placed in Santa Teresa assigned under theSan Jose spoke TMR. Gateway code also runs on each spoke TMR.

5.3.4 TEC serverA master TEC server is used to process events from managed servers. It islocated in Boulder, Colorado and physically resides in the Hub TMR server.

TEC server configuration was based on analysis of the following criteria:Frequency of TEC events, LAN proximity and loading, geographic location,network topology, capacity management of the TEC, detail level of eventmanagement, number of Tivoli managers deployed, and the number ofresources managed.

Events come from both in-band and out-of-band sources. Events areoriginated from Tivoli products and non-Tivoli products. These events aresent to the TEC as TEC events either by the originating source or afterconversion to TEC events by Netview.

Events are processed by the TEC server and displayed on a TEC console ina 24x7 operations facility in Boulder, Colorado and sent by pager to the samegroup. Second-level support or any other individual can also receive eventsby page and e-mail.

Three TEC consoles are used by operations. These consoles are operatedthrough a Tivoli desktop running Windows 95.

TEC events are defined by the following groups: Host availability, Netviewnode up/down, new ping (socksified host availability), process, file system,

Case study 89

NotesView, Netfinity, AMA, CRT, MQSeries, NFS subsystem, SNA links,hardware, and SP switch interface.

These events are stored in a Sybase SQL Server Database and will be usedas a source of information for the Tivoli Decision Support Event ManagementDiscovery Guide.

5.3.5 RDBMS and RIM hosts configurationThe Sybase SQL Server for AIX is installed in the Hub TMR Server inBoulder, Colorado.

The TEC Database is configured on this server with 500 MB of space for dataand 250 MB of space for log and stores all events processed by the TECServer. This database is planned to accommodate the Event ManagementDiscovery Guide data.

The TEC RIM host for the server infrastructure is also located on the physicalHub TMR server.

5.3.6 Tivoli DM and monitors for performance and capacity trend dataThe SDC West has implemented Tivoli Distributed Monitoring to providestandard monitors for AIX and Windows NT servers. These monitors store thedata collected into flat files, which are processed later, on the Hub TMR.

The standard monitors for AIX servers are:

• CPU Usage used to compute hourly average and sampled every minute

• Process memory and paging space sampled hourly

• Network packets (in/out) and errors (in/out) sampled daily.

• File system snapshot sampled daily.

Today, the SDC West makes use of Netfinity Capacity Manager in order tocollect performance and capacity data from the Windows NT servers. The DMmonitors are used to collect availability information. The following are thestandard monitors for Windows NT servers that will be implemented at thetime of the TDS deployment:

• CPU usage - This is the percentage of processor time monitor(NT_Processor monitoring collection) and is sampled every 10 minutes.

• Memory usage - This is the pages/sec. and Available Bytes monitors(NT_Memory monitoring collection) and is sampled every 10 minutes withan hourly average.


• Network Activity - This reflects the ammount of Packets Outbound Errorsand Packets Received Errors (NT_NetworkMonitor monitoring collection).

• Disk Utilization - This is the percentage of utilization of each drive or diskon the system. Currently using the Disk Space Percentage Used monitorin the Universal monitoring collection.

The way monitors get distributed to servers is dependent upon therelationships between the various Tivoli container objects. Essentially,monitors are grouped in profile managers (and their sub-profiles) by account,platform, function, and so forth on the Hub TMR following a consistentnaming convention. On the Spoke TMRs, similarly-named profiles exist,which have corresponding names and simply act as containers for subscribedservers. The Hub TMR profile manager then subscribes the Spoke TMRprofile managers to it.

Figure 38 on page 92 shows the actual profile structure implemented by thecustomer.

Case study 91

Figure 38. Tivoli Distributed Monitoring object relationships

5.4 Identifying the reports requirements

One of the most important steps to be performed when planning to eithermigrate to or deploy Tivoli Decision Support is to gather all the customerreporting requirements. This will enable us to decide, for example, which TDSDiscovery Guides will be used, how many Tivoli Discovery Administratormachines will be needed, and what the required hardware configuration foreach component of TDS will be.

In this section, we will discuss and identify both the customer’s requirementsfor reporting and all reports that are currently being used to satisfy these

NCOAIX Monitors

Distributed Monitoring

NCO.TMR2

AIXManaged Node

NTManaged Node

NCOAIX.TMR2

Customer ABC.TMR2

TMR2

HUB TMR

Spoke TMR

Customer ABCNCO

NCONT Monitors

ABCWEB AIX Monitors

ABCDFS Monitors

ABCNT Monitors

ABCWEB Domino Monitors

ABCAIX Monitors

ABCDFS.TMR2

ABCWEB AIX.TMR2

ABCNT.TMR2

ABCAIX.TMR2

ABCWEB Domino.TMR2

NCONT.TMR2


requirements. Future requirements, as well as future recommendations, willbe discussed in Section 5.10, “Future reporting requirements” on page 162.

5.4.1 Customer reporting requirementsReporting requirements in Distributed Systems Management (DSM) translateinto five fundamental metrics:

• Availability Reports

• Performance Measurement

• Response Time to Failures (SLA)

• Cost Prediction and Measurement

• Detailed Applications Related Reports

5.4.2 The SDC actual solution for reportingAs shown in Figure 39 on page 94, IBM SDC West uses a variety of platformsand systems-management tools to collect the required data to generatereports of its distributed environment. The challenge is to find a solution thatis able to process and interpret the data stored in different databases indifferent servers.

It is beyond the scope of this redbook to identify all the reports generatedand used by IBM SDC West. We will only consider the reports that coverthe basic metrics of availability, capacity and performance, response timeto failure (sla), and cost if available.

Note

Case study 93

Figure 39. The Problem for reporting

IBM SDC West uses two methods for reporting. Despite valiant efforts, thesetwo methods are still facing the problem of using multiple tools, dealing withdifferent sources of information, and storing the data in files with differentformats. The first one will be referred as the in-house method, which hasbeen developed by the IBM Service Delivery Center Tucson, Arizona. Thesecond method, Server Resource Management (SRM), has been developedby the IBM Global Service South Performance & Capacity team.

For organizational and security reasons, both methods utilize the concept ofaccounts to access the reports. Each group of people responsible for theiraccount has the capability of looking only at the reports that are related totheir business and interest. There are IBM internal accounts, which arerelated to IBM internal departments or locations, and external accounts,which are related to IBM customers. All these reports can be reached eitherthrough the IBM Intranet or Internet. For the purpose of this case study, wewill look at the reports of an internal IBM account called Network ComputingOfferings (NCO). The NCO account uses both methods of reports. We willidentify the reports available in the actual SDC solution for reporting and thenmap these reports with those produced by Tivoli Decision Support.

5.4.2.1 The in-house methodThe in-house solution relies on many sources for collecting data, such as:

• UNIX-based tools:

Analysis

Reports

.

.

.

Tool 1

Tool n

Tool 2


• The vmstat command is sampled every minute and used to compute anhourly average.

• Process memory is checked witht the ps gv command and pagingspace percentage full is checked with the lsps -a command andsampled hourly.

• Network packets in/out and errors in/out are sampled daily using thenetstat command.

• File systems snapshot is checked with the df -k command andsampled daily.

• Tivoli Applications:

• Tivoli Distributed Monitoring

• Tivoli NetView

• Tivoli Enterprise Console

• Netfinity Capacity Manager

Figure 40 shows how the process is used for reporting the in-house method:

Figure 40. The in-house process for reporting

TivoliApplications

NetfinityMonitors

AIX Tools

Phase 1 - Data CollectionPhase 2 - Data Processing

Phase 3 - Report Generation

MonitorsPerl Scripts and Programs

HTML and Java format

IBM Intranet

Case study 95

The three phases of the in-house process are detailed in the following list:

• Phase 1 - Data Collection

The monitors collect relevant information according to some predefinedthresholds and write the data to files on a file server.

• Phase 2 - Data Processing

As soon as the data is collected, it is processed daily by the in-house Perlscripts and programs populating some flat files for each server and metric.The rolling year of data is kept.

• Phase 3 - Report Generation

The reports are generated in HTML and Java format showing eachmonth's data in tabular format with links to applets that graph the data setsfor the year by account (server group).

5.4.2.2 The SRM methodIn order to satisfy the actual requirement for reporting, IBM Global ServiceSouth Performance & Capacity team has developed a set of Server ResourceManagement tools to expand the performance and capacity trending on theDistributed Systems Management (DSM) platforms and applications, such asAIX/UNIX, Windows NT, OS/2, SAP R/3, and Lotus Notes. The SRM tool setis used for both internal and external account reporting.

The SRM solution relies on existing monitoring tools for each availableplatform, such as Netfinity Capacity Manager (CISC platforms), Perl Scripts(RISC platforms), Zperstat (for SAP R/3), and NotesView (Lotus environment)to collect and pass on event data.

The SRM tool is divided into four main components that enable theperformance and capacity trending process as detailed in the following list:

• Phase 1 - Collection

The data is passively collected in multiple formats and stored into files.

• Phase 2 - Transmission

The SRM tool receives the data and converts it to a common format. Thenthe data are stored in a single database in a convenient format.

• Phase 3 - Analysis

An automated process provides Distributed Systems Managementresource trending and exception analysis in this phase.

• Phase 4 - Web Preparation and Presentation


The data is processed and HTML and Java reports are generated andpublished on the IBM Intranet.

Figure 41 graphically represents the SRM collection and reportingprocess:

Figure 41. The SRM method for reporting

5.4.3 The Reports of the NCO accountIn this section, we will show the reports generated by the two methodsdescribed in Section 5.4.2, “The SDC actual solution for reporting” on page93. The goal here is to provide information about the current scenario ofreporting used at IBM SDC West to satisfy the actual requirements.

5.4.3.1 In-house reportsThe following are the reports available for the NCO account using thein-house method for reporting:

1. Performance and capacity metric summary

As shown in Figure 42 on page 98, this report shows CPU utilization,memory paging utilization, and network I/O (IP packets and errors count)

SRM

Phase 1 - Collection

NetfinityManager

Perl Scripts

Zperstat

NotesView

DB2

SAS/VM

IBMIntranet

Phase 3 - Analysis

Phase 4 - WEB Presentation

Phase 2 - Transmission

Case study 97

per server for a specified month. There are also links from which you canhave access to detailed reports by server.

For CPU and Memory/Paging, the first pair of numbers lists the averagesof all samples and the average of the eight highest samples of data. Thesecond average gives some indication of load during high usage bursts,which may or may not occur during consecutive prime shift hours. If theaverages are similar, it can be inferred that usage of the system isrelatively steady throughout the day. The number in parentheses lists thedaily high sample.

For Network IO, the daily IP packet and error counts in parentheses areshown for input and output.

Figure 42. In-house performance and capacity

The following are descriptions of the detailed reports of the serversnjs1sm1.sanjose.ibm.com.

CPU Utilization by serverNetwork IO Utilization

DASD Usage Report Process Memory and Paging Utilization


Figure 43 states the high sample, the average of all samples, and the averageof the highest eight samples for CPU utilization by server:

Figure 43. Detailed report - CPU utilization by server

• CPU utilization by server

For UNIX servers, the data is collected every minute using the vmstat

command. For Windows NT servers, it is done by Netfinity CapacityManager. The data shown for future months is from the previous year.

Figure 44 on page 100 states the high sample, the average of allsamples, and the average of the highest eight samples for processmemory and paging utilization.

Case study 99

Figure 44. Detailed report - process memory and paging utilization by server

• Process Memory and Paging Utilization by Server

For UNIX servers, the data is collected on a hourly basis using the ps

and the lsps commands. For NT servers, all data is collected byNetfinity Capacity Manager.

Figure 45 on page 101 states the number of IP packets In and Out.


Figure 45. Detailed report - network I/O utilization

• Network I/O utilization by server

For UNIX servers, daily IP packet and error counts are collected usingthe netstat command for input and output. For Windows NT servers,the data is collected using Netfinity Capacity Manager.

Figure 46 on page 102 shows the size and daily percentage ofkilobytes used by the file systems for each server.

Case study 101

Figure 46. Detailed report - DASD usage by server

• DASD utilization by server

For AIX Server, the data is collected using the df -k command. ForWindows NT servers, the data is collected using Netfinity CapacityManager.

2. Availability and alerts summary

The report shown in Figure 47 on page 103 displays the availability byserver per month. Nodes are considered unavailable between nodeDOWN and node UP events received by the monitoring server (NetView,MLM, Tivoli applications, and so on). Availability windows are not currentlyfactored in (assume 7x24). Data is generated at the end of each month;therefore, data for the current or future months, if shown, is from theprevious year. In addition, percentages under 95 show up in red.

The report shown in Figure 47 on page 103 shows a summary of theevents for each system based on the current alert log for the accountNCO.

DASD Usage for snjs1sm1.sanjose.ibm.com


Figure 47. Percentage availability by server

• Alert summary report

Items covered by this report include the number of alerts and logentries, CPU and disk utilization, node up or down, and servicesstopped or started. Refer to Figure 48:

Figure 48. Detailed alert summary by server

Availability for NCO Systems

Alert Summary

Alert summary for: amawest1.boulder.ibm.com

Note: Account alert logs are regularly trimmed -- the oldest events shown will vary by how many alerts a system receives.

Log Entry Count Alert

5 . . . . . . Node down (unpingable from monitor server)

5 . . . . . . Node up (pingable from monitor server)

Log Entries:

Tue Jun 8 05:49:33 MDT 1999 System [amawest.boulder.ibm.com (9.99.188.204)], Message [Node down (unpingable from monitor server)], Subsystem [os]Tue Jun 8 06:01:43 MDT 1999 System [amawest.boulder.ibm.com (9.99.188.204)], Message [Node up (pingable from monitor server)], Subsystem [os]Tue Jun 11 05:52:39 MDT 1999 System [amawest.boulder.ibm.com (9.99.188.204)], Message [Node down (unpingable from monitor server)], Subsystem [os]Tue Jun 13 05:50:09 MDT 1999 System [amawest.boulder.ibm.com (9.99.188.204)], Message [Node up (pingable from monitor server)], Subsystem [os]Tue Jun 13 05:50:09 MDT 1999 System [amawest.boulder.ibm.com (9.99.188.204)], Message [Node up (pingable from monitor server)], Subsystem [os]Tue Jun 14 06:00:29 MDT 1999 System [amawest.boulder.ibm.com (9.99.188.204)], Message [Node down (unpingable from monitor server)], Subsystem [os]Tue Jun 14 08:59:54 MDT 1999 System [amawest.boulder.ibm.com (9.99.188.204)], Message [Node up (pingable from monitor server)], Subsystem [os]Tue Jun 15 05:51:12 MDT 1999 System [amawest.boulder.ibm.com (9.99.188.204)], Message [Node down (unpingable from monitor server)], Subsystem [os]Tue Jun 15 08:42:49 MDT 1999 System [amawest.boulder.ibm.com (9.99.188.204)], Message [Node up (pingable from monitor server)], Subsystem [os]Tue Jun 16 06:20:51 MDT 1999 System [amawest.boulder.ibm.com (9.99.188.204)], Message [Node down (unpingable from monitor server)], Subsystem [os]Tue Jun 16 08:27:16 MDT 1999 System [amawest.boulder.ibm.com (9.99.188.204)], Message [Node up (pingable from monitor server)], Subsystem [os]

Case study 103

5.4.3.2 SRM ReportsThe following describes the reports available for the NCO South accountusing the SRM tool set. We will describe the reports for Lotus Notesapplication, AIX Performance, and Windows NT Performance.

1. Lotus Notes reports

The following are the reports available for NCO South Lotus Notesservers:

• Mail Server Report

This report gives daily, weekly, and monthly statistics on Lotus Notesmail servers in the NCO South account, such as number of concurrentusers, number of mail traffic messages, and response time. The reportshown in Figure 49 is the monthly utilization statistic:

Figure 49. Lotus Notes - Monthly mail server statistics report

• Database Server Report

This report gives daily, weekly, and monthly statistics on Lotus Notesdatabase servers in the NCO South account, such as number of


concurrent users, the number of replicated documents, and so on. Thereport shown in Figure 50 is the monthly utilization statistic. There arealso reports that include weekly and daily statistics.

Figure 50. Lotus Notes - Monthly database server report

• Mail Hub Server Report

This report gives daily, weekly, and monthly statistics on Lotus Notesdatabase servers in the NCO South account, such as number of totalmail traffic (MBytes) and the average response time. Figure 51 on page106 shows the daily utilization statistic. Other reports include weeklyand monthly statistics.

Case study 105

Figure 51. Lotus Notes - Daily mail hub report

• MTA Server Report

This report gives daily, weekly, and monthly statistics on Lotus NotesMTA servers in the NCO South account, such as number of SMTPtransferred messages and the average response time. Figure 52 showsthe daily utilization statistic. Other reports include weekly and monthlystatistics.

Figure 52. Lotus Notes - Daily MTA server report

• Hourly Response Time Report

This report gives hourly response time on the Lotus Notes database,MTA hub, and mail server in the NCO South account. Figure 53 showsthe hourly response time for the Lotus Notes mail server.


Figure 53. Lotus Notes - Hourly response time report

• Hourly Concurrent Users Report

This report gives hourly concurrent users on the Lotus Notes databaseand mail server in the NCO South account. Figure 54 shows theconcurrent users report for the Lotus Notes mail server, which isproduced daily.

Figure 54. Lotus Notes - Hourly concurrent users report

Case study 107

• Hourly Sessions per Minute Report

This report gives hourly sessions per minute on Lotus Notes servers inthe NCO South account. Figure 55 shows the hourly sessions perminute by server report, which is produced daily.

Figure 55. Lotus Notes - Hourly sessions-per-minute report

• Hourly Mailbox Size Report

This report gives hourly sessions mail box size on Lotus Notes serversin the NCO South account. Figure 56 shows the hourly mail box size byserver report and is produced daily.

Figure 56. Lotus Notes - Hourly mail box size report


• Hourly SMTP Transferred Messages

This report gives hourly SMTP transferred messages on Lotus Notesservers in the NCO South account. Figure 57 shows the hourlytransferred messages by server report, which is produced daily.

Figure 57. Lotus Notes - Hourly SMTP transferred messages report

2. AIX reports

The following reports are produced by SRM for AIX servers in the NCOSouth account.

• CPU/Storage Utilization and IO Wait Report

This report gives daily, weekly, and monthly CPU Utilization of the AIXservers in the NCO South account. Figure 58 on page 110 shows themonthly utilization statistics. There are also reports that include weeklyand daily statistics. In addition, we can access data for a specificserver.

Case study 109

Figure 58. AIX servers - CPU utilization reports

• Warnings Only (daily, weekly, monthly)

This report gives the daily warnings during prime time of excessiveCPU utilization by AIX servers in the NCO South account according tospecified thresholds. This is a subset of the report shown in Figure 58,which contains only those servers with exceeded thresholds.

• Hard Disk/File System Utilization Report

This report shows the hard disk and file system availability by AIXservers in the NCO South account. Figure 59 on page 111 shows thedisk and file system utilization by server report, which is produceddaily.


Figure 59. AIX servers - Hard disk and file systems utilization report

• AIX Capacity Summary

This report gives a summary of the percentage of utilization for allavailable AIX servers in the NCO South account. The report shown inFigure 60 shows statistics on CPU utilization, Run Queue status,Memory status, IO Wait status, and Disk space status on a rollingmonth basis for all servers.

Figure 60. AIX servers - Account summary report

Case study 111

3. Windows NT Reports

The following reports are produced by SRM for Windows NT servers inNCO South account.

• CPU, Memory and Disk Utilization (daily weekly monthly)

This report gives daily, weekly and monthly CPU Utilization of theWindows NT servers in the NCO South. Figure 61 on page 112 showsthe monthly utilization statistics. Other reports include weekly and dailystatistics. In addition, we can access data for a specific server.

Figure 61. NT servers - CPU, memory, and disk utilization report

• Windows NT capacity summary

This report gives a summary of the percentage of utilization of all theavailable Windows NT servers in the NCO South account. The reportshown in Figure 62 on page 113 shows statistics on CPU utilization,Memory status, and Disk space status on a rolling month basis for allservers.


Figure 62. NT servers - Account Summary Report

5.5 Customer objectives

Although the customer has, over the years, developed a solution that worksand meets the company’s reporting requirements, there still exists, as in all ITsolutions, room to improve and produce a more cost-effective and powerfulsolution.

Most of today’s businesses display a reasonable amount of concern aboutaspect,s such as gaining further savings on optimization of server resourceswhile maintaining a high level of productivity. This is also the case with theSDC West.

An ideal reporting tool that enables the customer to meet his or her goalswould provide functions, such as Workload Characterization and Modelling. Abrief discussion of these two reporting techniques follows:

• Workload Characterization

This process maps an application metric against the server resourcesused, such as transaction rates/averages versus server storage and CPUutilization. For DSM machines, the quality of collection data varies byplatform and kernel collection method used.

Application workload data is collected and key metrics trended to producehistorical usage, application drivers, and server resources used; theoutput is a baseline representing customer usage and server resourcesconsumed.

Case study 113

• Modelling

Once the workload characterization baseline is in place, What If modelsand scenarios may be built based on customer's estimated businessdrivers and/or the associated server resource to be assigned to meetfuture business drivers.

With the actual solution for reporting being used by the SDC West, workloadbalancing and modeling is performed platform by platform, for example, RISCto RISC and CISC to CISC (but not RISC to OS/390 or other cross-platformcombinations).

Tivoli Decision Support along with its Discovery Guides is the best solutionfor the customer’s objectives and performs exceptionally well with mostbusiness strategies. Tivoli Decision Support best delivers on serverrequirements for expanded Data Collection, Database Interface, WorkloadCharacterization, Modeling, and Web Publishing.

5.6 Mapping Tivoli Decision Support Discovery Guides

During this phase, we have evaluated the various TDS Discovery Guides. Inmost situations, these guides, powered by the drill down capability of TDS,can completely cover the SDC requirements. In some situations, however, isnecessary to use two or more TDS reports to map an SDC report. On theother hand, some reports requirements are not able to be covered by TDSand these reports will be mentioned in Section 5.10, “Future reportingrequirements” on page 162. Table 10 shows the TDS Discovery Guides beingmapped to the customer’s requirements.

Table 10. The TDS Discovery Guides mapping

5.6.1 Detailed reports mapping workshopAs described in Section 5.4.2, “The SDC actual solution for reporting” onpage 93, the customer has some reports that are used to partially attend their

TDS Discovery Guide Customer requirements

Server Performance Prediction Performance Measurement CostPrediction

Event Management Response Time to Failures (SLA)

Domino Management Detailed Application Related reports

Network Element Performance Network Capacity and Performanceanalysis


actual requirement for reporting. In this section, we will show the reports fromvarious TDS Discovery Guides that have been analyzed in Section 5.6,“Mapping Tivoli Decision Support Discovery Guides” on page 114 andcompare them to the customer’s actual scenario.

The following table shows the customer current reports and a reference forthe recommended TDS report. These report will be displayed in Section 5.7,“Tivoli Decision Support reports and business information” on page 116.

Table 11. Detailed mapping reference table

Customer Current Reports Recommended TDS Report

Performance and Capacity metricsSummary. Refer to Figure 42 on page 98

Figure 63 on page 118

CPU utilization by server. Refer to Figure43 on page 99


Process memory and Paging utilization byserver. Refer to Figure 44 on page 100


Network I/O utilization by server. Refer toFigure 45 on page 101


DASD utilization by server. Refer to Figure46 on page 102

Future requirement

Percent of Availability by server. Refer toFigure 47 on page 103

Future requirement

Alert Summary report. Refer to Figure 48on page 103

Future requirement

Lotus Notes Mail server statistics. Refer toFigure 49 on page 104

Figure 74 on page 130Figure 75 on page 131Figure 76 on page 132Figure 77 on page 133Figure 78 on page 134

Lotus Notes - Database server report.refer to Figure 50 on page 105

Figure 77 on page 133Figure 78 on page 134Figure 79 on page 135

Lotus Notes - Mail Hub server report.Refer to Figure 51 on page 106

Figure 75 on page 131Figure 78 on page 134

Lotus Notes - MTA server report. Refer toFigure 52 on page 106

Future requirement

Lotus Notes - Response time report. Referto Figure 53 on page 107


Case study 115

5.7 Tivoli Decision Support reports and business information

In this section, we will give a brief description of the identified Tivoli DecisionSupport Discovery Guides that will be used to cover the customer’s reportingrequirements for this case study. In addition, we will show some reports thatwere used in Section 5.6.1, “Detailed reports mapping workshop” on page114 to map the existing customer’s reports. The intention here is to provide areport scenario with the same (or enhanced) quality as the current customer’sreporting scenario.

5.7.1 Server Performance Prediction GuideThe purpose of this guide is to supply data to help plan the network growthusing basic trending of key system metrics. Most of the performanceproblems in workstation networks and servers are the result of systemworkload gradually increasing to the point where it exceeds the capacity ofthe system or, as a result of soft errors, gradually increasing in volume until acatastrophic hard (unrecoverable) error occurs.

Lotus Notes - Concurrent users report.refer to Figure 54 on page 107


Lotus Notes - Sessions per minute report.Refer to Figure 55 on page 108

Future requirement

Lotus Notes - Mail box size report. Refer toFigure 56 on page 108


Lotus Notes - SMTP transferredmessages report. Refer to Figure 57 onpage 109

Future requirement

CPU and Memory utilization, and I/O waitreport by Operating Systems (AIX andWindows NT). Refer to Figure 58 on page110, and Figure 61 on page 112


Hard Disk and File System utilizationreport by Operating Systems. Refer toFigure 59 on page 111, and Figure 61 onpage 112

Future requirement

Capacity Summary by Operating System.Refer to Figure 60 on page 111, andFigure 62 on page 113


Customer Current Reports Recommended TDS Report


This guide relies on Tivoli Distributed Monitoring as the source of the networkactivity data and, if available, the Tivoli Inventory supporting enterprisesystem hardware information.

The objective of the Tivoli Decision Support for Server PerformancePrediction (SPP) Discovery Guide is to provide the customer with thecapacity to plan using basic trending of key system metrics. Most workstationand server performance problems in a network can be avoided by identifyingthe system workload on time before it exceeds the capacity of the systems.

The SPP guide has subsections in the form of questions, such as:

• How might I improve performance on my systems?

• How is my overall performance?

• What performance problems are on the horizon?

By clicking on these question icons, information can be obtained about yourenvironment in a report format.

The following are some reports available with the Server PerformancePrediction Discovery Guide.

All System Metrics reportThe following metrics are intended for both UNIX and NT platforms:

• CPU percent busy (user time and system time)

• CPU run queue length

• Disk I/O rate and Disk transfer rate

• Memory page-in/out rate (pages/sec.)

• Memory page-scan rate (seeks/sec.)

• Network packet collision rate (packet/sec.)

• Network packet input/output rate (packets/sec.)

• Network packet input/output error rate (packets/sec.) (packet # on NT)

Figure 63 on page 118 shows the All System Metrics report, which displays asummary of all system performance metrics sorted down by system purpose.

Case study 117

Figure 63. All System Metrics report

CPU utilization by serverBy using the drill down facility, we can have some variations of the All SystemMetrics report. Figure 64 on page 119 only shows CPU utilization for aparticular server called ariel.


Figure 64. CPU utilization by server report

Memory Utilization by ServerFrom the All system metrics report, we can choose to show only the memoryutilization. Once again, by using the drill down capability, we select only theDNS servers available in our network. Figure 65 on page 120 shows anexample of the memory utilization for all DNS servers in July, 1999.

Case study 119

Figure 65. Memory utilization report

Network I/O utilization by serverThis report provides network packet I/O rate, network packet I/O error rate,and network packet collision rate.

Figure 66 on page 121 shows example network I/O rate information for allSAP R/3 servers.


Figure 66. Network I/O utilization report

CPU utilization and memory page rates by operating systemAs shown in Figure 67 on page 122, this report provides daily informationabout CPU Utilization (% units) and memory page rates by operating systemfor all Oracle servers in our environment.

Case study 121

Figure 67. CPU utilization memory page rates by operating system

Summary by operating systemThis report gives a summary of utilization of all available servers by operatingsystem for all collected metrics.

Figure 68 on page 123 shows the summary of all AIX servers for July, 1999.


Figure 68. Summary report by operating system

Forecasts reportsOne of the most important features available in this TDS Discovery Guide isthe ability to provide forecasts. We can, for example, predict future averageCPU utilization of all servers in order to avoid a possible system slow down.In Figure 69 on page 124, we show examples of 30, 60, and 90 day averageforecasts of CPU utilization of all servers grouped by system purpose.

Case study 123

Figure 69. CPU average forecast by system purpose

Under-provisioned and Over-provisioned serversThis view highlights systems where the CPU activity is disproportionate to thenetwork activity. If you have a system that shows very high CPU utilization buthas relatively low network activity, that system may be under-provisioned (theCPU is inadequate for the work load). If you have a system that shows verylow CPU utilization but has relatively high network activity, that system maybe over-provisioned (the CPU is excessive for the work load). The measureused for this view is the processor overload. This is expressed as apercentage of the difference between the CPU and network utilization dividedby the network utilization. Figure 70 on page 125 is an example of this reportfor all SAP R/3 servers.


Figure 70. Under-provisioned/Over-provisioned servers report

5.7.2 Event Management GuideThis TDS Discovery Guide provides a strategic view of network activity asrecorded in TEC events and information about the response time for theseevents. In addition, it provides information about areas of high activity orrecurring patterns of system activity. The combination of the Tivoli DiscoveryAdministrator and the Tivoli Discovery Interface with Tivoli Decision Supportfor Event Management provides you with the following powerful analysis andreporting capabilities:

• It gathers and reviews information based on a set of powerful questionsand reports that address success rates, effectiveness, trends, peakvolume, and sources of events.

• It presents event management information as charts and tabular reports.

• It automates data acquisition and cube building

This guide helps you to tune your event management process using TEC. Itwill help you assess your performance in terms of the number of problemsbeing experienced and their severity as well as how effectively you areresolving them.

Case study 125

The following are some reports available with the Event ManagementDiscovery Guide.

SLA statistics by event classThis report ranks the different types of events that you have handledaccording to which ones have most often not been resolved within the boundsof the Service Level Agreement. Figure 71 shows information, such as thepercentage of met, missed, and nearly-missed SLAs.

Figure 71. SLA statistics by event class

Which events take the longest to fix?This view gives you a snapshot of the average duration (mean time to repair)for events of different classes and highlights the ones that take the longest tofix. Figure 72 on page 127 shows the amount of time in minutes that certainevents, such as Link_Down_Cisco and certain, take to be fixed.


Figure 72. Which events take the longest to fix? report

When are my peak times for event volume?Figure 73 on page 128 shows you the average number of events by eventsource for each hour of the day. This average is based on the previous 30days worth of events. This can be helpful in establishing the shift schedulesand staffing levels for your service center or in isolating a scheduled activitythat is causing problems.

Case study 127

Figure 73. Event source volume by hour report

5.7.3 Domino Management GuideThe Tivoli Decision Support Domino Management Discovery Guide allowsdata collected from Domino servers to be displayed in reports that meet theneeds of customers by helping them make decisions about their Dominoenvironment.

The Domino Management Discovery Guide enhances the functions of theTivoli Manager for Domino product allowing you to strategically manage theDomino installations in the enterprise network. Whereas the Tivoli Managerfor Domino provides powerful rule-based management applications for theDomino environment, the Domino Manager Discovery Guide provides ageneral overview of how the systems are performing.

The version of the Tivoli Domino Management Discovery Guide usedduring the course of this book was a beta code version. Functions,features, and supported environments for this product are subject tochange without notice any time before or after general release.

Note


The content and detail of the reports provided by the Domino ManagementDiscovery Guide are dependent on the type of data that can be collected andthe database schema in which this data is stored. In a TMR environment,Tivoli Manager for Domino monitors are defined and distributed to collectdata and then stored in a relational database. Once this data is in therelational database, the Domino guide can be used to extract and analyze thedata through reports in the TDS Discovery Interface. Such reports includeserver performance, server ranking, and server prediction reports.

For setting up the Domino Discovery Guide, the database schema must bedefined first. Domino-specify monitors are then distributed in a TMRenvironment, and a Domino roll up job is run nightly to collect and aggregatethe data into the database table. The Tivoli Discovery Administrator is used todefine queries to extract data from this table into a comma-separated values(.csv) file. The Cognos Transformer builds the multidimensional cube fromthis file, which can then be reported by Cognos PowerPlay. Finally, once theguides and roles have been defined, the Tivoli Discovery Interface is used toview these reports.

Since the Domino guide uses Domino-specific DM monitors for reporting, thisguide must also use the Domino Roll Up module, which comes with theDomino Management Discovery Guide. This Domino Roll Up module, whichis installed in a TMR environment, contains the scripts necessary to createthe database schema and perform the Domino roll up job.

The following are some reports available with the Domino ManagementDiscovery Guide.

Domino Network TrafficThis view shows how much TCP/IP traffic is sent and received by the Dominoservers. These statistics reflect the values in bytes from theNET.TCPIP.BytesReceived and NET.TCPIP.BytesSent monitors from theDomino servers. Figure 74 on page 130 shows the monthly utilizationstatistics by hostname report.

Case study 129

Figure 74. Domino network traffic report

Domino mail statisticsThese reports show the various Domino Mail statistics, such as:

• Mail Total Routed

Figure 75 on page 131 shows the total number of mails routed by theDomino servers. These statistics reflect the values from theMail.TotalRouted monitor from the Domino servers. The daily total valuesin bytes are shown for July 1, 1999.


Figure 75. Domino server statistics - Mail routed by server report

• Mail total KBytes transferred

Figure 76 on page 132 shows the Total KBytes transferred by the Dominoservers. These statistics reflect the values from theMail.TotalKBTransferred monitors from the Domino servers. The daily totalvalues in KBytes are shown for July 1, 1999.

Case study 131

Figure 76. Domino statistics - Total KB transferred report

Domino number of user statisticsFigure 77 on page 133 shows the number of users managed by the Dominoserver Cartman1. These statistics reflect the values from the Server.Usersmonitor from the Domino servers. This view shows the server statistics bytheir hourly values. This is a good time to start looking for hourly trends to findspecific server problems. The hourly values are shown for July 1,1999.


Figure 77. Domino statistics - Number of users report

Domino mail average delivery timeFigure 78 on page 134 shows the mail average Delivery time statistics for allDomino servers. The average daily message count for the mail averagestatistics is shown for July, 1999. The statistics shown in this report reflect thevalues from the Mail.AverageDeliverTime monitor from the Domino servers.

Case study 133

Figure 78. Domino statistics - Mail average delivery time report

Domino replication statisticsFigure 79 on page 135 shows the amount of requests for replication for theDomino servers. The daily total requests count for the mail average statisticsis shown for July, 1999. The statistics shown in this report reflect the valuesfrom the Domino.Requests.Per1Hour.Total monitor from the Domino servers.


Figure 79. Domino statistics - Replication statistics report

Domino server average delivery time by hourFigure 80 on page 136 shows the server average delivery time statistics forall Domino servers by hour. The average hourly delivery message timestatistics shown are for July 1, 1999.

Case study 135

Figure 80. Domino statistics - Server average delivery time by hour report

Domino server mail box file sizeFigure 81 on page 137 shows the server Mail Box file size statistics forspecific Domino servers by hour. The average hourly mail box size statisticsshown are for July 1, 1999.


Figure 81. Domino statistics - Mail box file size by server report

5.7.4 Network Element Performance GuideThe Network Element Performance Discovery guide will automatically identifyissues affecting the performance of critical network devices to allow networkmanagers to identify problems before they affect network performance. Thisguide will allow you to investigate the elements affecting your serveraccording to up time and down time, problem elements, and degrees offailure. This guide also helps identify memory usage issues, CPU utilization,traffic issues, and communication and router concerns. With the informationdiscovered using this guide, you can make meaningful network performancedecisions and resolve problems before they adversely affect your networkperformance.

We use the Network Element Performance guide to quickly identify devicesthat are the most heavily used or that show the greatest usage or error rates.Use these reports to analyze the devices that are most critical to yournetwork and to spot changes in error rate and usage behavior before theybecome major problems effecting users.

Case study 137

The following sections detail reports available with the Network ElementPerformance Discovery Guide.

Cisco CPU utilizationFigure 82 shows the daily average CPU utilization collected by date and byhostname from the Cisco routers in our network. In addition, it shows anaverage of CPU utilization. Watch this report for trends indicating an increasein router utilization.

Figure 82. Network Element Performance Guide - Cisco CPU utilization report

Name Server speed statisticsNetView collects Name Server performance data periodically during the day.Figure 83 on page 139 presents data for a single day during business hoursallowing you to spot trends in Name Server utilization and determine peakand off-peak hours. This information can be used to judge the remainingcapacity, to schedule maintenance (during off-peak times), or to schedulebulk jobs that depend on name resolutions.


Figure 83. Network Element Performance Guide - Name server speed by hour

Top ten problem systemsFigure 84 on page 140 shows systems that are going down most frequently(although not necessarily accruing the most downtime) on July, 1999. Manytransitions can indicate system problems that should be investigated.

Case study 139

Figure 84. Network Element Performance Guide-Top ten nodes by transition count

5.8 Suggested architecture and solution design

Based on the information gathered in the previous phases of this case study,we will now outline a recommended architecture and solution design for TivoliDecision Support for Server Performance Prediction and Tivoli DecisionSupport for Event Management Discovery Guides in our case studyenvironment.

We will make the architecture and design as flexible as possible so that, ifany additional TDS Discovery Guide is required, it can be added withoutmajor changes.


Figure 85. Recommended architecture in network mode

Figure 85 shows the high-level physical design configuration recommended tothe customer. The figure outlines an implementation of Tivoli DecisionSupport in network mode. Since all main Tivoli components and the databaseserver are installed on the Hub TMR in Boulder, it is advised to implement allTivoli Decision Support components on the same local network as the HubTMR Server. In addition to that, a TDS file server will be installed in each ofthe other sites in order to provide access to the cubes for the DiscoveryInterface clients. The roles of each component of TDS in this picture will beexplained as follows:

• The Tivoli Decision Support Discovery Administrator

The TDS Discovery Administrator server provides the generation processfor the cubes. This machine will be installed on the same local network asthe Hub TMR, thus, improving performance at the time of the cubegeneration process.

HUB TMRTECSybaseRIM Host

Spoke TMRRIM Host


Other sites

Boulder

TDSDiscoveryAdministrator

PrimaryTDS File Server

SecondaryTDS File Server


TEC

DM

ODBC Connection

Network Connection

FTP Process

Case study 141

Cubes vary in size depending not only on the amount of data that is storedin the database and captured in them but also on the time range that isspecified at the time they are built. Based on the number of endpoints andservers that are managed by the SDC, it might be a good approach tohave reasonable disk space available at the Discovery Administratormachine in order to allocate all the temporary and comma-separated(.csv) files created during the cube-building process. For hardwarespecifications, see Table 13 on page 145.

If the installation of additional TDS guides is required and results inincreased resource utilization and, consequently, the time it takes to buildall the cubes is not suitable to the customer, it is appropriate to haveadditional Discovery Administrator machines installed. A scenario wherewe can have only one TDS Discovery Guide per Discovery Administratormachine would be the best approach. Another reason to have additionalDiscovery Administrators would be for management reasons where eachone would be maintained by different support people.

• The TDS File Server

The TDS server components include the models, queries, templates, andother information required to generate views for the Discovery Interface.These components must be installed on each TDS file server in our casestudy environment.

The TDS file server should be a very fast computer to service files andshould have a fast network connection to clients. For hardwarespecifications, refer to Table 13 on page 145.

We recommend that you have one TDS file server per site. The one inBoulder should be called the primary TDS file server and will beresponsible for serving both the Discovery Administration machine and theDiscovery clients in Boulder. At other sites, the TDS file server should becalled the secondary TDS file server and will be responsible for servinglocal clients. This configuration can increase the response time for clientswhen accessing information stored in the cubes. There will be an updateprocess for the secondary file server that must be started after thecube-building process and after an installation of a new TDS DiscoveryGuide on the primary file server. This update process is automated bydefining scripts, Tivoli Tasks, and Jobs that run in a predefined order and

Note that it is not recommended to split one TDS Discovery Guide intomore than one Discovery Administrator machine.

Note


time. For additional details, refer to Section 5.9.2, “Installation of the TivoliDecision Support server components” on page 145.

• Tivoli Decision Support Clients

The Tivoli Decision Support client component is the Tivoli DiscoveryInterface that provides all the tools needed to open and work with views ofdata from your organization’s enterprise databases. This component mustbe installed on every client machine on customer sites where TivoliDecision Support is supposed to be used. These clients will have twokinds of connections:

• A network connection with the local Tivoli Decision Support File serverto get all the necessary information stored in the multidimensionalcubes for the multidimensional views.

• A direct ODBC connection with the databases in the Hub TMR serverfor online reports generated by Crystal reports.

• Cognos PowerPlay

PowerPlay is a third-party application that generates multidimensionalcubes and must be installed with Tivoli Decision Support. It must beinstalled on every Tivoli Discovery Administrator machine and everyTivoliDiscovery Interface machine.

• TDS Discovery Guides

Tivoli Decision Support Discovery Guides are used to analyze theenterprise’s key information. These guides provide users with acomprehensive set of best practices and views into their enterprise’sdatabases. All recommended guides for this case study should beinstalled on each of the Tivoli Decision Support File servers (primaries andsecondaries) and imported into the Discovery Administrator machine.

• The information repository (RDBMS)

The TEC database, which is used by Tivoli Decision Support for EventManagement Guide, is installed and configured in the Sybase server thatresides in the Hub TMR. Similarly, the database for Distributed Monitoring,which is used by the Tivoli Decision Support for Server PerformancePrediction Guide, is created in the same Sybase server.

Case study 143

5.9 Tivoli Decision Support deployment process

This section should be used as a guideline for the steps involved in installingall applications, patches, and configurations that need to be performed inorder to have your Tivoli Decision Support solution up and running in thiscase study environment.

The intention here is to provide a high-level view of the deployment processand outline the steps involved in the installation of Tivoli Decision Supportand the Discovery Guides. For detailed information, refer to the productdocumentation.

The Tivoli Decision Support deployment process involves several activities.Table 12 shows the macro procedures for deploying Tivoli Decision Support innetwork-mode and should be used as a guide in the SDC West environment.The following sections describe each procedure in more details.

Table 12. Macro procedure for deploying TDS

Step Description

1 Hardware and software pre requisites installation

2 Install the Tivoli Decision Support server components

3 Install the Tivoli Decision Support Discovery Administrator

4 Install the Tivoli Decision Support client component

5 Install and configure the Server Performance Prediction Guide

6 Install and configure the Event Management Guide

On the existing Sybase server, another database should be created toattend the Server Performance Prediction Discovery Guide data, and anextra table needs to be created on the TEC database to house theinformation source for the Event Management Discovery Guide. Foradditional details, refer to Section 5.9.5, “Deploying TDS for serverperformance prediction” on page 154, and Section 5.9.6, “Deploying theEvent Management Guide” on page 161

Note


5.9.1 Hardware and Software prerequisites installationThere is some prerequisite software that should be installed prior to the TDSdeployment:

• It is recommended that Microsoft Windows NT 4.0 with Service Pack 3 beinstalled on the Discovery Administrator machine and on all TDS Fileserver machines. Microsoft Windows 95 should be installed on allDiscovery Interface machines.

• The Sybase Open Client must be installed on all Discovery Interface andon all Discovery Administrator machines in order to establish theClient/Server Sybase connection .

• The ODBC driver should be installed on the Discovery Administratormachines and on all Discovery Interfaces machines. The TDS installationCD contains the Intersolv 3.01 32-bit Sybase ODBC driver.

Table 13 shows the minimum recommended hardware configuration thatshould be used for the case study environment.

Table 13. Minimum hardware requirements

5.9.2 Installation of the Tivoli Decision Support server componentsThe Tivoli Decision Support Server components should be installed on theprimary Tivoli Decision Support File server machine in Boulder and on allsecondary Tivoli Decision Support File server machines at each of the othersites. Since these machines are shared source file servers, the directory thatstores all cubes and queries should be available as a shared resource withfull read and write permissions in the network so that it can be accessed bythe Discovery Interface and Discovery Administrator machines.

HardwareCharacteristics

TDS File Server DiscoveryAdministrator

DiscoveryInterface

CPU speed Intel Pentium II400 Mhz

Intel Pentium II400 Mhz

Intel Pentium II300 Mhz

Memory (RAM) 128 MB 128 MB 64 MB

Free disk space 1.0 GB 80 MB 60 MB

Case study 145

Table 14 shows the required steps to properly configure all file servers:

Table 14. TDS file server deployment steps

Most of the above steps are fairly straightforward and can be easilyaccomplished by following the instructions in the referenced material. In thefollowing sections, we will provide more detailed explanations of the followingtasks starting with task 6.

Task 6: Creating and configuring the scriptsAs described in Section 5.8, “Suggested architecture and solution design” onpage 140, all secondary TDS file servers are updated after the generation ofa new cube or after the installation of a new TDS Discovery Guide.

Step Description Where Reference

1 Install the Tivoli Decision Support FileServer code

Primary TivoliDecision Support fileserver and allSecondary TivoliDecision Support fileservers

Tivoli Decision SupportInstallation Guide

2Configure the primary Tivoli DecisionSupport File server as a Managed Node ofthe Hub TMR

Primary TivoliDecision SupportFile Server

Framework Planningand Installation Guide

3Configure the secondary Tivoli DecisionSupport File servers as Endpoints

All Secondary TivoliDecision SupportFile servers

Framework Planningand Installation Guide

4Create a dataless profile manager calledSecondary_TDS_FileServers andsubscribe all Secondary Tivoli DecisionSupport File servers to it.

HUB TMR Framework Planningand Installation Guide

5 Make the Tivoli Decision Supportinstallation directory a shared resource

Primary and allsecondary TivoliDecision SupportFile servers

Windows NT ServerUser Guide

6Create and configure the transfer.cmdand copycubes.cmd scripts

Primary TivoliDecision SupportFile server

“Task 6: Creating andconfiguring the scripts”on page 146

7Create the tasks and jobs to run the scriptsdefined in task 5 Hub TMR

“Task 7: Creating thetasks and jobs” on page148

8 Schedule the jobs Hub TMR “Task 8: Scheduling thejobs” on page 152


Because cube generation fails if a user has a view open during the cubeupdating process, the update process first runs a script (shown in Figure 86)that copies all the generated cubes in the\\PRIM_TDS_FS\SHARENAME\Cubes\temp directory on the Secondary TDSfile servers. Later, another script (shown in Figure 87 on page 148) attemptsto copy these cubes to the \\PRIM_TDS_FS\SHARENAME\Cubes directorywhere PRIM_TDS_FS is the hostname of the primary TDS File server andSHARENAME is the share name of the primary TDS file server directory.These two scripts should be created on the primary TDS file server.

Figure 86 shows the update procedure first script:

Figure 86. The update procedure first script - transfer.cmd

The files to be transferred from the primary file server to the secondary fileservers are \\PRIM_TDS_FS\SHARENAME\Cubes\* and\\PRIM_TDS_FS\SHARENAME\Data\* where PRIM_TDS_FS is thehostname of the primary TDS File server and SHARENAME is the sharename of the primary TDS file server directory.

Note

@ECHO OFF:::: The following commands set the drive that correspond to the:: TDS shared directory in the primary TDS file server:: and the Primary TDS File server hostname::SET PRIM_TDS_FS="Here is your Primary TDS File server hostname"SET SHARENAME="Here is Sharename of the primary TDS File server directory"SET FS_DRIVE=\\%PRIM_TDS_FS%\%SHARENAME%SET FS_Cube=%FS_DRIVE%\CubesSET FS_DATA=%FS_DRIVE%\Data

:::: The following are the secondary TDS File Server local directories::SET DIR_TDS="Here is the complete path of the secondary TDS File server directory"SET DIR_CubeS=%DIR_TDS%\CubesSET DIR_DATA=%DIR_TDS%\DataSET DIR_TEMP=%DIR_CubeS%\Temp

:::: This step copies all new Cubes from the primary TDS File server:: to the temporary directory on the secondary TDS File server::ECHO ... Transfering the Cubes and configuration files from the primary TDS File Server ...xcopy %FS_Cube%\* %DIR_TEMP% /vxcopy %FS_DATA%\* %DIR_DATA% /v::

Case study 147

Figure 87 shows the update procedure second script:

Figure 87. The update procedure second script - copycubes.cmd

Task 7: Creating the tasks and jobsIn order to have the above scripts executed in an automated fashion, twotasks and two jobs should be created in the SPR_TaskLib Task library. Figure88 on page 149 shows the parameters of Transfer_Cubes, the first task to becreated.

The scripts shown in Figure 86 were used in our Lab environment. Theintention is to provide the reader with some example. These scripts may bemodified to attend specific environment requirements.

Note

@ECHO OFF:::: The following commands set the secondary TDS File Server local directories::SET DIR_TDS="Complete path of the secondary TDS File server directory"SET DIR_CubeS=%DIR_TDS%\CubesSET DIR_TEMP=%DIR_CubeS%\Temp

:::: The following command copies the updated Cubes to the Cubes directory::echo ... Copying the Cubes ...xcopy %DIR_TEMP%\* %DIR_CubeS% /v::


Figure 88. The Transfer_Cubes task

This task will run the script transfer.cmd stored in the Primary TDS file serversunfish. You can define this task using wcommands as shown in Figure 89:

Figure 89. Defining the Transfer_Cubes task

Figure 90 on page 150 shows the configuration of the Transfer_Cubes jobassociated with the Transfer_Cubes task.

# wcrttask -t Transfer_Cubes -l SPR_TaskLib -r senior \-i w32-ix86 sunfish ’C:\Program Files\TDS\transfer.cmd \-c ’This task runs the transfer.cmd script’

Case study 149

Figure 90. The Transfer_Cubes job

If the execution mode is set to parallel, the Transfer_Cubes job will run at thesame scheduled time in all hosts in the Secondary_TDS_FileServers ProfileManager.

Figure 91. Defining the Transfer_Cubes job

Figure 92 shows the parameters of Copy_Cubes, which is the second task tobe created.

# wcrtjob -j Transfer_Cubes -l SPR_TaskLib -t Transfer_Cubes -M parallel \-m 60 -o 015 -D -p Secondary_TDS_FileServers


Figure 92. The Copy_Cubes task

Similarly, this task will run the script copycubes.cmd, which is stored in thePrimary TDS file server sunfish. You can define this task using wcommandsas shown in Figure 93:

Figure 93. Defining the Transfer_Cubes task

Figure 94 on page 152 shows the configuration of the Copy_Cubes jobassociated with the Copy_Cubes task.

# wcrttask -t Copy_Cubes -l SPR_TaskLib -r senior \-i w32-ix86 sunfish ’C:\Program Files\TDS\copycubes.cmd \-c ’This task runs the copyccubeubes.cmd script’

Case study 151

Figure 94. The Copy_Cubes job

If the execution mode is set to parallel, this job will run at the same scheduledtime in all hosts in the Secondary_TDS_FileServers Profile Manager. You candefine this task using wcommands as shown in Figure 95:

Figure 95. Defining the Transfer_Cubes job

Task 8: Scheduling the jobsOnce you have defined the tasks and jobs as described in “Task 7: Creatingthe tasks and jobs” on page 148, you should define the schedule.

# wcrtjob -j Copy_Cubes -l SPR_TaskLib -t Copy_Cubes -M parallel \-m 60 -o 015 -D -p Secondary_TDS_FileServers


You can either use the Tivoli Desktop or the command line to schedule theJobs. You can define this task using wcommands as shown in Figure 96:

Figure 96. Scheduling the jobs

Figure 97 shows the scheduled jobs:

Figure 97. Scheduled jobs

5.9.3 Installation of the Tivoli Decision Support AdministratorThe Tivoli Decision Support Administrator component should be installed onthe Tivoli Decision Support Administrator machine in Boulder. In addition,

These Jobs should be scheduled after the cube-building process isfinished. For our example, we are assuming that the cubes are built dailyand that this process is finished at 1:00 am.

The Copy_Cubes job must run after the Transfer_Cubes job finishes.

Note

# wschedjob -n Transfer_Cubes -L SPR_TaskLib -t ’08/03/1999 02:00’ \-r ’24 hour’ -h sunfish -f ’C:\Program Files\TDS\transfer.log’ \-s "Transfer the TDS Cubes to all Secndary TDS File Servers’

# wschedjob -n Copy_Cubes -L SPR_TaskLib -t ’08/03/1999 04:00’ \-r ’24 hour’ -h sunfish -f ’C:\Program Files\TDS\copycubes.log’ \-s "Transfer the TDS Cubes from the temporary directory’

Case study 153

Cognos PowerPlay in administrator mode, Sybase open client, and the 32-bitSybase ODBC driver must be installed on this machine.

5.9.4 Installation of the Tivoli Decision Support client componentsThe TDS client components should be installed on every decision makermachine. The following software packages are part of the Tivoli DecisionSupport client components and should be installed and configured:

• Tivoli Decision Support Discovery Interface

• Cognos PowerPlay in Standard mode, On-line Books and Help

• Sybase open client

• 32-bit Sybase ODBC Driver

5.9.5 Deploying TDS for server performance predictionThe Server Performance Prediction Discovery Guide adds new monitors andtasks to the actual Distributed Monitoring environment. Table 15 lists thesequence of activities required to install and configure the Server PredictionPerformance Guide in the SDC West environment.

Table 15. SPP Discovery Guide installation steps

Steps Description Where Reference

1 Install the Distributed Monitoring Roll-upPatches

Hub and SpokeTMR servers and allManaged Nodes

Tivoli Decision Supportfor Server PerformancePrediction guideRelease Notes

2 Set Up an ODBC data source connectionTivoli DecisionSupport DiscoveryAdministrator


3 Install the Tivoli Decision Support forServer Performance Prediction Guide

Tivoli DecisionSupport File servers

Tivoli Decision SupportAdministrator guide andTivoli Decision Supportfor Server PerformancePrediction guideRelease Notes

4 Import the TDS Discovery GuideTivoli DecisionSupport DiscoveryAdministrator

Tivoli Decision SupportAdministrator guide andTivoli Decision Supportfor Server PerformancePrediction guideRelease Notes


Most of the steps in Table 15 are fairly straightforward and can be easilyaccomplished by following the instructions in the respective referencedmaterial.

A certain amount of configuration and effort is required to complete the DMRollup task. In the next section, we will provide a more detailed explanation ofthe installation and configuration of the DM Roll up tool.

5.9.5.1 Installing the Distributed Monitoring roll up toolOther than requiring the administrator to manually create the database andtables by running scripts included with this module for Sybase and Oracle,the standard Tivoli patch-style installation is almost fully automatic, and onlya simple configuration/instrumentation is needed.

5 Assign the ODBC data source.Tivoli DecisionSupport DiscoveryAdministrator

Tivoli Decision SupportAdministrator Guide andTivoli Decision Supportfor Server PerformancePrediction guideRelease Notes

6 Test the connectivity with the data sourceTivoli DecisionSupport DiscoveryAdministrator


7 Set all parameters in the cube, such asdate range, etc.

Tivoli DecisionSupport DiscoveryAdministrator


8 Build the cubeTivoli DecisionSupport DiscoveryAdministrator


9 Schedule the cube build taskTivoli DecisionSupport DiscoveryAdministrator


Steps Description Where Reference

Case study 155

The Tivoli Decision Support for Server Performance Prediction DiscoveryGuide presents information collected by the systems metrics from the TivoliDistributed Monitoring collection and archived by the DM Roll-up module. TheDM Roll-up module components collect, collate, and store the raw data fromthe monitors in the database through a RIM connection. The data samplestaken as part of Distributed Monitoring data collection will be aggregated androlled up from each Tivoli Profile subscribed host into the DM Roll-updatabase by a predefined task.

The Tivoli Distributed Monitoring (DM) 3.6.1 product must be installed on theHub TMR and updated with the Roll up patches. Table 16 tabulates, insequence, the tasks that need to be implemented in order to successfullyinstall and configure the Server Performance Prediction Roll-up module:

Table 16. DM Roll-up installation steps


1 Install patch 361-DMN-03 Hub TMR, Spoke TMRsand all Managed Nodes

Framework InstallationGuide 3.6 and TivoliDecision Support forServer PerformancePrediction guideRelease Notes

2 Install patch 361-UXM-03 Hub TMR, Spoke TMRsand all Managed Nodes


3 Install patch 361-DMN-08 Hub TMR, Spoke TMRsand all Managed Nodes


4 Install patch 361-DMN-9A Hub TMR, Spoke TMRsand all Managed Nodes



In the following sections we will highlight some of these tasks (starting withtask 6) and supply the reader with pertinent deployment information.

Task 6: Creating RIM objectThe 361-DMN-9C patch creates the RIM object; however, the patchinstallation options do not allow the user to specify the RIM Host. This patchwill, therefore, create the RIM host on the TMR server by default. In our casestudy, the HUB TMR server and the database server are on the samemachine. If the TMR server is not your database server, which is the casewith all Spoke TMRs, you will need to delete and re-create the RIM Object.This step is only necessary if the TMR server is not the database server.

5 Install patch 361-DMN-9C Hub TMR


6 Creating the RIM objectHub TMR and SpokeTMR

“Task 6: Creating RIMobject” on page 157 andSPP Release Notes

7 Size and create the ServerPerformance Prediction databaserepository

Hub TMR

“Task 7: Create the SPPdatabase repository” onpage 158 and TivoliDecision Support forServer PerformancePrediction guideRelease Notes

8 Set up the Server PerformancePrediction Roll Up Tivoli Environment

Desktop of Hub TMRand Spoke TMR

“Task 8: Setting up theSPP Roll up Tivolienvironment” on page159

9 Perform the Administration tasksDesktop of Hub TMRand Spoke TMR

“Task 9: Performing theadministration tasks” onpage 160

10 Schedule the Roll up tasksHub TMR and SpokeTMRs

“Task 10: Schedulingthe Roll-up tasks” onpage 160


Case study 157

To delete the DM Roll up RIM object, use the wdel command:

# wdel @RIM:spr_rim

To re-create the rim object, use the wcrtrim command. For a detailedexplanation of this command, refer to the TME 10 Framework 3.6 ReferenceManual, SC31-8434.

# wcrtrim -v Sybase -h rim_host -d dm_db -u dm -H /sybase -s SYBASE spr_rim

After the execution of this command, you will be prompted for the userpassword.

Task 7: Create the SPP database repositoryThe Tivoli Decision Support for Server Performance Prediction Guide relieson two Tivoli application databasesL: The Tivoli Distributed MonitoringRoll-up module database and the Tivoli Inventory database.

The Inventory database is optional for the operation of the ServerPerformance Prediction Guide and supplies additional enterprise hardwaredata when the customer has this product in their environment.

If the Tivoli Inventory database is not available, as is the case with the SDCWest environment, we will need to use a set of default files supplied with theTDS Discovery Guide installation in the $TDS/util directory.

In order for all five cubes of the Server performance Prediction Guide to bebuilt successfully, these files must be available as the default files or withdata when the Inventory database is available and the inventory query canrun. Always retain copies of the default versions of the following files:

• DM_INV_Memory.csv

• DM_INV_OsType.csv

• DM_INV_Processor.csv

The default RIM object name is spr_rim which connects to the dm_dbdatabase. The default database user is dm with the password dm_tds.

Note

The RIM host cannot be reset using the wsetrim command. The RIM objecthas to be deleted and recreated.

Note


• DM_INV_SysByIP.csv

Move these files from the $TDS/Util/Tivoli Decision Support for ServerPerformance Prediction directory into the $TDS/data/export directory.

Before the DM TDS Roll up can store the aggregated metrics in an RDBMS,we must create the database or repository. Scripts have been provided tocreate the database and install the DM_METRICS schema.

After a successful installation, the following RDBMS script files will be locatedin the $BINDIR/TME/SENTRY/TDS/rdbcfg directory of the Hub TMR server:

• cr_rollup_db.sh

• rm_rollup_db.sh

• new_passwd.sh

• cr_db.ora

• cr_tbl.ora

• rm_db.ora

• cr_db.syb

• cr_tbl.syb

• rm_db.syb

There are two ways to create your SPP Roll-up database and tables. One isby customizing the SQL templates, such as cr_db.syb and cr_tbl.syb.

The other is to run the cr_rollup_db.sh script on the RIM host. It will check theRIM object that was created for the SPP Roll-up to obtain databaseinformation, ask you about the size and device information, automaticallycustomize the SQL scripts, and create the required database and tables.

We run the cr_rollup_db.sh script on the Hub TMR and follow the simpleinstructions to create the DM repository.

Task 8: Setting up the SPP Roll up Tivoli environmentThe Installation process of the Tivoli Distributed Monitoring SPP Roll upConfiguration Patch 3.6.1 creates a policy region calledTMRHostname_SPR_Region on the Hub TMR Server. Within this region, theSPR_TaskLib Task library and the SPR_ProfileMgr profile manager arecreated. The SPR_ProfileMgr profile manager contains two profiles:SPR_NtProfile and SPR_UnixProfile, which are configured with prescannedmonitors and created during installation.

Case study 159

This TMRHostname_SPR_Region region is not visible on the administrator’sdesktop after installation. It resides as a Top Level Policy Region. You willneed to drag and drop this newly-created policy region from the Top LevelPolicy Region View onto the Administrator Desktop.

From the desktop, select the following:

Desktop --> TMR Connections --> Top Level Policy Regions

Task 9: Performing the administration tasksAfter migrating the Policy Region to the administrator desktop, the nextconfiguration step is to subscribe the Managed Nodes and Endpoints to theSPR_ProfileMgr Profile Manager. Once all the necessary subscriptions arecompleted, the administrator must distribute the platform-specific profiles tothe respective subscribers.

Task 10: Scheduling the Roll-up tasksTivoli Distributed Monitoring 3.6.1 has no problem monitoring a large numberof servers per TMR server. Since SDC West has deployed the Hub-Spokearchitecture, scalability should not be a problem. However, we recommendchanging the schedule roll-up tasks differently for each Spoke TMR in orderto ensure that all Spoke TMR servers will not be rolling their data up to thedatabase server at the same time. This is more of a database server capacityconcern than a TDS concern. The two tasks that should be rescheduled areSPR_DataAggregation and SPR_RollupIntoDB; they are located in theSPR_TaskLib task library.

The SPR_ProfileMgr object is created as a dataless Profile Manager and,therefore, we cannot subscribe any other Profile Managers to it. If you havea large number of endpoints, it is convenient to group them into Datalessprofiles managers and then make this profile a subscriber of theSPR_ProfileMgr. To do so, the properties of the SPR_ProfileMgr profilemanager can be changed to convert it to a database profile manager.

The SPR_ProfileMgr profile manager is, by default, assigned as asubscriber to the SPR_DataAggregation job.

The TMR Server is, by default, a subscriber to the SPR_RollupIntoDB job.

Note


5.9.6 Deploying the Event Management GuideTable 17 lists the sequence of activities required to install and configure theEvent Management Guide in the SDC West environment.

Table 17. Event Management Discovery Guide installation steps


1 Size the TEC Database.TEC Database onSybase server

Tivoli Decision Supportfor Event ManagementRelease Notes

2 Set up an ODBC data source connection.Tivoli DecisionSupport DiscoveryAdministrator


3 Create the SQL table, trigger, and views.TEC Database onSybase server


4 Install the Event Management DiscoveryGuide.

Tivoli DecisionSupport File Server

Tivoli Decision SupportAdministrator GuideTivoli Decision Supportfor Event ManagementRelease Notes

5 Import the Discovery Guide.Tivoli DecisionSupport DiscoveryAdministrator


6 Assign the ODBC data source.Tivoli DecisionSupport DiscoveryAdministrator


You may choose to schedule the jobs to run at different times using theTME Scheduler. The point to remember is that the data aggregation job,SPR_DataAggregation, must be scheduled to run and finish before theSPR_RollupIntoDB task is scheduled to start.

Note

Case study 161

5.10 Future reporting requirements

In the following sections, we will discuss future reporting needs that may beused by the customer. We will map those required reports that could not bepresented using Tivoli Decision Support. In addition, we will give a briefdescription of some additional TDS Discovery Guides that could be valuableif used in the customer’s environment. Some of these TDS Discovery Guidesare either available or are being addressed by new or soon-to-be-releasedTDS Discovery Guides.

5.10.1 Additional reportsBased in the information gathered in Section 5.6.1, “Detailed reports mappingworkshop” on page 114, all customer-required reports that are not availableto the recommended TDS Discovery Guide should be built. An additionalsub-project for delivering these reports should be initiated. In this case studychapter, we are not going to detail the contents of this sub-project but will,instead, present a table that details the additional report requirements. Theideas presented here are for your information only.

7 Test the connectivity with the data source.Tivoli DecisionSupport DiscoveryAdministrator


8Set all parameters, such as date range, inthe cube.

Tivoli DecisionSupport DiscoveryAdministrator


9 Build the cube.Tivoli DecisionSupport DiscoveryAdministrator


10 Schedule the cube build task.Tivoli DecisionSupport DiscoveryAdministrator




Table 18 displays the reports that need to be developed:

Table 18. Future requirements reference table

5.10.2 Additional recommended TDS Discovery GuidesThe following are some recommended Tivoli Decision Support DiscoveryGuides that can improve the analysis and decision-making process in thiscustomer scenario. Obviously, these TDS Discovery Guides may requireadditional Tivoli applications as prerequisites. Our goal here is only to provideinformation about how the customer can benefit from them.

5.10.2.1 Network Event Analysis GuideWhile the Network Event Performance Discovery Guide helps control theever-growing management to do list, which network events create, this guidewill track key performance indicators of your network by collecting,aggregating, and analyzing all the event traffic that NetView traps and cancorrelate. With the information discovered using this guide, you are able to

Likely TDS Discovery Guide Report

Tivoli Decision Support for ServerPerformance Prediction

DASD utilization by server. Refer to Figure46 on page 102

Either Tivoli Decision Support for NetworkElement Performance or Tivoli DecisionSupport for Server PerformancePrediction

Percent of Availability by server. Refer toFigure 47 on page 103

Either Tivoli Decision Support for NetworkElement Performance or Tivoli DecisionSupport for Server PerformancePrediction

Alert Summary report. Refer to Figure 48on page 103

Tivoli Decision Support for DominoManagement

Lotus Notes - MTA server report. Refer toFigure 52 on page 106


Lotus Notes - Sessions per minute report.Refer to Figure 55 on page 108


Lotus Notes - SMTP transferredmessages report. Refer to Figure 57 onpage 109

Tivoli Decision Support for ServerPerformance Prediction

Hard Disk and File System utilizationreport by Operating Systems. Refer toFigure 59 on page 111, and Figure 61 onpage 112

Case study 163

make meaningful decisions about improving your network performance andidentifying problems before they go out of control.

The following topics are provided by the NetView Network Event AnalysisDiscovery Guide:

• How is the event rate (by smartset) affecting the network?

• How is the event rate affecting the network?

5.10.2.2 Network Segment Performance GuideThe Network Segment Performance Discovery Guide provides the overallhealth of a segment for any period of time. It allows you to analyze collisions,broadcasts, multicasts, and performance locations within the network. Thisguide will also allow you to view information on network segment statistics.With the information discovered, you can identify performance problems andtheir causes.

The following topics are provided by the NetView Network SegmentPerformance Discovery Guide:

• How are errors affecting the network?

• How is Multicast and Broadcast traffic affecting the network?

• What is my network traffic pattern?

• What are the main failure points?

5.10.2.3 TDS for Information Management GuideThis guide enables you to analyze the problem and change managementinformation stored in your Tivoli Service Desk for OS/390 (formerly TME 10Information/Management) host databases. This guide is organized into twocategories - problem management and change management - to present themost typically sought-after information related to your service desk activities.This guide allows you to focus on activities and problems occurring within theservice desk arena. The Information Management guide tracks the mostcommon aspects encountered by a service desk including:

• Total time spent resolving problems

• Open problem volume by type

• Distribution of problems by severity

• Activity distribution by associated changes

• Activities coming up in the next six months

• Estimated duration of upcoming activities


5.10.2.4 Call Center Management Decision Support GuideBy limiting your focus to this area and viewing only the relevant data, a callcenter management analysis will help you determine how effective, efficient,and profitable your support center is. This Tivoli Decision Support Guidepresents the most typical data a support center collects including the numberof interactions, the first-call resolution rate, the elapsed time of interaction,and time to resolution.

5.10.2.5 Relationship Management Decision Support GuideThis guide highlights the relationship between the organization and itscustomers by focusing on how well requests are being resolved and theoverall health of the relationship. By viewing data from the perspective of therequest life cycle, you can identify obstacles or deviations from the mostefficient service process. Working with key business indicators, such asService Level Agreement (SLA) compliance and the number of call transfers,you are better able to understand how your customer perceives your service.

5.10.2.6 Knowledge Assessment Decision Support GuideWith the knowledge assessment Decision Support guide, you can begin tounderstand what solutions and diagnostic aids are working best to help youmanage your investment in knowledge. By looking at the KnowledgeEngineering category, you can get a better idea of how well you are usingdiagnostics and what knowledge is most effective. Indicators to exploreinclude the number of requests resolved with diagnostics and the number ofsolutions.

5.10.2.7 Service-level Management Decision Support GuideBy treating your support commitments as a focal point for further exploration,the guide for service-level management helps you ascertain how well you areoperating within budgeted guidelines and performing against the SLAs youhave established. For example, the Support Commitments categorycompares your customers' expectations with how well your organization ismeeting them.

5.10.2.8 Asset Management Decision Support GuideWith the asset management Decision Support guide, you can get a betterunderstanding of the assets your organization has deployed and theirassociated cost structures. This guide presents the most typical data an assetmanager needs but, historically, does not have easy access to. This dataincludes purchasing trends, yearly trend for asset acquisition, percent ofassets under lease or contract, asset base cost, as well as which networkhubs have the most connections.

Case study 165

5.10.2.9 Change Management Decision Support GuideIf there is one thing that is constant, it is change, and in a dynamic workenvironment, the change management Decision Support guide can help youget a handle on corporate changes and give you the data you need to makesolid management decisions. Focusing on how changes affect your bottomline, this guide includes:

• Labor cost groupings

• What changes are completed, overdue, and upcoming

• Estimated labor costs

• Percent of changes over cost estimate

• Request submission trend

• Task distribution


Chapter 6. Reports and decision information usage

In Chapter 5 of this redbook, we looked at the reports generated by onecustomer and offered a complete solution and design document equating thecurrent reporting environment and usage to the reports and businessinformation provided by Tivoli Decision Support.

Tivoli Decision Support is much more than just a report writer; it givesdecision makers the power to make well-informed decisions about theirenvironment and business. Customers can identify and analyze trends thatwould be difficult to identify if data were studied in isolation. In addition, it ispossible to evaluate the impact of a change that has been decided with thehelp of TDS, the time spent solving a particular problem, the quantity andlocation of some kind of asset to be upgraded or changed, how much must bespent, or the impact of a failure to accomplish a term of the Service LevelAgreement. Leveraging today's rapidly-emerging On-line AnalyticalProcessing (OLAP) technology, TDS Discovery Guides allow customers toexploit the vast amount of IT data and information needed to help meetbusiness goals.

This chapter demonstrates how Tivoli Decision Support can support thedecision-making process in your organization by describing a simple scenarioand outlining the steps used to find and analyze critical data with TDS.

The following sections lead you through a brief but complete data search thatyields specific results. The aim is to show how we can analyze and interpretinformation from the TDS Discovery Guides and make decisions based onthe content.

For this scenario, we are based on the assumption that the following productsare up and running:

• Tivoli Framework

• TEC

• Distributed Monitoring

• Tivoli Netview

• Software Distribution

• TDS Server Performance Prediction Discovery Guide

• TDS Domino Management Discovery Guide


6.1 The scenario

An IT Manager is concerned by the growing number of customer complaintsabout Lotus Notes mail service. It appears to be a response time-relatedproblem, and not everyone is affected by it.

The Executive Committee is cutting budgets, and one of the areas they arelooking at is Lotus Notes usage. Based on the fact that the mail service iscrucial for the business of the enterprise and that the Executive Committeehad closed the annual plan of investments for the year, any additionalacquisition of software or hardware must be very well-justified by the ITManager.

The IT Manager then asks the Systems Analyst if he or she can diagnose thecause of the problem and suggest a means to correct it. A detailed proposedsolution report is presented to the Chief Executive Officer. The CEO thenmakes sure of the commitment of capital involved and the benefit to theorganization of keeping the Service Level Agreement (SLA). The final reportis then presented to the Executive Committee.

6.2 The roles

We will now describe the roles of each of the decision makers involved. Thisscenario is only expressed as a guide to show how TDS can be used bydifferent role players in an organization and how each role player can viewthe information from different perspectives with the common goal ofmanaging the business efficiently.

In order to ensure that the Discovery Interface contains all the views that arerelevant to the data search of each decision maker, the number ofunnecessary views should be minimized by selecting the appropriate TDSDiscovery Guide and role on the Topic Map tab.

6.2.1 The systems analyst roleIn this scenario, the system analyst role represents an individual responsiblefor managing all Lotus Notes Mail servers in the enterprise. The systemanalyst is in charge of determining the overall performance of the servers andthe effectiveness of the mail service. He or she will deliver a report to the ITManager addressing the cause of the problem and advising a solution.


6.2.2 The IT manager roleThe role of the IT manager in this scenario is to look at the broader issue ofcurrent and future requirements of the IT infrastructure within theorganization and to make decisions about further IT investments or changesto the environment. This individual is responsible for determining problemareas in the products their department supports and anticipating thoseproblems before they occur.

6.2.3 The Chief Executive Officer roleThe role of the Chief Executive Officer (CEO) in this scenario is to decidewhether it is appropriate to approve any request for IT investment or changesin the organization and to present those requests to the executive committee.

6.3 The discovery process

Since the TDS Discovery Guide topics are worded as questions, a goodmodel for any discovery process is to pose it as a series of questions with thegoal of finding the answers with the help of Tivoli Decision Support.

Based on the scenario description, we need to determine why the currentMail service does not handle a large percentage of the total number ofrequests within an acceptable response time.

Based on the fact that not every customer is affected, there can be LotusNotes mail servers operating near their capacity. If this is true, there isprobably a strong case for investing in Mail service by upgrading hardware,thus, leveraging the service to conform to the SLA. If it is false, managementmay need to decide how to best use the current system instead of expandingit.

The following sections take us through a decision process using the TDSDiscovery Guides.

6.3.1 The system analyst discovery processFirst, we will establish the scope of our data search by asking the followingquestions, which will help the system analyst focus on resolving the problem.Some typical questions follow:

• Which mail systems have CPU workload problems?

• Which systems have a high average CPU run length cue?

• Which mail systems have high memory utilization?

Reports and decision information usage 169

• Which systems have a high memory page scan rate?

• Which mail systems have high network utilization?

• What is the average forecast mail delivery time?

The analysis of the views and information that these questions generate willallow the system analyst to identify whether there are any response- orworkload-related problems with the mail servers. The systems analyst needsto do the following:

• Find out why the response from the Lotus Notes mail servers is poor

• Analyze the information

• Consider solution options

• Present the proposed technical solution to the IT Manager for a finaldecision on any changes or technology investment that may be necessaryto resolve the problem.

To begin the decision process, the system analyst will use the Tivoli DecisionSupport Discovery Interface, select both the Server Performance PredictionDiscovery Guide and the Domino Management Discovery Guide, and choosethe role of systems analyst.

6.3.1.1 Which mail systems have CPU workload problems?After selecting the All System Metrics report, we will filter the information tosee only the Lotus Notes Servers. The resulting graph, as shown in Figure 98on page 171, displays the Lotus Notes server performance metrics by CPUutilization. This view shows us the monthly average percentage CPU busytime of the Lotus Notes Mail servers: nickel, desdemona, cypress, andburnet. The graph shows several CPU metrics from which it is clear that theserver nickel has high average CPU percentage busy, system time, and usertime utilization. This could be an indication that the server hasperformance-related problems. We can also understand that all the otherservers are under less stress.


Figure 98. Lotus Notes mail servers by CPU utilization

6.3.1.2 Which systems have a high average CPU run length cue?We will find the answer to this question by selecting the Server PerformancePrediction Discovery Guide and then selecting Busiest Systems report. In thisview, as shown in Figure 99 on page 172, we can look at the busiest systemsbased on the average daily run queue length metric for each system. The runqueue length metric is the number of processes that are ready to run(processes not waiting for Input/Output or user input) that the system cannotdispatch until it has free processor cycles. From the graph, we can see thatthe server nickel has a high run queue length. This a key metric fordetermining processor load and is measured in average number of waitingprocesses. The reports also show us that the other servers have average tonormal workload characteristics.


Figure 99. Lotus Notes Mail Servers daily average run length cue

6.3.1.3 Which mail systems have high memory utilization?Using the All System Metrics report in the Server Performance PredictionDiscovery Guide and filtering on By Physical Memory, we can see, as shownin Figure 100 on page 173, the busiest systems based on the hourly averagerun queue length metric for each system. The report shows us the memoryutilization for the Lotus Notes servers, and we can find out that the servernickel has a high utilization and that the usage for all the other servers ismoderate to low.


Figure 100. Lotus Notes mail servers by memory utilization

6.3.1.4 Which systems have a high memory page scan rate?By selecting the Systems That Need More Memory report from the ServerPerformance Prediction Discovery Guide, the system analyst can drill downand retrieve information from all Lotus Notes Servers. Figure 101 on page174 highlights systems with physical memory from 32 MB up to 64 MB wherethe page scan rate is exceptionally high.

The page-scan rate is presented in terms of pages scanned per second. Inorder to evaluate this metric, you need to take into account the amount ofphysical memory on the system. It is known that the server nickel has 64 MBof physical memory installed. A scan rate of 1000 pages/second isconsidered very high on a system with 64 MB of physical memory but not onone with 256 MB of physical memory. We can also see that the server nickelhas a scan rate of nearly 1000 pages per second. This can be regarded ashigh for this amount of memory and will need to be corrected.


Figure 101. Lotus Notes mail servers that need more memory

6.3.1.5 Which mail systems have high network activity?By selecting All System Metrics from the Server Performance PredictionDiscovery Guide, the system analyst can drill down and retrieve informationon all Lotus Notes Servers. By filtering on network utilization the networkactivity is displayed. Figure 102 on page 175 highlights the systems with highnetwork activity. It can be seen that the servers desdemona, cypress, andburnet have relatively low network utilization while that of nickel is high.Previously, we found that nickel had a high CPU utilization; this, coupled withhigh network activity, is an indication of an under-provisioned system.


Figure 102. Lotus Notes mail servers by network utilization

6.3.1.6 What is the average forecast mail delivery time?From the Domino Management Discovery Guide and the When might serversbegin experiencing problems report, the system analyst can filter by mailserver and then by the Mail.AverageDeliveryTime measure. Figure 103 onpage 176 shows the mail average and peak delivery time forecast of theserver nickel. The forecast highlights that, for the next 30, 60, and 90 days,the averages and peaks of mail delivery time are increasing. In addition,since, according to the SLA, all mail deliveries must be within 20 seconds,nickel will exceed the SLA within 30 days.


Figure 103. Lotus Notes mail server - forecasted average mail delivery time

6.3.1.7 The system analyst’s conclusions and suggestionsBased on the results of the information gathered earlier in this section, thesystem analyst will deliver a report to the IT Manager addressing the cause ofthe problem and deciding on a course of action.

The following are conclusions that can be drawn from the discovery of thenetwork:

• The servers desdemona, cypress, and burnet are operating within normalparameters and are attending the SLA.

• The server nickel is overloaded and under-provisioned. It means that theCPU is inadequate for the workload.

• The Lotus Notes mail service is currently operating at capacity, and theresponse problem only affects the customers attended by the servernickel, which is overloaded.

• The forecast to compromise the SLA is at least within 30 days since theworkload on server nickel is increasing.


The system analyst makes the following recommendations to resolve theproblem:

• Add or upgrade the CPU to server nickel

This will relieve the problem in the short term but does not address theunderlying problem of nickel being overloaded.

• Increase the amount of physical memory in nickel to 128 MB.

This will solve the problem in the medium term but still does not resolvethe fact that nickel is overloaded.

• Redistribute the workload across the other servers

This will offer a longer term solution but might be disruptive to theorganization.

6.3.2 IT manager discovery processThe IT manager will now consider the recommendations from the systemanalysis and use Tivoli Decision Support to answer some questions beforedeciding on what course of action to take. First, the IT manager will establishthe scope of the data search by writing down questions that will help him orher focus on resolving the problem. Some typical questions are:

• Which systems are over- or under-provisioned?

• Where are the performance anomalies?

• What performance problems are on the horizon?

To begin the decision-making process, the IT Manager will use the TivoliDecision Support Discovery Interface, select both the Server PerformancePrediction Discovery Guide and the Domino Management Discovery Guide,and choose the role of IT manager.

6.3.2.1 Which systems are over- or under-provisioned?By selecting How might I improve performance on my systems report? fromthe Server Performance Prediction Discovery Guide, the IT Manager can drilldown and retrieve information from all Lotus Notes Servers. Figure 104 onpage 178 highlights all Lotus Notes servers that are either under- orover-provisioned.

If you have a system that shows very high CPU utilization but has relativelylow network activity, we can say that the CPU is inadequate for the workload,that is, the system is under-provisioned. If you have a system that shows lowCPU utilization but has relatively high network activity, we can say that theCPU is excessive for the workload, that is, the system is over-provisioned.


The measure used for this view is the processor overload. This is expressedas a percentage of the difference between the CPU and network utilizationdivided by the network utilization.

In this case, the report shows that the server nickel has high CPU utilizationas well as relatively high network activity; this can be interpreted as beingunder-provisioned. It can also be noted that the other servers areover-provisioned.

Figure 104. Under-provisioned and over-provisioned Notes servers

6.3.2.2 Where are the performance anomalies?By selecting How might I improve performance on my systems report? fromthe Server Performance Prediction Discovery Guide, the IT Manager can drilldown and retrieve information from all Lotus Notes Servers. Figure 105 onpage 179 highlights the situation for all Lotus Notes servers.

This view can be useful in detecting areas where one or more of the systemsis not performing as expected. The logic behind this view is that, for systemshaving the same purpose and the same hardware configuration, processorutilization should be proportional to the network activity on the system. If it isnot, then there is probably something amiss with one of the systems.


In this report, we can see that the server nickel does not have the samebehavior as the other servers and that it has much higher average statistics.

Figure 105. Performance anomalies by server

6.3.2.3 What performance problems are on the horizon?By selecting What Performance Problems are on The Horizon? from theServer Performance Prediction Discovery Guide, the IT Manager can selectthe Systems most quickly approaching critical thresholds report and drilldown in order to retrieve information from all Lotus Notes Servers. Figure 106on page 180 highlights all Lotus Notes servers that are predicted to hit acritical performance threshold within the next 180 days. A critical situation ishighlighted in red for server nickel.


Figure 106. Lotus Notes server approaching critical thresholds

6.3.2.4 IT manager conclusionsThe IT manager’s role here is to look at the broader issue of managing thenetwork in terms of meeting SLAs and providing a scalable cost-effectivesolution. Based on the results of the information gathered earlier in thissection, the IT Manager will deliver a detailed proposed-solution report to theChief Executive Officer.

It is clear from the analysis of the reports that the server nickel is overloadedand that there is an uneven distribution of workload among the Lotus Notesmail servers. It has also become apparent that there is no formal process toadd users and services to the mail servers. After analyzing the reports, the ITmanager and the system analyst decide on the following solution:

• Since the enterprise has an under-provisioned server, it is necessary toredistribute the workload among all Lotus Notes servers, thus, providing alonger term solution while maximizing the capabilities of the network. Itmust be done within 10 days because the server nickel will sooncompromise the SLA.

• To implement a process to add users and services to the Lotus Notes mailservers will include the use of Tivoli Decision Support to identify which


servers are best able to handle the extra workload. This will allow the ITmanager to leverage the existing IT infrastructure and get a maximumreturn on the investment.

• Make budgetary provisions for memory and CPU upgrades for all theLotus Notes servers. The trends from TDS show that there will besignificant growth in workload and users.

Note that TDS has given the manager the power to predict when systems willreach their critical thresholds and, therefore, can plan and budget well inadvance in order to maintain SLAs.

Finally, the manager must present his proposals and solutions to the CEO.

6.3.3 CEO’s discovery processThe role of the CEO here is to make sure that the investments in thecompany’s IT infrastructure and resources are being managed efficiently. TheCEO is also concerned that any further investment or changes to theenvironment be of benefit to the organization. He or she considers theproposal from the IT Manager and, in order to begin the decision process, willuse the Tivoli Decision Support Discovery Interface selecting the ServerPerformance Prediction Discovery Guide and then choose the role of CEO.

The CEO needs to decide whether it is appropriate to approve the requestmade by the IT manager. A typical question might be: What are theperformance trends?

Analysis of the view and information provided by this question will allow theCEO to identify the performance behavior of the Lotus Notes servers and tocertify that the commitment of capital and time involved will be conducive tothe organization keeping on the Service Level Agreement.

6.3.3.1 What are the performance trends?By selecting Is my resource utilization growing? from the Server PerformancePrediction Discovery Guide, the CEO can select the Daily averageperformance trend report and drill down in order to retrieve information fromall Lotus Notes Servers.

Figure 107 on page 182 highlights the growth trend for criticalsystem-performance metrics over the last four weeks. It looks at the averagevalue on a day-by-day basis. This report is useful for spotting growth trendsand changing patterns in resource utilization.


Figure 107. Lotus Notes server daily average performance trends

We can see that the growth trend for the Notes server nickel is out ofproportion to the rest of the Lotus Notes servers.

6.3.3.2 The CEO’s conclusionsNow, the problem and the solution proposed by the IT Manager are clear tothe CEO. After considering all the information, the CEO approves the project.

Based on the information provided by the IT Manager, the CEO approves theproject to redistribute the workload among all Lotus Notes servers. It must bedone within 10 days in order to keep the SLA.

The CEO also asks the IT Manager to prepare a detailed process to addservices to the Lotus Notes Servers in order to better use the actual ITinfrastructure and the investment that had been made in the Lotus Notes Mailservice.

Based on the information gathered from TDS, the CEO finally prepares areport requesting the budgetary provision for memory and CPU for all theLotus Notes servers. The CEO now has a detailed description of the problemand is armed with confidence, answers, and solutions to present to theExecutive Committee.


6.4 Conclusion

In this simple scenario, we have attempted to show the power and diversity ofTDS. By choosing different roles and following their decision-makingstrategies to resolve a problem, we can see how each decision maker has apart in the final decision. Each role player needs different information fromthe same data; the analyst needs to know the cause of the problem; themanager needs to understand the impact of the solution on the network as awhole, and the CEO needs to know what are the benefits to the organization.

It would be almost impossible to show all the diverse roles and informationthat TDS can produce. Knowledge can help shape an organization’s thinkingand its approach to its customers and service issues. As you have seen inthis scenario, even a brief and basic discovery strategy can yield surprisingresults and help IT professionals make better business decisions.



Appendix A. Tivoli Implementation Methodology (TIM) 3.6

The Tivoli Implementation Methodology (TIM) provides Tivoli BusinessPartners and Tivoli Services with best practices for identifying, designing,planning, installing, testing, and documenting a Tivoli Enterprise solution.

A.1 Target market

The target market is Tivoli Services and Tivoli Business Partners customersthat value quality services as part of the solution.

A.2 Customer profile

TIM can be used in two different ways:

• Internally - TIM is designed for Tivoli Business Partners and TivoliServices. It is Tivoli’s process for a services engagement with Tivolicustomers. All Tivoli professionals are strongly encouraged to leveragethis methodology while selling and implementing Tivoli Solutions.

• Externally - TIM is designed to accelerate and optimize Tivoli servicesengagements. Customers should leverage service providers that utilizethe TIM in its entirety or as part of their own best practices. The TIM, TivoliCertification, and Training are all proof of Tivoli's commitment to an openservices industry.

A.3 The top three things to remember

The top three things to remember about TIM are:

• TIM provides market and customer confidence: TIM is an industry-widemeans of ensuring that our service providers are leveraging best practicesand maximizing customer benefits.

• TIM enables accelerated and optimized deployments: TIM enablesaccelerated deployments and reduces the time required to deliver Tivolibenefits to the customer.

• TIM 3.6 Captures "Best of Breed" Tivoli intellectual capital: TIM capturesyears of Tivoli architecture and solution implementation experience fromthe Tivoli organization and partner groups, thus, providing customers withaccess to evolving best practices through their services providers.


A.4 What is new with TIM?

New enhancements of TIM include the following:

• Manage the extended customer engagement: TIM now supports acomplete customer engagement - beyond that of just a softwareinstallation.

• Enhanced Support for Tivoli Product Line: Improved support for theTivoli product line includes detailed requirements and deployment guides,improved architecture and design information, and updated projectmanagement tools. This support includes the latest product offeringsincluding Security Management, Framework 3.6, and Tivoli Migration. TIMwill continue to be updated for the latest in Tivoli supported platforms.

A.5 What is unique?

TIM has the following unique characteristics:

• TIM Sets the standard for industry-wide methodologies: TIM provides anindustry-wide methodology to all of our certified services providers. Thisgives the customer confidence in an accelerated, optimized deployment.

• TIM is a Full Engagement Tool: TIM goes beyond a simple softwareinstallation guide, and it provides management for the full engagementprocess.

A.6 Where can I find information on TIM?

TIM is available for use by Tivoli services professionals and certified TivoliBusiness Partners.

Business Partners order the Tivoli Implementation Methodology for BusinessPartners Version 3.6 from the Tivoli Information for Partners (TIPS) Web siteby requesting part number LK3T-3567.

Tivoli employees may access TIM internally at http://corp.tivoli.com/ underthe Sales/Tivoli Services tab or at http://fortune.tivoli.com/TIM


Appendix B. Tivoli Decision Support customer support

At Tivoli Systems, we know dependable ongoing support and services areessential extensions of Tivoli software and an integral part of your enterprisesystems management solution.

B.1 The support process

The following list describes the process that will be carried out for any TivoliDecision Support customer query. This aims to give the reader an idea ofwhat the process is in order to understand how the call will be handled.

1. The customer will call the 1-800-Tivoli-8 number with a question orproblem.

2. The CSR will dispatch the call to the Tivoli-Indianapolis Support Center.

3. If the call pertains to a core question (Cognos, basic functionality, and soon), analysts in Indianapolis will handle the call. If the call is aguide-specific issue, we will transfer the ticket to the appropriate site.

4. The Indianapolis analyst will provide as much detail as possible andinclude any pertinent suggestions in the ticket description to assist theanalysts in Austin and Raleigh.

5. In some cases, analysts in Indianapolis will be able to solve foreignguide-specific issues without transferring the call to either Austin orRaleigh.

6. If the call is transferred to either site (Austin or Raleigh) and assistancefrom Tivoli is required in any way, please call them.

7. We anticipate that supporting TDS for Tivoli customers will be a joint effortbetween Indianapolis and Austin or Raleigh.

For related product support:

1. Cognos Support - For now, contact Indianapolis.

2. Seagate Support - [email protected]

Even though the support plan has been designed for Indianapolis to handlecore issues (Cognos, basic functionality, and so on), some cases may behandled in Austin or Raleigh, and, therefore, an understanding of the coreapplication is necessary.

Note



Appendix C. Tivoli Decision Support Discovery Guides availability

The Tivoli Decision Support Discovery Guides provide immediate access tokey IT enterprise information. These predefined solutions provide directanswers to the most pertinent business questions through a simple questionand topic paradigm and single views into the data. These solutions arecreated through knowledge of the data captured by Tivoli applications,knowledge of IT best practices, and knowledge of IT customer needs. TheTDS Discovery Guides provide out-of-the-box data views and reports forimmediate value.

Table 19 can be used as a reference to the TDS Discovery Guides availability:

Table 19. TDS Discovery Guides general availability

Tivoli Decision Support Discovery Guide General Availability

Tivoli Decision Support for Event Management Currently available on2nd Quarter 1999

Tivoli Decision Support for Server Performance Prediction Currently available on3rd Quarter 1999

Tivoli Decision Support for Network Element Performance Currently available on3rd Quarter 1999

Tivoli Decision Support for Network Segment Performance Currently available on3rd Quarter 1999

Tivoli Decision Support for Network Event Analysis Currently available on3rd Quarter 1999

Tivoli Decision Support for Software Deployment Analysis Currently available on3rd Quarter 1999

Tivoli Decision Support for Year 2000 Readiness Version 2.0 Currently available on3rd Quarter 1999

Tivoli Decision Support for Domino Management 3rd Quarter 1999

Tivoli Decision Support for SAP R3 Analysis 4th Quarter 1999

Tivoli Decision Support for Storage Management Analysis 4th Quarter 1999

Tivoli Decision Support for PeopleSoft 4th Quarter 1999

Tivoli Decision Support for Information Management Currently available on3rd Quarter 1999


Call Center Management Decision Support GuideShipped with TDS.Currently available onTivoli DecisionSupport version 2.0

Relationship Management Decision Support GuideShipped with TDS.Currently available onTivoli DecisionSupport version 2.0

Knowledge Assessment Decision Support GuideShipped with TDS.Currently available onTivoli DecisionSupport version 2.0

Service Level Management Decision Support GuideShipped with TDS.Currently available onTivoli DecisionSupport version 2.0

Asset Management Decision Support GuideShipped with TDS.Currently available onTivoli DecisionSupport version 2.0

Change Management Decision Support GuideShipped with TDS.Currently available onTivoli DecisionSupport version 2.0

Telephony Decision Support GuideShipped with TDS.Currently available onTivoli DecisionSupport version 2.0

Tivoli Decision Support Discovery Guide General Availability

Tivoli frequently announces the availability of new Guides. For the latestinformation on Guide availability, refer to Tivoli’s Web page:http://www.tivoli.com

Note


Appendix D. Special notices

This publication is intended to help anyone involved in the deployment of theTivoli Decision Support and the Tivoli Decision Support Discovery Guides.The information in this publication is not intended as the specification of anyprogramming interfaces that are provided by the Tivoli applications. See thePUBLICATIONS section of the IBM Programming Announcement for the Tivoliapplications suite for more information about what publications areconsidered to be product documentation.

References in this publication to IBM products, programs, or services do notimply that IBM intends to make these available in all countries in which IBMoperates. Any reference to an IBM product, program, or service is notintended to state or imply that only the IBM product, program, or service maybe used. Any functionally-equivalent program that does not infringe any IBMintellectual property rights may be used instead of the IBM product, program,or service.

Information in this book was developed in conjunction with the use of theequipment specified and is limited in application to those specific hardwareand software products and levels.

IBM may have patents or pending patent applications covering subject matterin this document. The furnishing of this document does not give you anylicense to these patents. You can send license inquiries, in writing, to the IBMDirector of Licensing, IBM Corporation, North Castle Drive, Armonk, NY10504-1785.

Licensees of this program who wish to have information about it for thepurpose of enabling: (i) the exchange of information between independentlycreated programs and other programs (including this one) and (ii) the mutualuse of the information which has been exchanged, should contact IBMCorporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA.

Such information may be available, subject to appropriate terms andconditions, including, in some cases, payment of a fee.

The information contained in this document has not been submitted to anyformal IBM test and is distributed AS IS. The information about non-IBM("vendor") products in this manual has been supplied by the vendor and IBMassumes no responsibility for its accuracy or completeness. The use of thisinformation or the implementation of any of these techniques is a customerresponsibility and depends on the customer's ability to evaluate and integratethem into the customer's operational environment. While each item may have


been reviewed by IBM for accuracy in a specific situation, there is noguarantee that the same or similar results will be obtained elsewhere.Customers attempting to adapt these techniques to their own environmentsdo so at their own risk.

Any pointers in this publication to external Web sites are provided forconvenience only and do not in any manner serve as an endorsement ofthese Web sites.

Any performance data contained in this document was determined in acontrolled environment, and therefore, the results that may be obtained inother operating environments may vary significantly. Users of this documentshould verify the applicable data for their specific environment.

Reference to PTF numbers that have not been released through the normaldistribution process does not imply general availability. The purpose ofincluding these reference numbers is to alert IBM customers to specificinformation relative to the implementation of the PTF when it becomesavailable to each customer according to the normal IBM PTF distributionprocess.

The following terms are trademarks of the International Business MachinesCorporation in the United States and/or other countries:

The following terms are trademarks of other companies:

Cognos, the Cognos logo, Impromptu, PowerPlay, PowerCube, and Scenarioare trademarks of Cognos Inc.

Oracle is a trademark of Oracle Inc.

Sybase is a trademark of Sybase Inc.

Crystal Reports is a trademark of Seagate Software Inc.

Tivoli Service Desk is a trademark of Software Artistry, a Division of Tivoli.

AIX AS/400AT DB2Home Director IBMMQ MQSeriesNetfinity NetViewOS/2 OS/390RS/6000 S/390System/390 TivoliTivoli Decision Support Tivoli Decision Support Discovery Guide


C-bus is a trademark of Corollary, Inc. in the United States and/or othercountries.

Java and all Java-based trademarks and logos are trademarks or registeredtrademarks of Sun Microsystems, Inc. in the United States and/or othercountries.

Microsoft, Windows, Windows 95, Windows NT, and the Windows logo aretrademarks of Microsoft Corporation in the United States and/or othercountries.

PC Direct is a trademark of Ziff Communications Company in the UnitedStates and/or other countries and is used by IBM Corporation under license.

ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of IntelCorporation in the United States and/or other countries. (For a complete listof Intel trademarks, see www.intel.com/tradmarx.htm)

UNIX is a registered trademark in the United States and/or other countrieslicensed exclusively through X/Open Company Limited.

SET and the SET logo are trademarks owned by SET Secure ElectronicTransaction LLC.

Other company, product, and service names may be trademarks or servicemarks of others.

Special notices 193


Appendix E. Related publications

The publications listed in this section are considered particularly suitable for amore detailed discussion of the topics covered in this redbook.

E.1 International Technical Support Organization publications

For information on ordering these ITSO publications see “How to get ITSOredbooks” on page 197.

• Creating Custom Monitors for Tivoli Distributed Monitoring, SG24-5211

• Deploying a Tivoli Infrastructure in Large-Scale Environments, SG24-5210

• TME 10 Deployment Cookbook: Inventory and Company, SG24-2120

• TME 10 Deployment Cookbook: Courier and Friends, SG24-4976

• TME 10 Framework Version 3.2: An introduction to the Lightweight ClientFramework, SG24-2025

• An Introduction to Tivoli’s TME 10, SG24-4948

• An Industry around the Tivoli Framework: Examples from 10/PlusAssociation, SG24-2122

• Using Tivoli Software Installation Service for Mass Installation, SG24-5109

• All about Tivoli Management Agents, SG24-5134

• A Project Guide for Deploying Tivoli Solutions, SG24-5310

• Designing Tivoli Solutions for End-to-End Systems and ServiceManagement, SG24-5104

• High Availability Scenarios for Tivoli software, SG24-2032

• Instrumenting Enterprise Applications Using Tivoli GEM, SG24-5399

• Integrated Management Solutions Using NetView Version 5.1, SG24-5285

• Using Tivoli’s ARM Response Time Agents, SG24-2124

• Measuring Lotus Notes Response Time with Tivoli’s ARM Agents,SG24-4787

• Using the Applications Management Specifications in a TMA Environment,SG24-4809


E.2 Redbooks on CD-ROM

Redbooks are also available on the following CD-ROMs. Click the CD-ROMsbutton at http://www.redbooks.ibm.com/ for information about all the CD-ROMsoffered, updates, and formats.

E.3 Other publications

These publications are also relevant as further information sources:

• TME 10 Framework 3.6 Planning and Installation Guide, SC31-8432

• Framework 3.6 User’s Guide, GC31-8433

• TME 10 Framework Release Notes Version 3.6, GI10-3028

• TME 10 Framework 3.6 Reference Manual, SC31-8434

• Tivoli Service Desk Enterprise Integration User’s Guide, GC31-5203

• Tivoli Service Desk Installation Guide, GC31-5167

• Tivoli Decision Support User’s Guide, GC31-5202

• Using Decision 2.0 Support Guide, GC32-0290

• Tivoli Decision Support Administrator’s Guide, GC31-5201

• Tivoli Decision Support Installation Guide, GC32-0289

CD-ROM Title Collection KitNumber

IBM System/390 Redbooks Collection SK2T-2177

IBM Networking and Systems Management Redbooks Collection SK2T-6022

IBM Transaction Processing and Data Management Redbooks CollectionSK2T-8038

IBM Lotus Redbooks Collection SK2T-8039

Tivoli Redbooks Collection SK2T-8044

IBM AS/400 Redbooks Collection Kit SK2T-2849

IBM Netfinity Hardware and Software Redbooks Collection SK2T-8046

IBM RS/6000 Redbooks Collection Kit (BkMgr Format) SK2T-8040

IBM RS/6000 Redbooks Collection (PDF Format) SK2T-8043

IBM Application Development Redbooks Collection Kit SK2T-8037

IBM Enterprise Storage and Systems Management Solutions SK3T-3694


How to get ITSO redbooks

This section explains how both customers and IBM employees can find out about ITSO redbooks,redpieces, and CD-ROMs. A form for ordering books and CD-ROMs by fax or e-mail is also provided.

• Redbooks Web Site http://www.redbooks.ibm.com/

Search for, view, download, or order hardcopy/CD-ROM redbooks from the redbooks Web site. Alsoread redpieces and download additional materials (code samples or diskette/CD-ROM images) fromthis redbooks site.

Redpieces are redbooks in progress; not all redbooks become redpieces and sometimes just a fewchapters will be published this way. The intent is to get the information out much quicker than theformal publishing process allows.

• E-mail Orders

Send orders by e-mail including information from the redbooks fax order form to:

• Telephone Orders

• Fax Orders

This information was current at the time of publication, but is continually subject to change. The latestinformation may be found at the redbooks Web site.

In United StatesOutside North America

e-mail [email protected] information is in the “How to Order” section at this site:http://www.elink.ibmlink.ibm.com/pbl/pbl/

United States (toll free)Canada (toll free)Outside North America

1-800-879-27551-800-IBM-4YOUCountry coordinator phone number is in the “How to Order”section at this site:http://www.elink.ibmlink.ibm.com/pbl/pbl/

United States (toll free)CanadaOutside North America

1-800-445-92691-403-267-4455Fax phone number is in the “How to Order” section at this site:http://www.elink.ibmlink.ibm.com/pbl/pbl/

IBM employees may register for information on workshops, residencies, and redbooks by accessingthe IBM Intranet Web site at http://w3.itso.ibm.com/ and clicking the ITSO Mailing List button.Look in the Materials repository for workshops, presentations, papers, and Web pages developedand written by the ITSO technical professionals; click the Additional Materials button. Employees mayaccess MyNews at http://w3.ibm.com/ for redbook, residency, and workshop announcements.

IBM Intranet for Employees


IBM Redbook fax order form

Please send me the following:

We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card notavailable in all countries. Signature mandatory for credit card payment.

Title Order Number Quantity

First name Last name

Company

Address

City Postal code

Telephone number Telefax number VAT number

Invoice to customer number

Country

Credit card number

Credit card expiration date SignatureCard issued to


List of abbreviations

CEO Chief Executive Officer

DM Decision Maker

DMP Decision MakingProcess

DSM Distributed SystemsManagement

DSS Decision SupportSystems

DSM Distributed SystemsManagement

IBM International BusinessMachines Corporation

ITSO International TechnicalSupport Organization

IT Information Technology

MLM Mid-level Manager

NCO Network ComputingOfferings

ODBC Open DatabaseConnectivity

OLAP Online AnalyticalProcessing

OS Operating System

RDBMS Relational DatabaseManagement System

RIM RDBMS InterfaceModule

SDC Service Delivery Center

SLA Service levelAgreement

SNMP Simple NetworkManagement Protocol

SPP Server PerformancePrediction

SQL Structured QueryLanguage

© Copyright IBM Corp. 1999

SRM Server ResourceManagement

TDS Tivoli Decision Support

TEC Tivoli EnterpriseConsole

TIM Tivoli ImplementationMethodology

TMA Tivoli ManagementAgent

TMR Tivoli ManagementRegion

TPS Tivoli ProfessionalService

TSD Tivoli Service Desk

199


Index

Aadministering 70administration 70administrator 68administrator system 14AIX 102AIX performance 104AIX reports 109alert log 102algorithms 13, 61Analysis 96analytical decision 75answers to questions 9application 10architecture 30availability 1

Bbandwidth 65batch reports 2best practices 23, 185better decisions 6Boulder 88Brazil 6broader vision 3budgetary provision 181business data 13Business Decision Information 7business decisions 183business hours 12business indicators 13business information 78Business Intelligence 1

defined 3business knowledge 12business leaders 27business models 13business operation 9

Ccalculations 12Categories 12, 69categories 62Category definition 16central repository 10

© Copyright IBM Corp. 1999

CEO 169CEO conclusions 182CEO’s discovery process 181charts 2Chief Executive Officer 168Chief Executive Officer role 169Cisco routers 138Client Database 14Cognos 12Cognos PowerPlay 10, 12, 14, 62, 143Cognos support 187Cognos Transformer 16, 67collection 96comma separated values 129CPU 99CPU utilization 97critical data 167critical network 137critical performance 179critical system 181critical thresholds 179Crystal Report files 69Crystal Reports 10, 12, 62cube build times 67Cube building problems 81Cube building process 64

step 1 65step 2 66step 3 66step 4 67

cube file 16cubes 68Cubes definition 16cubes.mdb 61, 65Customer confidence 185customer profile 185Customer reporting requirements 92customer requirements questionnaire 27customer satisfaction 9customization requirements 33

Ddata elements 13Database Administrator 45Database Server Information 38dataless profile manager 160DB2 16

201

Decision 1, 5Decision Makers 4, 6, 61, 73, 78decision making 9decision making process 1, 5decision process 170Decision Support Guides 32Decision Support Systems 1, 4, 5delivering services 9delivery mechanisms 10Deployment Phase 47

deployment guide 48input and output components 47process flow 48Training 52

Deployment phaseadvanced configuration and customization 51deployment preparation 49product configuration 51product installation 50

deployment strategy 24detailed design 30Dicing definition 18Dimension Line definition 17dimension members 16dimensions 9Dimensions definition 17discovering key information 13Discovery Administrator 10, 11Discovery Administrator PC Information 37Discovery Interface 10, 12Discovery Interface PC Information 38discovery process 169Distributed Systems Management 93distributed systems management 3dive 9DM 4DM Roll Up patches 156DM Roll Up Toll installation steps 156DM Roll Up Tool 155DMP 5Documentation Phase 54

input and output components 55process flow 55

Domino Roll Up module 129Drill Down 72Drill Through 80Drill Through databases 66Drill-Down 17, 33, 61Drill-Down definition 17

Drill-Through definition 17DrillThru.mdb 62, 66, 69Drill-Up 17Drill-Up definition 17DSM 93DSS 4

characteristics 5definition 5

Ee-Business 2, 3ed.mdb 62, 69EDAdmin.log 82effectiveness 9effects 12efficiency 9, 13endpoints 61, 74, 77, 160End-to-End service delivery 3End-to-End solutions 1end-user solution 13enhanced quality 116enterprise 2Enterprise Console 29Enterprise solution 23enterprise’s data sources 21enterprise’s databases 19enterprise’s operation 12enterprise’s service 13Event Management 125Event Management Discovery Guide deployment161Evolution to Business Intelligence 2Executive Committee 168existing 96existing IT infrastructure 181existing policies 28existing reports 51existing Tivoli Systems Management solution 28Explorers 21

FFail-over analysis 57fast access to information 2File server 14File Server Information 37files 10Filter definition 17forecasts 20


formal process 180function of an organization 9functional elements 53functionality and limitations 42functionality testing 53functions and capabilities 31functions for TDS 37

Ggateways 74, 77generating views 12GPFs 82guide the enterprise 3Guides 10, 13

Hhardware requirements 145help desk operation 9high availability environment 88high average CPU 169high CPU utilization 124high level 9high level physical design 141high level report 6high memory page scan rate 170high memory utilization 169high network activity 124high run queue length 171high success 21high-level task flow 87highly customizable 21hints 13historical records 20Hub 87Hub TMR 87Hub-Spoke 87

IIBM 85IBM Global Services 85IBM SDC West 93IBM SDC-West Environment 85IBM Service Delivery Center 8impact on the response times 80Information Technology 1Informix 16In-House 94

In-House reports 97installation method 70integration process 60interactive business indicators 6Intersolv 14interview 27intranet 10investments 168isql 81IT 1IT manager 9, 168IT Manager conclusions 180IT manager discovery process 177IT manager role 169IT technical leader 27

JJob schedule 153Jobs 148

Kkey business 13keyword searches 13kickoff 33knowledge 183knowledge discovery 9

LLAN 80Layer definition 17Leader 44levels of details 9local clients 142local network 141local TDS file server 143log entries 103log space 90Logical Design 33

Mmanaged nodes 160management gateways 61management tasks 20management team 45management tools 3manipulate 60mapping TDS Discovery Guides 33

203

Measures definition 17methodology 23methods 13Microsoft Access databases 69migrating 160migration 85miss the SLA 126Modelling 113Models 12Models definition 18multi-dimensional analysis 6, 12multi-dimensional array 16multi-dimensional Cubes 61, 80multi-dimensional space 18Multiple TMR Environment 77

NNCO 94Netfinity Capacity Manager 96Netfinity Capacity Manager. 95NetView MLM 102Network 39network administrator 45network analyst 9network bandwidth 63Network Computing Offerings 94Network Management 3network mode 14, 34network traffic 64, 67network-wise 89NotesView 96

OODBC connection 61, 69ODBC connectivity errors 81ODBC data source 63ODBC drive 14OLAP 6, 167OLE link 83One-Minute Managers 21On-Line Analytical Processing 167On-line Analytical Processing 6open calls 21Operations 89optimal 88Optimization 49optimization of server 113Oracle 14, 16

organization's experience 23organization's methodology 52output documentation 34over provisioned 124, 177overall management 45overview of the Customer 56overview of TIM 24Overview of Tivoli Decision Support 9

Ppatches 42performance 13permissions 82perspectives 9Physical Design 33policy region 159, 160populates 11PowerPlay 12, 16PowerPlay report files 68predictive analysis 3preparation for deployment 43primary TDS file server 142printouts 10pro-active 5problem management 72procedure for deploying TDS 144Profile definition 18profile manager 159, 160profiles 159profitability 13Project Analysis 41project Leader 44Project Plan 26Project plan 41Project Planning Phase 40


Project Task Plan 42Project Team 26, 44projections 20proposal for TDS 30proposals 181push content 10push-delivery 22

Qqualifier 81quality 116


quality of collection 113queries 12, 13querying 70quickly approaching thresholds 179

Rrapidly emerging 167raw data 65RDBMS 74, 143realistic deployment 71reducing IBM IT reporting costs 86related view definition 18related views 13, 18, 62, 69relationships 12remote sites 74replication 80report generation 70reporting requirements overview 27Reports Analyst 46repository 12Requirements Gathering Phase 25


resolutions 9resource allocation 20resource availability 35resource requirements 34responsiveness 72RIM Host 157RIM host 87RIM Object 157Role definition 18Rover 82rover utility 81Rover window 82

SSan Jose 89Santa Teresa 89scalability 160scheduling the Jobs 152scopes 9SDC 85SDC-West 85Seagate 12Seagate support 187secondary TDS file server 142Selection Criteria definition 18

Server Performance Prediction 117Server Performance Prediction deployment steps154Server Resource Management 94, 96Service Delivery Center 85Service Delivery Center architecture 88Service Level Agreement 168service level agreement management 3Service Level Agreements 1service management 3severity level 12shared drive 15Single TMR Environment 74SLA 1, 9, 168Slicing definition 18snapshot-style views 20Software Engineering Life Cycle Model 24Spoke 87Spoke TMR 87Spot trends 20SPP 117SQL 61, 82SQL queries 61SQL Server 16SQLplus 81SRM 94, 96SRM Reports 104Stand-alone mode 14stand-alone mode 34support centers 6support process 187surprising results 183Sybase 14, 16System Administrator 45System Analyst conclusions 176System Analyst discovery process 169System Analyst role 168System Architecture and Design document 26, 33Systems Analysis Phase 30


Systems analysis phasepreparation 31

Systems Analyst 168Systems Management 3

Ttarget market 185

205

Task library 148, 159Tasks 148TDS 5TDS Discovery Guides 143TEC 74technical proposal 26technical solution 31templates 12Testing Phase 52


the challenge 4third-party application 12TIM 23, 25, 185Tivoli certified consultants 46Tivoli commands

wcrtjob 150, 152wcrtrim 158wcrttask 149, 151wdel 158wschedjob 153

Tivoli Decision Support 3, 5, 6, 7architecture 34Base Product 10client component 62components 14, 61components integration 63concepts 16Discovery Administrator 11, 62, 141Discovery Guides 10, 12Discovery Guides availability 189Discovery Interface 12, 14, 68, 143environment 61File Server 12, 61, 142File Server deployment steps 146functionality 19functionality diagram 60functions 70goal 9Implementation Modes 14implementations 74into the Decision Making Process 5network mode 71overview 9Product Components 10resource mapping 36Server Component 10, 12solution objectives 42stand-alone mode 70

support process 187Supported Platforms 15terminology 16users 21

Tivoli Decision Support methodology 23Deployment phase 47Documentation phase 54Project planning phase 40Requirements gathering phase 25Systems analysis phase 30Testing phase 52

Tivoli Discovery GuidesCall Center Management 165Change Management 166Domino Management 128Event Management 125Information Management 164Knowledge Assessment 165mapping 114Network Element Performance Prediction 137Network Event Performance 163Network Segment Performance 164Relationship Management 165Server Performance Prediction 116Service Level Management 165

Tivoli Distributed Monitoring 7, 60, 61, 95Tivoli Distributed Monitoring object relationships 92Tivoli Enterprise Console 7, 60, 95Tivoli Enterprise Environment 60Tivoli Enterprise solution 7Tivoli Implementation Methodology 23, 185Tivoli infrastructure 75Tivoli Inventory 7, 60Tivoli Management Agents 61Tivoli Management Server 61Tivoli NetView 60, 95Tivoli Servers 74Tivoli Service Desk 7, 72Tivoli Software Distribution 60Tivoli System Administrators 45Tivoli Tier 1 Servers 77Tivoli Tier 2 Servers 77TMR 74, 77top level policy region 160topic 62Topic definition 18Topic Map 168Topic Map definition 19Tourists 21


Trainer 46Training plan 46transactional data 6Transformer 16Transmission 96trends 12Troubleshooting TDS 81Tucson 94Typical Architecture 35

Uunder provisioned 124, 174UNIX commands

df 95, 102lsps 95, 100netstat 95ps 95, 100vmstat 95, 99

user permissions 45user-friendly 21

Vversion 42View definition 19view hint description 62, 69viewing Crystal reports 69viewing multidimensional reports 68views 13vision 3

WWAN 80Web Administrator 46Web Preparation 96what if questions 1Windows 95 15Windows NT 4.0 15Windows NT performance 104workload 63workload characteristics 171Workload Characterization 113Workshop summary 46Workshops 46

YYear 2000 189

ZZperstat 96

207



ITSO redbook evaluation

A Design and Implementation Guide for Tivoli Decision SupportSG24-5499-00

Your feedback is very important to help us maintain the quality of ITSO redbooks. Please complete thisquestionnaire and return it using one of the following methods:

• Use the online evaluation form found at http://www.redbooks.ibm.com/• Fax this form to: USA International Access Code + 1 914 432 8264• Send your comments in an Internet note to [email protected]

Which of the following best describes you?_ Customer _ Business Partner _ Solution Developer _ IBM employee_ None of the above

Please rate your overall satisfaction with this book using the scale:(1 = very good, 2 = good, 3 = average, 4 = poor, 5 = very poor)

Overall Satisfaction __________

Please answer the following questions:

Was this redbook published in time for your needs? Yes___ No___

If no, please explain:

What other redbooks would you like to see published?

Comments/Suggestions: (THANK YOU FOR YOUR FEEDBACK!)

Printed in the U.S.A.

SG24-5499-00

AD

esignand

Implem

entationG

uide

forT

ivoliDecision

Support

SG

24-5499-00

Date post:	08-Jun-2015
Category:	Business
Upload:	banking-at-ho-chi-minh-city
View:	668 times
Download:	15 times