Pink Elephant Blog
CMDB Federation Part 3
The first argument is not well-founded since how many CI's are we actually talking about managing? Many organizations by definition of an asset deem certain CI's not worthy of management simply due to their relative financial cost. (ie: keyboards or perhaps monitors) The larger organizations can get into the double and maybe triple digit thousands but that would be the outside number and this is well within the capability of the enterprise database solutions in use today.
The second argument assumes that having a source of record where we track all relevant CI's in relationship to each other and IT services is only of use to the processes focused on service management. This is simply not true — procurement, software configuration, audit, security architecture and engineering, and project management to name just a few disciplines also have a use for the CMDB. The primary reason why an organization has multiple solutions for managing data is a result of history, politics and IT procurement practices. Based on a traditional technology management view each IT domain is managed as a unique function and procures tools for its own needs. For example: The database group has a database on databases, the Server group has one database for Unix boxes and another for Wintel Machines, the application groups track their applications, the network group is just concerned with network components, etc.. From this perspective each group has built separate data sources to manage their own CIs. However what do you do when you realize that managing each domain in mythical isolation prohibits you from understanding the relationship of dependency between them? It is only when an organization begins to move to service orientation that this question becomes a burning issue. Unless an IT organization can understand how any technology component connects to another, and how they both impact a business process it is very difficult to claim alignment with business objectives. This paradigm shift requires the creation of a CMDB where CIs can be modeled in relationship to each other. However, more importantly how they are bundled to create systems which in turn support IT Services as consumed by the business. Once upon a time the business had separate applications to support business processes such accounts receivable, inventory management, procurement, payroll, etc… Each of them had their own separate databases on different platforms which needed to be connected through complex integrations. However, IT stepped up to the plate and said wouldn't it make sense to have a suite of connected applications all getting their data from the same primary central source with federation to other internal and external sources applied when necessary. The Enterprise Resource Planning (ERP) Suite was born! So if we preach this as a good strategy for the business what makes IT any different? The answer of course is that we are not, only a few years earlier in the maturity curve. The follow-on question then becomes why keep two tools to maintain data about the same CIs? Unless there is some significant functionality difference the choice to not consolidate these duplicate sources of CI data at some point in the near future is based on politics and emotion not logic and cost.
The final argument assumes that managing data once in a single repository is somehow more expensive than managing and supporting multiple redundant data sources and tools. It would be a very interesting exercise to do a Total Cost of Ownership assessment on the various tools in the organization today and compare it to a centralized solution. Add to this the resource time required to create and update spreadsheets and databases, often duplicated within and between technology domains. Each time an organization buys hardware, installs, supports, buys licenses and maintenance contracts for data management solutions it incurs an initial and ongoing cost. To consolidate even a 1/3 of these could represent a significant long term savings. Now to be fair for some organizations many of the current data sources are low tech and have limited overhead costs. It is difficult to suggest that doing away with the spreadsheets in favor of an enterprise CMDB would save money based on consolidation. However it is a true statement that maintaining both the spreadsheet and the central CMDB is not an efficient use of resources. Add to this the cost of developing complex integrations that are not required and the third argument is hard to justify. The next post will deal with a further definition of the second application of the term federation. Troy
Like this article? 
Comments