MyCMDB? What are they smokin' over at Managed Objects?
[Update 2018: I heaped scorn on MyCMDB, but it was clearly a visionary implementation of ChatOps. Sorry Managed Objects.]
CMDB vendor proponents are often full of wind but this one is blowing a gale. What are they smokin' over at Managed Objects?
The IT Skeptic is immune to most vendors by now but three strikes in a row from MO is too much for me.
One, a recent blog post got me going.
As a manager, your ... [blah blah generalisations about management]...there are a number of similarities between effective business management and effective IT management – particularly, as it relates to the CMDB.
Draw that long bow almost to breaking point Siki, but OK I'll stay with you.
the CMDB provides a central focal point -- an accurate and complete view of the IT infrastructure
Oh really? In how many organisations? this is presumably an idealised view.
And yet, CMDB data inaccuracy is the number one cause for CMDB project failures -- followed closely by a lack of broad adoption of the CMDB across a broad set of constituents within both IT and the business.
Ah yes it was an idealised view. We are back to the real world now.
Going forward, the CMDB must be an absolutely accurate, trusted source of IT infrastructure information. In addition, the CMDB must be widely accepted and adopted across a broad set of IT and business users within the enterprise. IT organizations will each need to address both of these challenges for CMDB projects to be successful over the long-haul.
"Must" eh? And just how exactly?
Don’t think Managed Objects hasn’t noticed.
Innat nice? I feel better already. That folks is the end of Siki's post. Some platitudinous claptrap about CEOs, the most tenuous segue of the year to get us somehow to CMDB, admissions that CMDB doesn't work, wrapped up by a vague indication that Managed Objects are going to make it all better. Sounds like Siki was at CA too long.
Then I found this New Age woo-woo. This sounds more like the IT Swami than the CEO of a software company. There will be aromatherapy pyramid crystals in the CMDB next. Are you sure Managed Objects aren't a California firm? The post also contains a Crap Factoid gem but I'll issue an alert for that separately.
There's more where that came from. I especially like the way the blog's headlines don't relate to the posts. "We Are BSM": I think the "M" in "BSM" should in this case be dropped.
But the final straw is of course "MyCMDB", a social networking CMDB. Read the press release closely. It is an exquisite piece of vendor double-talk. The problem is presented in the second to fourth paragraphs: keeping a monolithic federated database up-to-date. Then the answer to a different proglem is presented: a "new visualization paradigm" [!retch] - a buzzword-rich environment which if you read closely is a bucket of bells and whistles for viewing only.
And fair enough too. Even if they are smokin' Acapulco's finest they wouldn't suggest letting end users update CMDB data. "Built-in governance lets users publish proposed CMDB changes while ensuring that actual CMDB updates are performed only by authorized personnel." i.e. we haven't eassed the workload any, we just let end users raise RFCs to point out errors. Not a bad thing but hardly a nooo paradime in CMDB data maintenance.
So what we have here with MyCMDB is YAFI, Yet Another Interface. Doesn't Siki remember how successful slapping a portal on Unicenter wasn't? That was the buzzword-du-jour then too.
"Social networking techniques are going to revolutionize IT management, by changing the way operations users interface with both the IT infrastructure, and each other," said Siki Giunta, President and CEO of Managed Objects. "myCMDB is not only the first-ever social networking application designed for IT, it represents the first delivery of the clearest, most concise strategic vision in the IT management industry today."
I'll have an ounce of what she's having.
Our industry has enough inept managers that vendors can actually survive by shovelling this stuff. Pile on the buzzwords, jump on the "2.0" bandwagon, make it new new NEW and there are enough idiots out there to fall for this crap. I guess it is appropriate that it was released at a Gartner Summit: an audience weighted towards the rich and gullible. Meanwhile Managed Objects' shiny new toy hasn't done jack about solving the original problem.
Granted there aren't many vendors around who actually make sense. As far as I can tell, you should add Managed Objects to the list of those who don't.
Made in New Zealand 
Comments
Another voice
Mark Lynd at Technology Snapshots:
They're still doing the bait-and-switch at MO
[moved this up to be a blog post]
Red Monk
The guys over at Red Monk reckon I'm rough on everyone who mentions ITIL, but ended up broadly agreeing with me I think.
CMDB on Wikipedia
Wow, I go away for a few weeks and all hell breaks loose. I don't want to get into a shouting match, but just wanted to share a story.
A couple of months ago, some people at my company asked me to step into a meeting they were having. Turns out they were debating whether or not we could say that the centralized data repository (with capabilities to stretch to a federated model) we have in our product was actually a CMDB. I will be the first to admit that I am in no way a CMDB expert, but I will also say I've read probably 100x more than anyone else here on the topic. The best part of the story - on the big screen in the conference room, they had pulled up the definition of CMDB on Wikipedia as their reference for what a CMDB is. Have you guys read it? Take a look. Would you base a product decision on Wikipedia? Would you base an operational decision on Wikipedia? Would you?
"Wikipedia information quality management". Aiiieeee
Wiki definition
Thanks for pointing out the wiki entry. I haven't seen it before and am no CMDB expert either but it mentions:
"In the ITIL context, a CMDB represents the authorized configuration of the significant components of the IT environment."
Now for something to be authorized it must authenticate. If a vendor has a CMDB does it mean that it can authenticate all IT components in the wild, because that is what it means? It has to be all because some companies interpretation of significant might not be the same as anothers. How does this authentication process work? Is a non-authorized component denied access to any other components?
It is clearly rubbish
It is clearly rubbish. The nice thing about a wiki is that all readers of this can go there and suggest or make changes. I've done so. I urge all of you to.
BTW the Wikipedia ITIL entries are quite good and much of the credit must go to Mark Gillett
Relax
Wiki is a good source of reference, when used in conjunction with other opinions.
(That's the bonus of technology, it can help to encourage/facilitate some discussion, but I agree to take it with a grain of salt)
Did anyone in your meeting mention consulting the ITIL library for the definition?
good thoughts on CMDB
Here's a kindred spirit with some interesting thoughts:
In other words, the vendor feeding frenzy is on.
Read the post for more good thoughts on CMDB
I've posted a rebuttle to
I've posted a rebuttle to your Kindred Spirit. Which I am happily reposting here, because your site seems to lack for any constructive or combative quarelling.
----------------------------------------------------------
Mr Araujo,
I have read ITskeptics blog and now yours, since this came to my attention, and I have some issues with your reviews.
I am intimatly familiar with the Managed Objects Product Suite, and your myopic review is to use your own words simpleton.
You don't understand its place or role in the integration platform that is Managed Objects. It is a small piece or solution to a problem thats vexed people for a while, um.. How do you improve your data? and we know that all data is crap, till proved otherwise, right? And as the IT skeptic is fond of pointing out that the wetwired individual is the place for that info, well it stands to reason you should appeal to him to play a key role, right?
In as much as your main three points:
1. Keep It Simple
2. Relationship Trumps Granularity
3. Process is Still Key
You show your naievity of and lack of experience with the Managed Objects Platform.
1. I'm a fond proponent of the KISS rule, Keep it simple stupid, and thats the only way to begin to make sense of a complex environment, where the relationships are all complex. This is step one with Managed Objects, the focus is quite simply on the Services that are Critical to You. And in most realities the stake holders are the sole repositories of this type of dependancy information. So again, why not leverage their expertise?
2. Understanding how technology impacts a service comes from having created the service model or logical picture of how your service/application looks and yields many of it's relationships or dependancies. Often this is only as far as you have to go. And yes, it's a simple thought exercise. People just have to do the work. That IS the relationship. It's rarely more complicated than that. But thats whats complicated.... yes, a real conumdrum.
3. Process? You are going to knock a CMDB enabling data support mechanism on a lack of process? (granted, why not, you don't understand how the integration platform works.) I thought you thought the CMDB was a respository of information the other processes external or internal took advantage of, *ahem* which Managed Objects does nicely. Want to compare objects(CIs) to their historical baseline? to other objects(CIs)? See all their changes? validate the data against an active discovered segment of the network? puhleez. you begin to loose any credibility you may have had.
ITIL is the process by which you decide how you want to take advantage of YOUR data, ie control your risk to unmitigated change. Now that you have the data, what usefull things would YOU like to do with it? Open an RFC to propose a change? Open an incident against a CI based on correlating a malfunction via real time monitoring, against a specific attribute, ie, an interface. And then look up all the CI's that have that same model of interface and begin to troll thru their alarm history for similar outages?
Surprisingly enough, I agree with your sentiment on a number of things, and in any other instance we would likely get along, but your review is malaligned and your conceptual grasp of how all the parts of the Managed Objects works lacks. It lacks depth of knowledge, comprehension, and for imagination.
So, Mr. I need an actively discovered cmdb, how do you improve YOUR data? How do you propose to inject the information that sits in the heads of the stakeholders into your cmdb to make it more meaninful? With REAL application and service dependancies? Cause connections from device to device don't always cut it. And Application modeling doesn't always cut it, cause there are always uniquely configured/architeched solutions that don't fall into a cookie cutter view of the world.
I should go on, but I shall not.
ice the cake with bullshit
Oh we get some good debates going here, don't you worry about that. And your contribution is most welcome (but let's try not to get personal OK?).
I think you missed my point. I'll take your word for it that MO make an excellent CMDB. You should know. And Araujo also said "I have been somewhat of a fan of Managed Objects". You should be careful not to alienate fans.
But I, and many others, am mystified as to how grafting the latest gadget onto it is going to help anyone other than the marketing department and the analysts (who are just an extension of the marketing department anyway).
i contest your assertion that "in most realities the stake holders are the sole repositories of this type of dependancy information". Unless you have a myopic view of stakeholders as being the key technical people within IT, then I don't think that is true. to the stakeholders, a service is something that comes out of a pipe. they don't know jack about how it gets there. And the people who do know don't need facebook to check the data.
"Understanding how technology impacts a service comes from having created the service model or logical picture of how your service/application looks ". How exactly does a collage of buzz-word-based user-interface gee-gaws help in modelling a service?
The criticism is not of MO's CMDB as a whole. It is of the attempt to ice the cake with bullshit.
skeptics != solutions
Alright,
MO doesn't need ingnorant fans. And neither does it need ignorant critics.
You question the wisdom of using a collective knowledge, or a tribal knowledge, and you question using a Database, since it's going to be out of date the moment you use it, and you question the wisdom of autodiscovery... I'm sure...
So, just what DO you believe? in Omniscient Discovery?
I assert that this site would be better suited to propose solutions than sling bullshit about applications you neither understand or have experience with. Correct me if I'm wrong, or post bombastic blather if you wish to dupe the next poor bloke that stops in. BTW, this is how you sound, and it makes me angry. (facebook, lol. you couldn't be further from the truth, and it makes you sound silly.)
The solution that Managed Objects has propsed is to give an Enterprise as many validation tools, either in the form of autodiscovery, element correlation accross monitoring and asset data, validating against change mgmt systems, or internal validation rules for manually entered data that has been determined to be correct or valid, to arrive at an accepted standard. Just because data is in someones head, doesn't mean it's bad. I'm frankly staggered that you would insult every stakeholder, operations person, or application owner, or service owner, who actually does KNOW something. I accept the stakeholder as something more than you do and It's smart to leverage what they know after it's been validated or accepted as true, and that process is up to the Enterprise to determine. Managed Objects provides the framework for that to happen in.
Now to the issue that you don't know how Managed Objects validates information is something you should remediate. I'll be participating in the BETA of MyCMDB to find out how I can make it usefull, because I know there is valid data in places I don't have a tool that can discover or leverage.
So its time for you to propose a solution. Feel free to provide examples, process driven use case scenarios, or simply constructive experience towards a better end.
Thank you very much.
it makes you sound silly
If you refrained from personal insults and angry rants long enough to read what is written here, and I mean posts other than those about your product, you'd see that much of the debate here is constructive.
And then if you calm down enough to read what is said about MO you'd see this is not an attack on MO in general. It merely questions the applicability of social networking tools to a CMDB and suggests this is pure vendor hype to get on the current 2.0 bandwagon. So all of your descriptions of the rich feature set and fabulous capabilities of MO in general are beside the point.
In terms of CMDB, I have long been a proponent that asset management, network discovery and other repositories are useful, nay essential. But the higher level logical mappings can only be done cost-effectively in people's heads, except in the most complex and advanced environments where automation may pay off. I question the wisdom of pursuing an idealised CMDB model for 99% of shops. That is an important idea, a constructive one, and one that is supported by the observed data so far in terms of success rates and paybacks from CMDB projects.
I'm a little bemused by your remark "facebook, lol. you couldn't be further from the truth, and it makes you sound silly". Perhaps you need to talk to your own marketing department, since the term is used on the MO homepage, it was also used in the press release which curiously seems to have been pulled but is of course out there in many places; and Siki's own blog describes MyCMDB as "a combination of Facebook interactivity, Wikipedia information quality management, and Google’s searching model".
Thanks for saying I'm bombastic - I'll take that as a complement. Someone's gotta do it.
Boring Basics and the Cult of the Amateur
With v3's announcement of an SKMS (Service Knowledge Management System) I suppose this was inevitable. I'm curious why MO used the CMDB term instead of SKMS, but I am not familiar enough with MO to understand why they may have done so.
Seems to me there should be more debate about the intelligence and analytics behind the 'knowledge' captured in these CMDB/CMS and SKMS beasts. Isn't that where the opportunity to automate really lies? Perhaps that cuts too close to home for some IT gurus, who want to continue being the 'experts'.
If you want to embed service-oriented analytics (ok I'll say it, "root-cause automation") into your management system, I don't think relying on a Wiki-style CMDB/CMS/SKMS is the best path to accurate results.
Having just finished The Cult of the Amateur I think can see why Skep may have taken his position. In part, ITIL's new vision of an SKMS may be contributing to this mess.
Evolving to 'autonomic' (another word I hate) computing may require monitoring intelligence and analytics with high degrees of accuracy; using Wiki-style knowledge will force the requirement for some kind of validation (CMDB audit?) to make this happen.
I'm not sure the SKMS should be the source for this, which may be why MO used the term CMDB. Only problem is, the Wiki approach seems better suited for an SKMS. Of course, ITIL makes fertile ground (to go with the bullshit) for confusion by depicting the CMDB/CMS as part of an overall SKMS.
The point is, relying on the Cult of the Amateur may not be the best way to keep the lights on. You'd better have some way of ensuring accuracy, which brings us right back to the boring old basics.
John M. Worthington
MyServiceMonitor, LLC
Hung up on SKMS? CMDBs?
John,
People, process, products and providers.
We need to talk about People though since it seems to be relevant to MyCMDB and skeptics and others disregard.
1. People; have always been the key reason a CMDB or ITIL or ITSM Project fails. You can't succeed in any of these ventures until the people who decide, and then drive the solution... care. And these are in fact different people. Ah.
So let me be frank. Databases Suck. People. ie the Masses can't visualize the data in a database. They can't make sense of a spreadsheet, or it makes their eyes glaze over, loose interest, loose heart, data is wrong, data is confusing perhaps but not wrong. Its HARD to look at a database and have it make sense. But you know what your data should look like. Who cares what the entire mess looks like, I can right my own ship, cause I developed it, or use it, or have a stake in it, am extending it, am responsible for it, etc.....
In a similar sense many CMDB's or Asset Databases don't have a mechanism in which to eaisly see the relationships between a device and it's service, at a basic level. There is A LOT of value in seeing this. This is another failure of how people 'see' in a loose sense the value of their data, or dependancy information. Again, who can you trust? "I" don't trust the application mapper, cause it's autonomic... but it's still wrong, and "I" don't trust the automatic discovery because it's wrong half the time, or doesn't have the connection "I" care about. So, lets have it... What DO you care about? ah... please enter your data here. Tell me what you know. great. thanks, now, lets go ahead and take that information and synchronize it with everything else we know, and create a mechanism by which someone agrees, this is valid data and can be entered as a defacto relationship, or ci, or attribute.
Without the people's buy-in, interest, self-interest, confidence! and continued service improvment ethic... yeah right I know I'm stretching it, you can't achieve even a reasonable amount of maintained data in a cmdb that is trusted.
I am not quite steeped in the SKMS matter you raise. I don't see how it has any bearing on the matter, so please tell me why you think it's more appropriate as an SKMS... not that It realy interests me.
The thing that interests me is now that I have valid data, how can I make it more usefull to the enterprise? What problem can I solve, what efficiency can I introduce, or develope, based on the need of the enterprise.
So, take a look at this in the aspect that there is a problem with CMDB adoption or ITIL driven Processes in a lot of Enterprise Organizations, because people tried it and died doing it. This is a means to answering why they failed, while at the same time making an attempt to inject more data that can be validated thru the processes the organization decides to use.
"Relying on the Cult of the Amateur" ... is in fact what many enterprise organizations do now, because there is no or little change management, and its certainly not supported by a solid repository of trusted data. They are the first years in the NOC, or on the helpdesk, and they don't know crap. But guess what guys, some organizations don't have a choice they have to start somewhere. So, the 3rd year or 8th year guy who's doing 3rd or 4th lvl support for an enterprise is a resounding and valuable resource for devices, and relationships, and data in an enterprise, and that information needs to be leveraged, so we can find that root cause based on the right dependancy mapping. And there is no replacement for what people know, right guys? And guess what, the guy who is the service owner knows something the 3rd lvl support guy doesn't, and thats important too. And that information needs to find its way into the System. This is one of those ways.
Or are you going to tell me you don't trust people, and you don't trust technology either? and you don't trust processes?
I'm open to hearing more potential solutions. Cause I'm interested in how to make my job easier.
MyCMDB or MySKMS?
Given this rant I surfed the MO site for more information. In fact, the 'MyCMDB' concept I found quite fascinating (what would you expect from MyServiceMonitor?)... the need for personalized views of CMDB data/information seems pretty obvious and a very good thing. Frankly, I also like the concept of leveraging Web 2.0 and things like 'Wikis'.
It's the use of that darned old 'CMDB' term again that kinda bothers me a little. While I like the concept of making the CMDB information useable for the 'Masses', I still think this seems more like a Service Knowledge Management System (SKMS).
from ITIL's (V3) Service Transition:
["Underpinning this knowledge will be a considerable quantity of data, which will be held in a central logical repository or Configuration Management System (CMS) and Configuration Management Data Base (CMDB). However, the SKMS concept is a broader concept that covers a much wider base of knowledge, for example:
Suppliers' and partners requirements, abilities and expectations
...
A service provider must first establish a service knowledge management system that can be shared, updated and used by its operating entities, partners and customers.
... Materials that can be included are:
]
I understand why the terminology may not interest you, but it does matter, the marketplace is confused enough (often as a result of marketers). I think what MO is doing is great, but don't let your spin doctors get out of control.
Regardless of whether it is 'MyCMDB' or 'YourCMDB', use of the term CMDB will require configuration management process, including verification and audit to ensure accuracy. I think you raise a great point in that MO may provide you greater ability to focus verification and audit activities where they really matter --- pretty important when your up to your ass in alligators.
But the use of 'Web 2.0' and 'Wikis' still seems more attuned to the ITIL SKMS than CMS/CMDB. These tools are focused on decision support, which to me says SKMS. In fact, although I am far from an expert in MO I would guess that you play in both CMDB/CMS and SKMS areas.
There is real danger in putting out bad data/information/knowledge....you should focus on the value of engaging People in validating this, in dealing with cultural hurdles, and in decision support. Naming the product 'MyCMDB' may have been asking for trouble.
John M. Worthington
MyServiceMonitor, LLC
Ah. Splendid. I see your
Ah. Splendid.
I see your point, and MO does in fact play in all those areas, but they are all muddy anyways. Take as fact that no-one agrees in practice what a CMDB is... across any enterprise, then why differentiate between a CMS or SKMS. Why worry about naming a thing, when the point is to arrive at IT Service Management. (Yeah fry me on it anyways, I don't really care about the name, but about the functionality, and the solution it delivers.)
I'm sure marketing took a look and said, what has greater name recognition.
CMDB wins hands down I'm sure, but I can't claim to know how or why it was named the way it was...
So, thank you for answering my questions about sematics.
Now, What about the Solution? How do you inject more meaninful data into the solution? How do you increase participation? etc....
"There is real danger in putting out bad data/information/knowledge....you should focus on the value of engaging People in validating this, in dealing with cultural hurdles, and in decision support. Naming the product 'MyCMDB' may have been asking for trouble."
I don't think I agree with you completely on the danger, as I said before, the sematics have to be agreed on in every encounter, nearly every meeting internally in an enterprise... in my experience. But like you said, engaging them in validating... and dealing with the cultural hurdles is the BIG challenge. And thats a function of leadership. No matter the tool you use, if your Management isn't behind the cultural changes of change and risk management then your solution is going to fail. It's just a matter of when.
So, again, the attempt is to provide a tool to those leaders, who want to make a difference in their ITSM/ITIL project, to increase their participation, and validation of the data that goes into it, by providing an avenue for interested parties to contribute.
Collaboration, Monitoring Intelligence and the Tipping Point
OK, we seem to agree on a few things after all...cultural hurdles, engaging staff in validating (CMDB audit), and leadership. I can't say I agree with you on terminology though, from the Customer's perspective it DOES matter and when vendors mix it up it makes the job of sorting out fact from fiction much more difficult (and makes you look like you're trying to get away with something)...
One thing I'd be interested in is analytics (i.e., root-cause, correlation, et al). I have thought for some time now that this is something that many players avoid (because they do not do it well) and I think it's pretty important.
After all, the right correlation approach might help accelerate the validation process by pinpointing service impacts (this may or may not be a welcome capability to some). It can also help leverage validated knowledge through automation (again, not always a welcome sight to some IT domains).
If we're going to talk about IT culture, why is it that I (often) get the impression that the ability to automatically detect which layer of which service component is the source of an anomaly seems so unwelcome? It is unfortunate that the combination of IT culture and the lack of capability by many of the bigger players often contributes to this perception and can contribute to failure.
Silo based monitoring is not just difficult, it directly inhibits the paradigm shift we seek. As you can guess, I'm a fan of intelligent service monitoring; do you play in this space or look to integrate with other players?
I think we've reached a tipping point regarding the amount of information a single person can deal with. While decision support tools like Wiki, Web 2.0, and CMS/CMDB/SKMS are very important, I think we'll will need to include intelligent analytics as well.
We can't simply 'collaborate' our way out of what is increasingly an n-tier, virtualized mess.
John M. Worthington
MyServiceMonitor, LLC
Walked right past MO
Skeptic - love the post, but gotta say that you're off when you call me "rich and gullible".
Speaking as someone who just got back from the Gartner show, I vaguely remember seeing a sign at the Managed Objects booth that said, "MyCMDB". In the half-second I had to process, I think I snorted, blinked and moved on. Anyone who thinks pushing together "My" and "CMDB" is a good thing deserves what they get.
present company excepted
When one slags off a group of people, one often inserts qualifiers such as "tend to be" or "weighted towards" so that once can exclude present company as the exception :-D
rich but not gullible?
well, I wouldn't mind being rich... ;-P
if you are not gullible then you are rich
A skeptic believes that if you are not gullible then you are rich
CM-Wiki-DB-pedia
"Even if they are smokin' Acapulco's finest they wouldn't suggest letting end users update CMDB data."
Not so fast, Skep.
You see, David McKee posted a comment to this that is worth a trip back to the site, if you haven't seen it.
This post wraps up your post with a nice big yellow bow to make the ultimate CMDB/Social Networksing/Wiki connection.
It's so rich, I'm getting all farklempt...
Today's (5-8-2009) Dilbert
reminded me about this thread.... http://www.dilbert.com/
John M. Worthington
MyServiceMonitor, LLC
The folly of the commons
The comment Ken mentions is here. It is a doozy. I have ordered a new book, The Cult of the Amateur which sounds like it is applicable here.
I've had a blog post in planning for ages "The folly of the commons". When you have hundreds of thousands of contributors for something like Wikipedia yes you do tend towards some sort of norm. When you have one or two anal zealots driving a dozen unwilling, like you will in most corporate wikis, the result is undisciplined inconsistent unreliable crap. Ungoverned Web 2.0 such as wikis only works on a massive scale or an informal requirement.
The folly of the contollers
I never mentioned users controlling the content of the IT Wiki. I hoped it was understood that those who actually work in the environment and have the knowledge in their heads would be the main contributers. If these IT stake-holders are, as you put it, "anal zealots" then regardless if they contribute to the knowledge base of a wiki-ized cmdb, the enterprise will fail.
The idea is to capture knowledge, is it not? The hope is accuracy of that knowledge. I believe that are a few good articles that examine the accuracy claims of a wiki-epdia against a printed encyclopedia written by a gang of experts.
Welcome...
David,
Welcome to the discussion.
In this most recent post, you write:
"I never mentioned users controlling the content of the IT Wiki. I hoped it was understood that those who actually work in the environment and have the knowledge in their heads would be the main contributers"
1. So what exactly is the mediating force here that keeps this from happening? It seems to me like you are contradicting yourself here. How would contributions of this knowledge not alter the content of the Wiki? After all, the ability for a registered user to directly edit Wiki content is one of the compelling benefits.
2. When it comes to the configuration of environments and applications, it's been my experience that it is extremely rare for consistent knowledge to exist about them. The pace of change is too high, there are too many changes and too many affected devices. Relying on (human) memory for such detail is inappropriate, unless your life is about maintaining that detail.
In fact, much of my work has involved bringing people together to discuss this and (ultimately) uncovering just how different their individual views of the area are. It's not that they're bad people or trying to cause things to fail. They just are working from a notion of how the world was, not how it is.
Memory is an imprecise and sketchy base on which to build an authoritative reference. If you want to engage people to discuss things and come up with new ideas, I'm all for using content management and collaboration tools to do so. Let's just not kid ourselves about accuracy.
You also write:
"The idea is to capture knowledge, is it not? The hope is accuracy of that knowledge. I believe that are a few good articles that examine the accuracy claims of a wiki-epdia against a printed encyclopedia written by a gang of experts."
In the broadest possible sense, I would agree with you. Yes, the idea is to capture knowledge. As the old saying goes, the "devil is in the details".
As far as the printed encyclopedia goes, there's no doubt that biases can make it into printed text. One hopes that the editorial process that the publisher uses help identify and manage them. Ultimately, the reader is free (compelled?) to consult multiple entries and make sense of it for themselves about what the truth is, if they are concerned about the accuracy of the entry.
Sites like Wikipedia have a more dynamic nature to them and it is undoubtedly going to suffer more problems related to individual point of view. Adding mass to a given point of view grants legitimacy that is not necessarily deserved, but it doesn't make it right/correct.
I feel that mashing the ideas of a CMDB and an encyclopedia together is the same as mashing an apple and an orange together. What you're left with is a mixture, not something that is more one (apple or orange) than the other. We also need to consider the specific content, the intent, rules for interpreation and management of content, as well as common usage scenarios.
Just because we can mash these ideas together, doesn't mean we should.
kengon
The possible
Kengon
Thanks for the welcome.
"Just because we can mash these ideas together, doesn't mean we should."
Perhaps, but just because something may be difficult, may never even reach a level of completeness one would desire does not mean we should not try it.
You are correct of course when you speak of human memory being in-concise, and certainly most data here would be updated by automated tools, discovery and the like, however the main focus is to have something instead of nothing.
I don't pretend to think that a wiki based pile of interconnected knowledge is going to exactly represent the actual ideal, but certainly it can get closer to reality than on-the-fly discovery and several individuals who have some bits of knowledge in their heads.
The idea as far as I am concerned is to be able to have some level of confidence in the knowledge, with the understanding that the accuracy is NOT 100%, and one should look further. In the same way that Wiki is a great place to start a research project, when the paper is turned in it really should have a bibliography that cites actual research.
In the same way, when a wiki-iezd CMDB is used, it invariably should be used in a similar fashion, and the knowledge gained by its use would then correct errors that were in it, thereby increasing the confidence factor of the knowledge stored. So in this case, actual data discovered in some small portion of a CMDB Enterprise would feed-back to correct that area - the data being "actual" should negate "bias".
You also stated: "We also need to consider the specific content, the intent, rules for interpretation and management of content, as well as common usage scenarios."
I agree, those things define the meta data constructs of the CMDB, and there are many others including new ones not yet thought of. Those things may be defined by the policies of the enterprise, or they may be just "things as the actually are". I would add one more important one that I mentioned above: Confidence factor. How confident am I that this data is accurate? And yes, even that bit of data could be skewed. I don't deny that mis-information can be added, but the goal is to have useful things.
I guess in a nut-shell, my position is that it is better to know something and be partially incorrect (and be able to test an improve my knowledge) than to know nothing, or scattered bits with no connection at all. Does a social network of stakeholders, knowledge experts, and discovery tools create a better "encyclopedia" of IT knowledge? I think it can. Can it also create a dangerous, biased tapestry that has gaping information holes? Yup. Just like the internet.
But I think we all agree that the internet and things like Wiki are useful.
David T. McKee
... is a function of perspective
David,
Thanks for your response.
I noted that you didn't answer my intial question(s), namely:
"So what exactly is the mediating force here that keeps this from happening? It seems to me like you are contradicting yourself here. How would contributions of this knowledge not alter the content of the Wiki?"
Part of the reason that I ask the question is related to the authoritative nature of the database. If you don't control the quality of the inputs (i.e. populate from a verified source), the data it contains and any inferences made using it are questionable.
In an ideal world, the CMDB is a reflection of how the real world is right now. In the real world, there's always (I absolutely hate absolutes) a delta between what the CMDB shows and what the reality is. Few organizations have the discipline, infrastructure or processes in place to ensure that there is no delta. Certainly none that I've worked with.
It seems to me that exapnding the set of data to contend without managing how that is vetted or introduced into the system is a recipe for disaster. Especially for something that is intended to provide an authoritative view on how things should be.
What do you have to do above and beyond (what is already not getting done) to manage this? This seems to me like a bridge too far.
In a certain sense, your statement frames the entire thing for me:
"I guess in a nut-shell, my position is that it is better to know something and be partially incorrect (and be able to test an improve my knowledge) than to know nothing, or scattered bits with no connection at all"
Yours is a valid point-of-view and I have no objection to it from a global perspective. Certainly, I have gained direct benefit from the very approach you've described, but it depended upon what I was trying to do. If I only need a rough idea to move forward AND the consequences of failure aren't that high, good on you then. "Close enough for horseshoes and hand grenades" is not a bad standard in such a situation.
Being appropriate to what you're working on is key.
If you are going to make a decision about whether to approve someones request to "foo the bar" on a production system and you're not sure that the data is accurate, you're betting that you'll not get bit. So, tell me, how lucky do you feel?
If you already know that the data is compromised and you just go through the motions "becuase that's how the process works", then you're complicit in the matter when it fails. Even if you're just engaging in a thought exercise or doing some basic deployment planning, it could make a signficiant difference to the decisions made.
You also note that:
"In the same way, when a wiki-iezd CMDB is used, it invariably should be used in a similar fashion, and the knowledge gained by its use would then correct errors that were in it, thereby increasing the confidence factor of the knowledge stored."
David, please, you don't need a "wiki-ized CMDB" to do that. You can do that with any garden variety CMDB (from Excel spreadsheet to a full-on vendor supported DBMS). All it requires is:
At this point, the person responsible for maintaining the database can research it and then update the database if it really is "wrong".
[While we're in the general vicinity of "right" and "wrong". Wrong (in the context I am using here) is not a function of bias (influenced or altered by a point of view). It's related to an independently verifiable fact. Anything else is just an opinion valid from a certain point of view.]
So, depending upon what was "wrong", I would imagine that that person would want to know what the source of the drift was and even (gasp) try to prevent it from happening again.
The feedback loop that you describe is fully independent of any technology.
You can get higher confidence factor for FREE when you increase the rigor.
But that's not necessarily a popular point of view when you're promoting tools (commentary, not accusation). I should know -- I work for a vendor!
It's much nicer to think (and pitch) that the new, shiny tool is going to help solve all our problems and relieve us of our responsibilities... but, that's a dialogue for another evening/thread!
Best,
kengon
real feedback can be savage
Having recently conducted a webinar for a partner and tool vendor, I certainly won't throw any stones here...
But truth be told, it would be interesting to get some real feedback on what I'm up to...as painful as that may be. Still preechin' service monitoring intelligence as an important enabler to ITSM adoption and, forgive me, used V3 and the CMDB concepts in the material.
I even quoted you Skep (with acknowledgements as you requested). Be happy to e-mail you a link as I did not want to appear to be 'pitching' on the site...
I can't play on the site if I can't take being savaged once in a while myself.
Keep up the good work.
John M. Worthington
MyServiceMonitor, LLC