Network Computingwww.networkcomputing.com

CORPORATE VIEW / BRIAN WALSH

The Inertia Of DMI

Not all forms of idleness are so cathartic. Take waiting for real progress on the Desktop Management Interface (DMI). Let's face it, watching industry standards progress is not much of a spectator sport. It's probably not much of a sport for the participants either, especially when there's only one horse in the race. That's the frustrating thing about the Desktop Management Task Force's (DMTF) efforts. There is no competing effort. There is no OS/2 vs. Windows, no Token-Ring vs. Ethernet, no Oracle vs. Sybase. There is a newly defined standard way to manage desktop CPUs, hardware peripherals and software components and there is the status quo.

The DMI is a specification for components (desktop computers, software and peripherals) and the software that manages them (asset management, help desk software, version control, and so on) defined by the DMTF. When widely implemented, the DMI has the potential to lessen greatly the time and effort necessary to keep an increasingly complicated and increasingly large number of desktops running. All the major vendors have at least nominally signed up and there seems to be no alternative on the horizon.

Despite the support from vendors, the DMI's rate of progress and market penet ration has been slow-too slow to make much of a difference up to this point. Perhaps even without the bureaucracy of an official standards body, there is only so much progress to be made when you stick a dozen of the industry's major players in a room and ask them to work together.

Consumers, corporate PC managers and IS management do not recognize the impact that the DMI can have on their pocketbooks and on their user's satisfaction level. The DMI story simply has not gotten enough air time, probably because there is a lack of killer apps and user success stories out there. It's a classic Catch 22: Users are waiting for DMI enabled products, and vendors are waiting for user demand. Some vendors, like Intel, have their entire suite of products DMI enabled. Most vendors are playing wait-and-see. It is up to the DMTF to break the impasse.

To give credit where credit is due, the DMTF has done an admirable job of getting at least surface consensus among vendors. It is time to spend a little energy on raising the recognition factor among its intended audience. The best way to do that is to agree on what DMI compliance is, create a certification process and brand products as DMI compliant.

Perhaps the lack of competition has made the effort complacent. Would the Unix vendors have gotten together and finally started reading off the same page if Microsoft wasn't kicking down the door? Probably not. Is there a standards body or vendor that will come up with a competing technology outdating the DMI? Definitely not.

The DMTF was initiated because there is a real need for desktop management. The Internet Engineering Task Force (IETF), the group behind TCP/IP, the Internet and all sorts of wonderful network stuff, had its hands full and was not going to address desktop components, so the DMTF was formed three years ago to kick-start the process and get the technology together on a fast track. Has the DMTF included the IETF as early and as often as it should have? Probably not.

Needs IETF Support

Conversely, not everyone who has problems managing PCs has an SNMP infrastructure in place. In order to succeed, the DMI needs to function out of the box on a minimally configured CPU, on or off a network, with or without a defined infrastructure. Home users, small businesses and departmental LANs all need to be supported. So there has to be a way for components to find managers and vice versa. A non-SNMP solution is required.

The DMTF has too many positions in this area to appear consistent. One is that organizationally, the people who are responsible for the care and feeding of routers, servers and hubs are a different population of IS professionals than those responsible for managing printers, software packages and desktop CPUs. But should the desktop support staff be responsible for building a different logical network in order to use the DMI? They should be able to leverage the SNMP-oriented investments in place.

Most of the recent ink that DMI has seen in the press has been on this SNMP vs. DMI nonissue. The fact is that the DMTF is committed to transport independent transfer of DMI information. Interoperability and portability are two of the major design goals of the specification. There is no reason that the two technologies cannot complement each other.

These are two of the factors handicapping this one-horse race. In order for the race to get interesting, the DMTF shoul d get the whole issue of SNMP clearly defined and out of the way. A priority should be placed on a practical, elegant, robust implementation of the MIF-to-MIB technology. Also, it should define compliance and start a brand process.

In the meantime, vendors of packaged software can deliver DMI component support. Now that the software MIF is defined, adding support should take minimal effort. OS vendors need to commit to hard and fast dates when they will ship the service layer. We need an organized and consistent source for distribution of the DMI. Microsoft, Novell, Sun and IBM have all announced support. Now's the time to walk the walk.

Brian Walsh is a senior consultant with Cap Gemini America, based in Portland, Ore. He investigates network technologies and oversees development and implementation. He can be reached at bwalsh@nwc.com .