This document provides an overview and design guide for implementing Tivoli Decision Support (TDS). It describes the TDS product components, implementation modes, supported platforms, concepts and terminology. The document then discusses a methodology for a TDS implementation project including requirements gathering, systems analysis, project planning, deployment, testing and documentation phases. It also covers TDS architecture and design considerations such as integrating TDS with Tivoli applications, component integration, stand-alone vs. network options, and case studies. Finally, it includes a case study of a TDS implementation project at a customer site.
A design and implementation guide for tivoli decision support sg245499
1. A Design and Implementation Guide
for Tivoli Decision Support
Edson Manoel, Fernando Bergamo, Dave Hulse, Rakesh Parshotam
International Technical Support Organization
www.redbooks.ibm.com
SG24-5499-00
16. He is currently working on deploying Tivoli enterprise solutions for several
IBM customers in Brazil.
Dave Hulse is an Advisory IT Specialist working at IBM Global Services
Johannesburg, South Africa. He has over 20 years of experience in the IT
industry. He has been with IBM for 18 months and, during that time, was
project leader responsible for the design and deployment of the largest Tivoli
implementation in Southern Africa. His areas of expertise include designing
customer IT solutions, and he has extensive experience in the field of
systems management.
Rakesh Parshotam is an Advisory IT Specialist working as a Tivoli Architect
at IBM Global Services in South Africa. He holds a degree in Computer
Science and is a Certified Tivoli Consultant and Microsoft Certified Systems
Engineer. He has been working with Tivoli for the past three years and has
held various positions including Technical Team Leader for major Tivoli
systems management deployment projects in South Africa.
The team would like to express special thanks to Ling Tai, Senior Software
Engineer working for Tivoli in Raleigh, for her major contribution to this book.
Thanks also go to the following people for their invaluable contributions to this
project:
Kim Querner
Tivoli Systems, Austin
Bill Meloling
Tivoli Systems, Raleigh
Lisa Chaves, Axel Elfner
IBM, Tucson
Shawn Eldridge, Douglas Fuzie
Tivoli Systems, Indianapolis
Temi Rose
International Technical Support Organization, Austin Center
Milos Radosavljevic
International Technical Support Organization, Austin Center
xiv A Design and Implementation Guide for TDS
17. Comments welcome
Your comments are important to us!
We want our redbooks to be as helpful as possible. Send us your comments
about this or other redbooks in one of the following ways:
• Fax the evaluation form found in “ITSO redbook evaluation” on page 209
to 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 redbook@us.ibm.com
xv
20. across the entire enterprise as e-Business spawns more and more devices
that are connected to it.
A few years ago, it was sufficient for service providers (IT Departments) to
manage and plan business operations using monthly batch reports. Changes
in the organizations took a long time to be implemented. After that, with the
implementation of some management tools, we were able to execute queries
from the historical operational data in order to get reports or charts that only
allowed us to be reactive to problems.
Today, enterprises need to provide decision makers with fast and easy access
to information that reflects the constant changes in the environment. Decision
makers and customers need to have access to tools that provide them with
the ability to identify trends and model relationships in the data to find
behavioral anomalies in the business environments.
Exception and
Predictive
Management
Based on SLA
IT Investments
o n Proactive
cti Inter
t i sfa Management
Sa Platform
er
m
sto
Cu
Managed
Environment
Monitoring &
Defined
Process
Reactive
Few Defined
Process
Fire Fighting
No Tools
No Process
Business Drivers
Figure 1. The evolution to business intelligence
Large amounts of data are stored in your enterprise. This data contains
precious information about the way the enterprise does business, its process,
and customers. In these competitive days, using the knowledge provided by
2 A Design and Implementation Guide for TDS
21. this data in order to make strategic business decisions can often move the
enterprise ahead of the competition.
Business intelligence is what we are describing in this section; It is the ability
to be proactive to problems, leverage the assets in our business to gain profit
from available data, and provide the know-how needed to make well-informed
decisions for our business.
As e-business drives the need for more network devices, we will need
technologies that enable us to manage resources across the entire
enterprise, end-to-end, not only by exception but by predictive analysis as
well. 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 on
the state and function of individually managed elements or groups of similar
devices. However, these tools, with their incompatible and independent data,
do little to help those who must manage based on a broader vision of the
business and its supporting services, a capability that is now essential in
enterprise distributed systems management.
The challenge is to view systems and network management from the
perspective of the business as a whole. End-to-end service delivery and
reporting has become the model for distributed management. This model is
commonly called service management or service level agreement
management. The question facing IT managers is whether there are tools and
products that are up to the challenge.
The greatest obstacle to full end-to-end service level agreement management
is not the lack of but the abundance of management tools. If you think of your
own organization, there are probably numerous tools for managing the
enterprise. Some are vendor-specific, and others are produced in-house,
each defining its own standard for data formats and reporting. Every tool has
been optimized to address a specific or limited set of management functions.
Introduction 3
22. Multiple Management
Functions
Monitor A
Monitor B Transforming
the Data ......
.
. ... into Business Information
. Standard Format
.
Monitor Z
Figure 2. The challenge of a better solution for business information.
As shown in Figure 2, the challenge is to find a complete solution that
provides an integrated framework or platform offering multiple management
functions across multiple vendor applications, services, or devices across the
entire enterprise collecting the data and storing it in a standard format that
can 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 both
research and in many different applications, but it has not yet been uniquely
defined.
In order to avoid possible misunderstandings, it is necessary to present the
basic characteristics of the class of DSS we will define. Let us start with a
brief discussion of the environment in which a DSS will be used. The key
person in this consideration is an individual who uses a DSS in real life
situations. By convention, such a person is called a Decision Maker (DM). By
this term, we mean both a person who makes real decisions (depending on
4 A Design and Implementation Guide for TDS
23. an application, this person may be a manager, engineer, or operator) and an
expert who may that person’s supervisor. Decisions are made within a
Decision Making Process (DMP), which, in situations that justify the use of a
DSS, is a complex sequence of tasks. We assume that a final decision is to
be made by the Decision Maker, and a Decision Support System does not
serve as a replacement or control of a DM. In other words, a DSS is not
aimed 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 may
obtain, from the DSS, information and answers for questions that she or
he 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 can
be used to stimulate the DM’s thoughts about the problems.
The following DSS definition is the one that can better explain the class of
DSS we will work with:
DSS DSS is a supportive tool for the management and processing of
large amounts of information and logical relations that helps a DM
extend his or her habitual domain and, thus, helps him or her
reach a better decision. In other words, a DSS can be considered
a tool that, when under the full control of a DM, performs the
difficult tasks of data processing and provides relevant information
that 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 possible
environment for facilitating the Decision Making Process and helps you to be
pro-active, planning future changes and determining their impact on the
organization.
The better the measurements and feedback regarding business processes,
the better a decision maker can adjust for changes and maximize the results
in the decision making process. In addition, when decisions are not made in a
Introduction 5
24. timely manner, windows of opportunity can close, and business is usually not
done.
Tivoli Decision Support as a technology is best known for dynamically
providing the decision maker with interactive business indicators and then
allowing the user to look at those indicators from many different perspectives.
For example, let us suppose that a product manager wants to know how well
the product is being supported in South America this month and compare the
rates with the same month the previous year. Once she or he views the
high-level report, she or he may drill into the region to only look at how Brazil
is doing. Moreover, she or he may drill into the southeast region and look at
how a particular city is doing. This technology is called On-line Analytical
Processing (OLAP) or multidimensional analysis.
In addition, Tivoli Decision Support allows us to benefit from information
collected by the customer’s Tivoli solution. For example, the support centers
collect a large quantity of transactional data from their customers, which
contains valuable information about the way they interact with the business.
With Tivoli Decision Support, Decision Makers have a way to manage this
data and convert it into useful information providing a way to evaluate and
identify trends, to gain insight into the way customers do business, and to
make better decisions.
Tivoli
Applications
Decision
RDBMS
Data processing and
Management of logical
relationship
Tivoli
Decision
Support
Decision Maker
Accessing business
relevant information
Figure 3. TDS in the decision making process
6 A Design and Implementation Guide for TDS
25. As shown in Figure 3 on page 6, Tivoli Management Applications, such as
Enterprise Console, Service Desk, Inventory, Distributed Monitoring, and so
on collect the data and store it in databases. Tivoli Decision Support selects
management data from these databases, performs calculations, and adds
value to the data by managing the natural relationship in the data. At this
point, only business relevant information is offered to the Decision Maker who
is in charge of the decision.
With Tivoli Decision Support, Tivoli Enterprise solution has moved a step
forward to reach the desired solution for Business Decision Information
providing 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 proactive
planning
• 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 following
chapters:
• Chapter 2, “Tivoli Decision Support general overview” on page 9
This chapter provides information about the product describing the
concepts and terminology used by Tivoli Decision Support. In addition, we
provide 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 basic
information about the methodology used to plan, deploy, and migrate to
Tivoli Decision Support:
• Requirement Gathering phase
• Systems Analysis phase
• Project Planning phase
Introduction 7
26. • 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 Tivoli
Decision 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 studies
environments
• Troubleshooting tips
Chapter 5, “Case study” on page 85
This chapter exercises the knowledge acquired from the previous
chapters performing an example by exploring one of the IBM Service
Delivery Centers as a customer presenting a structured Tivoli Decision
Support deployment solution.
Chapter 6, “Reports and decision information usage” on page 167
This chapter demonstrates how Tivoli Decision Support can support
the decision making process by describing a simple scenario and
outlining the steps used to find and analyze critical data in order to
make a well-informed decision.
8 A Design and Implementation Guide for TDS
28. collected can be shared with others in the organization using delivery
mechanisms including hard copy printouts, files, and push content. In the
latter case, content that has been collected by one user can be sent to a
central repository on a company’s intranet from which other users can gain
access 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 for
using the TDS Discovery Guides. The base product is composed of the
following components:
• Discovery Administrator
• TDS Server component
• Discovery Interface
• Cognos PowerPlay
• Crystal Reports
The TDS Discovery Guides are software add-on modules that put the
application of TDS in context. For example, the Call Center Management
Guide deals with issues related to the decision making process associated
with support requests, resolution rates, and so on.
Figure 4 on page 11 shows the relationship between the Tivoli Decision
Support Base Product and Tivoli Decision Support Discovery Guides.
10 A Design and Implementation Guide for TDS
29. Tivoli Decision Support Discovery Guides:
Ready-to-use Solutions
Figure 4. Tivoli Decision Support components
The following sections are dedicated to explaining each of the Tivoli Decision
Support components. For further information, refer to the product
documentation.
2.2.1 Tivoli Decision Support Discovery Administrator
The Discovery Administrator helps you ensure that Tivoli Decision Support
functions 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 gather
and maintain all data used by Tivoli Decision Support. The Discovery
Administrator can be customized to automatically gather the data, which is
stored in special files (it populates these special files with current data
from your organization’s databases) at pre defined intervals or it can
enable you to perform such operations manually.
• It provides specific parameters you can set when building or customizing
cubes. These parameters affect the operation of specific cubes and
enable you to customize the behavior of views in the Discovery Interface.
Tivoli Decision Support general overview 11
30. • It enables you to set parameters that are specific to your enterprise’s
operation. These parameters, such as severity level thresholds and
business hours, determine how Tivoli Decision Support interprets data
and makes calculations when generating views.
2.2.2 Tivoli Decision Support Server component
The TDS Server component, best known as TDS File Server, acts as a
repository for TDS. This component contains TDS related models, queries,
templates, and other information required to generate views for the Discovery
Interface.
2.2.3 Tivoli Decision Support Discovery Interface
The Discovery Interface is the client component of TDS. This is the interface
to Decision Support. It provides all the tools needed to open and work with
views of data from your organization’s enterprise databases.
2.2.4 Cognos PowerPlay
Cognos PowerPlay is a third-party application from Cognos Inc. It is a
multi-dimensional analysis and reporting tool that is included in Tivoli
Decision Support. Cognos PowerPlay can generate customized views based
on queries to the databases in your enterprise. It can also display views in a
variety of graphical styles including bar, line, and pie charts.
Using the tools provided by Tivoli Discovery Interface and PowerPlay, you can
turn low-level detailed data into useful business knowledge. After a view is
opened in PowerPlay format, you can analyze many dimensions of the data to
determine relationships, trends, effects, and so on. PowerPlay also gives you
the option of further accessing view details so that you can break out and
analyze the data behind it.
2.2.5 Crystal Reports
Crystal Reports is a third-party reporting application from Seagate Software
Inc. This application generates text-based views from standard database
queries. Tivoli Decision Support uses many views in Crystal Reports format
in the TDS Discovery Guides.
2.2.6 Tivoli Decision Support Discovery Guides
A Tivoli Decision Support Discovery Guide is a TDS module that groups
enterprise data into specialized categories. Each category contains a series
of topics that correspond to the different aspects of that category. Each topic
12 A Design and Implementation Guide for TDS
31. contains a number of views that are associated with the data elements being
examined.
Tivoli Decision Support uses the Discovery Guides to aid in discovering key
information. With this information, Tivoli Decision Support becomes a
powerful end-user solution. This solution provides users with a
comprehensive set of views into their enterprise’s data. Along with the views
are methods (including algorithms, queries, and reports) for abstracting key
business indicators from the business data. Managers can use these
indicators as key business information to improve efficiency, performance,
and profitability.
TDS includes several Discovery Guides. Other Guides are available as
additional options. Appendix C, “Tivoli Decision Support Discovery Guides
availability” on page 189, offers a complete list of the Tivoli Decision Support
Discovery Guides including those that are shipped with TDS Version 2.0.
TDS Discovery Guides contain algorithms, queries, reports, views, and
business models that best represent a business concept. Guides can be very
robust and contain several hundred views and multiple business models.
Along with the views, guides have embedded contextual information
associated with views. The context helps users identify, discover, and
understand what the view has to offer. For example, as the user views and
interprets data in Tivoli Decision Support, the Tivoli Discovery Interface
provides 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 Decision
Support guides. By selecting guides in the Discovery Interface, managers can
define the scope of their data searches to yield the most relevant results for
their needs. A call center manager, for instance, may want to see only data
that pertains to his or her area of the business. He or she may not need to
review data that another department manager needs to review. It is only
necessary to activate all relevant TDS Discovery Guides and turn off all other
guides. The views shown in the Tivoli Discovery Interface topic map are only
those associated with the Call Center Management Discovery Guide.
Managers can select as many Guides as they want to expand the scope of
their data search, for instance, if the call center manager wants to review not
only relevant call center data, but also data collected about the health of his
or her business’ contacts. The call center manager selects the Call Center
Management Discovery guide as well as the Relationship Management
Discovery Guide. Now, the views available to the call center manager in the
Tivoli Decision Support general overview 13
32. topic map are a combination of the two guides he or she selected. The call
center 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 Network
mode.
• Stand-alone mode
All the TDS components are installed and run on one machine. The stand
alone machine also requires the installation of the database client
software and the ODBC driver in order to have access to the databases
from which one or more cubes are built. This database connection also
allows report generation by running database queries against the
individual databases.
Figure 5 shows an example of a Tivoli Decision Support implementation in
stand alone mode:
INVENTORY
ODBC Connection
DM
TEC
Machine running TDS DATABASES
in stand alone mode
Figure 5. Tivoli Decision Support in stand alone implementation mode
• Network mode
Only TDS Discovery Interface and Cognos PowerPlay are installed on the
client machine. In addition, the client requires the installation of both the
Client Database and the ODBC Driver, in order to have access to the data
stored in the database server, when generating Crystal reports. The TDS
Version 2.0 installation CD contains the Intersolv 3.01 32-bit ODBC Driver
for Oracle and Sybase.
The TDS Server component is installed on a file server which the client
machines have access to a shared drive that will contain all the cubes
generated.
A separate machine is used as the administrator system where the
Discovery Administrator module is installed along with PowerPlay. The
14 A Design and Implementation Guide for TDS
33. Administrator system should access the shared drive in the TDS File
Server. In addition, it also requires the database client and the ODBC
driver in order to have a connection to the database from which the cubes
are built. The cube files created by the Discovery Administrator are stored
on the TDS File server.
The diagram in Figure 6 on page 15 shows an example of a Tivoli Decision
Support in the network mode:
stores
the Cubes
access access
TDS File Server
the Cubes the Cubes
builds
the Cubes
TDS Discovery TDS Discovery
Interface Interface
TDS Discovery
Administrator
ODBC
connection
Crystal Reports Crystal Reports
Database Server
Figure 6. Tivoli Decision Support network implementation mode
2.4 Supported platforms
The following software platforms are supported by Tivoli Decision Support
Version 2.0:
Operating Systems:
• Windows NT 4.0
• Windows 95
Tivoli Decision Support general overview 15
34. Database Management Systems:
• Oracle
• Sybase
• SQL Server
• Informix
• DB2
2.5 Concepts and terminology
This section provides some important Tivoli Decision Support concepts and
terminology.
Category
A Category is a major division of data in the Tivoli Decision Support topic
map. The enterprise data is grouped according to concepts, such as
productivity or interaction trends. Within a Category, the user can find more
specifically-related types of data. See also Topic and View.
Cubes
A cube is a data container used by PowerPlay. PowerPlay is a
multi-dimensional reporting and analysis tool packaged with Tivoli Decision
Support.
As opposed to a flat two-dimensional table of rows and columns, a
multi-dimensional array can be visualized as a cube with many sides, with
each dimension forming a side. The cube is arranged so that every data item
is located and accessed based on the intersection of the dimension members
that define it.
Cubes are built by the TDS Discovery Administrator, which runs a query
against the database and executes the Cognos Transformer. Cognos
Transformer is a component of Cognos PowerPlay. The function of the
Cognos transformer is to input the queries and summarize the data (by
counting, averaging, calculating percentage, and so on) and pack this
information into a compressed cube file (*.MDC). The TDS Discovery
Interface executes PowerPlay reports that look at these cube files for
historical data rather than live data.
16 A Design and Implementation Guide for TDS
35. Dimensions
A dimension refers to a broad grouping of descriptive data about an aspect of
a business, such as software products and dates. Each dimension includes
categories in one or more drill-down paths and an optional set of special
categories. See also drill-up and drill-down.
Dimension line
The dimension line shows the dimensions in the cube and the categories
within each dimension currently being examined.
Drill-up and Drill-down
Drill-up refers to looking at data in a progressively more general way whereas
drill-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 the
lower level of consolidated data, drill-through goes one step further by looking
at the actual data records themselves. For example, if the breakup of the
types of problems resolved by a particular analyst is the lowest level of
consolidation, drill-through looks at the actual records that correspond to the
problem descriptions themselves.
Filter
A filter is a means of ensuring that a data search yields the most relevant
results. In Tivoli Decision Support, the user can specify data selection
criteria, such as data ranges or severity levels, that restrict the data search
and 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 another
dimension to provide a new perspective on your views. A view can contain
several layers, but you can look at only one at a time.
Measures
Measures refer to indicators you use to gauge the performance of your
organization. For example, measures can be the number of problem requests
received and the average time taken to resolve a problem.
Tivoli Decision Support general overview 17
36. Models
A model contains definitions of queries, dimensions, and measures as well as
objects for one or more cubes that Cognos Transformer creates via the TDS
Discovery Administrator for viewing and reporting in PowerPlay.
Profile
A profile is a feature in the Discovery Interface that enables each user to
configure settings and views that pertain only to him or her. The Discovery
Interface can contain several profiles.
Related view
A related view is a view that is different from the current view but may contain
additional relevant data. Tivoli Decision Support automatically suggests views
that are related to the current view. These additional views are listed in the
Related Views tab in the hint pane.
Role
A role is a user-selected description that describes the user’s position in all
areas of the business. A user can select one or more roles based on the
scope of his or her position. By specifying one or more roles, the user
establishes the scope of the information contained on the topic map. The
more roles are specified, the greater the scope of the data searches
displayed on the topic map.
Selection criteria
Selection criteria are the parameters specified by the user when conducting a
data search. Selection criteria act as filters ensuring that only relevant data is
yielded by a data search. See also Filter.
Slicing and Dicing
Slicing and Dicing refers to the process of extracting information for viewing
from the cube file by selecting different dimensions. This process can be
thought of as constructing a multi-dimensional space by using the selected
dimensions for its constituent axes or as looking at the same data from a
variety 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
18 A Design and Implementation Guide for TDS
37. topics. Within each topic, the user can choose an individual type of data for
viewing. 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 view
pane. See also View.
View
A view is the most detailed type of question in the topic map. A view provides
the user with an outlook of the data stored in the cube file or the data
retrieved from a special database query.
2.6 How Tivoli Decision Support works
The Tivoli Discovery Administrator module, which is installed on your system
if you run in stand-alone mode or on the system administrator’s system if you
run in network mode, connects to your enterprise’s databases. When you
issue a request for information in the Tivoli Discovery Interface, Tivoli
Decision Support either reads the information from the database directly (if
the report requested is a Crystal report) or reads the cube file created by the
Tivoli Discovery Administrator (if the report requested is a multi-dimensional
report). The cube is summarized data that is read from the database when
the cube is built by the Tivoli Discovery Administrator. The information is then
returned to the Discovery Interface and presented to you.
Tivoli Decision Support general overview 19
38. TDS Discovery
Administrator
Cubes
Multi-dimensional Reports
Enterprise
Databases
TDS Discovery Interface
Crystal Reports
Figure 7. The operation of Tivoli Decision Support
Because of its integration with PowerPlay and Crystal Reports, Tivoli
Decision Support provides snapshot-style views of data that are displayed in
the Discovery Interface. The data can be viewed in one of several formats: as
text, a bar chart, a line chart, or some other graphical format. The default
format depends on the type of data you are viewing, but you can select
different 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 your
search for data. For example, you can use bookmarks to collect your favorite
views; so, they are instantly available. Instead of manually browsing for data,
you can use the Search tool to find information based on keywords. The
20 A Design and Implementation Guide for TDS
39. 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 of
needs unique to the group:
• Explorers use existing Tivoli Decision Support metrics and reports as a
stepping stone to discover additional trends and views. After they notice a
trend in the data, they investigate why the trends occur. Most
organizations have a limited number of employees devoted to the task of
exploring, but they are typically required to continually research the
effectiveness of their organization. The information they gather is funneled
to other employees in the organization.
• Tourists want to explore, but they do not want to go into areas that are
dead ends or areas that do not quickly meet their needs. Typically, tourists
want as much freedom as possible to follow their touring needs as long as
each step meets their needs. They spend time looking for data, but they
want a high success rate in finding what they want when they want it.
There are usually more tourists in an organization than there are
explorers.
• One-minute managers do not want to spend their time exploring. They
want to continually review a set of views that allow them to know what they
need to know. One-minute managers need a fixed set of views they can
reference, and they want views customized to their specific needs. For
example, analysts may only want to look at their open calls. This view can
be set in the Discovery Interface; so, it is readily accessible to the
One-minute manager.
Tivoli Decision Support satisfies the needs of different types of users with
an environment that is highly-customizable.
The customizable nature of Tivoli Decision Support lends itself well to
explorers who are continually viewing the enterprise’s data sources to
discover trends and views.
Tourists also benefit from the customizable features of Tivoli Decision
Support, which enable them to expand or limit the number of
pre-packaged views. Finally, One-minute managers appreciate the
user-friendly Discovery Interface, which assists them in locating the view
or sets of views they want to reference. Also, Tivoli Decision Support’s
Tivoli Decision Support general overview 21
40. push-delivery feature enables all users to receive updated views but is
particularly helpful to the One-minute manager.
22 A Design and Implementation Guide for TDS
42. refined by Tivoli Professional Services and selected Business Partners. TIM
is organized according to the Software Engineering Life Cycle model. This
model addresses each element that is critical to the implementation of any
software development activity. In Figure 8, a schematic overview of TIM is
given.
Figure 8. TIM schematic overview
TIM provides standard verified methods for use by project managers and
Tivoli-certified consultants to execute each phase of a Tivoli implementation.
With this common deployment strategy, Tivoli and Tivoli’s business partners
can provide:
• Accurate and complete requirements definitions for Tivoli solutions
24 A Design and Implementation Guide for TDS
43. • Efficient requirements analysis to generate an architecture and design for
a solution
• Complete project planning and detailed design for a solution
• Accelerated deployment of Tivoli solutions
• Detailed solution verification that lends itself to customer regression test
activities
• Completed solution documentation that can be used by the customer,
consultants, Tivoli support staff, and Tivoli development to ensure the
long-term success of that solution
To find information on TIM, refer to the instructions in Appendix A, “Tivoli
Implementation 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 in
line with TIM, we will follow the process flow defined in the TIM methodology
to detail each phase of the TDS implementation. Since our main focus in this
chapter is the implementation, the methodology detailed below will only
highlight those procedures that are significant to TDS. It is assumed that TDS
has already been identified as the solution that the customer requires; so, we
will not go into detail about the pre-sales and best-fit Tivoli product analysis
exercises, which are part of the Sales Engagement phase.
3.2.1 Requirements gathering phase
Requirements gathering, as it relates to Tivoli Decision Support, is a
systematic process of identifying a customer's reporting requirements in
order for us to deliver a well-thought-out implementation of Tivoli’s
decision-making software. With the aid of detailed questionnaires, the
consultant services organization works with the customer to identify complete
and accurate requirements for their reporting solution. This activity also helps
the customer establish the proper expectations of the breadth and scope of
the TDS solution.
In order to deliver a definitive TDS requirements document, we will tailor this
requirements gathering phase to provide only the information necessary to
define the scope, architecture, and estimated hours that will be required to
implement the customer’s TDS solution. The objective of this segment is,
therefore, to gather requirements that enable the following:
Methodology 25
44. • A system architect to analyze the information and successfully create a
System Architecture and Design document
• The consultant, business operations, project management, sales team,
and the deployment team to work together, led by business operations, to
develop 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 of
the requirements-gathering phase:
Table 1. Requirements gathering phase items
Requirements gathering phase
Input Initial customer requirements questionnaire
Output Tivoli decision support requirements questionnaires
Figure 9 outlines the process flow of the requirements-gathering phase:
Requirements Gathering Flow
Customer TDS
Requirements Requirements
INPUT Questionaire Questionaire OUTPUT
Figure 9. Requirements gathering process flow
We will now take a look at the questionnaires shown in Figure 9.
3.2.1.1 Questionnaires
Questionnaires serve as the main tool for gathering a detailed description and
logical picture of the customer’s environment. It is a tool that portrays the
customer’s environment and high-level goals for reporting on his or her IT
environment.
Gathering the customer-specific TDS requirements is the focal point of this
exercise and will be investigated shortly. First, however, we must take a look
at the systems management requirements of the customer in the form of the
Customer Requirements Questionnaire.
26 A Design and Implementation Guide for TDS
45. 3.2.1.2 Initial customer requirements questionnaire
The information gathered in this report serves as the single input element of
the implementation solution. Our aim is to process this information and
produce other questionnaires and reports that will serve as inputs to the
subsequent phases of the implementation cycle.
In this questionnaire, many business-specific questions are answered. The
most important and valuable pieces of information gathered would be the
customer reporting goals and issues. For example, the answers to the
following 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 reporting
solution components that are significant to the customer’s business. He or
she can now focus on the implementation of the product functions of Tivoli
Decision Support and gather all the necessary TDS requirements.
3.2.1.3 Tivoli Decision Support requirements questionnaire
Having manipulated the information received above, we are now ready to
draw up a questionnaire to extract the TDS product-specific information. The
TDS provider will set up an interview with the customer requesting the
relevant 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 clearly
distinguished; furthermore, a set of suggested questions for the questionnaire
will be proposed.
1. Decision-making/reporting requirements overview:
• Purpose
It is during this step that Tivoli personnel acquire their initial information
on the customer’s reporting requirements. It is assumed that the
customer has an amateur solution in place and intends to migrate to
Tivoli Decision Support. The customer will be questioned on his or her
current reporting activities, and a document detailing his or her
requirements will be drawn up.
• Required information
Details of what the customer expects from the Tivoli Decision Support
solution, current process, procedure, service levels, reports, and any
Methodology 27