The IT Skeptic - Comments for "While ITIL V2 CMDB was silly, ITIL V3 SKMS is totally absurd"

ITIL V3 SKMS

Visitor — Thu, 02 Dec 2010 15:37:36 +0000

I know about one. The mormon Church has a awsome SKMS. It include all requested by the metodology. It was developed by a BYU student.

ITIL's blue-sky toys

skeptic — Mon, 18 Jan 2010 22:05:13 +0000

ooh sounds like a question for the ITIL Wizard. Don't ask ME to sort out ITIL's blue-sky toys for you :D

CMS vs SKMS

Johnna — Mon, 18 Jan 2010 21:47:05 +0000

I am prepping to take ITIL v3 Intermediate- Rel, Control & Validation and am confused on the dif btwn CMS and SKMS. The ST book gives me the impression that the CMS is only the data & information layer of the SKMS and therefore the knowledge processing layer and presentation layer are not in the scope of the CMS. Is this correct?

knowledge at the core of service management

skeptic — Fri, 20 Nov 2009 20:46:26 +0000

On re-reading Service Transition I see you are right that SKMS is defined in the book as a concept not a technology, unlike CMS, and that is a fair criticism of my original post that it interprets SKMS too much as a thing not an activity. That will be a common mis-interpetation i suspect, especially as SKMS is presented alongside CMS and wrapped around it.

"The concept that there is ultimately knowledge at the core of service management and that moving towards more mature and effective practices is dependant on effectively capturing and managing that knowledge" is a powerful concept indeed, and KCS did it a thousand times better than ITIL V3. If ITIL represents a summation of industry best practice, the absense of input from KCS is notable.

Concept vs. Tools

PRL — Fri, 20 Nov 2009 17:06:37 +0000

You are on track in pointing out that the broader definition of a system (that I would define with the old laundry list of people, process, data...) is what the SKMS is referring to. It seems the original poster and many subsequent contributors are falling into the common IT trap of trying to define everything in terms of software and denying the existence of anything that can't be demonstrated with a specific tool or product. To answer the challenge of providing a real world example, I would argue that anyone providing a service has a SKMS, but in various degrees of successful implementation, integration, automation, etc. and often characterized by thoughts in people’s heads vs. schemas in a database.

The concept that there is ultimately knowledge at the core of service management and that moving towards more mature and effective practices is dependant on effectively capturing and managing that knowledge seems a proven (and even intuitive) conclusion.

Point still stands

Charles T. Betz — Fri, 15 Aug 2008 18:42:29 +0000

OK, 1959 or assembler wrapped with Cobol a few years later. I wasn't around. Point still stands even it it was 1965. Applications are tremendously long lived.

Charles T. Betz
http://www.erp4it.com

Huh?

Visitor — Fri, 15 Aug 2008 17:54:09 +0000

Neat trick, considering Cobol was developed in 1959.

Short life expectancy?

Charles T. Betz — Fri, 15 Aug 2008 12:11:24 +0000

We have COBOL running that was written in 1955.

Charles T. Betz
http://www.erp4it.com

Once a system is barely adequate

skeptic — Fri, 15 Aug 2008 02:38:10 +0000

One more from the book: "Once a system is barely adequate, leave it alone. Its life expectancy is short so why invest in optimising something that will be torn down soon enough?"

"Real ITSM understands this

Visitor — Thu, 14 Aug 2008 23:53:53 +0000

"Real ITSM understands this and prohibits all strategic planning as an irresponsible waste of resources. Better to sail the unpredictable winds of change, as flexible and unencumbered as possible."

Isn't this a strategy? :-)

Good stuff. Can't wait to read my copy.

Sounds like Calvinball to me.

Charles T. Betz — Thu, 14 Aug 2008 23:25:25 +0000

http://www.simplych.com/cb_rules.htm

Charles T. Betz
http://www.erp4it.com

No plan survives the first encounter

skeptic — Thu, 14 Aug 2008 23:22:00 +0000

"the explication of processes such as Incident, Problem, and Change is ultimately futile?". Absolutely. The Introduction to Real ITSM says:

The modern world is entirely too dynamic for any sort of medium or long term planning to be worthwhile.
Governments, laws, executives, competitors, technologies, recessions and fads come and go like the weather. As the old military saying goes “No plan survives the first encounter”. Strategic planning is as futile as an umbrella in a cyclone. Real ITSM understands this and prohibits all strategic planning as an irresponsible waste of resources. Better to sail the unpredictable winds of change, as flexible and unencumbered as possible.

What is then to be done?

Charles T. Betz — Thu, 14 Aug 2008 19:54:10 +0000

Agreed, stability is a relative and context-dependent term.

So, does this mean that the ITIL and ITSM project is infeasible? That the explication of processes such as Incident, Problem, and Change is ultimately futile?

"process control models should instead be empirical; they are designed for a continuous cycle of inspection and adaptation as needed." [emphasis added]

"[I]nstead" of what? Rigid a priori processes never to be critically examined? You seem to be reacting to a caricature of BPM.

