As we said at the start of this chapter, there's more to performance management than just baselining. What baselining techniques bring to performance management is an ability to plan future requirements based on historical trends in network use. However, it is important to realize that not all network requirements are purely evolutionary. For example, if a major new client/server or intranet application is rolled out, it will likely have a significant impact on the network -- but there is no way of determining that impact from historical data. Instead we must rely on a different set of techniques -- application modeling.

The goal of application modeling is to determine how a new application will impact network performance and capacity requirements so that needed changes can be made prior to the application rolling out. This is essentially a five-step process.

1. Transaction analysis. How much data is associated with typical user transaction or interactions?

2. Use analysis. What are the classes of user, what is the transaction profile associated with each class of user, and how many of each class of user are located at each site or network area?

3. Application model. Combine the information from each of the previous steps to determine the profile of the additional traffic impact on each link in the network.

4. Network impact model. Superimpose the application model on the existing network traffic profile to determine the likely overall capacity requirements once the new application is rolled out.

5. Network redesign. Determine where additional capacity is required or what network design changes might be required.

Transaction Analysis

The first step in application modeling is to determine the different types of user interaction with the application and the amount of data associated with each. If the application is an "off-the-shelf" solution some of the required data may be available from the application vendor. Also, some of the modeling tools provide typical data for common applications like SAP or Peoplesoft. However, if you don't have the appropriate data handed to you on plate (or you don't trust it) you are going to need to do two things. First, you'll need to determine what the primary types of transaction/interaction are. Next, you'll need to establish how much data is associated with each type. The method you'll use to do that will vary depending on how far along in the development cycle the process is. If the application is nearing completion, you'll be able to use the "application fingerprinting" technique -- simply use a Sniffer or other network analysis tool to monitor the actual traffic associated with each type of transaction/interaction. If, on the other hand, several modules are still unfinished (because you're planning well ahead), you'll need to work off the functional specification or with the developers. This is a good excuse to spend time with the developers and make sure that the application is going to be "network-sensible."

Use Analysis

Next you'll need to find out what the major classes of user are. Different classes of user will interact with the application in different ways -- for example, a data-entry person will use an application very differently than a manager who wants occasional reports. For each major class of user you need to build a transaction profile -- a data-entry clerk might perform one type of transaction two times a minute from 9 to 5 at a relatively consistent level of activity. The manager class might perform sporadic transactions throughout the month but each use a particular reporting transaction intensively on the first morning of a new month. Once you've analyzed the transaction distribution for the major classes of user, multiply the transaction volumes by the transaction data size (from the previous step) to build a data traffic profile for each class of user. Finally, you'll need to determine how many of each class of user are located at each site (or building, or floor, depending on what type of network you are planning capacity for).

Application Model

Having established the traffic profile for each user class and the distribution of the users across the network it's necessary to combine that information and build an application model. In the good old days that meant starting with a very big piece of paper with a schematic of the network and progressively adding the traffic profiles of the various users together as links concentrated onto other links. That still might be an effective approach if your network is relatively small, but if the network is large and complicated you might want to use a modeling tool. Some modeling tools, such as CACI, offer a great deal of modeling detail (including the impact of queues in network equipment, for example), while other tools, such as the Make tool from Make Systems, utilize a simpler steady-state approach.

Network-Impact Model

Unfortunately, the new application is probably not going to be the only application on the network -- it's going to have to share space with all the other existing applications. To build a network-impact model, you're going to need know what the current traffic levels on your network are. Hopefully that information is available from the baselining tools you've implemented (if not you'll need to use a Sniffer-type product to sample representative parts of the network) You must then add the existing traffic to the application model to build the overall network impact model.

Network Redesign

The purpose of all this modeling is to give you insight into how your network might need to change to support the new application. Perhaps there isn't sufficient capacity in your network or perhaps the topology of the network needs to change to optimally support the new application. This is where the modeling tools really come into their own -- particularly for large WAN networks. For example, with the Make Systems product you can take utilize a tariff database to automatically optimize the network design so as to minimize telecommunications costs.