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.<br/>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. <br/>This enables the concept of a Resource to be partitioned into its physical and logical aspects. This has a number of benefits:<br/>        • There are various different viewpoints taken in the operations process and this split reflects some of those critical viewpoints <br/>        • 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.<br/>        • 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).<br/>        • By concentrating only on logical aspects, we are better able to produce models that can be applied to non-networking domains of interest.<br/>        • Policy can be applied to govern physical, logical, or both aspects of the resource operation and functionality<br/>        • PartyRoles can be defined to better link business and system goals with the implementation<br/>        • Through continued abstraction, we can apply this principle to enable (for example)<br/>        • Software people to work on the software portion of the logical resource model<br/>        • Network people to work on the networking portion of the logical resource model<br/>        • Protocol people to work on the protocol portion of the logical resource model<br/>        • And so forth<br/>        • The portioning of the model better enables different people to work on different parts in parallel<br/>This basic model will be refined over the course of this section. <br/>