This chapter is from the book
This chapter is from the book
This chapter is from the book
CMS as an Integration Mechanism
Data integration is a longstanding problem with software systems, especially with management software. Proprietary management tool interfaces have long ruled this market. They created a nice development partner ecosystem for the major vendors, but the practice makes it difficult to plug tool A into tool B to attain more comprehensive value from the union of the two. In defense of the major vendors, they appeared on the scene at a time when proprietary integration was the only option. Once established, these interfaces took on a life of their own and are now so deeply entrenched, they are nearly impossible to replace. That said, however, it is time to change. The integration pain has become so severe that progress toward unified service management is being hampered.
Software tools are gravitating toward functions that act as either data providers (such as discovery) or data consumers (such as analysis tools). These classifications establish the major points of integration, where one must integrate with the other. Some tools act as both providers and consumers (for example, the server agent), consuming data for one purpose (localized analysis on the server, for instance) and providing data for another (in this example, presenting the server’s data for analysis in a broader context). Either way, integration can be a quagmire.
Figure 2.12 is a picture of a simple integration challenge. As you can see, many integration points are required, each with its own data model and its own access and exchange protocols. As the number of tools increases, the integration challenge grows exponentially. Clearly, this is not sustainable in a large environment.
)
Figure 2.12 Proprietary tool integration
The DMTF’s CIM and other standards promised to address this situation long ago. Until recently, the standards were held back. Either vendors were unwilling to support the standards effectively or technology limitations prevented a vendor from “shoehorning” a standard into its antiquated technology. New technologies based on true object models and object integration are finally now gaining enough of a groundswell to move the industry toward acceptance of standards-based integration.
Data and messages are the basis of tool integration, with much of the emphasis being on the data. Standards for message exchange are already accepted practice (for example, SNMP trap or CIM Event), although more work is needed. The data side of integration is the gap, and that gap is filled very nicely by a CMS.
As the CMDB gains popularity, vendors and users alike are recognizing its potential to simplify the integration problem. The very nature of the CMS is grounded in common data formats and interchange specifications, so it seems to be suitable for tool integration. Indeed it is. You will see many more possibilities emerge over the next few years to act in this capacity. Most of the innovations will not even be so explicit, but if two tools are using a common CMS, there is no need to explicitly send a piece of data from one tool to another. The data is already in the right place. Figure 2.13 indicates how the CMS simplifies the integration problem of Figure 2.12.
)
Figure 2.13 CMDB as a common tool integration point