Change Management and Air Traffic Control

For the last post on Change Management I used an airline analogy since they always seem so appropriate in relationship to this process. Doing so triggered my memory of another meaty metaphor along the same lines. For this story I have to give full credit to my good friend George Spalding and he will probably accuse me of using his best material but at least I give him full credit.

The Pink Elephant FAQ

The most frequent question I'm asked is "how did you come up with that name?" It's not always the first question that crops up, but usually after all the business discussion is out of the way I can almost count the seconds! "....... so how did you come up with a...

Service Owner — The Missing ITSM Role

There has been much written about the role of the process owner being a critical success factor for any effort that attempts to manage cross functional processes across a silo based organized. However, processes are not the only things that need to be managed across the deep management chasms that separate our IT domains. Consider that most IT Services are also agnostic to organization charts and require the same enterprise accountability and oversight. 

Not Ready for The CMDB

When you navigate the Blogesphere in search of comments on thoughts about the CMDB you often find very skeptical individuals who claim it cannot be done as described in ITSM. While technology and the amount of data requiring management may seem daunting please consider that the most difficult challenge to successfully implementing a Configuration Management Database is typically IT culture. In Short many companies are just not ready for a CMDB! In my experience most organizations are not culturally ready to tackle a CMDB even though I believe that it is something that is inevitable and maturity around Configuration Management and Processes in general follows a similar pattern.

CMDB Federation Part 6

This is the sixth and final of a series of posts dealing with the concept of CMDB Federation. CMDB Federation Summary A key benefit of adopting a best practice standard is the adoption of a common language. However, consider that the term ‘federation' is used by many in regards to implementing the CMDB but has three separate applications depending on whom you are talking with.

CMDB Federation Part 5

This is the 5th of a series of posts dealing with the concept of CMDB Federation. Application #3: CMDB Federation the Dynamic View of Existing Data The third definition of federation is much like the one we just addressed and struggles with many of the same challenges. However, in this application a central CI record is not actually created with a replication of chosen data from distributed sources. This model is based on the concept of creating a dynamic view of a CI by pulling from existing data sources each time a request is made.

CMDB Federation Part 3

This is the 3rd in a series of posts dealing with the concept of a Federated CMDB There are three traditional objections to this first application of the word federation:

 
    • The database would be huge and performance would be an issue
    • The ITSM processes don't need all of that data so why would I mess up the CMDB with information these processes don't require.
    • The cost of this consolidation would outweigh the benefit

The Federated CMDB Part 1

The emerging capability of federating data sources is the biggest boon and the largest potential pitfall that has arisen for the discipline and process called Configuration Management! On the surface this may appear to be a completely contradictory statement. However, as is the case with all good intentions it all comes down to the application. First and foremost, database federation is an absolute must for a successfully Configuration Management Database (CMDB) implementation.