IT Service Management Blog
Follow information regarding IT Service Management via this blog.

Avoid CMDB, Discovery, and CMS Provider Conflict. Just Do It.

My grandfather's cousin was in India and talked with a man who said he had seen the Indian Rope Trick performed, for real, as a child.  Really? My grandfather wanted to know.  Oh yes, he said he saw it with his own eyes.  And since it was still the 19th century, there were no phones cameras or internets to share them on.  So word of mouth it was, and therefore trust and a person's reputation for honesty and integrity carried a lot of weight then.


Are we so much better with a CMS today?  How do we take someone's word for the quality of data in your CMS.  Now, this isn't the "Is your CMS 'on fire'?" blog, that was about how to measure data quality.  This blog is about how to create data quality.  And one creates quality by paying  attention to the conditions that create quality from the very beginning.  Starting with trust, and then proving it with conflict.  Conflict can either weaken or strengthen trust.


My grandfather's cousin heard at a convention one time that provider conflict is ubiquitous, pervasive, a fact of life.  Really?  I don't think so.  I have challenged, and have yet to find, an example in which you must onboard two providers of the same attribute.  Don't worry, I'm getting to all the defenses.


Provider conflict occurs when an attribute of a CI has more than one active provider in the same scope, and a consumer (or a proxy thereof) has to choose.   So if you avoid this condition at system architecture, then you are ok.  But what if you have provide conflict today?  Wait a minute, how did that happen?  The COP model says, don't do that!


But what if a provider "goes down"?  Get the application back up.  If it is important enough to provide actionable configuration data, it's important enough to have a failover or backup system.  You're going to have far greater problems using (read-trusting) an out-of-sync, alternate, "backup"  provider than getting the proper provider back up.  This is a 1992 discussion and I think I'm going to fall over unconscious the next time I hear someone actually serious about this one.


Think about it this way:  you're the CIO, and you want a report of something about your IT.  Suppose you've asked for some data that is in more than one place.  Are you seriously going to allow the person who compiles your report to put conflicting data in the report?  You don't have time for this!  No CIO I know (yours either) should tolerate an answer like "well….might be A…could be B…".  That is what you are doing when you have provider conflict.  The CIO would want his report maker to go to the one source to which the business places accountability.  Not the "copy the lab people use".  Not even "Bill the important guy's  supplemental spreadsheet-o'-knowledge".  The provider that is accountable to the business.  There can be only one, in the same scope.  It's like the two clocks proverb, keep one clock in the house and you always know what time it is.  Any other number than one and you're not quite sure.


But what about, all those reconciliation engines?  Reconciliation engines are like nuclear power:  they can be used for good or evil, and, you don't want to get any of it on you.  Reconciliations should be used to establish identity, not resolve provider conflict!  As a corollary, data which is duplicated in multiple providers, for the purpose of identity, is not conflict.


Reconciliation engines implement "weights" and "rules" which can be used  for resolving conflict.  This is a needless waste of computing resources.  All those rules and weights must ultimately must reflect some kind of business logic:  engines and rules can't buy off the human decisions that basically tell it who the authoritative source is.  Is not that same information available at solution architecture time?  Just do the analysis once for all time, not a thousand times a day.


Do it from the beginning.  There is no reason to allow provider conflict to be introduced during system architecture or operations.  Simply onboard an attribute one time, and do not onboard it again unless there should be a change of provider (which will probably happen as you transform and improve your IT environment over time).  Just stop.  Just walk away.  "We already have a provider for that attribute."  will get you very far.


But what about curmudgeonly data owners?  Can't we just onboard Maria-the-friendly-admin's database?  It's accessible and looks good.  There's that issue of trust on the part of the consumers.   The consumers  invest trust in the data they consume, and the success of their actions based on the data are a measurement.  This is business-level trust.  You can't mess around with non-authoritative providers!


But what if I already have provider conflict?   First, stop onboarding any more provider conflict.  Then, audit, rationalize, and remediate, one attribute at a time.  Purge the conflict!  Then watch your consumers smile.  Don't have the political power to effect organizational change?  Get some help.  Get the wheel turning in the right direction.  Demonstrate the value.  Don't give up.  Or, email your resume to and…


But what about my grandfather's cousin?  Things change.  Trust, but verify - and certainly don't take the word of a last-century technique.  You have the tools today to see things for yourself.   Trust built on verification lets you build an excess of trust that you can pass on to your consumers,  rather than use up trust, which then uses up trust from your consumers as well. 


But what about differing scope? Not a problem my friend.    Those guys in Data Center X can do it any way they want.  But in our back yard, we all agree on who the authoritative providers are.


But what about discovery?  Discovery is an enigma in certain spaces.  Is it a special case.  Is it just another provider.  Must it follow the rules the other providers do.  I basically am saying, discovery gets no special treatment and should be treated from the CMS perspective just like another series of providers, no matter whether the discovery populates the CMDB directly or via another authoritative provider like Asset Management.


Discovery, because of it's necessary flexibility in having multiple ways to get things done, can be abused with provider conflict.  For example, SNMP discovers an attribute of a server named "model".  SNMP returns a value of "foo".  However, WMI returns for the same attribute, the value of "Foo.42".  They mean the same thing, everybody knows that foo IS 42.  But the values, when compared for equality, are not.  Wise discovery managers will rationalize each attribute discovered, and avoid provider conflict.




One need not suffer under the yoke of crappy configuration management practices or oppressive reconciliation engines. 


It is not only desirable, but possible, to avoid operational provider conflict.  If you do you CMS will be trustable.  If you don't, it won't.  Would you like to trust your CMS?  Just do it.

I hope this gives you some hope for the future.    Be liberated by knowledge! 


Check out our best practices library:  CMS Strategy Guide, Provider Onboarding Guide, Consumer Onboarding Guide, Discovery Onboarding Guide...we've got 'em.  Come get yourself come CMS chops at our shop!


Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Showing results for 
Search instead for 
Do you mean 
About the Author
Jody Roberts is a researcher, author, and customer advocate in the Product Foundation Services (PFS) group in HP Software. Jody has worked ...

Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.