Evolution of Management Systems Integration

Integration across application and network levels, and among management systems at the same level, is clearly a key to the evolution of management systems. Unfortunately, integration has been one of the most abused words in the systems management marketplace. Many management vendors have positioned their offerings as integrated solutions, but too often their capabilities fall far short of what is actually needed by administrators. Most early products included only the least valuable capabilities and were then marketed strenuously.

This section looks at the types of integration, from the simplest to the most comprehensive, as a background for discussions of future developments.

Superficial Integration

The two most superficial forms of integration are integration on the glass and integration on a system. Integration on the glass means that there is a consistent look and feel to the management tools on the platform. Consistency is helpful because it reduces training and simplifies many tasks, but integration on the glass is of limited value after the training savings are realized.

The first Simple Network Management Protocol (SNMP) management tools used a dedicated computer system, called integration on a system. This can be a wasteful approach, especially when the demands on the server are low. Early SNMP platforms made a virtue of this fact, by marketing several tools sharing a single server as a form of integration. These platforms used their event management functions to launch a specific tool whenever criteria called out by a set of rules were satisfied. Such sharing does save hardware costs, and keeping it all local to one server simplifies some of the tool-launching logic. However, after those efficiencies are realized, the value is limited.

Data Integration

Data integration has long been touted as a breakthrough that will solve management challenges arising when a set of tools is needed to restore service levels. When one tool cannot share its information in a straightforward way with others, staff time must be expended to close the gap. The usual process has entailed using a tool, getting its output, and entering that as input for another management tool. Involving staff also raises the possibility of errors being introduced by staff as they manually move information between tools.

Extensible markup language (XML) is emerging as the preferred way of attaining a level of data sharing and integration. XML-parsing technology and document creation tools are readily available, simplifying the transformation between local and standard representations. In practice, selection of a common schema remains a challenge. All the different parties sharing data must have a common way of interpreting the tagged and structured information inside an XML document. Within an enterprise, such interfaces can be handled with local standards because documents are shared in a single organization. However, sharing information across organizational boundaries, or in the absence of strong standards, can be more of a struggle because there's no guarantee that the schema used by each party is compatible.

The work of the Distributed Management Task Force (DMTF) may be very helpful here. This standards body has defined the Common Information Model (CIM) and an encoding scheme for XML documents. However, this standard has not yet clearly demonstrated its value. Economic realities tend to work against spending in support of standards that may not demonstrate an immediate payback.

One outcome of the emerging focus on XML is a shift away from efforts to create a single management information repository. Projects that attempt to define and implement such a single repository for management information almost always fail, for reasons that are clear, especially in hindsight.

The first barrier for unified management information repositories has been the schema. Every management vendor has its own internal schema and prefers to impose it as the industry standard. Competitors understand the advantages of having a proprietary schema, which ensures lock-in for their products; the resulting deadlocks often lead to early failure.

Another barrier was the relative immaturity of distributed database technologies. Problems of keeping information fresh, arbitrating concurrent updates, saving information, and providing easy database backup and recovery often made any effort look impractical. It appeared that the foundation technology was not ready for prime time.

Distributed database technologies have matured, but the reluctance to reengineer fragmented databases is still strong. Adoption of a monolithic management repository requires extensive changes in almost all organizations. The reality is that there are many databases within an organization that hold critical management information. In some cases, databases are separate for legal or regulatory reasons; in all cases, organizations are reluctant to reorganize their databases.

Rather than focus on the data store, XML facilitates data exchange with a protocol for documents, using a defined encoding scheme. Schema descriptions and presentation information can also be appended to documents. That is what makes XML a strong alternative to the repository concept for data integration.

Event Integration

XML document exchanges are sufficient for ongoing data communication between management tools. Such exchanges are essentially synchronousa tool receives a message and responds to it. However, that is only part of the answer; event integration is also required, because management tools need asynchronous communication with other parts of the management system.

Event integration enables a management tool to signal asynchronously and activate another part of the management system when a specific event occurs. Such integration must be bi-directional; events can flow in either direction as determined by the specific needs of any management task. Each party must be able to understand the event so that it can take the appropriate action. As more events are encoded as XML documents, XML can simplify the integration process and leverage data-integration methods for use in event integration.

Process Integration

Solid data and event integration enables administrators to build management processes, which are automated sequences of tool functions that are sequenced and controlled by a process manager. Process integration offers high value to administrators because each automated process saves staff effort and expense each time its triggering situation occurs.