The IT Skeptic - Comments for "IBM: the company with such a firm grasp of ITIL strategic issues that they sold their service desk"

ITIL history from the originator

skeptic — Tue, 19 Mar 2013 20:38:00 +0000

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

That IBM rep should be shot

skeptic — Mon, 24 Sep 2007 18:43:00 +0000

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!!

TSD...

itsm_stephen — Mon, 24 Sep 2007 18:20:30 +0000

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?

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

vaioboyaus — Tue, 03 Apr 2007 14:04:49 +0000

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

BrendanM — Tue, 03 Apr 2007 13:12:42 +0000

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 CMDB.info for an alternative open source view of the CMDB.

Getting back to the

skeptic — Tue, 03 Apr 2007 07:42:48 +0000

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....

Centralization or Consolidation

dool — Tue, 03 Apr 2007 05:03:36 +0000

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.

Oh but I'm not joking

skeptic — Tue, 03 Apr 2007 03:53:36 +0000

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).

huh?

dool — Tue, 03 Apr 2007 00:34:37 +0000

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...

the best way to get proper control is to get it all in one place

skeptic — Mon, 02 Apr 2007 19:57:19 +0000

...like 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

Deja Vu

dool — Mon, 02 Apr 2007 14:02:42 +0000

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-

"...it's all in one place."

Mainframe CMDB

Onus — Mon, 02 Apr 2007 04:44:49 +0000

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....

What's big??

kenilian — Sat, 24 Mar 2007 03:33:59 +0000

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.

A Key Principal of Architecture

BrendanM — Sat, 24 Mar 2007 03:09:47 +0000

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.

ITIL in SMEs: You can't just prune it

skeptic — Sat, 24 Mar 2007 02:53:25 +0000

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.

Fundamental concepts of the business interfacing with IT

BrendanM — Sat, 24 Mar 2007 01:37:58 +0000

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. CMDB.info 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 http://www.cmdb.info/pd1/html/index.php?name=Sections&req=viewarticle&ar... / >CMDB.info 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.

Change has four major views

skeptic — Sat, 24 Mar 2007 01:36:26 +0000

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'."

BRM vs Change

kenilian — Fri, 23 Mar 2007 23:29:11 +0000

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

Mainframe CMDB

kenilian — Fri, 23 Mar 2007 23:17:34 +0000

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

adding comments to get your URLS converted to links

skeptic — Fri, 23 Mar 2007 05:36:12 +0000

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.