IBM: the company with such a firm grasp of ITIL strategic issues that they sold their service desk

Is it just me or does anyone else think it is a bit rich IBM lecturing ITIL vendors?

After all, this is the company with such a firm grasp of ITIL strategic issues that they sold their service desk product to Peregrine, abandoned to an inevitable brutal death. That's a bit like GM getting out of making engines and then telling other auto makers what they need to make cars. Listen to IBM's understanding of how important a service desk is to service management:

"It would be wrong to assume that it was a non-performing product," insists Dean Verhaege, VP strategy at Tivoli's enterprise solutions group. "It generated a consistent cash flow and delivered a satisfactory return on investment. The reasons for selling it are primarily due to the refocusing of Tivoli's business."

Or, as Mike Twomey, senior VP at Tivoli's small-to-medium business management solutions group, put it at the time of the sell-off: "The question was does this fit strategically as a product set? The conclusion was no. It's still a strong product, considered one of the leaders in the space."

I have a lot of respect for Big Blue. I was aghast when the sale happened and the mystique of IBM died for me that day. To this day that move mystifies me.

I actually agree with the main thrust of the article: the vendors have been slack in documenting how to do ITIL using their tools: "the onus is on IT management vendors, not customers alone, to figure out how to do that". But people who live in glass houses shouldn't throw advice.

It also begs the bigger question of why ITIL does not address some of this. As the vendors work their way up from the technology, OGC should be working their way down from the processes. But that is a blog for another day...



strangely enough I still run that system today. so, when IBM came into our office a few months back talking about ITIL and how they have long been part of it, writing it, and all of that, i had a nice laugh.

perhaps it is true that one hand of IBM was doing that while another was doing something completely different. but to those of us in Operations running this stuff day in and day out they seem like idiots. MRO Software? this is their response to Remedy and Service Center? even CA has a better shot with their SD technology. they had something, they could have built on it before BMC, before HP and they blew it.

oh, so, for fun, i asked if i could get a 'free' upgrade from my TSD to the new TSD. they said..."no."

i'm still running it now. still can't tell the difference between a request, incident and problem with it (it has only one 'ticket' system in it) and there is no way to force associations between tickets and assets or between RFC's and 'tickets' (you would hope to have it go to either a request or problem) but regardless of all of that, it still works.

the question is, if i do track all that stuff, and associate all that stuff, what is the ROI for doing so? what does it really matter that i know how many problems or incidents are associated with this particular CI or this particular set of CI's? i know i can become more 'strategic' by doing so and hopefully spend my money (on technology, process, or people fixes) but has anyone actually done so? and if so, can they share their ROI data with me please?

That IBM rep should be shot

I was in software sales for years. that sales man missed a golden opportunity. He gives you a "free" upgrade to a new service desk offering; he erases all the bad feeling; he gets you back into the "family"; he locks you into annual maintenance revenue of ... what is it at IBM now?... 18%? 20%?; he scores all the services revenue for the conversion, and he has a further beach-head to expand into other tools.

I wonder if he'll make quota?

As to your question, it deserves a blog when i get a moment. Most of your comments deserve a blog: great commenting thanks!!

More on IBM's role (or not) in the formative days of ITIL

From Alan Nance, who was there:

Role of IBM in ITIL: I never heard that story about the IBM bid. It sounds like something IBM would do but not like something the UK government would have been equipped to deal with. Again remember the procurement-centric thinking of the CCTA at that time. What is undoubtedly true is that the thinking from IBM’s ISMA heavily influenced the first ITIL books (Helpdesk, Problem and Change Management). Traditionally there was particular criticism of the helpdesk book for this reason and also the fact that it did not jive with the other later books. In fact had the CCTA not changed course quickly, I doubt that ITIL would have been anything more than an echo of IBM speak. Another lost fact is that Malcolm Fry was actually writing his own version of “ITIL” at the time for Protocol and I actually looked at that when I was General manager at Pink Elephant before encountering ITIL as best practice. With no offence intended towards any of the people who did great works at the CCTA but to my mind, the growth of ITIL to international best practice was really forged in the later books. Brian in particular reached out to experts and thought-leaders from across the sea and in different walks of life like Hans Dithmar, Martin van Kesteren and myself and of course many others whom I know less well. These efforts lead to real assimilation of best practice and the strength of the books today.

Role of IBM within ITIL an dother stuff

