System architecture and design document

The objectives of this process are to design and document the physical and logical 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).

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

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

The TDS architecture

Chapter 4, “TDS architecture and design considerations” on page 59 is dedicated to designing solutions and focuses a great deal on various architecture considerations. For this reason, we will not go into too much detail here on the TDS physical design. This architecture section will introduce some TDS architecture concerns and present to the reader a standard design on which the customer’s solution should be based.

The foundation of the physical design depends on the customer requirements and the answers to the questionnaires presented to the customer in Section 3.2.1, “Requirements gathering phase” on page 25. The analysts will need to study the customer’s environment and business with the intention of

identifying suitable TDS hardware components and personnel resources.

They will then need to bring these two resources together and apply a process to deliver a suitable architecture. Insights into some of the thought processes 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 a typical TDS implementation in Network Mode. In Network Mode, only

Decision Support’s client component and PowerPlay are installed on the client machine. The other components are installed elsewhere. The user of the client system only has access to the Discovery Interface. You must administer Decision Support for all clients from the system administrator’s system.

Figure 11. Typical architecture

As mentioned before, Chapter 4, “TDS architecture and design

considerations” on page 59, will go into the details of the physical and logical design considerations of a TDS implementation.

Resource availability

Early in the process of developing a system architecture and design, a rough determination as to what hardware might be required for deployment is made.

It is important to generate this information as soon as possible so that hardware can be procured and made available as soon as hands-on deployment work begins.

The system requirements for Tivoli Decision Support may vary greatly and will depend on many environmental factors. For the purpose of simplifying this exercise, we will assume that a networked topology of clients fed by a file server will be the standard workgroup configuration. With that in mind, cube build 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 running

• Performance of the File Server

• Performance of the processor that builds the cubes

The Tivoli Decision Support Installation Guide, GC32-0289, lists the operating system and suggested hardware requirements for each Decision Support component. It differentiates between two classes of machines: a low-end and a high-end machine for each component. Although this serves as a good base, it is often not easy to rank the type of environment that you are 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 product line. This table provides you with an easier method of deciding on the configuration 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 of contacts, 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 a survey sheet that should be filled in by the customer with help from the systems analysts. The survey should be structured in such a way that

Size of Center Client PC Requirements

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

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

File server information

This is the repository for TDS and contains the TDS models, templates, queries, and other information required to generate views for the Discovery Interface. It is necessary for this to be reasonably fast to service the files.

Every client machine will connect to this server and, thus, the network connection must be reasonably fast. These factors need to be investigated at this point. Figure 12 shows an example file server information form:

Figure 12. File server information example form

TDS Administrator PC information

This component provides functions for TDS configuration and administration, for example, setting system parameters that control the behavior of TDS. This machine requires a fast hard drive and fast network access to the database server. Figure 13 on page 38 shows an example TDS administrator PC information 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 to the TDS file service/directory?

Example Form

Figure 13. TDS administrator PC information example form

TDS Client PC information

ODBC connection to the database server, sufficient disk space, and shared access to the file server are some of the main criteria that need to be looked at in this step. Figure 14 shows an example TDS client PC information form:

Figure 14. TDS client PC information example form

Database server information

Identify the machine that will host and the type of RDBMS that will retain the respective configuration repositories. The following information is required to set 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 other applications? 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 do with the data collected in the configuration repositories; this information will assist 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 information

Since TDS is comprised of three directly-related components functioning on different machines on the network, it is important that all network shortfalls be identified. 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 it is 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 the database remains in use while the data is backed up. Cold refers to logging off 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 Tivoli Decision Support multidimensional view is open. Cube builds should be done during business off-hours.

Note

Figure 16. Network information example form