There is too often too much focus put on the database itself with fixed requirements of known technologies and elements today and architected to meet a requirement today leaving the data stale almost as soon as it enters the CMDB. Thinking in terms of ETL (extract, transform and load) into single consolidated repositories again puts the focus on fixed data as if IT might be building a significant structure like a damn to last the ages when we live in an age of agility and cloud computing requiring real-time views to make market time decisions.
I'm going to speak in terms of the “concept” of a CMDB versus the “thing” of a CMDB. The “concept” is an enabler to providing Intelligent Workload Management (IWM) in a complex heterogeneous and changing environment, both from a technology and business standpoint. Data needs to be referenced where it is created and managed (not collected or – ETL'd) and relationships created to other pieces of data from many sources to become meaningful information in a view that enables IT to Acknowledge – Assess – Act to market conditions in market time. This must be done agnostic to current technology definitions, infrastructures and restrictions in place today as they WILL change tomorrow.
Practices must also be considered that govern change and automate the current “operational” view of the environment while still remaining agile and flexible. This is the CMS (configuration management system). When opening Pandora's Box of one CMDB, introduce the concept of two CMDBs by which to manage what's really operating against what was last approved – now that generally strikes daunting fear in most IT organizations I speak with. The amount of data and the dynamic nature of the data today must include a level of automation to apply control and governance and still provide agility to the business.
The only “relevance” a CMDB and CMS provide an organization is when they are put into context of enabling IT organizations to move from managing technology silo's, which these articles focus, to managing services relevant to the business. The CMDB and CMS have no relevance on their own, it's what they enable that is relevant. Marrying policy, security and business objectives in a complex, heterogeneous physical, virtual and cloud environment to attain Intelligent Workload Management to make market time decisions is the enabling relevance of the CMDB.
On one final note, the public cloud and your providers, what should you know? The reason you move a service to the public cloud is to leverage extended capacity on demand without the investment and/or overhead of having those resources on-premise full time. The key word was “service”, you are subscribing to a “service” and the service warranty is what you care about, not their infrastructure and how it is managed. What this introduces into your CMDB and business aligned services initiatives is that you are responsible for the overall service, but you may not be responsible for all of the infrastructure. It will be imperative to “monitor” the service provided and bring that performance and availability information into your CMS view of services to have a holistic view of the service. It is not imperative to bring in the infrastructure components.
CMDB, CMS and business aligned services is a passionate debate depending upon your vantage point. So have you considered just how you will create your virtual service view and manage those business aligned services regardless of technology? Now and in the future?
Novell Business Service Management Solution
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.