Environmental Models

  The description of the scenario in the introduction already comprised the objects' dependencies. These immediately lead to the dependency model of figure depicting the web server with its database, both web clients, the DNS server and a generalizing object for the common communication infrastructure. In the following, such models are called environmental models to stress their capability to reflect information specific to real objects in the managed IT-environment (in contrast to the abstract models explained further down).

Each node represents one single or alternatively a group of real objects, which may be enriched with further management information--corresponding with traditional management variables in other information models. The group- or collective objects are used in various cases: They represent whole domains (e.g., organizational units like departments or responsibility areas of IT-managers) or--on a more technical level--distributed applications that are intended to appear in the model as a whole, but not in full detail. Figure  depicts such a domain object, by hiding the whole domain R under one node. It could, e.g., be the model that is displayed to the administrator of domain L who is not allowed to look at details beyond his own area, but nevertheless is interested in dependencies to the outside world. Domains are represented by one element in the model, which is either a terminal element or stands for (and may be expanded to) collections of one ore more:

• simple (terminal) objects also taken from the modeled environment, and/or
• underlying (sub-)domains, recursively providing more fine grained levels of detail.

[#!ghw99!#] presents further details on the subject of domains. As they obviously are an important concept, the architecture presented in section also includes the appropriate features.

The second type of components in the models are (directed) edges representing dependencies between the nodes. For some applications of the models, undirected graphs are sufficient. For others it is useful to attach further management relevant attributes, e.g.:

• to form groups which, e.g., express that a dependency only occurs together with others,
• to express that some dependencies must occur in a certain timely order,
• to attach values of strength or likelihood, but also
• to reflect 'internal' management information, e.g., how the dependency was detected or how much effort its reevaluation would take.

  

Figure: Management perspective from domain L

If DNS in our example fails, web clients in principal are still useable by typing IP addresses. This restriction in the quality of service could be denoted as an attribute of the dependency between the clients and the DNS server.