Figure LR.04 - Resource specialization and inheritance

Resources are physical or non-physical components (or some combination of these) within an enterprise’s infrastructure or inventory. They are typically consumed or used by Services (for example a physical port assigned to a service) or contribute to the realization of a Product (for example, a SIM card). They can be drawn from the Application, Computing and Network domains, and include, for example, network elements, software, IT systems, content and information, and technology components.
One of the principal mechanisms of object-oriented analysis and design is the principle of abstraction. Network entities, like a Router, are very complex. Abstraction lets us focus on one or more aspects of a complex entity and (temporarily) ignore its other aspects. This enables us to divide a single complex entity into multiple simpler entities. In this case, we can clearly divide the Router into its physical and logical aspects. The separation is simple to determine: if you can touch the entity, then it is a physical entity; if not, it is a logical entity. Thus, the chassis, cards, and cables of a Router (among other things) are all physical entities, whereas the services and protocols that a router is running, or the number of processes that it has defined, are logical entities.
This enables the concept of a Resource to be partitioned into its physical and logical aspects. This has a number of benefits:
        • There are various different viewpoints taken in the operations process and this split reflects some of those critical viewpoints
        • The physical model view deal with such considerations as the shipping of cards and spares holdings. A physical resource may have many functional viewpoints but at many stages of the lifecycle the functions are not be relevant.
        • The logical model view (functional model) deals with the operations purpose in a consistent fashion regardless of the physical construction. A logical function may have many potential implementations, but the specific implementation may not have yet been chosen (e.g. during the planning phase).
        • By concentrating only on logical aspects, we are better able to produce models that can be applied to non-networking domains of interest.
        • Policy can be applied to govern physical, logical, or both aspects of the resource operation and functionality
        • PartyRoles can be defined to better link business and system goals with the implementation
        • Through continued abstraction, we can apply this principle to enable (for example)
        • Software people to work on the software portion of the logical resource model
        • Network people to work on the networking portion of the logical resource model
        • Protocol people to work on the protocol portion of the logical resource model
        • And so forth
        • The portioning of the model better enables different people to work on different parts in parallel
This basic model will be refined over the course of this section.