CMDB and WIKI. good mix?

[mrcasal]

Hi everybody, I'm starting to deploy the Configuration Mgmt in my organization.

We're using Remedy for Incident, Problems and Changes, and we're thinking about building a CMDB over Oracle DB and integrate it with Remedy.

My idea is, use Remedy in order to control workflow and use Oracle Database as CMDB master.

I'm starting to do it, but now I've a new variable.

The IT WIKI is being born into my organization. I'm very happy about it, because I believe that WIKI is a really powerfull tool for knowledge management. Everbody is cooperating, and adding differents things to the WIKI. Develoment teams, analysis teams, operation, service desk ....

I think that it's a really good way in order to manage all this huge amount of information. But I'm not sure about the future relationship betewen WIKI and CMDB.

anybody have any experience about a similar situation?
are the CMDB and IT WIKI going to fight till someone fall down?

My idea is to use CMDB as formal record track, and IT WIKI for general knowledge.

Am I too utopic?
Do you think that is posible to manage this boundarie?

I know that it's very long, I hope not to be very boring

regards

[rjp]

Never say never - innovation comes from people just doing what seems like a good idea. (Just remember someone else will be paying for it).

Having said that - caution - CMDBs and Wikis are in one critical sense opposites - Control.

The information going into and out of a CMDB is intended to be very tightly controlled. A Wiki works on the reverse principle in that it needs to be open to all comers to function as intended.

- If you think can get justifiable value, then go for it. Just be aware from the usage-philosophy and management-control point of view a CMDB and a Wiki will be pulling in opposite directions.

WRT to Wiki specifically as a knowledge management tool: Wikis are suppoosed to be 'tolerant' of inaccurate information. The idea is that over time a community of peers with complete access to the articles will ensure that what is a) incorrect, and b) cared about, will get corrected.

However, in an IT organisation there are a few things that may undermine the functioning of a Wiki - and prove costly.

* The community is small. Very small if you consider the levels of specialisation that may go into any one entry.

* No one may really care enough about any article to validate and correct it until a situation arises in which the have a use for it.

* Generally an inaccurate Wiki article does no harm if it's about the history of dance in Norther Africa. But as a knowledge base for an IT department, using an inaccurate Wiki article to inccorectly solve an issue that may, for example, be affecting every desktop in you company, could be extremely costly.

How are you going to QA a tech support wiki so that it doesn't pose a real business risk?

[mrcasal]

I'm agree with you, WIKI and CMDB could flow into opposite directions.

They are differents, I Kwon and I realise that they've different purpose, but I'm afraid about reach people feelings with this view.

WIKI is easier, and more friendly, it's open and it was born to share knowledge without constrains.

I want both in my organization, but I believe that the challenge is to highlight the different natures of each tool

Everybody must know that IT WIKI is not for incident management, or problem management or change management, WIKI is an usefull tool to share experience, and knowledege but is not the corporate aplication supporting IT process.
how can we get it?

if you have a really friendly and easy tool in order to manage your process, nobody is going to use another tool to post the same information.

if your process aplication is hard, difficult, unfriendly, probably people is going to work over WIKI or another else tool, and they're going to use the corporate tool as an burocracy mandatory.

I think that the trick is, like almost in life, balance.

your aplication that update CMDB by managing your process, must be a good tool, and WIKI must be and adicional and complementary tool in order to make richer the life and the inteligence of the entire organization.

anybody has reach a situation where these couple could live together friendly?

[itilimp]

At a slight tangent... which wiki tool are you using? Some of us tried TikiWiki at my place but are having real trouble getting support from some quarters who still prefer to write their notes in MS Word. Although we have a macro to convert documents into Tiki syntax, it is still tedious for screenshots unless you just upload the document. At which point it begs the questions why not just use document management or the HD knowledge base.

[mrcasal]

Hi itilimp, we're testing the tool, currently it's not running into live enviroment.

We're using MediaWIKI, and we've not test uploading an word file to the wiki, I'll write tomorrow in order to tell how you can do it.

With the ordinary installation, you can only upload jpeg files.

now we're investigatin about migration from MySQL to Oracle, we've to do it before to put it into live

regards

[Guerino1]

Mrcasal,

I believe that the Wiki and the CMDB are two totally different technologies, as one is for content management and the other for tracking entities, relationships, and depenedencies, throughout their lifecycles in your environment.

You may want to consider that using a Wiki may appear good on the outside but will actually represent a long term risk to your organization, since you're embedding your company's proprietary and core information in a technology that is not standard and supported universally. All Wikis are not created equal. It's not like throwing your data in an MS Word document that you know you can translate to other systems. I think that if you run the details and the risks by your business they may not appreciate them as much as you do the technology.

The other thing we've found with a Wiki is that unless you have a highly agressive and diligent group of people reviewing and managing the content before and long after you put it in, you will get a large quantity of junk in you Wiki, over time. Stale data won't get cleaned up and after a while your wiki will have more problems than it will present value. I'm not saying don't use a Wiki but recommending that you are very careful in how you do so.

As for the CMDB topic, I believe that if you saw a real CMDB you'd understand that it is in no way, shape or form anything like a Wiki, as a Wiki is all about content and links and a CMDB is all about live data and relationships and dependencies between it all.

I hope this helps.

Regards,
_________________
[Edited by Admin to remove link]

[mrcasal]

many thanks for your reply Frank.

I think that is a really usefull reflexion about this topic.
I'm agree with you, when you talk about the care you must have with this kind of tools.

WIKI do not fix at all with an hierarchy, it's made to build knowledge community, and it's not suitable for support any business process.

But I've faith, I believe that this kind of cooperative tools could be very productive and usefull in corporate enviroments.

One thing is clear, you always need a CMDB in order to use it with all your IT process, but I think that you can build a cooperative enviroment where people can share information, experience, docs ... in order to achive better levels of performance on the basis of daily work.

regards and thanks for your replys, it's being really interesting.

[mrcasal]

[itilimp]

Thanks, I know a lot of people use Mediawiki. The Tikiwiki already has the functionality for document upload so I don't think we'll be changing to another wiki. More likely they decide to put in something completely different! I was just curious

[LJohnson]

Consider that you are comparing an open technology [wiki] to a canned solution [CMDB].

Your comments would be more relevant if you were comparing wiki to databases.

A database without the definition of data and processes to interact with it is a raw technology in need of purpose.

A wiki without definition and structure is a raw technology in need of purpose.

TWiki recognizes this in their open source environment by coining the term 'Twiki Applications' which are much more than the more widely adopted 'Twiki plugins'. Granted, there are few open source wiki applications - I for one - am drawn to Wiki's and am eager to bring the ITIL definitions of Configuration Management to wiki.

In our organization the 'rigidness' of Remedy and Oracle databases do not lend themselves to rapid adoption of new technologies/processes/procedures. In my opinion, this is because they need to be defined before they are used (populated with data) - and only then can data be extracted and used.

The wiki and yet to be defined 'wiki CM application' would allow for rapid creation of information that can in turn be used to create the definitions for wiki forms for subsequent workflow process data collection. All the while, providing for enterprise wide distribution of knowledge as it is learned/acquired.

In short, CMDB is great for managing defined processes with defined data elements.

Wiki, with an application layer, can act as a CMDB as well.

Wiki, allows for start-up collaboration to aid and assist in defining both process and data elements; until they are mature enough to migrate to either the CMDB or the CMwiki.

Regards

[mrcasal]

Hi LJohnson, I'm really interesting in your reply

can you tell me where can I find more information related to 'Twiki Applications'

thanks in advance

[Guerino1]