* The farther we progress down the SOA path, the more relevant the CMDB becomes
One of the foundational concepts of the IT Infrastructure Library is the notion of a configuration management database. As you may remember, ITIL began life back in the 1980s as part of an effort to optimize the quality of IT services provided to the U.K. government. It was widely adopted in Europe through the 1990s, and has taken hold in the United States over the past four or five years.
So much has been written about the CMDB that you would think there isn’t much more to say. However, service-oriented architecture (SOA) brings with it an entirely different slant on configuration management. The truth is that the farther we progress down the SOA path, the more relevant the CMDB actually becomes.
Most of the articles on SOA seem to be from the perspective of design, development or runtime. To date, most of the SOA products in the marketplace have addressed these phases as well. Our focus here at EMA, however, has always been on the management aspects of IT systems. And one of the big problems with managing SOA is that it introduces a new wrinkle to the management landscape.
The culprit, and a big hurdle for enterprise management vendors, is loose coupling. One of SOA’s key characteristics is that services can discover each other and link in real time, at the software layer. SOA services are virtualized from the underlying technology and theoretically can be moved from one device to another without affecting the overall integrity of the system.
Contrast this to traditional distributed systems, where application execution is tightly coupled to specific device IP addresses. These systems are “hard-coded”, in effect, to their underlying technology. Most Business Service Management (BSM) products on the market today address tightly coupled systems by requiring humans to model the software-to-hardware relationships manually. By “telling” the management product which hardware actually supports a given application, humans create a graphical service view that can then be used for application troubleshooting.
With loosely coupled systems, this manual mapping process becomes either impossible or irrelevant. If you want to see the cost of managing IT skyrocket, try throwing bodies at the task of manually mapping SOA ecosystems.
A combination of automated application discovery and identification, along with a robust federated CMDB, will likely be the key to managing these loosely coupled systems. Systems that can intelligently sift through network traffic, application signatures, device addresses, and other information, and store it all cohesively in a CMDB, will likely be required to support these systems.
There is a reason why major vendors have declared open season on configuration discovery specialists, for example, IBM’s November 2005 acquisition of Collation and Symantec’s February purchase of Relicore. It’s no coincidence that IBM announced an enhanced CMDB in June, or that network vendors such as Cisco are entering the application space. As the need to manage increasingly complex and diverse composite transactions escalates, the CMDB will likely be the centralized repository for relating applications to infrastructure through multiple technology layers.
This vision is utopian, in that it will likely take years to mature. Meanwhile, the CMDB stays relevant, as a key enabler for managing complex SOA deployments at reasonable cost.
