"We show you how to process the future".
 
BAN BOTTLENECKS
 


» Overview

 

Ban Bottlenecks

The Ban Bottlenecks Lifecycle

The majority of the work associated with our Ban Bottlenecks service occurs behind the scenes. As a result, many of our customers and prospects are unaware of the extent of the efforts and preparations we go through to make this service work so effectively. The following description summarizes how Transaction Design, Inc. (“TDI”) collects, manages, analyzes and communicates this critical information stream.

1. Before installing any software on your system, we hold a conference to learn about your system and your business. We will work with you to decide the best indicator(s) of the workload. For example, a "transaction" may be a batch transmission, a user session, an ATM/POS transaction, or some combination. Our standard procedures for common applications will analyze application logs to extract counts, response times, service levels, and completion codes. If your system does not run one of these commonly used applications, we will discuss custom enhancements to our tools that will result in data collection from your application. We never modify your application or the OS. We only read the important logs and transaction files produced by each. 

2. We or you load our software (the TDI Toolkit®) onto your system. Unlike many enterprise software packages, this step does not require that we go onsite. Normally, we’ll send you the software via email and show you how to install on your subject systems. It takes about 30 minutes.

3. We perform an initial audit of your system and allow our software to collect statistics for a couple of days. The TDI Toolkit requires negligible CPU cycles. We strictly adhere to the rule “Don't become part of the problem!”  We provide reports on how much resource our tools are consuming. The TDI Toolkit will require some disk space, depending on your configuration. We maintain 35 days of logs on your system, and 25 months of data on ours. 

4. After this “break-in period,” we’ll send you a preliminary report that summarizes the findings of our initial system audit and the results of our first few days of operation. If there is something seriously wrong with your system, this is the point at which we'll start evaluating it. This preliminary set of reports also provides you with an introduction to our reporting format and an introduction to our support team here as well. We usually set up a web conference to review the reports and propose tuning changes or other action items we’d like to see you undertake. We’re careful not to inundate you with suggestions at this point. We focus on an iterative approach to system management: suggest the most obvious changes; enact those carefully; measure the results; and move on to the next layer of issues. 

5. After the preliminary report cycle is completed, a new client enters into our “natural” cycle. Our software continues to collect and report statistics daily, and we receive the data weekly (each extract is usually less than 1 MB). 

6. All the intensive number crunching and data retention required for this process is performed far away from your servers. We run the extracts through our proprietary software which parses the collected metrics, extracts meaningful information and updates a series of databases, charts and worksheets.

7. A TDI analyst examines these results manually and looks for ominous trends, red-lining, thrashing, and other signs of system distress or anomaly. None of the analysis and grading described here is performed through an automated engine. Each of our customers is unique, and each of them benefits from the build-up of the experience we obtain by learning more and more about their systems each reporting cycle. 

We will investigate problems and produce detailed "drill-down" analysis and recommendations for future avoidance when appropriate.

8. The TDI analyst assigns grades to the system in various areas (Application, CPU, Disk space, etc.). The grades are based on our experience with your and others’ systems. The report card makes for a nice Executive Summary for management. Here’s an example pulled from the most recent report we prepared for one of our clients: 

System Report Card

Module Available:

100%

Hardware Status:

OK

Application:

**

CPU Capacity:

B**

Available Memory:

A

Page Faults:

C

Page Evictions:

B

Paging Space:

A

Disk Space:

A

Disk Busy:

A

Disk Balancing:

A

Disk Cache:

A

X25 Capacity:

B

Ethernet:

A

Queues:

B

Fault Tolerance:

A

** -- Incident/In-Depth Report or Recommendation
A -- Adequate
B -- Basically Adequate
C -- Cause for Concern
D -- Deficient, needs fixing
F -- Failing, causing a bottleneck or outage
Y -- Yes N -- No

Our clients look at the Report Card, and if all the grades are A’s and B’s, and there are no “**” marks, they can close the report and put it on the shelf. They can take comfort in the fact that TDI team has reviewed their system for the last month, looking for problems or worrisome trends, and didn't find any. However, if there are “**” marks or grades lower than a B, then we recommend that someone review the issues or concerns we have raised. For that, a detailed report follows the grades.

9. A summary of the report is sent via email as soon as we've finished. The full report is delivered CD or DVD.

10. As part of the standard Ban Bottlenecks service we hold a web consultation. We discuss our findings, and then open a discussion with your team about your concerns, plans, and especially business plans.

©Copyright 2009
Company | Ban Bottlenecks | Consulting | Software | Papers | Home | Sitemap