Newsletters

The data used in capacity and performance analysis can be obtained from a wide range of different places. Systems level data, for example, might include statistics such as percentage utilization. Application-level data can be pulled from Oracle databases. Business data, too, can be harnessed. This can include such data as the number of sales orders, the number of lines per order, total revenues, etc. It is vital that such data be integrated with other IT data sources.

Business data should be better organized for a number of reasons. Alignment is the primary factor - integrated data helps IT and business move in the same direction, thereby strengthening the overall strategic focus. Further, such an alignment is seen by many senior managers as the "holy grail" of IT Service Management (ITSM).

Think about it. You don’t hear managers preaching about the importance of "marketing and business alignment," nor do you hear much about "finance and business alignment." It’s always IT, and the reason is simple - managers intuitively realize that IT is one of the best ways to improve business profitability.

To make such an alignment happen, though, IT has to be the driver. It is a lot easier, after all, for IT to learn about the business, than for line of business units to master the intricacies of IT. But whoever is the instigator, the results are savings through raised efficiency and greater value through innovation. And the benefits can be significant. Decision making, for instance, can be bolstered by the achievement of stronger alignment. This helps in understanding the level of criticality of different actions and processes, by exposing dependencies and by increasing awareness of the true business value of the various aspects of operations.

Further, it is smart to have technical staff understand as much as possible about the business value of the applications they run. By marrying technical and business efforts, both sides are empowered to create greater value for the enterprise.

Demand Management
Demand Management is about optimizing the usage of different resources by modifying schedules and workloads in order to distribute the load more evenly. However, this process has to be carried out in tight cooperation with the users of the services. Otherwise disruption may occur in tandem with a whole lot of complaints to the help desk.

For best results, input should be obtained from several different sources prior to commencing the Demand Management process. Find out from the various departments that will be impacted, for instance, how the different workloads contribute to the overall level of utilization. There may be nuances here that need to be thoroughly understood so that any changes produce the desired effect.

Another important factor during the planning stage of Demand Management is the influence of seasonality, as well as the cyclical nature of different events. Retail traffic, for example, has seasonal peaks. Financial applications, on the other hand, may well have monthly, quarterly and annual cycles that produce significant spikes in volume. And just as each industry has its own patterns, they also tend to have metrics and statistics that are of special importance. These will vary from operation to operation. Common ones include transactions completed, transaction time, number of concurrent users and service hours. It is up to the capacity planner to communicate to the line of business heads to ensure these are fully understood. Only then can truly accurate analysis take place.

User-Agents Offer a World of Possibilities
There are many possible ways to facilitate closer alignment of IT with the business. It all begins with data collection. This must encompass historical statistics from both the business and IT sides. Probably the best way to achieve this is by using agents.

There are several different kinds of agents. There are platform agents such as those that deal with Sun, IBM, HP, Microsoft, SUSE and Red Hat. There are application agents specific to Oracle, SAP, Sybase, DB2, Exchange, IIS, SQL Server and BEA. And there are user agents.

User agents fall into three broad categories: general log agents, user table agents and user parameter agents. The TeamQuest Performance Software Suite contains all three types. It is a simple matter to activate them in the application.

A general log agent collects log messages from various applications using mainly ASCII-text log files. Updates are carried out automatically. Such data is suitable mainly for alarming. It is possible, for example, to set up alarms based on key words contained in logs.

A user table agent is extremely versatile and is probably the most heavily used type. It requires that a table is created using a script. They can contain any number or combinations of textual and numeric fields. They are also suitable for alarming as well as tabular reports. Note that in TeamQuest Release 9, only tables could be created with user table agents. Release 10 provides the added capability to make charts using this table data.

A user parameter agent holds date, time, resource and any number of other numeric values. Such agents are suitable for reports, charts and alarming. TeamQuest Manager facilitates the creation of user parameter agents. These are often done using Perl or other scripts.

Making Use of the Data
User agents can be harnessed for a variety of purposes. Alarming, reporting, automatic correlation resources and capturing TeamQuest IT Resources are just a few of the possibilities.

Let’s take a look at a couple of examples of user agents in action.

The first example concerns the booking of sales orders. In this case, data is transferred from the clients to web-based servers running Apache, to application servers running BEA WebLogic, and finally to a database server running Oracle. In that database, vast quantities of data are stored that can be harnessed by user agents.

TeamQuest makes it easy to create and define user parameter agents to utilize such data. All you need to do is name the application, the system, the processes and specific statistics to capture. You simply draft up a database query to obtain hourly summaries as well as averages and other vital statistics.

TeamQuest IT Service Analyzer is then fed this data. This includes I/O and other stats from the Oracle server, workload and service activity on the application server, as well as the number of orders completed. The user agent, for example, gathers the number of orders completed per minute and the number of lines per order, as well as the value of orders. All of these statistics can be viewed on IT Service Analyzer. This enables the analyst to zero in on the peaks and troughs and to drill further into the data to determine the source of any ongoing issue.

The second example is about an enterprise application that is being licensed and used by multiple departments. A license server monitors license usage. Its log file is accessed by a TeamQuest user agent by writing a Perl script. This provides information in tabular form of the usage of each department and each section of the organization. In this case, user parameter agents are not a good fit as they can only deal with a specific range of parameters. As user table agents have no limitations on the number of parameters, they are used instead.

The table is defined using TeamQuest. Alarms are activated if too many licenses are active in any one department or organizational unit. In addition, derived table statistics and license breakdowns are available. TeamQuest software can take this raw data and apply calculations to it. By taking into account such factors as cost for labor, hardware and assets, power, cooling and software licenses, a chargeback report could be created, for example. This would list service charges by department based on their rates of license usage. As a bonus, Release 10 of TeamQuest also turns such data into charts and diagrams.

User Agents in the Real-World
TeamQuest user agents are used today in countless companies around the world. A large European financial services firm uses them in a highly complex enterprise environment with more than 20 trading workflows. In this organization, some workflows depend on dedicated services whereas other services are shared between workflows. This investment firm uses a Service Oriented Architecture framework.

To deal with massive fluctuations in trading volumes at a moment’s notice, the company has developed a conceptual architecture that breaks each workflow into five elements:

• Trading capture
• Trading systems
• Pricing
• Risk management
• Back office

Moving data is regarded as a major milestone. Within each of the five groups, data also moves through several minor milestones.

This investment bank designed a log-bus architecture to track each milestone and feed it into a Sybase RDBMS. By means of a delta engine to deal with time differences and a JMS provider to stream data to where it was needed, data is fed into TeamQuest.

First it goes through a JMS client and from there the user agents provide data to TeamQuest for analysis purposes. As TeamQuest is based upon snapshots, the JMS streaming data is converted into snapshots using log files. Every 10 seconds, a snapshot is taken. In particular, this company was interested in the maximum time taken for major and minor milestones.

In this case, the company needed to conduct in depth capacity planning to verify they could handle heavy traffic spikes based on anticipated growth rates and worse case trading scenarios. In addition, they wanted to be able to drill down into the data to find the source of performance bottlenecks so they could be eliminated before they impact users.

This TeamQuest functionality allowed this financial services giant to obtain the "complete picture" of its environment.