The CMDB as a dead elephant, it cannot be done ... NOT

[The following post appeared as a comment on this blog on the original "dead elephant" article, but I like it so much I've moved it up to a posting: "work with your supplier like your business did 20 years ago when they were starting with ERP in getting the functionality you need into your CMDB of choice. In short, step out of that damned box, stop moaning like silly end users and get the job done!"]

It never ceases to surprises me as an IT veteran how little people change while the technology evolves around us. In part I agree with some of the statements made here, but a lot I just do not.

It was about 15 years ago when I was talking to the logistics director of a retail company in Europe about implementing the ERP system they bought. Their 6 warehouses he managed were going to be rolled out and upgraded into the system. He assured me it was impossible, and he used more or less the same arguments that are used here. They had over 100000 items (counting seasonal goods), high and low turnover, emergency orders, people already too busy (and dumb) etc etc. In short: could not be done.

Now we in IT are used to end users saying their business is unique, not like anything else, impossible to capture blah, blah, blah. We tend to learn to ignore most of the chatter because at the need of the day we are able to address almost all issues. Users lean towards the logical fallacy that is well known, The Argument from Personal Incredulity, ie I cannot explain or understand this, therefore it cannot be true, or in our cases, be done.

To cut a long story short, 2 years later the system was in, running these warehouses very efficiently, the system was ordering goods and they were saving money. O yeah, before I forget, the logistics director was replaced 6 months into the project.

Lets move it up a notch. How about a car manufacturing plant, multiple product lines, and the whole thing run in JIT logistics? For those not at home in this field, JIT stands for “just in time”, ie the car manufacturer does not have any stock, he receives daily the parts required to achieve what is planned to be produced for that day. Think about it, for example the car seat required for that day. The exact number of seats for all cars, in the correct color and upholstery option are delivered daily to the plant or even in multiple deliveries during the day. This seat is only one of maybe hundreds of thousands of items, with a production line that does NOT stop for almost anything. But yet, they manage to make it work.

Apparently we as IT have cracked some very tough nuts in the past. Through the use of a good architecture, good software and changes to the underlying business processes we are successful in supporting our IT customers.

After reading this article I could not help but think that I had taken a time machine back 20 years. A CMDB has a low number of items, low turnover and probably no transaction data attached to it .. when compared to the business we support daily. It then stuns me when people say: can't be done. My current role that has changed from 20 years managing on the business IT side to managing implementations in the IT arena, the likes of CMDB's and other tools. I am confronted daily with the arguments (fallacies) I stated previously, and I use the same examples I user here (and more) to break those doors down. Basic number comparisons tend to humble the IT department when they see what challenges the business end is faced with, and that we as IT have resolved!!

Hard to initially populate?

Once more, look at how businesses do this. In my example of the 6 warehouses they had to come in on a Sunday, count everything in one day, enter that data and have everything ready for the Monday morning business. Easy? Heck no, but doable and done hundreds of time across the globe where stock levels have to be accounted for in a new system. In IT, where large numbers of stock (configuration) items can be reached automatically, where item turnover is measured in years, where we have low numbers of items (compared to the business), no transactions and no business pressure to fit in one day (or week or month), and this is not a doable action?

Also, a typical ERP implementation needs to take on existing data, a data load of 1 million+ records from 30+ entities is not that untypical. In IT we have maybe 30k, from about 3 different entities. The effort is truly trivial. We were implementing a help desk and one of the “issues” the management raised was the difficulty of the data load, ie taking on and converting data from the existing system. We went to the business, got the numbers from a recent data load for the ERP implementation they had completed two years back. They were stunned and rather shame faced when we put those numbers up on a slide.

Hard to sync and keep up to date?

I have been asked this question by C-level types a number of times. I turn around and ask them what their (IT) supply chain looks like. The look I usually get back is once of amazement and confusion. It never dawned on them to not only document and stream line the supply chain of the business, but also their own!! Businesses manage to sync their supply chain, track every item they have to infinite detail ... and the IT department cannot? There is no fundamental difference: there is a need, a purchasing process, goods received, warehousing and life cycle management. No rocket science here, just basic process definition and alignment.

Before I go on ... yes, in this process there will be manual effort involved. For some reason IT always thinks that they can only reach maturity through automated process. Crap (if you forgive my English). If it is good enough for the business then it is good enough for us. The CI is created when ordered, not when installed, it is activated when it is received at the goods in department, not when it arrives at the desk to some technician, etc, etc. We need to stop thinking like silly techies and learn from the businesses (that use solutions we as IT provide and support, oh the irony here).

We also sell tools to support data warehouses. I have been to major international banks that run data warehouses feeding off of 15 different data marts (all with unique data sources), containing tera bytes of data. These are kept up to date daily, where data lineage, reconciliation, consolidation, data redundancy checking etc etc is all done to deliver a data warehouses that supplies data to comply with some of the most strict laws on the plant, ie reporting in the banking sector. For those not familiar in this area I suggest taking a glance at the BASEL II regulatory requirements. If banks do not comply they loose their credit ratings, and we all know what that means. They keep this all up to date using solid tools we in IT provide (ETL tools, meta data repositories etc etc ... the irony starts dripping off at this point)

Now, here we sit with our piddling little CMDB, carrying maybe 200k records, most likely no transactional data, just “is” data, with turnover measured in years ... and it we cannot keep this up to date? If we were a business we would not survive for more than a week, and to honest, I would be ashamed to even make a statement like that.

No standard model?

Show one standard ERP model, and this will make sense to me. Our IT model is infinitely simpler than what businesses have implemented thousands of times. I actually had to read that statement a number of times to grasp what was being said. Huh? I strongly suggest counting the number of entities and attributes in ORACLE's or SAP's ERP model. Then please explain why this DOES work and any model we can come up with cannot.
Does a CMDB make sense?

This is all so reminiscent of the discussion in the 1980's about ERP packages. Would they bring the benefit they projected? Were they mature enough? They we are all sooooo complicated to implement. We are now 20 years on, and you would struggle to find any business that does not have some type of ERP system implemented. Not because of the hype, but because of the solid business benefits they all have achieved, after going through the pain first of course ... and the help of some very innovative IT folks!!

Sorry about the rather long rant here, there are a lot more example of here that are sorely based on the logical fallacy I mentioned previously. My basic message to all you IT operational types out there: Do not be so parochial, step over to the business side and talk to them. Look at the issues that have faced them over the years and how the resolved them. Document what you feel is important to your CMDB implementation and then talk to the business for advice on how to proceed. If you have a logistics director or other person in the know ask him to present supply chain basics to you to understand how this works. Find a good business analyst to help you document what needs to be done. Find an architect (preferably one that helped with your data-warehouse initiatives) to help you define your infrastructure to keep your CMDB up to date and tip top. Finally, work with your supplier like your business did 20 years ago when they were starting with ERP in getting the functionality you need into your CMDB of choice. In short, step out of that damned box, stop moaning like silly end users and get the job done!