90 Using zEnterprise for Smart Analytics: Volume 1 Assessment
Whenever possible, verify actual results against projected results; that is, undertake the
classic “before and after” comparison. The goal is to show that the base capacity planning
(when from one z architecture-based server to another z architecture-based server) or a
specific consolidation sizing projection is allowing the system to run within the expected levels
of performance.
Tuning can also be part of the process. It targets the optimization of the system to enable it to
run as efficiently as possible. If tuning is required, it is helpful to modify only a single
parameter at a time. After the change, the consequences of this specific change need to be
evaluated. After the consequences of the first targeted individual tuning are fully understood
in terms of its impact to the system, then (and only then) you can move to change the next
parameter. Iterate until no more parameters are left to be changed. “Bulk” (simultaneous)
changes are not helpful because they do not enable you to understand the cause and effect
of these changes. Unraveling the interdependent effects of multiple changes can be difficult
and sometimes impossible.
The goal of understanding the “before and after” situations, whether by capacity planning (z to
z) or through sizing (consolidation or new workload), is to better understand the results,
validate the input, better forecast future growth, and create a larger database of real cases to
be fed back to development. This process enables each of us to participate in the
enhancement of existing tools and methodologies.
We have described many versions of sizing and capacity planning processes. Keep in mind
that from this point on, when we refer to sizing, that will be a reference to the process that
handles sizing of a new application. The sizing description that follows will be an
example of a
scenario, similar to the Banking Smart Analytics scenario we are implementing.
The example that follows is only to illustrate the process. The input numbers used and the
results produced do not map against the real implementation described in other chapters of
this book, nor in other related volumes.
10.5.4 Cognos 10 BI sizing for Linux on System z: Input
The process to size Cognos 10 BI for Linux on System z is well established. When targeting
the System z architecture, it is a two-step process that we explain later in this section. It is
recommended that you seek IBM’s support for help with these tasks.
The sizing guidelines are based on IBM internal testing and real-life experience. Successful
sizing guidelines are always developed in collaboration between a qualified client and IBM
Cognos representatives. By working together, we ensure the proper interpretation of the
information collected throughout the client interview process and the correct application of
Cognos 10 sizing methodology.
Sizing input data
You need to gather the following types of information to enable the Cognos 10 BI for Linux on
System z sizing:
򐂰 User roles
򐂰 User concurrency
򐂰 Use of portlets and Business Insight Consumer dashboards (BIC)
򐂰 Solution access patterns
򐂰 Application complexity
򐂰 Query complexity
򐂰 Output complexity
򐂰 Percentage of overall BI content for heterogeneous query
򐂰 Percentage of overall BI content for master/detail query
Chapter 10. Stage 6: Sizing and capacity planning 91
򐂰 Percentage of overall BI content using personal data merge
򐂰 Percentage of overall BI content Dimensionally Modeled Relational (DMR) data query
򐂰 Percentage of overall BI content for statistics
򐂰 Batch report processing requirements
򐂰 IBM Power Cube® building requirements
򐂰 Technology preference
򐂰 Deployment option
As you can see, there are many areas required to be part of the input to produce the proper
Cognos 10 BI sizing. Some of these entries are only the top header of many sub-items.
Describing all the entries here is beyond the scope of this book. However, we chose a few
areas to illustrate the level of the input requirement.
User roles
The idea behind asking the client to define user roles is to provide the required granularity to
enable you to differentiate ratings of concurrent users based on different user roles. Examples
of user roles are illustrated in Figure 10-7.
Figure 10-7 Types of Cognos 10 BI users
Application complexity
No two client applications are exactly alike. To produce a proper sizing, you have to provide a
simplified measure of projected or existing application complexity, described in a number of
areas. In each area, application complexity is expressed through four categories: simple,
intermediate, extended, and highly extended. Figure 10-8 on page 92 illustrates an example
of query complexity parameters.

Get Using zEnterprise for Smart Analytics: Volume 1 Assessment now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.