In the long run, we are all dead. I will be happy with relative stability for the next 20 years or so.

Charles T. Betz
http://www.erp4it.com

A matter of scale

JamesFinister — Thu, 14 Aug 2008 18:56:41 +0000

An interesting point, and I'm sure I've seen something on this recently (New Scientist or HBR?).It also takes me back a complaint I always had about one of the early but much used diagrams where you had the users needs and the IT department's capability in equilibrium. Something I found out a few years ago is that once you meet a need you generally generate a new need in it's place

I do wonder if it is a matter of scale though, or at least of how far away your view a departments performnace. At some point does the variation become just noise depending on what you measure and where? Also does it apply in a highly dysfunctional organisation, where the user and customer have low expectations, as much as in one that basically OK?

The myth of stable operations

Visitor — Thu, 14 Aug 2008 18:03:31 +0000

- "...can we not then assume that repeatable, discrete processes (BPM as applied to ITSM) can serve to at least operate those systems?"

To Messrs. Palmer’s and Finister’s point, the above assumption contributes to the problem and should be challenged.

For a long time, organizations were thought to be stable, to be in balance. That is, if left alone, organizations will seek and find equilibrium. Further, the process model used to control them should be “defined”. Every piece of work should be completely understood so that a well-defined set of inputs generates the same outputs every time.

Many no longer adhere to this idea. Instead, there is the growing realization that organizations are in "dynamic disequilibrium" or states of multiple equilibriums. In other words, organizations are *never* stable; they are always out of balance. Improvement initiatives are not organizational disrupters because organizations are always being disrupted anyway. And the process control models should instead be empirical; they are designed for a continuous cycle of inspection and adaptation as needed.

There are many reasons why but to elaborate each would require a level of detail not appropriate for a blog. I’ll just explain the simplest:

The “stable model” describes organizations as going through a sequence of shock, equilibrium, shock, equilibrium. Shocks are generally external demands: new services, new technologies, changes in leadership, layoffs, outsourcing, business cycles, and so on. As long as the shock isn’t too big, the organization will eventually go back to equilibrium.

Each shock presents choices and requires decisions. Even operational organizations in which decisions are rigidly centralized cannot eliminate ambiguity in all areas of individual choice and initiative. Delegation must take place so that behaviour is elicited rather than controlled. Organizational arrangements must be made in order to guide staff toward consistent decisions.

During the early ‘70s, researchers from Yale figured out that the time to equilibrium for such systems scales exponentially with the number of components in the system to the power of four. The more services or products offered, and the more participants involved, the longer it takes to reach stability.

An organization with just a handful of services and 50 staff members would take many decades before it became a stable system. Given that few operational organizations can wait that long, clearly this presents a problem.

Non functional requirements

JamesFinister — Sun, 10 Aug 2008 18:24:04 +0000

Charles,

I think you have have pointed out something that is possibly very interesting.

To those of us who know ITIL inside out (well V2 at least) I'm sure we could all implement ITIL using a waterfall approach. In many environments though organisations embarking on an ITIL implementation still don't know "what will happen next." Part of my argument here, from having tried with some success to steer a multi national financial services company in this direction, is that actually the non functional elements are difficult for the customer to define, even if post event they seem obvious. Hence a waterfall apporach is obvious in retrospect, but not at the time of execution.

I have a contract for a service desk in front of me that I think can be read two ways. A decent service provider would read it and understand the gist of the service by being creative, whereas a second rate provider would (HAS) chase the individual targets not the big picture.

I don't have a lot of time for the major consultancy I used to work for, whose appraoch in reality seemed to be that implementing ITSM was simply a project managment issue, but two things I did agree with were that you need to asses an organisations starting point, and you need to use a contingent approach to project managment.

The interesting question

Charles T. Betz — Sun, 10 Aug 2008 15:40:01 +0000

Beyond historical trivia, we don't seem to have any interesting differences on waterfall vs. agile in the context of the SDLC. I was trained by Accenture (then Andersen Consulting) in their linear development methods and found them excruciatingly ineffective.

The interesting debate is the latter point I raised. How is the operations domain a "laggard"? This raises the question of Agile perspectives in the context of ITIL and ITSM.

For those not familiar, the Agile Manifesto is here. Quote:

- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan

While it is true that SDLC practices have suffered from attempting to frame development as a "stable system" with repeatable, discrete activities, is it not true that the whole point of the SDLC is to create "stable systems"? And can we not then assume that repeatable, discrete processes (BPM as applied to ITSM) can serve to at least operate those systems?

While the concepts on the left are also meaningful for operations, the concepts on the right cannot be discarded (as the Agile authors even admit for the SDLC).

To James Finister's point above, certainly ITIL implementation projects might benefit from Agile methods. But the case is not as compelling, because the major point of ITSM is to codify standard practices. Even Agile practitioners admit that solving known problems (e.g. implementing a payroll system) can be effectively done through linear techniques.

