CMDB Data

[alphasong]

The fundamental idea that relationships should be unified is wrong. Any relationship is defined by the two entity types it joins. "Unifying" relationships results in overly generalized CMDB models where a Printer can "contain" a Relational Database and other such nonsense.

Far too much of the CMDB conversation takes place without reference to relational theory. See Chris Date and Dave Hay for truly rigorous thinking in this area. Dave has even modeled some CMDB terrain in his latest book.

-ctb
_________________
Charles T. Betz

[Guerino1]

Hello Charles,

[alphasong]

The way I see it, the problem of CMDBs built on an overly generalized relationship model derives directly from the vendors and consultants who wrote the ITIL Service Support volume, and from the vendors and consultants who developed the poorly conceived DMTF OIM/CIM.

I as a data-oriented practitioner in a corporate setting have had to work very hard to undo the damage wrought by these misguided approaches.

So tell me again why end ITIL users need to abdicate their responsibilities to vendors and consultants?

If the CMDB acquirers would come to their in-house data architects, before reading ITIL v2 as a data requirements specification and assuming that all they need is four tables in a database, they would be much better off. And this does not necessarily mean that they go and build the thing in-house. A good data architect will help immensely in package evaluations and implementations. (I'm assuming that most shops big enough to justify a CMDB have some data architects around.)

Everyone has a stake in the conceptual data model, because that is the structured description of your business's universe of discourse. That is the first thing a Dave Hay or his peers will tell you. It is *not* something to just leave up to a vendor because they have been spreading fear, uncertainty, and doubt regarding the problem's "complexity."

CMDB is as complex as supply chain optimization or manufacturing ERP. It is no more complex. And massive efforts in those areas have failed when people abdicated their responsibilities for understanding the core business processes and data architectures, out of misguided optimism that "our vendor partner is handling it."

See www . tdan . com/i025hy04.htm

Yours,

Charlie
_________________
Charles T. Betz

[Guerino1]

Charlie,

I have to honestly say that if we sit you down with your CIO/IT Leader and the business leaders that have to pay for your ideas, I have a hard time believing that you will get the support that you think you will.

Your advice goes directly against common business sense, which is to not reinvent or re-implement existing wheels when there are so many other more important problems to solve. Using your internal resources to start from scratch and try and plan for, design, build, deploy, test, maintain, expand, and upgrade a system that has nothing to do with your core business and for which solutions already exist is something I would have to question. I'm sure your IT leader(s) would question it, too. I'm even more sure the business(es) funding IT would question it even more. However, I obviously can't change your mind so I won't try.

For those of you reading this thread, I recommend one thing... "common sense". Use the problem solving skills you've built up to understand your business' needs and whether or not what you're doing is time and money well spent. If it exists already, why would you do it again? Unless, of course, you have your own agenda and/or other personal motives that have nothing to do with the well-being of the enterprise you work for.

I recommend that anyone looking to implement any solution(s) takes the time to understand the bigger picture and all available options before taking on such an endeavor. Also, I recommend that you make sure that what you're doing is truly aligned to the goals and vision of your business. Not doing so is exactly what gives IT organizations bad reputations.

As always, I hope this helps.

My Best,

Frank
_________________
[Edited by Admin to remove link]

[jpgilles]

I agree with Franck that common sense should be used, which does mean I disagree with Charlie...

My take of "common sense" is that if IT is to provide your company with competitive advantage, you won't get it through standard, "one size fits all" types of solutions.... as soon as your competitors use the same solution.

That may take you back to the well known approach: 80% buy and 20% build...

cheers
_________________
JP Gilles

[alphasong]

So, if I am to understand correctly: "common sense" says that due diligence on a multi-million dollar investment - or a mission critical ASP relationship - is a waste of time and re-inventing the wheel?

-ctb
_________________
Charles T. Betz