Preparation

 

  

Figure: Two phases of preparation

The first phase needs to be carried out per dependency model. It selects the objects that are finally going to be represented in the model. Most basic choices are:

• the desired level within the management hierarchy: e.g., high level services, applications and their components, network systems, or any other level,
• the object type: e.g., all available services vs. a certain selection of classes,
• the model's main range: restricts the model, e.g., to objects from one certain department or area of responsibility,
• the models border area: in addition to the main range the model may also enclose collective objects representing things outside that range, like internet or the domain R in figure which are represented in the model just like any other object.

Obviously the selection heavily depends on the purpose that the model will be used for. Figure further shows two choices on which level the selection process of step 1 may take place:

i')

Either on the abstract (class-) level, e.g., ``web servers'' and ``web clients'' followed by (possibly platform supported, automated) instantiation, to select the real objects belonging to the chosen classes.

ii'')

Or directly on the level of objects in the real world, e.g., web server on host b.R, web client on host e.L etc.

So far, the selection of objects followed a top-down approach. However, one also has to consider restrictions coming from the modeled environment and the modeling tools used in the later phases, because these may only accept restricted types of input data that is not available for all objects. Especially collective objects for domains are usually not supported by current automated modeling tools. Section  will therefore also show how our approach deals with this problem.

In step 1-ii the chosen objects must be mapped onto the matching components, applications etc. in the real environment. This requires no special actions for simple objects but for those where the realization is dispersed over distinct real objects, e.g., distributed applications and also the previously mentioned domains. In our example, two main routers could be selected to represent the object communication infrastructure.

One can see that this phase is only semi-automatable through the help of systems management or workflow utilities which are able to provide lists of available services, domains and departments etc. The assessment whether those objects should take part in the model must be done by human administrators.

In phase 2 the appropriate probes to meter the objects' activities (as explained in section ) must be installed. As for all measurements in distributed environments special care has to be taken on where to place the means of collection and the model generating algorithms; esp. in the TCP/IP world, where the management data is transferred `inband' through the same channels as the user data. In some cases it is necessary to create multiple models for the same environment, e.g., due to the application of distinct management tools or overlapping modeling of different organizational areas. Therefore, it is an important requirement on the means of information collection to be able to install them independently from a single model creation process, thus making them and their collected data reusable.