2.3 Bottom-up Approach: Ensuring feasibility

As mentioned before, the requirements-based top-down approach of the previous section has to be complemented by an accompanying bottom-up approach based on an analysis of the modeled resources. For each GAMOC, we have to answer the question ``What can reasonably be assumed in general about resources of that class?'' or, in other words, ``What can be directly obtained from these resources?''. If the answer here is negative for information that is required according to the previous step, we should probably not add it to the GAMOC in order to ensure an efficient implementation. In this case we have to find other GAMOCs or other mechanisms to meet this specific requirement. In terms of interoperability of management, this step is the crucial part of the approach. On the one hand, specifying too little information for the GAMOCs will make integrated management inefficient or even impossible. On the other hand, assuming too much about the characteristics of resources will obstruct interoperability and implementation. If the information specified is not implementable or valid for a vast number of resources, management applications will frequently have to cope with responses like ``not implemented'' or ``not available''.

The major problem in contrast to other management disciplines is that only little experience with management of distributed applications exists. Hence, answering the question ``What can be assumed about resources of a class?'' is by far not trivial.

In our approach, we answer the question again in a way aligned with the RM-ODP. For each of our GAMOCs, we analyse the respective structuring rules (ISO 10746, Part 3: Architecture) of the viewpoint languages resulting in detailed hints on what information an application should easily be able to provide to management. An example might illustrate this: The rules related to interfaces or interface templates, respectively, show that information on other software including its version and other management information can be introduced without difficulties.

Another important source of information are the consistency rules that relate different viewpoints. For example, rules related to the consistency of engineering and computational specifications justify the definition of information that gives an answer to the following question: ''We installed software package XY -- what are the names of the processes that have to run properly in order to have the application in an usable state?''