Dissecting Systems Management with ITIL

Recently, I’ve been brain dumping my thinking and knowledge about systems management into a mind map. The goal is to use it for an upcoming longer piece that answers the question “what is systems management?”

Using ITIL

To that end, as I’m going about organizing the clusters of ideas, I’ve begin to ask myself if I should or should not start with the ITL filter of the world, namely:

• Service Desk – help desk, handling requests
• Incident Management – dealing with instances of bad things that happen, and restoring service as quickly as possible
• Problem Management – dealing with the core causes of re-occuring bad things, that is, incidents, and ideally fixing said problems
• Configuration (and Asset) Management – keeping track of everything in your IT environment
• Change Management – tracking and updating your information about the items in IT
• Release Management – the practice of actually updating the “physical” items in your IT, not just the Change Management records thereof
• Service Level Management – making sure your IT is fulfilling its promises to the rest of the organization and the management of those promises, all revolving around the key artifact of a Service Level Agreement, or SLA
• Capacity Management – assuring, by planning, monitoring, and adjusting, that you’re IT isn’t over-loaded or being used ineffectively
• IT Service Continuity Management – disaster recovery and high availability; key here is agreeing on what “absurd” situations and “acts of God” (or “risks”) IT will try to cope with
• Availability Management – the process of putting measure in place to ensure that the systems stays, including responding to un-availability, all at an acceptable cost
• Financial Management for IT Services – keeping track of how much IT costs and making sure to bill or charge-back users as needed

It should be noted that I’ve omitted a further level of grouping: Service Support (the first 6) vs. Service Delivery (7-11). Whew!

There are also several clusters of “best practices,” or what I’d call “cross cutting concerns”:

• Security Management – essentially what it sounds like, protecting information and process and, in the service thereof, access to that information and process
• Software Asset Management – the aggregate of taking care of all of your software from the metaphor of an “asset”: essentially Configuration and Release Management, informed with the monitoring and reporting aspects of keeping track of those software assets.

It’s All Process

At the core of each part of ITIL is the basic feedback loop below, a sort of “rinse, lather, repeat” workflow:

As close followers of ITIL are quick to interject, the above is process, not implementation. That is, in a software developer’s terms, they’re use cases, or even “wordy” stories, for IT systems management. That’s the aspect that attracted me to ITIL when I was writing such software at BMC: finally, someone had written down exactly what they wanted in clear, understandable terms.

What this means, though, is that there’s a quite a lot of glue — both conceptual- and code-wise — between ITIL and the actual software that’s used to perform systems management. What exactly that glue looks like is the wiggle room for vendors and users of vendors’ platforms.

Sizing

At an SMB level, the critical part of that glue is simplifying not only the software, but the concepts that the software is driving. For example, is there much utility in a small or even medium shop keeping configuration and release management separate (even just conceptually)? At a low-level, of course these things are different, but in practice I’m not sure there’s much utility for the “admin on the run” to even know they’re different. The same could be said for Service Level, Capacity, IT Service Continuity, and Availability Management: they’re all just making sure things stay up and running; that is, that IT is doing it’s job.

Now, don’t take that compression as a condemning of ITIL complexity on my part. Instead, I would suggest that benefiting from that complexity is one of the benefits of a wealthy IT department vs. a strapped IT department. Being able to harness complexity rather than be befuddled by it has benefits, but the upfront costs are a high barrier to entry.

So, again, part of starting the ITIL breakout of the systems management space when answering the question “what is systems management?” has to take into account who’s asking: small or large IT shops?

Business Alignment

In considering all of this, another nice aspect of ITIL is that it actually has the potential to deliver on the grand visions of business/IT alignment. While I’m suspicious that those two groups could ever truly “align” without simply combining, others hold out much more hope, so I try to keep my eyes more white than yellow on the topic.

Cynicism aside — and back to glue — ITIL has always struck me as a good paste pot to draw from when trying to align with business. It’s almost like the SOA as biz-IT glue thought (take that as praise, condemnation, or both). Of all the sorts of methodologies I follow — even Agile software development — the canonical ITIL documentation continually stresses and hooks up to serving the business.

More importantly, it relentlessly covers three prime tenants of pragmatic enterprise software:

1. it’s all about getting money from customers and, or “business”
2. IT people and business people are different, they hedge disaster by communicating as much as possible
3. barring all else, cover your ass

As a fan of The IT Skeptic, I know ITIL isn’t going to scramble an egg inside its shell. But, there’s still plenty fun and usefulness to be had despite needing the break a few eggs.

Back to the ITIL Filter

To the original question — is ITIL a good basis for answering the question “what is systems management?” — my answer is a tentative yes. But, that answer is backed up by the clarification that ITIL is a good bag to pull from when asking “why?” more so than “what?”

One other major motivation is to remain true to the notion that it’s good to follow standards (open, quasi-open, industry, or de facto) instead of NIH’ing a new vocabulary. Since ITIL is far from “free” or even “open” standard, I’m not sure how much that applies in this case as a justification-crutch. But, there is something to be said for it being a standard of some sort.

What do you think?

Technorati Tags: itil, taxonomy, smb