Don't Let Federation Scare You! Some Common-Sense Recommendations for Effective CMS Deployments

To IT organizations struggling to get just one instance right, the notion of maintaining and managing a federated set of Configuration Management Databases (CMDB) as described in ITIL v3 can easily seem off-putting.
The truth is, however, that federation can actually introduce new levels of simplicity in defining phases and planning the scaled, evolutionary ramp of CMDB Systems. This column provides a few guidelines for getting “federation” right, combining a few overall recommendations for CMDB initiatives with some specific guidance for federation.

ITIL v3’s notion of a Configuration Management System (CMS) implies more than federation. It clearly stipulates that the CMS can have multiple CMDB’s coordinated through a core system in which consistent naming and modeling for Configuration Items (CI) and CI attributes become one of the key foundations for cohesively accessing different “trusted sources” of information.

As such the CMS becomes less a “repository” than a federated set of sources that can actually work together to enable more effective collaboration across IT in virtually all disciplines, from Incident and Problem Management, to Release Management, to asset management and financial planning, etc.

But federation can also seem complex and at times overwhelming.

The concept of a federated CMS is not new. Prior to ITIL’s introduction of the term “CMS,” Enterprise Management Associates (EMA) referenced a “CMDB System” (CMDBS) to stress the architectural role of CMDB initiatives -- as a set of technologies to enable the effective integration of multiple management investments to work together cohesively.

This has long been a distant dream for IT architects, which is now slowly becoming reality. For arguably the first time in IT evolution, technology, organization and process are coming together to help architect more streamlined foundations to promote more effective ways of working.

Recommendations

There are a lot of fairly consistent reasons why strategic projects of all kinds fail, or conversely, why they succeed. CMDBS initiatives clearly have some unique twists and turns, and they up the ante on planning and communicating– more than most. Below is a list of some key recommendations (both general and unique to the CMDBS) that should help you breathe a little more easily when it comes to planning a phased approach to federated CMDB deployments.

1. Define sufficiently detailed requirements: This may be pretty self evident, but the rush to get started on a tactical basis often overpowers better intentions to take a little more time and make adequate, detailed plans.



2. Insufficient attention to process: While by now almost everyone recognizes the need to pay attention to best practices, such as ITIL, in a very large number of strategic initiatives, process education is dealt with in an ad hoc manner, often after the initial planning is done. In almost every case, when EMA dialogs with these groups, they wish they would have invested more in process readiness up front.



3. Executive support: We see time and again that lack of firm commitment from executives can seriously disrupt strategic initiatives. Don’t expect to get very far in your CMDBS until you have strong top-down support. On the other hand, you can leverage an effective and very finite first-phase objective to garner executive attention. (Hint: EMA estimates that most senior IT executives have six-month attention/commitment spans – before they need to see results.)



4. Develop a good core strategic team: A good core strategic team for a CMDBS typically includes a combination of wide-ranging skills, including process expertise, communications expertise to support iterative dialog across multiple stakeholders, a mix of appropriate architectural skills overall, and expert data base skills. Outside services from your software vendors or strategic consultants can also be important in supporting you as you optimize your CMDB investments to your environment.



5. Select based on integrations with your own environment: There are a number of good choices for core CMDBs and what EMA calls “citizen CMDBs” – or products designed to assimilate data and federate into a larger whole.
   
   So don’t let a vendor get away with a rip-and-replace approach, and be very skeptical of vendors trying to leverage your interest in their CMDB to sell you every product they have. Some vendors are more forthcoming than others about their “third-party integrations” – but if you have to reach too far just to find out, it is probably not the right choice for you.
   
   Do an assessment first of what you feels your core monitoring, analytic, asset planning etc. solutions are likely to be, and then try out each vendor based on its willingness to support you in these integrations.



6. Staff stakeholder buy-in: Your “communicator,” with the support of process and architectural expertise, should be prepared to iteratively dialog with various constituencies across your IT organization and with the relevant lines of business (LOB), to help bring critical stakeholders on board and document their priorities and concerns. Ultimately, the goal is to enlist them as active and enthusiastic participants versus just consumers. Ultimately, they, as constituencies, are critical to your success in building a federated model with appropriate technological, political and process-sensitive roots.



7. Start Phase One with an eye to demonstrating value: Don’t forget that CMDBs are “enablers” and will not show value until they enable something tangible. First-phase objectives may be targeted at lifecycle asset management, or Incident or Problem Management, or Change and Release Management, or disaster recovery, etc.
   
   However, a successful first phase is usually even more narrowly defined than that – e.g. “lifecycle asset management for remote workstations and lap tops,” or “Change and Release Management for critical servers associated with XYZ applications.” This is where the federated model can really help you get started. You need to plan for the long haul, but you don’t need to boil the ocean in phase one.



8. Don’t confuse phases with CMDBs: It should be stressed that these phases do not necessarily correlate with an additional CMDB or MDB pulled into the system. Quite often, even phase one deployments depend on multiple federated sources in the sense of management data bases – e.g. a pre-existing asset management database that may itself be a point of assimilation for multiple sources underneath it. Phases should be simply defined to enable something specific, and their architectures should evolve as pragmatically as possible to fit those requirements.



9. Look for points of automation: There are a number of tests for whether you are or are not ready to go beyond Phase One into Phase Two, or Phase Two into Phase Three – in CMDBS initiatives. Some of the above items, like executive and stakeholder support, or team readiness, or level of detail requirements, continue to apply. However, one test that you should also apply is “how much have I automated in terms of updating, maintaining, and extending the CMDB System?”
   
   We recommend metrics based on cost per CI in terms of the above as a guideline. You might, for instance, intelligently define your next phase as moving toward more automation and greater efficiencies in maintaining and marginally extending your initial Phase One.
   
   Moving ahead when just maintaining your core Phase One investment causes you migraines is definitely ill advised.



10. Use common sense above all: CMDBS’s are not “products to be deployed.” They are ongoing enablers that can help to transform your organization in potentially hugely positive ways.

SUMMARY

Ultimately it’s the transformation, not the CMDBS itself that counts. Keeping your eyes and attention on that fact can prevent crusades that lead to nowhere, and allow you the patience and peace of mind to optimally prioritize as you go forward.