In-Depth

Hierarchical Usage Models (Part 2 of 3)

Using a layered approach can help expand usage analyses to more complex projects.

• By Enrique Castro-Leon
• 08/08/2006

Intuitively we can see that a usage model analysis constitutes a tool to provide economic justification for major purchases. For instance, we go through this process in our personal lives before we select a home. Usage patterns provide insight into the type of home we want to buy: its distance from work; whether we need an apartment, penthouse, condo, a hotel room, or a house; whether we want to rent or buy; even the layout of the dwelling itself is considered.

In the first article of this series, we explored how usage analyses are applicable to deployments of complex IT systems, be it the grid mentioned in that article, a new VOIP system, or a replacement for an aging ERP system. There is one caveat. Traditionally usage analyses have been applied to a single product, such as a server. Generalizing the concept to a platform or to one of the systems mentioned above is less obvious because of the extreme complexity involved. We hinted in Part 1 that the problem could be made tractable through a layered approach. The layered or hierarchical approach is the subject of this article.

Beyond the overall economic justification, the hierarchical approach also helps a business establish relationships across layers -- for instance, _ is processor X a good match for running the ERP application Y? _ These relationships are not trivial to establish because of a semantic gap. A processor sits four or five logical layers below an application and a different terminology is used to define processor behaviors from the terms used to characterize an ERP application. How do we ensure a certain CPU is a good fit under these circumstances?

We do it by analyzing each layer semi-independently. This spares us from having to count electrons when trying to understand how an ERP application works, because the layer that covers ERP need not be concerned with how electrons move through transistor gates.

The best-known example of a layered decomposition is the 7-layer ISO OSI model (physical, data-link, transport, network, session, presentation, application) used to explain the workings of the Internet. This model is so expressive that it is still used for this purpose, even though one of the most-used Internet protocols, the TCP/IP protocol, does not strictly adhere to the ISO OSI model.

Computing platforms are amenable to similar treatment. A key observation is that layer-to-layer interactions can be added separately to yield an integrated platform view for usage models. The approach is illustrated in Figure 1.

Figure 1. A Hiearchical Usage Model Framework
Click to enlarge

This model is a framework. It is not a usage model but a template from which specific layered usage models can be instantiated. Layer selection is usually system-dependent, determined by a system architect. There is no right or wrong layering choice. A selection is chosen to yield the best insight into the system behaviors.

As an example, let _ s assume we are analyzing a server and that we have picked the CPU, chipset, baseboard, complete server, and software as layers 1 through 5 respectively. At Layer 1, the CPU level, the usage context is system design; the user is a hardware design engineer, and a usage model is the process of placing a CPU chip into a specific design. This is far removed from an application user.

Furthermore, under this example, assume someone asked whether a certain processor is a good fit for implementing a matrix-matrix multiplication algorithm. The semantic gap makes the question unanswerable if we constrain ourselves to the CPU level, Layer 1. To address this question, we need to know the overall memory bandwidth available to all the processors connected to a memory bus. This is defined by the chipset in use which is a Layer 2 entity, not a Layer 1 entity. However, requirements for overall memory bandwidth establish a logical linkage between two levels and drive cross-level requirements.

We call these logical linkages vertical feeders which summarize the requirements from all layers above. Without these cross-layer requirements a CPU designer might conclude that the algorithm will run faster from cache and hence adding memory would be superfluous. This is a logical conclusion from a narrow view that ignores vertical feeders, but obviously absurd once a system view is factored in (see note 1). Applications above impose the need for a certain memory space that won _ t fit in the cache.

Likewise, understanding the usage models for the CPUs and the usage models for a chipset, plus the vertical feeders in between, provide clues for the suitability of running certain algorithms but not whether the CPU and chipset yields good I/O performance. For that we need to understand performance behaviors at the server level.

A formal usage model analysis consists of examining and discovering usage models for each layer in detail and establishing a logical chain for requirements across layers through vertical feeders. These cross-layer relationships help bridge the semantic gap.

In summary, the application of this framework addresses two problems:

1. The framework allows the partitioning of a complex computer system into logical layers, each with its own usage models. Because usage models are determined for each layer, the analysis is carried out without worries about the semantic gap. The level-by-level analysis is much simpler than analyzing the whole system all at once in one step.

2. Vertical feeders impose additional requirements at each layer and define relationships between layers. By applying these requirements transitively, it _ s possible to eventually map high-level requirements, such as business requirements to devices at the lowest layers. This is not a new process, but this usage model framework provides an orderly way of getting to the results.

This analysis raises two benefits: inferences about usage models for the whole platform (derived from the layer-by-layer analysis) and platform attributes or features that have been optimized vertically as a platform, not piecemeal.

Next week, in Part 3, we apply the Hierarchical Usage Model Framework to the original grid computing example described in Part 1.

- - -

Note 1: The movie _ 2001: A Space Odyssey _ brings an excellent example of cross-level requirements conflicts when HAL, the computer aboard the spaceship Discovery, decides that human life is expendable on the mission to reach Jupiter. HAL was incapable of bridging the semantic gap beyond the level of the spaceship _ s hardware. A narrow _ thinking _ to ensure the integrity of the ship _ s hardware led to disastrous results for the mission as a whole.