As a Founding Brother of the ITIL movement ;-) I would just like to add two more cents to Brian's comments.
1. I agree with Charles that Edward Van Schaik, as the most well known member of the IBM ISMA team, is a major major influence in IT Service Management thinking. In fact I based my project to create one of the first commercially unattended operations in Europe on this body of work in 1984. This obviously predates ITIL. Many people would like to see this team acknowledged for their great pioneering efforts.
2. In addition to the ISMA book there were also other earlier works from Prof. Maarten Looijen in The Netherlands and from two German authors Graff and Greiller who could also be considered pre-ITIL pioneers. Each provided substantial contributions to our profession.
3. I spoke to Malcolm about his unfortunate misquotation recently and he would be the first to acknowledge that this was grievous. While Malcolm didn't contribute to the original publications, he did author a series of books derived from IBM thinking that were published around the time of the ITIL books. Malcolm remains an avid writer of very useful books and has been a longtime icon on the ITIL related circuit.
4. Charles' comments on portfolio management and change management seem to be in the right general direction with the exception that ITIL version 2 clearly states that change management does not extend to application management. So I would suggest that any claim that ITIL Change Management preempts strategy, architecture, development or indeed portfolio planning is not correct.

Hope that this helps. I love skeptics :-)

As Oscar Wilde said:
Rules (like best practice) are for the guidance of wise men and the obedience of fools. Alan Nance later added, "in any ITIL project, understand who are the wise men and who are the fools and which are you?"

ITIL history from the originator

