New thought on Configuration Management: In a truly federated environment in which CMDB consumes data from other sources, the owner of the CMDB will little control over the quality of the data he or she receives. Do we need to review the goals of Configuration management or the roles?
Interesting question but possibly an academic one. I have never seen a real world example of a customer using only federated data with their CMDB. In fact instances where I work with a customer using any federation at all are rare. In Customer Support, there are two possible reasons for this.
1) It is widely used but very robust and rarely experiences a fault that customers want to report
2) Very few customers use the feature.
In most cases I can't tell which of these is the answer
Of course, I should say that a feature could be both very robust, and also not widely used at the same time :)
- it isn't as academic as you might think. We aren't using the Federation links in Atrium. However, I am currently consulting with an organization who has the concept of "Sources of Record" and Atrium CMDB consumes their information. We (as owners of the CMDB) can report any data quality issues but are reliant on the owners of the Source or Record to clean up their data. Rather than being the "Single Source of Truth", our commitment is to accurately represent the Source of Record. If the Source of Record isn't correct or provides faulty data, we have little recourse.
My opinion (granted I am not a CMDB "expert") is truly federated data is a mythical creature in a Atrium CMDB. There are probably some lesser-used niche cases where federation is used but largely I think the data has to be stored in the Atrium CMDB for most of the functionality to work.
I think 's use case if the first I have seen where they are looking to use purely federated links to another system. I think in an ideal world this is a neat concept. In reality I think the challenges Syd is face with will be the norm, and why most people will store the data in their Atrium CMDB instead of federating.
Syd, how is the performance using the federated links? I tried it out a bit around 2010 in 7.6 with our LANDesk DB for application data and we not impressed. We were not going to be able to use this data as part of licensing compliance so we knew right away besides performance that the lack of capabilities wasn't going to work for us.
I would venture to answer your question "Do we need to review the goals of Configuration management or the roles?" by stating that both need to be reviewed and updated if your data is going south. Data quality is always a result of definition and definition should always be stated in the CM plan. CM is the definition of what your CMDB will reveal. Do you have a CM Plan?
- we aren't using BMCs Federation. The data is maintained externally and then we run AI jobs to bring the data (with a fair amount of data checking and cleanup). So performance isn't really an issue. In the future, I think we are going to start providing some Federated links back to the source programs. They have a significant amount of contact info, cost info (stuff typically managed manually).
- that is a valid question. We have a governance document that manages the data in the CMDB. It controls the AI jobs that bring the data in, review and notification processes around data quality issues, processes for adding new sources of information.
The interest challenge with this environment is that we have several "approved" inventory systems. We take feeds of the inventory information in for our Applications, Servers, Network Info, Database Info, and Services. A very common ticket is "why isn't my CI in the CMDB?" Usually we can track the reason to some violation of "policy" of the inventory system that we screen for but the inventory system doesn't. In other words, our governance and control is pretty strong, but our authorized sources aren't so rigorous.
We are doing CM for the Atrium CMDB, but our sources of record aren't nearly as mature in their CM processes. We're working on it. ADDM is being used and pointing a number of issues that are having to be addressed. But we can only cajole, beg, bargain, or refuse to take their data. We can't add the necessary controls to make them more reliable.
In a follow up, question is really the heart of this discussion. My organization may be exceedingly siloed . But if the management of inventory is distributed, do we "distribute" CM? Personally, I think the best solution would be to have a framework the inventory systems would use and have to live by. We aren't there yet.
IMO, CM has to mature beyond the CMDB so that it's policies/processes/procedure's inputs and outputs extend to the Source of Record and Transaction systems. The CMDB is only one of the tools in the application of business processes that define Configuration Management.
Practically, it makes no sense to say that your Reference system (CMDB) has to comply with these objectives (x, y, z) when the inputs (Source of Record or data feeds) either don't or cannot supply the required component. Additionally, the CMDB really just holds or refers to "this is what it is since the last time we put the data in the CMDB" CI data. What's important is the transaction record regarding that data - the fix, the change, the release, the expiration of a contract on an approved system, etc. Sometimes the transactions take place outside of ITSM too so then how is the CMDB acting as an input to their requirements?
Once CM starts to be seen as a Business Process instead of the CMDB, then CM begins to develop as a Practice and the CMDB provides support to that practice.
Just to prove my theory that federated links are not really used. Adding to the academic aspect... from what I have seen there are two ways use the term federation is used...
1) the data is imported (copied) into the Atrium CMDB from another source. This other source is supposed to be the system of truth for that data.
I have been in discussions where instead of relying on discovered data or some other systematic data (monitoring tools, etc.) the federated source is a table in another DB where users are fat fingering data. Besides maybe removing some duplication of data entry I don't see much being gained in this specific example (of fat fingered data). Still highly prone to data errors and omissions by people. Why don't they just put the data straight into the Atrium CMDB/Asset Management (they are the same basic data so let's not differentiate).
I have an issue with this definition of federation. Sure the data is coming form other source but is it "true" federation?
2) What I tend to think of when I think about "true" federation (at least in terms of Atrium CMDB) is the data is not stored in the Atrium CMDB. All of the federated data exists in some other system (which could be an Atrium CMDB) and is pulled real-time into the Atrium CMDB upon demand.
Are these two ideas of what federation is the difference between conventional federation and productized federation in the case of Atrium CMDB?
Although after I typed that last paragraph I looked up the DMTF had to say about it: http://dmtf.org/sites/default/files/standards/documents/DSP0252_1.0.1_0.pdf
Page 9 states:
"The mechanisms and formats used to store data. The specification is concerned only with the exchange of data. A possible implementation is a relational database that stores data in tables. Another possible implementation is a front-end that accesses the data on demand from an external provider, similar to a commonly used CIMOM/provider pattern."
Maybe the concept of Atrium CMDB federated links tainted my train of thought regarding federation.
Alternately "The CMDB Imperative" does states on pg 128:
"Many CMDBs, especially in large environment rely on copy integration to get their data. This immediately makes the data's accuracy and authenticity suspect. Instead of using data that is duplicate, federation ensures you tap only into the one true source."
The debate rages on :)
Jason - Federated links and the concept of Federation tends to be a convoluted subject for 2 reasons: 1) Lack of definition on what Federation means, 2) Lack of capability to execute -whether system or user driven. My thought on the matter is that BMC has done some nice work to increase the system capability; however, without the user capability of understanding when and how to use it, the system capability is fairly useless.
Here is one of many practical scenarios for Federated links between the CMDB and SCCM --> Computer Systems (specifically PCs) are loaded into the CMDB from an integration with SCCM. SCCM contains a great deal of information that 'could' technically be mapped to the CMDB - things like CPU, memory, processor, OS info, installed software and about a 100 other things. But why map them into the CMDB when they're already in SCCM? all of those things are useful information facts for solving issues with PCs or even research for changes, but none of those items themselves are used against Change, no Software Contracts are being allocated, License Management isn't used, etc etc etc. It's alot of information that has the potential to change quickly, but has no practical purpose for the Transactions that need to be used against it. (At least as it's been defined for not-said company). So, what's the solution to extend the capability of a reference system? Use a federated link from the PC's CI to the SCCM URL page where it displays all of this information. People who need the information have easy access to various sources from one system. It meets the transactional business requirement, but doesn't over-architect the data requirements.
So my take on it is that Federation is what it is, it's the user's ability to understand the system's technical capabilities that allow a corp to implement a strategic plan to capitalize on data system(s)...
We could say the same for SQL DBs and the functionality to use DB Links to other DBs. If your DBA doesn't know what they are, when and when not to use them, can't create them, etc - then there isn't really a debate, it's just a lack of knowledge and an inability to utilize functionality that may or may not help the business with a strategic data plan.
Thanks for your thought. I agree with the CMDB/SCCM scenario. What I am wondering is that actually being done by companies? If they don't care to track those components for CM/IM/PM/etc. are they finding enough valuing by building the federated links?
"BMC has done some nice work to increase the system capability; however, without the user capability of understanding when and how to use it, the system capability is fairly useless."
That is true for almost the whole Remedy product line. What I am starting to find is much of what BMC has built it beautiful and neat but too complicated for many organizations.
Very few companies effectively use the Federation capabilities in BMC, in my experience that's due to a maturity problem in optimizing process service models.