Any model of a computer system will generate a large amount of numeric data. You can get breakdowns of response times, throughputs, device loads, numbers of each type of work unit in various queues, and so on and so on. The intended recipient of the information that the model was built to convey, will probably be concerned mainly with the following issues:

• How much worse will things get if we do nothing?
• Will the problems be CPU related or I/O related?
• How much better will things get if we perform an upgrade?

You, the modeler, need to present results that relate to these questions. Our main advice here is - don't get bogged down in too great a degree of detail. In particular, try to avoid modeling individual units of work, such as named transaction types or specific users. Try to model at the level of entire applications, or even the whole workload. Explain that if the entire application is predicted to perform relatively worse (or better), then on average all the sub-units within it (individual users, transactions etc.) will also perform relatively worse (or better). There is little or nothing to be gained from "proving" this fairly obvious fact by attempting to model individual transactions. Apart from anything else, as soon as you start attempting to discuss individual transactions in detail, you risk opening the flood-gates and releasing torrents of digressions about application and database design, user behavior profiles, interactions between transaction types and so on. Interesting and important as these issues might be, they are issues of performance analysis rather than modeling, because they are below the level of granularity that an analytic model can usefully reach. When presenting results, therefore, concentrate on the relative response time changes of large units of work. By "response time" we mean the results presented by the model, which show the total elapsed time (including queuing) needed to obtain the CPU and I/O service that the application uses during the modeling period.

The best way to address the issue of whether the workload is I/O bound or CPU bound, is to show the gross breakdown of each workload component's response time as the sum of busy and queuing for CPU service, and busy and queuing for total I/O. It summa rises the general "balance" of the system at a glance.

A good use of the projection facility within What-If models, is to use the various projection points to represent different potential upgrades, rather than activity at particular times in the future. This lets you create simple but striking graphs of the relative response time changes under a variety of possible upgrades, and effectively addresses the recipient's third requirement for information.

The principle is to provide enough information to answer the questions being asked. It doesn't help you or your intended audience to offer too much detail, whether the planning technique you use is trending, analytical modeling, simulation or good old-fashioned guesswork!