It's the truly creative development that requires iterative methods. Is implementing ITIL particularly creative? And do we want to abandon countable, measurable, event-driven processes when system stability and business operations are at stake?

Now, I am falling into the trap of associating ITIL primarily with operations. The Service Design process areas are in particular where ITIL v3 intersects with the SDLC. I interpret those processes primarily in terms of non-functional requirements for the development project. And non-functional requirements such as operability, scalability, and availability are notoriously the areas where Agile development has little to say.

Part of the problem is the focus on the functional customer, who tends to not understand non-functional engineering, debates around platforms and coding languages, etc. The customer too often can be leveraged with arguments like "See, we have it working in the development environment. It's just that those data center people (or operations, or applications support, or architecture) won't let us put it into production because they don't like the hardware and software we decided to use."

The data center people respond by saying, "OK, give us another data center because we are out of capacity because people aren't aligning with our standard infrastructure that we can scale efficiently."

I am not sure how these tensions will resolve, and am interested in all views. Certainly cloud computing has something to offer, but its potential will be long in coming. Until then, for companies that actually have to buy and run hardware and infrastructure software, the Agile challenge will probably have no grand solution, and frictions will continue.

Charles T. Betz
http://www.erp4it.com

Waterfall

Visitor — Fri, 08 Aug 2008 19:44:11 +0000

- “"Waterfall" as referenced here is an uninformed caricature of Royce.”

Huh? Royce didn't invent waterfall. In fact, he argued against it, not for it (except in the most trivial cases). And the article you cite quotes Jerry on the Mercury Project as saying "...waterfalling a huge project was rather stupid ..."

And this caricature is well accepted across industry and government. For a long time, DoD standards, for example, outlined identical constraints and required a "strict, document-driven, single-pass waterfall model". It has since been revised, acknowledging that “...design is rarely the smooth linear sequence of development stages many models suggest.”

- “…first I have seen Takeuchi and Nonaka ascribed any influence.”

While the ideas had been around, this paper was a major event. It presented, for the first time, empirical case studies across half-a-dozen industries showing the efficacy of the ideas, as well as prescriptive guidance. Its influence can be detected in oft-found rugby terms found in iterative development (e.g. Scrum), as the paper uses a Rugby metaphor (“…tries to go to the distance as a unit, passing the ball back and forth”) to explain the concepts.

- “…not sure why the Spring framework is mentioned.”

Java is not a good language for agile development. It isn’t conducive to short iterations. Nor does it really let you move from one change to another without a cumbersome compile-deploy cycle. Developers often have to jump through hoops to test components in isolation outside the containers. Not to mention the desire of agile practitioners for more productive levels of abstraction as well as a more expressive syntax. Spring came about to address these concerns.

Spring displaces complex frameworks like EJB. The abstraction of services gives simple ways for agile teams to deal with transaction management, integrating with MVC frameworks, and object relational mapping. The notion of the application, for example, is a black box “system” designed using interfaces injected at runtime. Therefore, beans and POJOs do not have their dependencies explicitly constructed in the code. Versus, say, EJB 2.X, in which all the collaborators have to be wired together.

Or the other way around

JamesFinister — Fri, 08 Aug 2008 08:17:38 +0000

Surely it isn't just a case of agile developed software being operated under ITIL practices. What about the development of service management tools using agile methods that keep pace with an IT departments experiential discovery of what service management means to them? Or, even, using agile type approaches to an ITIL implementation? A lot of ITIL implementations fail because theya re percieved as monolithic linear projects.

Agile methods

Charles T. Betz — Fri, 08 Aug 2008 03:27:47 +0000

The success of Agile is at this point inarguable. However, Agile's roots far predate 1986, and this is the first I have seen Takeuchi and Nonaka ascribed any influence. "Waterfall" as referenced here is an uninformed caricature of Royce. No serious software engineering theorist ever proposed anything so linear; I think that the myth of deterministic software development probably originated more from an unholy alliance of PMI types with large consultancies.

A good concise overview is this article from IEEE Computer, June 2003 (not sure on what basis it appears on the UMass site - link not guaranteed to last). Fascinating quote from Gerald Weinberg:

"We were doing incremental development as
early as 1957, in Los Angeles, under the direction
of Bernie Dimsdale [at IBM’s Service
Bureau Corporation]. He was a colleague of
John von Neumann, so perhaps he learned it
there, or assumed it as totally natural. I do
remember Herb Jacobs (primarily, though we
all participated) developing a large simulation
for Motorola, where the technique used was,
as far as I can tell, indistinguishable from XP."

(XP in the above quote meaning eXtreme Programming, a prominent Agile variant.)

Also not sure why the Spring framework is mentioned. It's not a "method" and can be used by practitioners of varying development philosophies.

The broader question is whether Agile and ITSM/ITIL have anything to offer each other. There is nothing preventing Agile-developed software from being originated and operated under ITIL practices. But I think the boundary between tacit and explicit is a more fundamental problem, and not just a matter of the "operations domain is a laggard."

Charles T. Betz
http://www.erp4it.com