[Infrastructures] RE: ITIL? (Rainer.Heilke@atcoitek.com)

Steve Traugott stevegt@TerraLuna.Org
Tue, 11 Oct 2005 22:47:49 -0700


On Tue, Oct 11, 2005 at 09:31:50AM -0600, Rainer.Heilke@atcoitek.com wrote:
> But I think we may be straying off-topic for this list...?

Nope -- not off topic, just risking beating the horse well after it's
dead.  ;-)   This list is about infrastructures; the definition for
infrastructure which I tend to use is "the substrate an organization
needs to do its job".  If I were to write down the charter for this
list (I suppose I should do this eventually), it would say something
about organizational engineering, and recognize several layers or
components; technical, organizational, financial, and so on.  

We focus more on the technical tools because we're a bunch of geeks,
but the technical tools are useless without an organization that knows
how to use them and has the financial and cultural will to do so.
(I've found that most of the time I spend on a site with folks tends
to be working with them on the cultural and financial bits.)

The thing that struck me about ITIL when I first saw it was that it's
completely an organizational solution -- they try to solve everything
in that layer.  ITIL is so tools-agnostic that it seems to assume
there are *no* tools -- and things that should be handled e.g. by a
version control tool get handled by meetings and human procedures
instead.  

There is some merit to being tools-agnostic, as long as the document
suggests that tools would help, and as long as the community culture
encourages good implementations.  So far I'm not seeing anything like
those traits in ITIL community culture.  Does anyone know of any ITIL
implementation which uses anything other than human-executed
procedures?

I think the success or failure of any of these procedure-based
standards is all in the implementation.  ISO 9000, for instance, is a
lot shorter than ITIL, and has a useful key idea; "say what you're
going to do, do it, then say what you did".  That makes it easier to
implement.  While I've seen some laughingly bad ISO 9000
implementations (one was at NASA), I've seen some very good ones.  The
cleanest was where the organization (IBM's Kingston Programming Lab)
created a component for each department, team, or major workgroup in
their existing bug-tracking tool; if something was wrong with any
group's process, you'd simply write a bug against that group.  Review
and QA were set up such that a department manager couldn't close the
bug without actually fixing it.  The ISO documents themselves were
simply part of the "design spec" for each group; it the group didn't
meet spec, it meant a bug existed.

Steve
-- 
Stephen G. Traugott  (KG6HDQ)
UNIX/Linux Infrastructure Architect, TerraLuna LLC
stevegt@TerraLuna.Org 
http://www.stevegt.com -- http://Infrastructures.Org