OSI With A Twist

• 08/01/1999

I get questions all the time about systems management requirements documents. Should wewrite them? How do I write them? What do I put in them? And ultimately, can you write onefor me? In general terms, they are pretty easy to write if you know what's important. Mymodel for requirements is called "OSI With A Twist." A twist of what you mightsay? Well it's a twist of common sense.

Open Systems Inter-connect (OSI) defines five functional areas regarding systemsmanagement. The five areas of the OSI systems management model are: fault management;configuration management; security management; performance management; and accountingmanagement. A good start yes, but just the beginning. Before you can decide how to manageyou need to classify what you are going to manage. This hierarchy forms what we callManaged Objects.

Four classes of managed objects are defined. Those classes are: Node objects; Systemobjects; Application objects; and Service objects.

Node objects generally equate to a physical entity such as a router, an Ethernet hub, apersonal computer, or a UNIX server. Management of a node object is generally limited topinging it to determine if it's present on the network.

System objects usually refer to software, like an operating system, or physicalentities that aren't manageable unless the relevant node or operating software isfunctional. Examples of system objects are operating systems -- HP-UX, Solaris or NT forexample -- and related parameters such as file systems and disk drives on servers.Similarly, interfaces on routers, hubs, or switches are considered system objects because,on increasingly frequent occasions, their existence depends on system configuration.

Application objects are entities such as electronic mail, databases, databaseapplications, Netscape or Microsoft Web server software and Lotus Notes.

Service objects are a combination of node, system and application objects. Forinstance, to manage an electronic mail service it's necessary to consider not only theapplication itself, but the systems on which the applications run and the networkinfrastructure on which access to the application is provided.

Thus, the managed object hierarchy is roughly analogous to a protocol stack. That is,each successive class of managed objects more or less "sits on top of" theunderlying object class.

The table illustrates the relationship between the managed object hierarchy andmanagement functional areas and some examples of possible products as they fit into themodel.

The hierarchy defines categories of managed objects while the OSI systems managementspecification defines management functions that can be implemented for any type of managedobject. Any or all of the management functions are available for all classes of managedobjects.

Seems simple? If it's broken down properly -- it is. The key is to break it into asmany small pieces as possible. Then assign products to fill the pieces. Before long youwill build an entire enterprise management system.

This is just a small sample of possible products. In reality many of these products andothers can fill many different functional areas. I have by no means covered them all.