Problems of Manual Model Creation

  Section already mentioned that most papers on the benefits of dependency models assume the existence of such models. Others, like [#!clem94!#] present means of describing models suitable for IT-management, but also do not provide models as such.

Despite of the positive results of such investigations, dependency models are hardly used at a larger scale in real environments. This is due to several reasons:

Up to now, they have to be created by hand; this can be a very time consuming task, especially in complex environments with a large number of services. The problem gets worse if different applications of the dependency models are taken into account which need models at different levels of detail. Either, one finds some kind of compromise or has to create several distinct graphs.

From a purely top down perspective, the `best' models are based on generic services; reusable in various environments. However, to guarantee a wide acceptance, it is finally up to international standardisation organisations to define generic descriptions of services and their dependencies -- usually taking a very long time.

Examples for generic definitions can be found in the Common Information Model (CIM, [#!cim20!#], [#!appmof21!#] respectively), defining classes for services and other managed objects including several types of dependencies.

Later, during the utilisation of models, it might be necessary to change some of them, adapt them to new conditions, etc. This is especially a problem, because services often cannot be modelled on a very abstract level, but -- as programs available on the market do not always exactly match the exact requirements -- the models must consider the properties of the real world service realizations. Even simple software updates might then lead to changes in the models. Over the years, this again sums up to a time consuming task.

Preventing the design of widely used models is the lack of an established common model description format on the market. This makes the realization of management applications more difficult and is a real handicap for reusing the same models for different purposes. Actually, this problem should, e.g. be addressed by the information model of management platforms -- but nowadays these are not yet powerful enough to handle the kinds of dependency descriptions needed.

The above reasons finally lead to the fact that companies do not deliver models along with their products. This is a further handicap for their customers. The only dependencies usually described are vaguely expressed prerequisites like ``needs HP-UX10 and 200MB of disk space''.

There are further reasons, why companies do not deliver more exact dependency descriptions: On the one hand due to confidentiality of the information, and on the other hand due to strategic reasons which are enforced to help strengthening the companies market position.

The big efforts that have to be taken to generate the models also do not allow to carry out modelling regularly. This prevents their application for special management tasks, as described in the end of section .

All these disadvantages are reasons why dependency models are not widely used. One attempt to overcome -- at least the most significant -- disadvantages is to automate the creation process of models as much as possible. This would help to reduce the time to create, as well as to maintain the models, to an acceptable extent and thus help to diminish the problems coming from the companies (still) not delivering models with their products.