here is more insight into the origins of ITIL (and IBM's role in it) from THE MAN, John Stewart


I can't add to the historical argument of IBM's contribution to ITIL. However, as a mainframe IT guy from way back (in the 1970's-1990's) who now works full time implementing both ITIL processes and HP Service Desk, I can say this - there is a lot of overlap and to me, ITIL has taken the old ITSMA into the post mainframe era even if that is not ITIL's genesis.

In my mainframe days I was involved in Change/Problem/DRP/Capacity management etc. I felt a lot of the mainframe disciplines were "lost" when distributed computing, PC's and client-server came in - and then the Web! Well and truly the cowboy era.

Then, to my joy, the disciplines were rediscovered by the new IT generation as this wonderful thing called ITIL. To my greater joy, and financial benefit, I found that all the stuff I had learnt and developed as a dinosaur mainframer, was now right up there in terms of this modern new methodology.....and strangely I was able to "reinvent" myself as a consultant in the new field, and even as an ITIL trainer. (Even if it did cost me a lot to get ITIL Manager's certification!). And by the way - no-one I know of used ITSMA exactly as per the wall chart, Share/Guide sessions, and IBM System Journal articles....they adopted and adapted it to their organisation. And that was before we'd even heard of "Best Practice", too.

So - regardless of the documented contribution of IBM ITSMA to ITIL - I think you'll find a lot of old IBM Mainframers wondering what all the fuss is about, and why it isn't just IT common sense!
Great topic for a rainy day though.

CMDB in the mainframe era?


Did the CMDB concept come up back in the day? In any other form than the metadata repository products like Brownstone and Reltech?

Charles T. Betz

Mainframe CMDB

I don't recall it being a big deal. I think IBM's INFOMAN had some sort of CMDB but I never used it. In the early days, we knew what hardware we had (mainframe, disk, tape, comms controllers and a heap of 3270 terminals), and we sure knew what software we had....Just look at CICS for all the online stuff, Batch applications were in nice controlled source libraries (in the shops I managed anayway), and all the IBM OS software was controlled by whatever their mainframe patch product was (was it SMP?).
And nobody updating Production software without goinf thru the software librarian...because Access control stopped them. (RACF, ACF2). (Well except for us Systems Programmers who were Gods of course).
So no formal CMDB as such, but nothing like the plethora of hardware and sfotware we have now to manage. ......Ken

Mainframe CMDB

Do any of you guys and gals remember the DB2/(Supp)Repository, AD/Cycle offering from IBM - now THAT's a CMDB! The goal seemed rel similar - shove as much IT information into a database as the hours in a day allow in the leap of faith hope it will help improve the efficiency and effectiveness of your 'processes'. Sound familiar? INFOMAN was the direct result of the IBM/ISMA project which was PRECEEDED by Business Systems Planning or BSP, taking Change, Problem and a snif of configuration as far back as 1972 with a theme of managing IT as an element of the business..... nothing is ever new... ITIL V3 is looking a lot like a pair of 1970s flared trousers....

Deja Vu

I remember once attempting to explain distributed architectures to a Mainframe expert a few years back. Nothing too crazy. The conversation involved physical and logical application servers (Tomcat), JVM, database replication, transaction middleware, n-tiers and such.

The expert looked at me as if I was from another planet. "Why on earth would you do something like this?" they replied, "It's been done for years with CICS/DB2 and, best of all,..."

-drum roll-

"'s all in one place."

the best way to get proper control is to get it all in one place rack mounted servers using virtual machines with a central UDDI, central database server, central LDAP server... the best way to get proper control is to get it all in one place, as the "midrange" world has finally discovered after twenty years


I truly hope you are being sarcastic. Centralization for the purposes of better control have a very poor history of success. Or else we would:

- Abandon the end-to-end principle and centralize Internet controls in one place

- Remove end-user PCs and centralize end-user computing in one place

- Just run IBM computing and AT&T telecommunications

On second thought, I'm certain you are joking...

Oh but I'm not joking

Oh but I'm not.

The planet is paved right now with multi-million-dollar projects to consolidate hundreds of servers onto virtual machines on one big rack.

VOIP gives us one communications backbone to manage instead of two.

The internet itself has contributed by killing off client/server in favour of dumb (read:HTML) clients and massive application servers.

What is Google if not a massive centralised hub of the internet?

Even SOA can be viewed as an attempt to centralise each service in one place :-D

Just because one layer of the IP stack runs on a decentralised model should not distract us from the overall trend. And as a client of the pestilential Registerfly I for one would be happy to see a bit more regulation if not centralisation in domain management (fortunately their billing system was so bad I hold almost nothing with them).

Centralization or Consolidation

I guess I'm confused.

- Consolidating server sprawl is a cyclic event driven by cost. If they happen to implement application rationalization, rarely do the architectures revert to "putting it in one place".

- A VoIP convergence event is also driven by cost rather than centralized control. And you'll notice VoIP architectures based on open protocols like SIP are highly distributed by nature.

- Client-server may be in decline, but that has only increased the proliferation of distributed architectures and content delivery networks. HTML clients are really not the same as dumb terminals, green-screens or TTYs. And think about it, when you open your link to Registerfly, how centralized is it really? I glance at the page and see several very disparate systems, vendors and architectures at play.

- I helped Google architect their infrastructure - the only semblence of centralization is the output on your browser and even that is an illusion. I'd give more detail but they take NDAs very seriously.

- I'm bewildered by your SOA point. SOA may be a mechanism for aggregating disparate systems and exposing them as services, but how is a composite application not a distributed architecture?

There has always been and will continue to be strong advocates for centralized control. The ITU vs. the IETF is my favorite. The DRM advocates are another. But the strategy of "putting things in one place" usually doesn't work for long.

Getting back to the

Getting back to the mainframe is not so much about "putting" in one place, as we did then, more about managing in one place.

Under virtual machines I can see and manage all my servers thru one interface

With VOIP in place I manage all network traffic with one set of utilities

HTML is ****ing dumb: I try to code it. The device is more intelligent but the task is not. And really dumb desktop devices are making inroads in business...

Google was a facetious example, but in Google I go to one point to effect all my access to the web (really: I seldom use any other interface for finding stuff)

And SOA was facetious too, but rather than having 100 routines by 100 authors in 100 locations, we are supposed to go to one best routine in one place to provide that service...

On one level I guess I'm just winding you up, sorry :-D but then again, 40 virtual servers on a monster bit of iron sure looks like 40 MVS regions to me....

To the point where the enterprise I am at calls them...

I am working in an org where it is quite large by Australian Standards - greater than 30, 000 seats.

Wait for it, when they use a virtual server they call it by the name LPAR - hmm smells like mainframe to me. The problem I am working on is dumbe software vendors who want to charge my client for the number of CPU's on the box, not the CPU's allocated to task/application. Hmm I have vague memories of suppliers trotting this one out when the big iron was getting more CPU's.

Next thing you know, we will be charging virtualisation by the MIP... ;-)

Looking in her eyes I felt as near to Icarus as to the city before me as to the death of the sun. (The Long Road of the Junkmailer, Patrick Holland, 2006)

Another controversial discussion

To de-centralize or centralize, consolidate or not.

Centralisation and consolidation are 2 different things

These strategies are in-line with the sales and technology cycles of the industry marketers and spin doctors. No sooner had the virtual server farm been implemented and a few heavy height apps were running like pigs, we were given the line that not everything can be virtualized. Great, here we are 8 hosts (4CPU), 100 guests, and few Tb of SAN sitting behind it and we still need more infrastructure. We were then sold other software with the strong recommendation of not to virtualise, we went against that recommendation and it runs fine for Dev, it only operates in Dev, ie: Source Code Management System, but that was not the only instance, saved a crapload on some other software which was licensed by CPU and now runs prod on virtual. At the top end of town the virtual server still cost as much as piece of tin, it works out a lot better for the small to medium enterprise. Have a look at MetaFrame, it has matured over the years and is a fantastic solution for centralized control of the desktop. M$ is yet to come real close to this one due to a long standing relationship. RPC to a terminal server, under a thin term is just not the same thing. Centralization of DB services is essential to all organizations, if you have db servers with idle cycles you need to look at utilizing those resources, but treat the requirements on a case by case basis. Centralized Java frameworks are not always great especially if they are hit multiple DB platforms, middleware and other unsociable factors. We went against the recommendations and they run fine with the understanding that we will scale out when required. Ie: More cloned guests the same as the others. While we are at it, Why don’t we give the good old M$ domain a good kick in the nuts as well, its been the root cause of many issues and still runs best with a decentralized representation. Now bandwidth is so cheap you need to question many of our old solutions as to whether a more centralized architecture is a more practical approach. I’ve seen it all, Linux guests running under MVS on Z series mainframe to serve up file and print, and yes there is limit to MIPS. One day I’ll tell you all what its like to bring a medium size organisation to a standstill. I was told the day before, that there was a bottle of Champagne with my name on it, but when it was opened 2 weeks later I wasn’t invited. So WTF. I stayed another 12 months, finished the rollout, left for 24 months and have now come back to move from Zos/linux back to an M$ solution. Guests for Tin, Linux to M$, but out of this we still have a shiny beacon, The MAINFRAME. These guys have my ultimate respect in the IT space for process, and the conceptual understanding of the CMDB. And the day that MVS regions and virtual guests are given the same consideration I’ll be more interested in what wine is being served with lunch. A new question for Skeptic: Is the CMDB really ITIL’s appendage. See for an alternative open source view of the CMDB.

No offence to the mainframe guys

I don’t believe the concept of the CMDB ever really came up in the mainframe world as they have it all at their fingertips anyway. Not sure about 20 years ago. I do know nowdays there is a tool for every task that you want to carry out on a mainframe system. Including a variety of virtual engines to offload process cycles (MIPS). Provided your talking with the right people and asking the right questions you get what you want. I currently work with a mainframe capacity specialist and mainframe analysis and tuning is a true art. They have all of the CMDB info at hand but for most of the mainframe guys if it exists outside of the mainframe world they don’t want to know about it. But they can tell you everything about the blue box. I’m fairly sure this has always been the way.
Without the learning of the mainframe discipline, ITIL would have never reached its current level of maturity.

see my latest blog entry

see my latest blog entry for a story about this

ITIL v2 Change Management

This is a belated response, but I can't find where ITIL v2 excludes application management from change management. It clearly excludes *project change management* but that is not synonymous with application change management. Project change is generally concerned with the baselining and change control of project deliverables. Its arguably most critical responsibility in this is maintaining change control over the project's statement of requirements.

If I am installing a major new production application, that final release/deployment to production hardware had better ought to have an RFC!

Charles T. Betz

only controls change once development throws it "over the wall"

I think the thing is that it only controls change once development throws it "over the wall" to production, as compared to SDLC within development environment.

I'll verify that in the books another time - I've had a few red wines and I'm ready to sleep ;-)

I had a client who was having CVS and Bugzilla imposed on him as prod change management because that was what they used in dev. I askld him WTF has that to do with production change control.

A Fence around Production

I think ITIL has confused things with it's wording of "Request For Change", and then there are Requests for Service which can become Changes.

My "adapt and adopt" approach, which I've implemented in a number of clients as an ITIL-based practical change process is this. The concept is to build a fence around "Production" and use ITIL based processes and an appropriate integrated tool to manage it all. Thus:

- Every change to Production must have either a Change "record", or be documented in an Incident - ie I don't require a Change to be raised for everything done during Incident recovery as long as it is documented and linked to the CI. (Anything done after an Incident - eg a permanent resolution done at the next outage - must have a Change record).
- The SDLC is kept separate - but the end result is (ideally) an Application Release, subject to Release Management. There would then be one Major Change record for the release as a whole. If Release Management not in place then appropriate Changes are raised before implementation.
- Other Projects are handled similarly via Project Management, but again there must be one or more Change records for each Production Change resulting - even if only one Major Change. But ideally all Project Implementations are done as REleases.
- Where the business submits Requests for Change (including Application Changes), these will often be diverted to the SDLC or Project Management processes and thus "leave" the Change Management system. They return (if approved and built) as part of Release or Project implementations.
- Finally, there will be lots of Requests For Service which are really changes, but are routine requests from users for alterations to PRoduction. These are more like Model Changes, typically minor. The key is that the Change Manager should pre-define what can be done as a Request for Service vs a formal Change (and what can be done as Pre-Approved Change), AND the one tool should document both of these so that everything is visible.

The outcome of all this is a quite practical interaction of SDLC, Project Management, Requests for Service, and ongoing Changes to Production.

No such thing as a business request for change in my experience

The thing I have never seen across multiple large U.S. IT shops is a business customer submitting anything termed a Request for Change. I see Project Initiations all the time, and I have seen Accenture implement something called Demand Management, using the Mercury IT Governance toolset (formerly Kintana). IT demand requests in my experience are handled by a cadre of Customer Relationship Managers who have the credibility to deal with senior business executives. Routine Service Requests are handled in different tools with different processes. And Demand Management is *not* muddled together with people needing password resets!

I continue to poll U.S. IT managers and architects whenever I speak, and the percentage who use the term "Request for Change" applied to business requests for new or changed service functionality is very small to nonexistent. Requests for Change are short lead time processes focused on changing the functionality in environments under change control (not only production, but often test, QA, and BCP as well).

Charles T. Betz

BRM vs Change

I agree with you Charles...When I run Change Management process workshops (usually prior to implementing HP Service Desk), I spend a little time talking about the role of Business Relationship Managers (or CRM's or Account Managers or whatever strucutre IT has in place for dealing with Business Management). This IS where most major initiatives come though...and also where SLA's are negotiated and managed. And yes, this is usually handled outside the IT change process - which to me is all about managing changes into Production.
The Requests for Change from the business I see are exactly as you say: "short lead time processes focused on changing the functionality in environments under change control (not only production, but often test, QA, and BCP as well)" (Can I use that definition?). Includes where business units have some independence over parts of their IT and need (eg) a new server built and linked to the network, or IT to make changes to reports.
I think it comes down to two main streams of requests to IT - those "day-to-day" from users, and those bigger initiatives at a management to management level.
ITIL Help Desk (Service Requests) and Change Management is (to me) about handling the former, AND about controlling the end game of the latter when they are to be implemented into Production.
Having said that, a client has just asked me to extend their HPSD implementation supporting Change Management to include Variations Requests from their customers and track the whole life cycle...will be interesting to see how that turns out........Ken Briscoe

Fundamental concepts of the business interfacing with IT

Yes, all of this is basically correct; however we have missed some fundamental concepts regarding scalability. We apply scalability principles to infrastructure and applications on a general basis as a necessity, but when it comes to business process it would seem that this concept goes out the window. What fits one size of organization is not suitable for all.

Training vendors are only too happy to take the money from course participants and teach what is in the curriculum without understanding or imparting the knowledge to apply the scalability concepts. Consequently the newly empowered students then want to apply best practice approaches that do not fit the size of organization where they work. A recipe for disaster.

Charles, with a $1.3BN budget I would assume that your organization is around the 100,000 + seats. Ken, Skeptic and others most likely work within similar sizes of enterprise. I fully respect your positions on this subject matter, however I work as a senior project manager in organizations from 500 seats to around 35,000 seats. I think you guys under estimate the chaos of a small organization. Small organizations rarely pay the market rate for a suitably skilled resource and then become more reliant on having their internal people trained in concepts that promote best practice assuming they will also understand how to implement this for their sites. I haven’t worked in an organization under 3000 seats for about 5 years., but even in my current role the line between business and IT is blurred. So often the business setup their Project offices, Business architecture committees, Project Approval boards, and approach IT after they have drafted schedules and plans for major initiatives. These boards whatever their purpose need to be forced to interface with the change management board. Until this factored into the best practice ciriculum smaller organization IT departments will continue to have to battle the business imperatives of the masters they serve.

All IT environments should be treated with production respect when it comes to change. The organization is funding effort in these environments and any impact will cost the organization money.

A key fundamental principle is MONEY, it all costs money. Structured process is implemented in order to control workflow effectively, and a complimentary output is a cost effective approach to IT operations.

Rightly or wrongly, many organizations select tools to impose process requirements within their organizations. Whether it is HP Service Desk, Open View, Omni view, etc, Clarity, Remedy, Demand Management / Governance tools or whatever, many of these are overkill for smaller organizations and still require significant customization. At the end of the exercise for a smaller organization the cost benefit analysis doesn’t justify the investment. Consequently other organizations take the learnings of their business partners and continue under the premise that they cant afford to conduct a similar undertaking or there is no financial benefit in doing so. One way to combat this evolution of IT process mis-management is to promote open source tools for the undertaking of the key functions. promotes scalable and customizable, open source tools to facilitate Service Management, Change Management, Asset management, Auto discovery, Systems Monitoring, Document Management and organizational collaboration. Many aspects of customization and facilitating industry accepted practice business processes under an open source approach are discussed in the / > forums.

If ITIL is going to stand up as the industry accepted framework for IT management for all sizes of organizations it needs to accommodate the full spectrum of business practice which impacts the ability to provide IT services within all sizes of organizations.

What's big??

I live in Australia, and like skeptic, 3000 seats is a large organisation. In IT terms, most clients I work with have less than 200 IT staff - though some are bigger. The major focus is to scale ITIL and the tool (eg HP Service Desk) to that size organisation. Adapt and Adopt as appropriate - minimise bureaucracy, maximise benefits. Needs a lot of common sense but can be done. I find ITIL a good framework to build scaled solutions around - but that's all it is. As Anthony Valle said in another post - it's not a religion but some people treat it that way and that to me is the real problem.
THe smallest implementation I've done of Help Desk, Incident/Problem/Change/Config Mgt, with HPSD as the tool had only 50 people in IT. Before this: Chaotic - yes. Able to respond quickly and flexibily to business needs - definitely. Able to cope with growing scale -struggling. Afterwards - still chaotic (but planned chaos). And better able to handle the increasing scale of their operations with an APPROPRIATE level of ITIL-esque bureaucracy. Remain flexible and quick to respond but in a discipline, documented way: Yes. Nowhere near perfect, but ITIL still proved a very useful basis. And very scalable. Cheers.....Ken.

ITIL in SMEs: You can't just prune it

The IT Skeptic lives in a little country. Where I come from 3000 seats is a national government Ministry or a top 50 corporate.

So I can confirm what you say about ITIL's struggle with applicability to smaller organisations. I own both the 90s version and the 2005 edition of the ITIL small scale books. They contain much useful information but I feel they don't come to grips with the realities of small or even medium enterprise: they feel to me like they are written by large scale people writing for small scale clients, rather than by people who live small scale. Actually I know this is not true, as I know one of the original contributors who does great work in small organisations. But the books FEEL that way.

I think the reason is because ITIL needs fundamental transformations when taken below some minimum size of organisation. You can't just prune it, you need to genetically re-engineer it.

A Key Principal of Architecture

Absolutely agreed.

A key principle of infrastructure architecture should also be applied to the architecture of business process. That is all things are scalable to a point. There will be both high and low thesholds where the architecture is no longer feasible.

Change has four major views

From an upcoming IT Skeptic article:

"Change has four major views: Organisational, Project, Development and Operations. But these are only views: the underlying change entities exist as a single set. Note also that these are not IT terms. That is, IT Operations is a subset of Operations, IT Development is a subset of Development. Other groups to have a development area include Marketing and R&D... A lot of debate stems from definition of terms or scope. If we have a clear mental model of all the aspects of change (the IT Skeptic once mapped about twenty, not the four here), then we can be clear what we mean when we talk about that much-debated word 'Change'."

The "request for change" from a Business perspective

“Why should we raise a request for change regarding project initiation” is the normal response from the business. The amount of times that I have seen business projects initiated, and then cause extreme pressure back on the IT department, is incredible. They usually make poor choices on technology (Often sold as a solution to all of their problems) and then the IT area is left to support a high maintenance system. In many organizations 6 – 8 weeks for a server is an acceptable timeframe, often not understood by the business. Not to mention the concept of structured change and approval. The business should be made to interface with some IT governance process for their IT project initiation. Whatever the environments, mainframe, middleware, midrange, apps servers, virtual servers faciltating SWtest, Dev, AXP, Prod, there are people affected by outages and poor performance in all regions, and that is what results from the business treating the IT department like the poor cousins living in the basement. I know I keep suggesting tools, but under open source Content Management Systems and Issues and Bug tracking systems a service management cmdb can be designed to suit a variety of organizations.

The Business Request for Change is called Ideation/Initiation

I am absolutely in agreement that project initiation needs to be handled with a structured, repeatable process and enterprise risk management and visibility for all the reasons you suggest. However, the timeframes, workflows and stakeholders are radically different between the project initiation process (aka Demand Management, not in the ITIL sense) and short lead time change controls.

In my experience, because they are often tracked as project milestones, there is huge drama and intensity around the 2-4 week lead time changes to controlled environments. Suggesting that this process be expanded to project lifecycle concerns which may span months or years is ill advised.

The tools are different as well. From a tools perspective, for demand management, use CA Clarity (aka Niku) or HP/Mercury IT Governance (aka Kintana). Compuware, Primavera, and others also have credible products. For Change Management, use Remedy, Peregrine, or any of the other service desk products with a Change module. You may have an interface between them, but the tools are doing very different things. Don't mix them up just because ITIL was written at a ivory tower level of abstraction.

So, we have significant divergences at the process level, the conceptual data level (the terminology of Demand versus Change) and the system level. The only commonality is at an extremely generalized, academic level. Yes, they are both "Changes." So what?

See What's a Change Manager to Think? at

Charles T. Betz

adding comments to get your URLS converted to links

You guys who are registered users now need to change "input format" when adding comments to get your URLS converted to links. Sorry, in Drupal you can't change it permanently, so you need to change it any time adding a comment with a URL.

it's a pain, but I had to do it to keep spam out. i fixed this one for you Charlie and I'll do any others i see

P.S. I LOVE Bob the Change Manager and ITIL's rule-the-world aspirations. Both that article and your comment fit well with an upcoming article from me.

Not quite

The ITIL v2 concept is that the Request for Change PRECEDES the initiation of the project. A request for a new $10 million CRM system is a "request for change." That is what I have been critiquing.

It's all very clear with a close reading of the Blue book.

Charles T. Betz

ITIL 3 take

In ITIL 3, of course, there is a more comprehensive view of the whole service transition process and the role of change management within the whole service lifecycle.

IBM and itil inventors

I worked for ccta from 1987 to 1994 and again from 1999-2002 (when it became part of OGC); I wrote five of the original books under the supervision of Dr John Stewart the person who DID create ITIL

In that time I did not consult anyone from IBM, I did not refer to any of the IBM 'body of knowledge' nor did my colleagues to my knowledge. I did have the pleasure of meeting one or two good people from that company and visiting their offices (one in Portsmouth if I recall) to talk about itil. And before I rejoined ccta, I nearly accepted a job with IBM---I was very impressed with the people in the London offices and in fact rather regret not taking up their offer---so this is not an anti-IBM tirade.

John in his research period did talk to people at IBM but he did not base ITIL (in fact GITIMM as the acronym was at that time) on the IBM materials it was only one of a ton of influences that were distilled. John did his research and NOTHING fitted the scope of what he wanted to build, so the IBM claim is like many others, a stretch.

Malcolm presented at the ITIL launch (and very well too) at the Barbican in 1991; he was not a contributor. he is a long standing consultant in the field and does very entertaining gigs, he wrote to me and told me he had been misquoted by the press, that is not just rumour

John (and his boss Pete Skinner RIP) are the creators of gitimm/itil no one else. The rest of us did what John directed us to do. incidentally I do not subscribe to itil as being a bible. John ---and you can still contact him at ogc to verify this---wanted the 'best' practices available as a reference, not a blueprint. itil was never intended to be 'you must do this because we are so flaming clever' provided ideas and options that you could adapt and adopt within an overall framework to catalyse cultural change

Which is why I agree with the skeptic about v3; you can comply with a standard, not with itil. And trying to force a new direction when companies have spent millions following a direction set out in v1 and only slightly changed in v2 seems a strange move. Users should apply critical thinking to any 'best practice'


This isn't a beat-up-IBM blog, really it isn't


Someone (presumably IBM or ex-IBM) has gone to a lot of trouble to make sure Wikipedia credits IBM with providing "key inputs to the original set of ITIL books" and "the ongoing involvement of IBM ITIL authorship is a matter of record".

Well, yeah. But I think they "do protesteth too much". Malcolm Fry of BMC claims a similar thing. (Rumour has it he has descibed the "creator of ITIL" line as a mis-quote).

You won't find many authorship credits for either of them, so while I'm sure their contribution is real, in neither case was it quite to the extent they'd have you believe.

The difference is that Malcolm Fry has real credibility and a proven record of commitment to ITIL over decades.

I question the same for IBM.

And nobody else sees the need to claim credit on Wikipedia.

I am that person


I am that person, as the Wikipedia edit history clearly shows. My contact information is quite public.

I have NO previous or current connection to, interest in, or particular affection for IBM, and their current position vis-a-vis ITIL is not a concern to me. I am senior enterprise architect and lead architect for ITSM strategy for a US Fortune 50 organization with an $2bn IT budget.

My motivation in ensuring this credit is to show that ITIL did not spring full-blown from the UK, but in fact has a traceable lineage. The IBM-sponsored work is the FIRST comprehensive work I (as researcher of IT history) can find on the subject of systematic IT management, as distinguished from technical issues, and (having it personally in possession) I can attest that there are significant similarities and the derivation claim appears well founded.

The work took another form here:

Van Schaik, E. A. (1985). A Management system for the Information Business. Englewood Cliffs, NJ, Prentice-Hall, Inc. ISBN 0135499658

As you can see here I also have defended the Enterprise Computing Institute from having their attribution deleted: Again, my motivation in doing this is to demonstrate the broader ITSM context ITIL is a part of. It's all towards the end of demystifying ITIL, and I think we have common interests there.

I'm debating whether I have the time to give some of your CMDB writings some contradictory response. I've implemented successful CMDBs, dependencies and all, and they can be done without excessive spend if some intelligence is employed in defining self-reinforcing processes. The CMDB writings on are experiential, not speculative (except where clearly identified as theory).


some robust debate on CMDB

Hi Charles

I confess I didn't decode who had written the entry. If there is an easy way to do this I haven't worked it out.

Do I detect a hint of the old US/UK rivalry here? :-D While IBM's contribution was significant I don't see the point in singling it out other than that it was American in origin.

I'd be delighted for some robust debate on CMDB. I've been allowed to get away scot-free for too long.


Well, yes

Perhaps. That whole taxation/representation thing, you know :-)

It's not really the IBM corporate attribution per se; I don't really care about that, while I do realize it makes me look like a shill for IBM I just have to dismiss that as occupational hazard. Ditto for the ECI literature.

It's the cited work that I think is notable. I've been hearing about the "Yellow Books" for years. They really were seminal. If there is something predating them that is equally comprehensive, something from which THEY drew, then perhaps their notability would diminish. But I can't find anything. The cites in the Van Schaik work do not show any candidates except for a 1974 Nolan book (Managing the Data Resource Function, St. Paul, Minn.: West, 1974) I have yet to track down. (This stuff gets pretty obscure!)

And yes, I am US-centric in my outlook. I think that both the Yellow Books and the ECI library reflect a certain US pragmatism that contrasts usefully with some of the more problematic aspects of ITIL. Certainly their language and conceptual structures are more in synch with my experiences in various Fortune 100 organizations in the Upper Midwest.

One naked emperor you haven't even touched on is the large scope ITIL has for Change Management. ITIL sees the Change Request as preceding project initiation, which is out of step with both the Yellow Books and the ECI library. Where I DO think a CMDB can be implemented, I do NOT think that the complete ITIL concept of a Change Management process is practical, except in the most abstract sense. See

The vocabularly is wrong; what ITIL terms the true front end of change is actually better understood as Demand and Portfolio Management and I've already seen the linguistic disconnects create confusion. ITIL as a library contributes little to Demand/Portfolio management; much more robust work can be seen cited on the IT Portfolio Management Wikipedia definition (


Thanks for another topic :-)

Thanks for another topic :-) I'm doing my first serious Change implementation right now, so I'll have more to say once I've worked thru the books in detail.

Malcolm Fry claims his books were seminal too. I'll see if I can draw comment from someone who was there.

Where did you even FIND the Yellow Books in this day and age?

Syndicate content