The topic I address in this book already has many acronyms: CMIP, SNMP, ASN.1, NMS, EMS, OSS, OSF, TMN, OSI, MIB, FCAPS, GDMO, and SAP. Before I add CIM, WBEM, CIM-XML, xmlCIM, UML, mof , NPI, CMPI, SBLIM and other ingredients to the alphabet soup, I would like us to agree on the topic we are addressing and some basic, simple vocabulary to describe it.
Imagine that I have invented a toaster which can accept simple management commands such as "lower the bread, turn on the heaters, turn off the heaters, tell me the colour of the bread (never mind how it does this), eject the bread" and "set thermostat to x C."
Toaster management in its simplest form is illustrated in Figure 2.1: I sit at a management workstation (my computer) which is locally connected to the toaster and enter commands to cook my toast . The protocol that my management workstation uses to talk to the toaster is a private matter; the interface presented to me is tailored specifically to the toaster and, because the connection between the two is local, any threats of unauthorised people using my toaster may be handled by locking my kitchen door.
These days, however, all devices must be connected to the Internet; so, after a period of private toast making, I succumb to peer pressure and connect my toaster and other kitchen appliances to the wider world.
Figure 2.2 illustrates my new situation: I can now manage my toaster, microwave, and refrigerator from management workstations in my office or local Internet caf. However, I now have more problems to face: the remote connection means that locking the front door is no longer sufficient to prevent unauthorised toast making; the heterogeneous nature of the devices means that some form of standard protocol is needed to keep the management workstation software tractable, and the opportunity for my wife and me both to be managing the kitchen at the same time means that we may conflict with each other when configuring the same device.
In addition, because there are several devices involved, we may want to manage not only the individual devices, but also services offered across several of them: co-ordinating, for example, microwaved beans with golden toast. How may such services be managed now that they are not resident on any single device?
These are the kind of problems, although not necessarily in the kitchen, which the DMTF set out to address in creating the WBEM/CIM architecture.
Given the confusion of terminology within the device, network, and service management world, I intend to use only the terms "device management" and "service management" in this book.
Device management is the term I use to mean the management of a single device using commands which the device itself knows how to execute. The toaster command "lower the bread" is a device management command as it refers to a primitive action which the toaster can perform. Note that, as an operator, I do not know how the command is executed by the toaster; it may cause a voltage to be placed on a relay coil, which causes a rod to move outwards, causing a micro-switch to close, and so on. It is sufficient for me to know that lowering the bread is a primitive operation that the toaster can do.
Service management is the term I use to mean the management at a higher level of abstraction. The command "toast a piece of bread the way Chris likes it and inform me when it is done" is an example of service management. This is not a command that the toaster knows how to handle directly ”some intermediary process will have to break the command into primitive steps (lower the bread, turn heater to 150C, etc.) before the toaster can do it. In this case the service management command affects only one device, but typically such a command might affect several: "cook a meal of beans and toast the way Alison likes it."
Of course, this categorisation is not precise. One person's service management is the next person's device management; a telecommunications carrier might use service management commands to configure a virtual IP router. The customer of the virtual router would then see it as a device and perform device management on it.
The reason I have stressed the device/service distinction is that, in many fields, customers are demanding more service-level management.
In the telecommunications and computer worlds , for example, buyers are putting increased pressure on suppliers to provide service management using abstractions that are meaningful to the buyers ' operators. They are demanding that they be able to manage video streaming applications, mobile workers, and other services affecting many parts of a network so that operators have to work less often at the device level; e.g., "set parameter 7 of port 39 on device 87 to 1."
Operators capable of manually converting requests for a video streaming application into a set of primitive commands to configure parameters in devices are rare and expensive as they need to be experienced and have a deep insight into the system. The cost of these operators, the so-called OPEX or operational expenditure, constitutes a large part of a network owner's outlay, and some telecommunications operators have recently announced that, with the next generation of network equipment, they are looking for a reduction of between 25 and 40 percent in this cost. Even with experienced operators, however, manual configuration using low-level commands is error prone. Although we still need to be able to configure the parameters of a particular port (device management), the cost of skilled operators and the revenue lost through manual configuration errors have driven a demand for the management of end-to-end services and abstractions.
This move to high-level services is reflected in the work of organisations such as the Parlay Group  and JAIN,  which were formed to allow network operators to define open application program interfaces (APIs) to networks, particularly Internet Protocol (IP) and Public Switched Telephone Networks (PSTNs).
It is important to re-iterate that one organisation's service is another organisation's device; the services being discussed by Parlay and JAIN, for example, would not be considered services by a customer of a company providing a distributed Backup and Restore service ”they are components which allow the Backup and Restore service to be built.
The cost of operator error, particularly when operators are asked to work at the component level, has also initiated a discernible move away from operators entering commands ("disable port 7 on card 23") to entering suggestions ("I suggest that port 7 on card 23 be disabled"). The management system can then reply that disabling that port would affect the service of 453 users, currently producing a revenue of $1087 per minute. The management system could then refuse to obey the command for anyone other than a senior operator.
Because many system failures are caused by inappropriate operator commands (an oft-quoted Gartner study  attributes 40 percent of all failures directly to operator error and a further 40 percent to software bugs , many stimulated by management tasks such as upgrading), the softer "suggestion" mode coupled with a higher-level abstraction allows management software to protect operators from their own errors.
In addition to the device/service split, there are many ways of categorising types of management; Figure 2.3 illustrates some of these (although there are many more). The axes shown are:
What type of management do you actually want to do? For example, do you simply want to collect and display alarms or do you also want to configure things? Do you want to collect and analyse performance information? This classification of management is often known as FCAPS (fault, configuration, accounting, performance and security management). I describe FCAPS in more detail in Appendix C.
The entity to be managed might just be a single device, but also might be multiple devices one at a time, or multiple devices simultaneously to establish a connection across a network. There are numerous ways of enumerating these scopes; the Telecommunications Management Network Forum, for example, uses the categories shown in Figure 2.4. 
Through what type of interface do you want to manage your system? By using a graphical user interface (GUI) with sophisticated diagrams, pull-down menus , etc.? By typing textual commands into a command-line interface (CLI)? By writing a program to access an API? By using a standard Web browser (browser user interface: BUI)? Each of these may be applicable in different contexts and may need to be used by different operators managing the same device simultaneously.
Many devices, particularly small routers designed for homes and small offices, are being shipped with BUIs: the operator simply connects an HTML browser to a particular port on the device and enters information into the screens which appear. In this case, the entire management system is driven by software running on the device being managed. More sophisticated systems may require a Java or C++ program on the operator's computer to provide a more complete graphical interface for the operator ”showing, for example, pictures of devices turning red when faults are detected and allowing the operator to point and click on components to be managed.
Even more sophisticated systems may require a CLI for the operator and a programmatic interface for higher-level management systems. There is certainly much anecdotal evidence to suggest that, at least within the telecommunications field, "real" operators do not use graphical interfaces and that this is not just a macho attitude ”it is a reflexion of the speed and flexibility of a command line for an experienced operator.
 Gartner Research Note TG-07-4043
 Note that this picture is often drawn as a pyramid the other way up with business management very small at the top. I have changed the representation because it seems to imply that element management is large, network management slightly smaller, etc. In fact problems increase rather than decrease as one travels towards business management.