More on CMDB – and Active Repositories

I've been having a conversation (via email) with BillN, prompted by my piece on CMDB here. I thought that I’d reproduce the conversation, with his permission, and see if anyone else had ideas in this area (there's some more background on CMDB here).

BillN: That was verrry interesting… A planning tool that can use the CMDB for a base can prevent all sorts of implementation disasters and cost overruns because it can deal with the very complex interactions that a full grown IT setup will have developed.

Over my many years in IT, I have repeatedly seen serious problems develop when managers with limited technical understanding won't listen to the warnings from the tech staff. Been there, done that, more than once.

But a tool that can demonstrate the complex impacts of a new project before it is committed to go could save all of its cost in just avoiding one large overrun. To my mind, this is the best reason of all to put a CMDB on the fast track.

The bigger the organization, the more value this represents. Think about the value of being able to fully understand all of the impact that a major new application (Sarabanes-Oxley for instance) will have before you commit to a specific design. And then when committed, the value of avoiding surprises to the project when later new apps are proposed.

Based on my experience, this would have saved each of the companies I worked for more than enough to pay for CMDB, with benefits in addition.

On another subject entirely, reuse, there is another area that could use an effective DB as a plan/implement tool.

David: It is all part of the old "active enterprise repository" idea, isn't it? Back in the 1980s, in Oz, we ran our (IMS) database out of a data dictionary, so we could validate program specs before coding them. Not only did we store our data analysis and generate database definitions, we collected operational behaviours, logged production failures against the physical side of the dictionary and stored database restart instructions in what had become an active dictionary, since restart and the decision to restart, was automated [normally, a failure just affected and stopped one transaction and there was no need to stop the whole database; repeated failures, for example, would result in an override of any generic “restart database” instruction – and this all worked because we had rock-solid transactional processing].

Then I came back to the UK and found that such ideas weren't popular [although you can probably still find commercial examples, even so]. But we did have data analysis and a data dictionary still and this [potentially] helped re-use - you could find candidates for reuse at the logical level, going in through entities [in fact, our reuse was massive, although it was mainly reuse of the security and printing subsystems and reuse of single database structures – nothing wrong with that, of course]. You didn't need to rely on naming standards [being followed in order to make sense of operational systems]...

But even that ended with OO in the nineties. I remember saying to OO gurus that you needed some way to find these low-coupled highly cohesive objects for reuse without relying on names - and being told I just didn't understand. Some years later I ran into one of those gurus again (Ian Graham, I think) and in the course of explaining why the promised OO reuse hadn't happened, he ventured the idea that they should have implemented a "catalogue" [aka repository?] of objects, back when they started… Now I can resurrect many of these old ideas in the context of CMDB, UDDI, executable UML etc. Things go around, they come around..

BillN: Looks like you were ahead of your time. I tried to get TPTB to accept the repository concept for developer assistance, even designed one myself when the commercial ones were turned down for cost, but I wasn't even allowed to work on it. Talk about short sighted.

David: Very few people measure "lifecycle cost"…

BillN: David, that’s a major miss by most IT organizations.

David: And this is partly because the use of stock markets for financing companies - and short term executive contracts - means that everyone's horizon is about 6 months out.. Whenever you see somebody doing something stupid, either they're stupid - or (more likely?) what they're doing makes a lot of sense (financially or career-wise) from their POV...

BillN: I don't see the problem as 'financing via stock market', but as 'measuring rewards by quarterly stock performance' because of the short horizon of most stock analysts. A few companies, such as IBM, still have a long view. Part of the problem comes from stock holders wanting gratification by quarter, particularly the large mutual funds which are also driven quarterly.

All of it stems from the 'instant gratification' theme that runs throughout our country. This short view, lack of patience, call it what you will, is the basic cause of a lot of problems we face.

David: Yes, fair enough...