A cool look at ITIL
Now that ITIL is the de facto standard for IT operations, the time is ripe for a more objective evaluation of ITIL’s merits and caveats. Let's do that on this website. In the ITIL world it is still spring or summer. This blog seeks to balance that with an icy blast of winter through the techniques of the skeptic – consider the observable facts and question the underlying assumptions – as well as applying that other great Litmus test: common sense [Common sense is something that used to be common, hence the name. You youngsters look it up on Wikipedia].
The IT world is traditionally split into development and operations halves. In the operations hemisphere, ITIL has been the centre of attention for most of this century. If you have anything to do with running computers and you haven’t heard of ITIL, you should read up on it, if only to be in the know at those awful parties where IT people talk their own language like some secret society.
Gartner have a most useful model for considering the waves of irrational exuberance that regularly sweep across the IT industry: the hype cycle (see a picture of it and more info here). ITIL is somewhere around the peak, though it varies around the world. I think it is not in the trough yet anywhere: it is still greeted with acclaim and enthusiasm and often inflated expectations. But progress down the slippery slope is beginning. Hopefully a little objectivity now can reduce the height of the peak and the depth of the trough, and ease the transition into a more stable maturity.
Please come along with me on this journey as we explore the winter side of ITIL. I will post more thoughts approximately every when I get around to it. Your comments are not just invited, they are expected. If we get enough interest, I will open up a forum here too. If anyone feels they have enough material on this topic to run their own blog, contact me.
I urge you to please consider registering as (a) you can then get notifications when I add something (b) you can take part in the forum if we get one later and (c) it's only polite to identify yourself. You can still add comments even if you remain anonymous: I'm more interested in your opinion than your identity.
[There are many more reads for this page than the others in the blog. You guys coming direct to this URL know there is more to the blog eh? See the blog link below or in the menu at top right]
OK look away now, go read the rest of the blog. This next bit is for the search engines:
Still reading? You would be amazed how many people search on "[something] sucks" to find or measure negative sentiment, so let's say ITIL sucks even though I don't think ITIL sucks and i wouldn't say ITIL sucks but just for those who might have used ITIL sucks as keywords. Likewise people may look for an IT critic. I don't mind being called the IT Critic, though IT sceptic is more accurate I think. Though it is fair to say I am being critical of ITIL so IT critic fits. And we do cover ITIL problems here because there are problems with ITIL and a sceptic would certainly examine ITIL problems. Note I spelt it IT sceptic for all those good folk who use the dictionary spelling of sceptic not the skeptic variant we skeptics use.
Made in New Zealand 
Comments
Don't let ITIL happen to your business
ITIL is an outdated business philosophy that has become the defacto example of how NOT to run a business. It is grossly inefficient and the loss of worker productivity is enormous. In an ITIL environment, the typical IT worker (the people actually doing work) spends about twenty five percent of their time dealing with and performing ITIL tasks. That’s about two hours of unproductive work in an eight hour day. The resulting information and data gathered from ITIL processes is completely useless when it comes to developing efficient methods of responding to IT issues and providing good customer service. By the time some analyst or researcher compiles their data and makes recommendations, the entire situation has already changed and any resulting decisions and changes are way off course and simply create more inefficiency. ITIL creates and perpetuates inefficiency.
One of the biggest fallacies of ITIL and similar business models is the belief that there is some sort formula or equation that can be used to determine the number of employees that are needed to provide adequate customer service. Once you hear management talking about “ratios” and “metrics”, your business is destined to fail. These ideals have destroyed every business that has embraced them.
Most customers have unique needs that vary from company to company as well as individual to individual. Creating “one-size-fits-all” policies and procedures is an inefficient way of providing IT services. Having standard baseline procedures are fine as long as you have good workers who instinctively know when their customers’ needs have changed and adapt accordingly. The time and money wasted on surveys, form filing, data gathering, analyzing, and meetings would be better put to use in adequate up-to-date worker training. No one knows the work as well as the people who DO the work.
Good customer service starts with having well trained IT personnel run by a good first line supervisor. Having that eliminates all of the ITIL waste and streamlines IT responses. Oh, but the proverbial bean counters will disagree! Everything has to be documented, studied, analyzed, talked about, meetings held, and decisions made by those who have no idea what the workers actually do. What a waste. If you fired all of the bean counters and hired actual workers instead you’d be surprised at how much work would get done. Yes folks, ITIL does suck, and ironically, the data proves it. And I know, since I’m stuck in an ITIL world where the higher-ups wonder why things don’t get done with the number of people we have. ITIL creates a lot more inefficiency than it eliminates. Don’t let ITIL happen to your business!
DG Streiland
Don't shoot the message
Shoot the messenger not the message: bad management is bad management however it is labeled. Sure anyone who manages only by numbers is a bad manager. Sure bureaucracy that makes process less efficient is a bad idea. How many "ITIL sites" have you experienced? One? It doesn't have to be that way.
(BTW, you clearly are refering to Incident and Request management, as your world seems to be a service desk one. ITIL is far more than service desk. )
ITIL is better than no process at all. ITIL is just a tool to describe the standard generic portions of a service improvement programme. The result is the result of the programme, not of ITIL. The house is the result of the carpenter not the hammer. If you are the victim of a bad improvement programme you should no more blame ITIL than blame HP for providing the servers - it is what your company does with them that matters. If you need some external agent to blame for your situation, why not go back to The Devil? It makes as much sense.
Actually I don't think you should feel bad. You clearly work on a service desk that is nothing short of miraculous: support analysts who work better without supervision and can determine their own processes ad-hoc according to circumstance. I'd travel a long way to see that. Take videos and sell them - you could make a killing, like videos of two-headed goats and freak waves.
Seriously, you have identified exactly what the problem is with most service improvement programmes: "Good customer service starts with having well trained IT personnel run by a good first line supervisor". Precisely. Improvement is totally dependent on people factors: communication, education, motivation.
The choice of process tools you use has little influence on the outcome, so long as you have them. Otherwise you would be inventing your own, like a carpenter tying a rock to a stick to drive nails. ITIL is a pretty good choice in most cases.
Good Process is related to Good People
it certainly seems like our blogger is on the savage journey!
but I can't help but suggest that good processes are often the result of good people... it is interesting that when we have good running processes we take them for granted and don't hear much about 'process'...but that doesn't mean they aren't there....
ITIL suggests some guidance (from good people) that has been proven to work in many different environments... it's the adaptation that can get us in trouble....that takes People skills. Teamwork. Experience. Patience. Understanding...
and Attitude.
John M. Worthington
MyServiceMonitor, LLC
What is the difference between Good Practice and a Best Practice
If Service Management is Religion(eg.Christianity), can any one let me know what is Best Practice? Is it Bible? What is Good Practice? Believe this is a silly way of asking a question, but still, trying to understand more about ITIL, being a novice in the Service Management.
Thanks,
Rama Rao,
Change Manager at CSC
ITIL Sucks - One for the Google Count
From a North American perspective, methodologies like ITIL are the reason why the British no longer have an empire. Failure is OK with ITIL, as long as you followed the proper process.
I keep thinking of the British Army battle with the Zulus in the 19th century when the British lost the battle because the quartermaster insisted on troops filling out the proper requests for ammo in the middle of the battle. The troops ran out of ammo, although the quartermaster had plenty of ammo, and everyone was overrun by the Zulus carrying spears.
Of course, the quartermaster had all the paperwork filled out properly, which is commendable, although, his severed body parts were placed in the paperwork basket.
I can envision a YouTube spoof of Apollo 13 with NASA following ITIL processes. "Putting together a CO2 scrubbing canister from duct tape and plastic bags is not in my job role. Do you have a change request for it? After all, it's not in the manufacturer's design documentation."
What gets me is that ITIL is almost the 180 degree opposite of TQM, which was the big fad of the 1980's and 1990's.
ITIL disperses ownership of deliverables too widely. The result is a "Tragedy of the Commons" when it come to process ownership. To overcome the "Tragedy of the Commons" problem, you have to have a huge staff to make up for the shortfall, which is unworkable, especially in today's global economy.
ITIL is another management fad that needs to die, die, die.
Totally agree with you.
Totally agree with you. ITIL has created a bunch of excess IT jobs. Sheesh, where I work we've got analysts for each touchpoint within a process. When I started 25 years we were Systems (or Programmer depending on your take) Analysts and did the job end to end. Sure, we have great tools now, but why do we have to have 5 cookie cutter type jobs to get something done! ITIL, SDLC, Six Sigma please go away!!
Tool Standard - OGC
See this link for the story on the new ITSM tool standard from OGC:
http://searchcio-midmarket.techtarget.com/news/article/0,289142,sid183_gci1349709,00.html?track=NL-1014&ad=691872&asrc=EM_USC_6060584&uid=8271475
Now there's a single standard for ITIL compatible (NOT COMPLIANT - ITIL is a FRAMEWORK!) Tools.
Does this move ITIL towards some maturity - is it still SPRING or SUMMER?
standard?
I'm going to blog on this latest turn of events soon - gathering facts. I am greatly concerned by the use of the word "standard"... amongst other things
ITIL is great for trainers and companies offering classes
After more than 20 years in the IT industry I have never been more frustrated than I have been with ITIL. It is overblown and misunderstood. In my opinion the fad took off because the certification is relatively cheap and very easy to obtain.
The uneducated IT and HR professionals found yet another certification to base their lack of IT knowledge on when hiring people.
I am ITIL certified and pretty much laughed through the course. Apparently no one in the IT field is aware of the COBIT framework which combined with something most organizations lack...common sense management...will acheive the same results at a fraction of the cost.
ITIL offers some good advice, but it is not new information. It is taught in business schools across the nation. ITIL was created in the United Kingdom for governmental agencies that were run by non-IT people.
I'm sure trainers love it. In my experience, most have not implemented it or worked under for a number of years.
Just wait...something else will come along and every moron with a check book will run to that fad.
Definatly Fall
This looks to me like another effort to suck as much cash out the ITIL trademark as possible until it is completely worthless (mentioning it on your website will decrease your page rank...). I may be wrong, but again customers will pay the price for this. They will pay extra for ITIL compatible tools (the audit comes at a cost), will stop benchmarking the tools against their own requirements (hey, it is OFFICIALLY ITIL COMPATIBLE, it should work) and again will believe IT service management to be a product that you can buy at the local SW shop.
*sigh*
Nobody is perfect
So tell me where ITIL condones failure? What ITIL does say, if not explicitly, is if you do fail then admit and learn lessons from it. In my experience that is the vital first step on the ITSM journey - accepting your high KPIs are the result of poor KPIs/measurement systems/management bias and not good performance.
I think you'll find that what happened in the Zulu wars was more a case of the ammo being on site, but the tools not being available to open the box. Sounds like quite an important lesson to me, and of course the British army has had a few successes since then to add to their battle honours. The trouble is in life we have to be taught the same lesson time after time.
I'm not a great fan of the Apollo 13 simulation, but a lot of us have been using Apollo as a case study from the early days of v1. For instance the quote that the reason the Apollo programme succeeded is because they had good configuration management in place, which allowed them to know exactly what the crew of Apollo 13 had in the capsule so they knew how to build the workaround. Sadly Nasa only learnt that lesson after three astronauts died, partly because Nasa didn't understand how various CIs interacted - and partly because - oh, they designed the hatch to the capsule so it couldn't be opened from the inside.
As for dispersing ownership, I guess the Toyota model has sort of passed you by, rather like your automotive industry ;-)
The Quartermaster was innocent - astronauts in IT?
There were in fact two Quartermasters Pullen and Bloomfield. Many still debate their guilt. I now believe both were innocent and my reasons for that follow. Also, since when did rescuing astronauts and racing formula one cars become a much valued IT skill? First - the zulu story:
I have actually told the Zulu story, albeit with some embellishment, on my classes for many years. After a hundred years of shame and ridicule it was discovered in the late 90s that the Quartermaster was not to blame, his name has since been removed from the army wall of shame... A team from Oxford University returned to the battle field to investigate whether English 'best practices' had been our downfall. They discovered the firing perimeter was more dispersed than 'standard practice'. They also discovered plenty of ammunition boxes still littering the perimeter. they had been broken open with rifle butts and prised open with bayonets. Why? Because they were all originally screwed shut with a special screw that could only be opened by the Quartermaster (QM).
So there is little doubt that when push came to shove the QM handed out whatever he could as fast as he could. Unfortunately, allocation points were based upon troop positions and some troops were more distant than policies and procedures stated.... Remember, all he needed to do was account for it - hence all the chits of paper found around his body. The investigative team visited a local Zulu leader to find captured rifles. They found them! On inspection they discovered at least 3 rifles that were proven to be authentic. The main rifle was the Martini-Henry supplied to all troops at Isandlwana, Rorke’s Drift, and Ulundi (The battle you are referring to is the former).
The Martini-Henry was a modified American Peabody (Patent 1862), a single-shot, hinged falling-block rifle, developed after an exhaustive series of tests during 1866 to 1871. It was employed to ensure a huge hole was blown in the attacker, this was to overcome the previous issue of having to shoot most zulus 2 or 3 times because they had juiced themselves up the night before on a trance inducing local herb!.
Anyway, when taken to a lab and the conditions of the battle recreated (95 degrees and dusty), the guns jammed consistently after 8-9 shots. The marks on the breeches backed up this hypotheses. They were bayonet marks. The men were obviously trying to unjam the gun. Guns jammed, fire rate drops, line overrun. Game over. So much for the British 'best practice' jab - but it was NOT British doggedness that lost that one. In fact the same discipline won a famous battle and numerous Victoria Crosses the next day at Rorke's Drift (Zulu - Michael Caine...).
So, as always in a problem situation, there were a number of contributing causes to the loss - not one bead practice or one bad person. Remember - a best practice is one that can be applied as a must-do, and then adapted as a need-to..... a best practice that cannot be adapted based upon changing circumstances is not a best practice at all.... I think thats termed 'red tape' (there is a story on that as well!)
One quick note on simulations. May I remind everyone that although fun is important, the primary purpose of a simulation is to mimic real life and allow participants to practice scenarios and their actions in safety. rescuing astronauts and racing cars has little to do with simulation an IT environment!. These 'simulations' are more akin to team building exercises.... and how you can cover the expanse of ITIL V3 (twice V2) and run simulations in the same time as a V2 Foundation class is beyond me - something has to give....
Learning vs. Teaching
The evidence for these experiential simulators is very high.
Forget team building or that simulators allow participants to apply practical decision-making and quickly see the consequences without fear of failure. A useful managerial teaching tool even on a bad day.
The power of these games lies in their demonstration of the traps that occur because ITIL (or IT) practitioners do not think in systemic terms. These games have been played over many years with participants across diverse backgrounds yet the same qualitative behavior patterns emerge (crisis, chaos, fiefdoms, collaboration, order, improvement, mastery). The individuals are part of a larger system but perceive this only vaguely at best. The game is designed to parallel the silo structures that happen in real life, whether in IT, NASA, airports, or raceways.
It teaches that the causes of its problems lay in the structure of the game--workflow, information flow, decision making policies—not in the individuals themselves. In other words, the structure of the organization determines how it behaves. This is precisely what happens in the real life of IT organizations.
The key to real improvement lays in changing these things. The learning comes when participants see how their performance connects to the way they think. They stop thinking in terms of static snapshots (“incidents” or “service requests”) and begin to discern the structural causes of team performance. They then learn to focus on desired outcomes rather than reacting to the event of the moment, to break their tendencies toward linear, reactive thinking.
Teach this in a classroom and its academic theory. Teach it in an experiential simulator and its pragmatic.
They also learn other important aspects to organizational improvement: anticipating and recognizing delays between action and consequences; the patience to deal with the delay; use patterns of behavior as a diagnostic tool; in order to succeed the rest of the team must succeed as well; and so on.
[In case you were wondering, I do not make or sell any simulators. I use them to teach my staff. The level of competence and insight for participants always rises dramatically post-simulator.]
Would you train a pilot in a train simulator?
Hi 'visitor' - I agree - simulators are fantastic incubators but I think you are speaking to loose use of the term 'role-play'. At best the games you refer to are process improvement tools and as I suggested, good for 'team building' exercises. You should be able to use them again and again with different scenarios and the same people... For practice makes perfect goals, and exploring and responding to new and emerging situations... typically these are all play once games. Once you know how they work behind the scenes - they get a bit boring and lose value.
I am speaking to the (mis) use of the term simulation.
Does it make sense for a surgeon to be trained in a flight simulator, or for a pilot to be trained in a train simulator - no. Will an IT professional gain usable experience of managing IT services by racing cars or rescuing astronauts? Of course not. Yes - the role-play games we see expose those involved to the woes of silo and disjointed operations. That is why I termed them team (or process) building sessions. Although useful, they are irrelevant to the challenges of designing an ITSM strategy or running a service organization. They lack the right context.
The current 'simulations' are fun ways of immersing the student in a safe albeit different environment. The fun environment makes the new and sometime strange concepts more easily accepted. I too have explored and licensed them. They tend to be break-fix or process centric, missing the whole point about service - and service management, which is centered around the management of services, customer, customer value and customer satisfaction to name but a few elements.
They are game and role-play experiences - not simulators.
A simulator mimics the actual experiences a participant will encounter in the real world - hence the use of the term simulator. Simulations should include the scenarios you wish to experience, to simulate, so you can practice and learn from realistic scenarios. They should be facilitated by recognized, expert, practitioners and based upon a relevant ‘body of knowledge’. They should be repeatable, configurable and adapt to new requirements and emerging trends, providing a continual and ever challenging experience.
Simulators should allow participants to make mistakes, leave them in the room, and take the lessons learned, techniques, and dare I say it 'best practices' out of the room with them. Simulators should be designed to remove all the sharp objects from the room, and then introduce them one by one in a controlled fashion so they are recognized and dealt with appropriately.
Simulations simulate the real world in a protected cocoon. Can you really tell me that the games available today do that? No they don't. If you want to rescue astronauts or work for Nase - there;s help. If you want to understand the heart of Formula 1 (which is actually getting sponsors to stick their logos on everything that i snot nailed down!), there is another.... if you wish to understand why your bags get lost by the airline... need I say more.
Where are the real simulators for ITSM? Of course that would imply that the builder and facilitator would actually have to know how to setup and run a service organization....
Wax on
With the exception of Apollo, I believe all the current ITSM simulators are based on the workings of an IT organization in support of a business (e.g. airline, racing team). But I’m not convinced that should be the priority.
All simulators are missing some facet of reality--often intentionally. By minimizing the traditional IT-context, the preconceived notions are left outside the room. Learning speeds up for what matters: the lessons of service management.
As a former pilot and skydiver, we made use of game simulators that had little to do with flying. Long before you step into your first glider or strap on a parachute, for example, you worked though team simulations designed to instill natural instincts for emergency procedures and operational checklists.
The best pilots I ever met (WWII veterans) never set foot in a simulator more advanced than a creaky wooden chair. Learning is not doing. Learning is reflecting on doing.
It’s analogous to “wax on” and “wax off”. The student never sees the context of kung-fu but learns it nonetheless. The lesson is stripped down to its important essentials, the learning is internalized and the student is now armed with a critical new insight.
On flying...
Both you and Ian have raised valid points. Still, as a current pilot and flight instructor, let me add a few:
How we trained pilots in WWII is radically different than it is today. The "rule book" for flying during this time was only slightly larger than a comic book (yes, I do have one). Learning to fly by the "seat of the pants" (for the non-pilots, that's a reference to experiencing gravitational forces and correcting based off of the sensation) is appropriate for primary training, but insuffiicient thereafter. I think that's the level of capability we're at today with ITSM, but I digress... back to it.
In the flying game, we now work with complex machines, in complex airspace as part of a extremely large airspace control network/system. As such, we've upgraded our training techniques to keep up with the changes. Indeed, epsecially when you get into larger aircraft where operating costs are so high, the first time a candidate will get into the actual aircraft to fly it isn't long before their official checkride. That's how good the full motion, immersion simulators are. That being said, there are lots of things that can get done with less capable equipment. It all depends upon your training objective.
One of the pirmary benefits is that (for pilots anyway), you can experience a situation (like flying an instrument approach for example), be completely overloaded and have it go pear shaped. You stop, debrief, put in a correction and fly it again. You do better the next time. In real life, when it reallly goes pear shaped, (best case) you just break the rules and deal with the gov't, (worse case) you can bend/break some metal and/or (worst case) cause people to be killed or injured due to your decision making and performance.
The organizations we work in are complex as well. In most cases, failure is not a life-or-death situation. That's both good and bad. There's something to be said for consequences. When they're high enough, one tends to take preparation and execution more seriously. Those that don't pay the price. Aviation sees this on an all too frequent basis.
My key points are these:
kengon
I think WW2 Pilots had to 'learn on the job'
Good conversation. Just a quick opinion though on your WW2 pilot comment. I worked with ex-RAF 'chaps' for years at a UK bank. I tried their wooden chair simulator - they learned by doing - by surviving one flight after another and discussing their experiences back at the base over a cuppa tea. As for your use of non-specific simulators - I understand they have their value - but they are not 'simulators'. My point has been from the outset that these 'simulators' do not represent real-life as you would experience it as part of an IT service organization.
As the complexity of systems increases, so does the need for a simulated environment to train. You mentioned NASA, and pilots - there is proof enough. Everyone who gets to fly the multi-billion dollar shuttle has to successfully complete a minimum number of hours and scenarios in the simulator. Simulators also help folks make mistakes and live to tell the tale - and also without breaking a hugely expensive piece of equipment.
The challenges of today's service management environment cry out for a real-life simulator. Service support organizations have them. As ITSM professionals we get to make investment decisions using other people's money. Anyone who tries out a stock market simulator (such as Wall Street Survivor) will understand what I mean when I say the more real you can make it - the more relevant and powerful the learning experience.
The purpose of a simulator SHOULD BE to offer as real an experience as possible. Where are the 'service encounters', the service portals, the service catalogs, the CMDB/Asset Management dilemma, and so on....
"The challenges of today's
"The challenges of today's service management environment cry out for a real-life simulator."
On that we agree. I see today's ITSM simulators as the first generation. Or maybe version 2.0, as folks like G2G3 have done very clever work incorporating ITILv3 into their latest versions.
A few weeks ago, I got to try out a series of simulators from a firm called BTS. These sims were designed to experientially teach sales, leadership and management, strategic alignment and business acumen. Impressive products.
Its a sign of things to come. Teaching is an art and there are limits to the classroom "chalk and talk". Organizations need new perspectives on training for the 21st century.
Chalk and Talk
Hello!
Although I agree on several subjects that have been raised here, I would like to add my own comment on the "Chalk and Talk classroom" aspect.
Just because teaching is an art, a good teacher must be an artist and therefore (s)he has no limits for the imagination. I need a powerpoint and a whiteboard for my classes, but I also use trivial pursuit, nintendo DS, PlayStation 3 and lego pieces for my classes.
You must catch the student attention and, of course, remember the Montessori lessons and remember that the student that *does* something will learn at a higer rate than the student that listens on *what and how to do* something.
I don't mind if we call them role-play games or simulators (of course, they are not simulators!). But I encourage to use different methods to teach on ITSM better than "Chalk and Talk", because it is soooo boring!!!
Antonio Valle
G2, Gobierno y Gestión de TI
http://www.gobiernotic.es
Hello Jerry, Tomorrow I'll
Hello Jerry,
Tomorrow I'll do the APOLLO13 Simulation game combined with an ITIL Foundations training. This Apollo game, based on the actual apollo 13 case, is a perfect way to make (IT)people aware of the fact that working in processes as a team actually improves performance and thus outcome/result (in the apollo 13 case the astronauts Lovell, Schweigert and Haise coming home safely).
Further we have done this simulation game at NASA (unfortunaltely not myself, so I speak from hearsay) and NASA was very enthusiastic.
I've been ITIL consultant/trainer from 1995/96 onwards now. Starting with ITIL V1 (the 40+ books) untill now ITIL has dramatically gone forward, however we, in Holland, have seen shortcomings as well and there are still. Reason why we have developed additional models to fill-in the gaps.
I disagree that ITIL should die. It has been a strong model ever since and proofs that proces approach wins over adhocracy. And Gartner has stated similar....ITIL is there to stay.
Eppo Luppes
Getronics Consulting Netherlands
It sucks
It sucks, it's like communism.. great in theory but...
Configuration Item
What I like to know is exactly what is the definition of a CI? How does one define the CI for a physical server for instance. ? Is the DNS name of the server an attribute of the server or the primary object name? when the servers memory is upgraded or the operating system is upgraded is a new CI created? Can anyone tell me how we manage the CIs when a server is replaced with a new box completely -- is this a new CI and does it have a historical tracking to the older technology box?
what is the definition of a CI?
The ITIL meta-data sucks. There is no good definition within the ITIl materials of what the data should look like (the best you will find is on page 164 of the blue book). So "officially" there is no answer to your question. As a result there is much debate.
Is the DNS name of the server an attribute of the server or the primary object name? Yes. Whatever. Your call. I would say that service management is about user-oriented computing, so using the DNS as the primary object name is unlikely to be meaningful to many users. others will argue that doesn't matter as the user ses the service not the underlying CIs. More debate.
when the servers memory is upgraded or the operating system is upgraded is a new CI created? No, the properties of the server have changed. Unless of course the memory in the server is itself a CI, which is entirely permissible - but daft.
when a server is replaced with a new box completely -- is this a new CI? Probably, because among other things the CMDB should support Financial Management
does it have a historical tracking to the older technology box? Yes, because a CMDB maintains checkpoints over time. There is a physical CI which is the server ("HP Unix box A12745") and there is a logical CI which is the function the server performs ("webserver #1"). The current version of the CMDB relates the new box to the function. A historical checkpoint of the CMDB relates the old box to the same function.
I'm amused you ask the question here, as this site argues that the whole CMDB concept is a crock of the proverbial. You will get a wider range of opinions (which is all there is on CMDB design) here or here
CMDB and CIs gone amuck
My questions were meant to be somewhat cynical from the standpoint that they are not answered and I know that. I have worked with a major vendors product for 3 years now. I some deep knowledge of the datamodel that is used. I can tell you for sure that when it comes to best practices ( what ever tj\hat may mean ) in this case decades of modeling practices have been thrown ignored. But this leads back to what is the CI name, because in this models case even the main name of the CI does not have a unique key constraint. In fact the entire model is held together with surrogate keys ( Object Identifiers they are call ). This design 'feature' has been carried to the extreme where almost 50% of the fields in the system are object identifiers.
The result:
1: poor performance that will be difficult or impossible to fix with hardware. For DBs are less than a million records or even in the hundred thousands we should not have performance problems.
2: not scalable
3: the user interface is horribly difficult to use -- except for the black belts
4: The reporting capabilities of the system is terrible complex and only highly trained employees can extract the information. Also because the system uses weakly typed data the usability of reports is undermined severely.
ITIL metadata is a mess.
Duh. Sorry, I missed the tone. That's the trouble with email and forums: without voice and body language I for one get the wrong end of the stick.
I suspect you work with the same product I did, or two vendors are making the same mistakes which is entirely possible.
ITIL metadata is a mess.
Never pick a fight with a Cannabis enhanced Zulu
Jerry
Ive used that Zulu war analogy for bad use of best practices for years after my Dad took me to see Michael Caine and Stanley Baker in the film of the same name when about 8. I too was led to believe it was the Quartermaster's (QM) fault, only to learn in recent years that primary fault lay at the hand of the rifle used. Investigators from I think Oxford University revisited the battled field - Isandlwana (http://en.wikipedia.org/wiki/Battle_of_Isandlwana) to discover ample ammunition boxes out on the picket and firing lines - and although they were to be opened only by the QM using a special screwdriver - they had been crashed open with rifle butts.
So it was clear that even a QM places survival ahead of process and procedures. When they visited a local Zulu village to speak with descendants to gather more (local) knowledge - the previous accounts of the battle having been reengineered by the British establishment a la General Custer storyline, they noticed a rifle above a fireplace. It was one from the battle - a Martini-Henry, a US manufactured rifle, designed to blow a 6in hole in a charging Zulu warrior. It was commissioned for the war in a 'best practice' fashion - to drop a Zulu with one shot. Previously it could take 3-5 shots to bring down a Zulu - only later would history explain to us why Zulus seem to posses magical powers... it was something much simpler than Kevlar.
Anyway, the rifle was noticed to have bayonet marks on the breech, implying someone had tried to use the bayonet to unclear a jam. When tested in the same conditions as the battle - dusty and 95 degrees - it jammed consistently after 8-10 shots. A new theory was developed - there were plenty of bullets as more and more ammunition boxes were discovered and plotted by GPS on this information. More rifles were inspected and similar marks found. So it was likely that the rifle jams were common across the firing line. As they did, the rate of fire would decrease. This was exactly how Zulus fought battles against the British. They would count your guns and rate of fire and look for a weakeness.
Another crucial factor was that the picket line had actually been posted further apart than procedures dictate.... due to the force being split previously - the infamous Custer tactic.
So - how do I loop back here to the point of the thread - remember - those that write the reports typically blame someone else. Problem management and proper root cause analysis is subject to agendas and selective memory as well as insufficient or inaccurate information. Its never one thing that goes wrong - its always a combination. Always test for the conditions you expect to encounter in use. Never pick a fight with a Cannabis enhanced Zulu (http://www.pbs.org/wnet/secrets/previous_seasons/case_zulu/clues.html) - their secret weapon to overcome our fire rate - best practice?
And... a best practice is one that can be adapted as need be to suit the desired outcomes, on the assumption there is a controlled procedure to document the changing conditions and reason for change. War and the survival instinct is an accelerator for best practice development. I wonder... how effective might use of ITIL practices been in the Zulu Wars? Hhmm...