THE NEW STEADY STATE IS CONSTANT FLUX

A few weeks ago I read Mark Smalley’s‘Kill DevOps’ on the back of a year of increasing interest in Devops, in particularly when compared to the slow-and-steady ITIL.

Mark finished his article with ‘The only desirable steady state is a constantly evolving state of mind.’ And thus rejecting basically any system or methodology, including DevOps which embraces change like no other.

And that got me thinking: do we need stability (for which we often strive)?

Human nature often makes us conservative (maybe along the lines of ‘better the devil you know?’).

A majority of people prefer the status quo, the familiarity of the existing practices, the security of knowing how to do something.

From an organisational point-of-view stability is also preferred. Very few business models welcome surprise and change and are normally based around a status quo (which can be expanded, enhanced or sometimes just maintained).

Even CSI, which is in essence continual change, is based on improving SOMETHING that is more-or-less stable, that can be benchmarked and baselined; and from there to improve efficiency & effectiveness of the status quo.

In fact many of the best practice concepts around Service Operations, are based around BAU (or Business As Usual). By thorough design and testing we avoid any surprises in operations, thus enabling us to deliver a dependable, repeatable (, measurable), guaranteed service … day-in-day out … the same every time.

Based on the renowned Ivor McFarlane I often explain the Operations is supposed to be a boring place to work and that as an Ops Manager, if your staff gets excited … you should get worried!

Or I use a fast food chain as an example of a process based organisation, where everyone (almost regardless of past experience) can create the same quality food (using the term lightly), anywhere on this planet!

But those later ones are certainly not attractive examples of stability: boredom and fast food do not rank particular high on most people’s wishlist.

And thus despite our preferences, we are looking for change, for excitement, for new experiences, new horizons … a bucket list to work through before the eternal stability of death reaches us.

DevOps advocates rapid change and Disruptive Technology hardly preaches a dull and secure application.

So, which one is it: the security of stability or the excitement of change.

As per usual the answer lies in the middle, a bit like bi-modal IT, merging DevOps and ITIL, having your cake and eating too, having the best of both worlds.

I think chaos is change without a solid foundation, thus neither improving nor deteriorating the situation (which BTW makes chaos a constantly changing status quo … ooh, that’s deep).

Stagnation on the other hand is stability for the sake of stability causing dogmatic, micro managed often overly-bureaucratic organisations.

I can accept that change is inevitable and that potentially change is a good thing (as good as a holiday I’m often told!). But not all change and not change for change’s sake.

I see benefit in distinguishing improvement (the same but better) and innovation (different) and both will need a place in a mature Service Management organisation.

It is true that ITIL does not really deal with innovation (a bit in CSI, a bit under ‘new technology’ in Capacity Management), but neither does DevOps (or COBIT or pretty much any best practice that I know of). And where DevOps supposedly signifies the death of ITIL, Mark poses that ultimately DevOps needs to die as well to keep changing/improving/innovating/evolving.

Ultimately everything must or will change, including ITIL and DevOps, but I don’t think we need to actively euthanise either of them (just yet).

Rather (and as always) we need to apply the common sense guidance of either methodology (, framework, or whatever you want to call them) where and how it applies best; and make sure you have the right objective in mind (, business goals, value, again many terms that can be applied here). If there are ‘blindspots’ (like innovation) than make sure you augment your organisation with the necessary structures to fill these in.

For innovation specifically ‘Google time’ comes to mind (20% of time spend on ‘personal’ projects, which got abandoned in 2013), or something I picked up as 7x7x7: 7 ideas are given $7,000 to work on for 7 weeks. This keeps the wildly creative and anarchical innovation within defined time (7 weeks) and budget (7x7=$49,000) constraints and cycles.

So, let’s embrace change but makes sure we have a clear understanding of the direction of this change. After all ‘let’s go left’ only makes sense if you know where you are and where your destination is!

And let’s not blame our ‘system’ or methodology for the lack of innovation but instead make sure innovation is covered within the system (and yes, that includes innovation OF the system).

Onwards and upwards!

(to boldly go …)

the ITIL Zealot

May 2016

ITIL vs Dev-Ops (itSMF debate)

This month I participated in our local itSMF branch seminar. As it was the last quarter of the year, we were already a bit in the Christmas mood and as it is called the silly season we tried to make the content light and entertaining. To this regard there were 4 IGNITE session. This is where each speaker has a limited number of slides (in our case 20), which auto-forward (in our case after 30 seconds) so that the presenter has not control over the presentation behind him/her. And by asking the speaker to present not only in this format, but also in a more polarising way, we kept it quite entertaining.

But in addition we also introduced two DEBATEs. I’ve used this format in my training whereby the candidates are either in favour or against a statement (like ‘outsourcing will make all our problems go away’ or ‘you should always charge for a service’). This makes them think about all the arguments in favour, but also the weak spots of these statement and phrase there position and rebuttal accordingly.

For the itSMF seminar each team (for or against) presented an IGNITE (although the more traditional 15 slides and a 20 second auto-forward), and then a rebuttal. The debate topics were:

•    Chicken or Egg, what comes first: process or tool
•    Traditional Service Management vs. Dev-Ops.

I was on the latter debate, obviously defending traditional service management. My role was to present our case through the IGNITE, and I’ll provide a brief synopsis of that. To this effect I’ve shared my slidedeck HERE.

I first [slide 2] narrowed the debate down to ITIL vs. Agile and decided that a battle of this magnitude could only be properly debated, explained, reflected by using that other epic battle of good vs. evil: Star Wars!

No doubt that ITIL takes the role of the Jedi here [3]. The ancient, ruling order, steeped in mystic, historical processes but in essence a democratic society for the common good.

Agile on the other hand has more similarities with the Sith [4]: powerful, challenging the ruling order, using emotional, rash decisions (over rational, risk averse ones) and attractive to young padawans/developers.

A good example was the Deathstar [5], a somewhat rushed project that contained a fatal flaw, causing it to blow up with considerable damage to the customer (the republic).

So, what did they do: they build another Deathstar, with the same flaw and put it into production before it was even completed. No surprise then, it blew up again, with even more devastating customer impact (victory to the rebellion).

In my opinion, a lot of this has to do with perception [7, yes I skipped 6 which only served to further focus on an apparent lack of planning with Agile]. You see, Dev-Ops or Agile is currently at the height of the Gartner Hype-curve. In the minds of some people it can do no wrong, and should be used for everything and anything.

ITIL on the other hand is done the bottom of the curve, in the ‘through of disillusionment’. Many organisation have tried and perhaps not achieved the results they were hoping for. Now they are throwing out the baby with the bathwater, completely rejecting any of the common sense best practice IT Service Management approach that ITIL describes.

To a large degree I think this is because of the perceived bureaucracy that ITIL introduces [8]: processes, procedures, templates, workflows, … everything needs to be documented, reviewed & approved.

Perhaps so, but ITIL never actually identifies how complex, wordy, lengthy or formal these procedures need to be. Or even whether they should be written down at all.

More important is to understand WHY something needs to be done (rather than how) [9]. PRINCE2 (from the same best practice stable as ITIL) actually identifies tailoring as a must for every methodology and that tailoring is not about whether to use it or not but about how (formal) to use it. This is driven by factors of size, risk & complexity.

Change Management is a prime example [10]. This often becomes a bureaucratic bottleneck, because people focus too much on the formalities, paperwork, CAB meetings etc.

The ITSkeptic told at the Australian itSMF LeadIT conference, how one dev-ops engineer exclaimed that he could but a new version in production, ‘before you could get an Emergency CAB together’. That last statement doesn’t leave me with a lot of confidence, in particular if it was a mission-critical service/application we are talking about here.

Instead we should focus on the real goal of Change Management, which is to minimise impact. ‘Horses-for-courses’: sometimes you can go slow and secure, other times you need to go quick, but you better wear a helmet!

And Change Management accommodate the Dev-Ops concept of ‘failing fast’ [11] through defining different categories of change, each with their own level of documentation, assessment, approval and oversight.

1.    The Emergency (or ‘oh-shit’) Change means we don’t throw caution to the wind, but instead apply a different, faster, less rigorous process (basically we decrease time, but increase risk)
2.    The Standard Change allows a cookie-cutter approach to frequent, repeatable change, which will significantly reduce overheads
3.    And the use of ‘minor’ Change categories will allow a less convoluted path to be followed, whilst still maintain the appropriate governance.

The key here is no to be afraid of failure, but also not to close your eyes to the risk [12]. Mistakes are part of everyday life, and in fact mistakes are essential for growth, improvement and innovation. I call this the concept of making ‘deliberate mistakes’ [13].

So in our battle of Dev-Ops vs. Service Management, we find that ITIL actually incorporates everything that Agile is trying to achieve. But then, it does much more, allowing for both fast and slow changes; and with a lifecycle that includes Strategy & Operations (as well as Design, Transition and Improvement) [14]

Thus there can be only one outcome, and the (ITIL) Jedi must win [15].

But perhaps rather than looking at Star Wars as the fight of Luke against the Empire (and his father) of the first (now the last) three episodes, perhaps we should encompass the whole (6 episode) series as the lifetime of Anakin Skywalker (from good to bad, and back to good): In Anakin we find good and bad, jedi and sith, passion and ration, similar to how Dev-Ops and Service Management attempt to achieve the same goal (-better- value of services) through different approaches [16].

As long as the good side wins in the end!

(May the ITSM force be with you)

the ITIL Zealot

November 2013

The Alternative to ITIL …

If I follow the social media ITIL seems to be over the hype-curve, with many people predicting its impending demise, often due to various reasons:

• The joint venture with Capita (AXELOS) will make it too commercial
• COBIT (or …) is better
• DevOps will replace it
• Cloud computing has made it obsolete
• BYOD has made it obsolete

In our MALC course we actually debate the relevance of ITIL, whereby I as the facilitator take the opposing view, often using the very reasons I’ve highlighted above. It is refreshing to go over to the ‘dark side’ and attack the ITIL framework for all its weaknesses (or heralding the benefits of those mentioned above). At one stage we nearly decided to quit the course and start doing COBIT Foundations instead!

But it also makes me realise all the good things about ITIL and how to actually, practically apply it. I will address the ‘negative’ reasons in reverse order, but first I think it is important that at the heart of all this we are talking about IT service management. Service management is all about delivering (IT as) a service to the customer: a fixed-price, black-box, repeatable, guaranteed, managed & measured value.

This immediately invalidates any reasoning that a new kind of technology (for instance Cloud, BYO) will replace ITIL. ITIL\service management is not about technology, but which processes (\activities) to follow to make sure the technology delivers the benefits (=value) they’re supposed to. So, whilst Cloud and BYOD may make it easier to manage the technology, it is still required to define business value, guarantee the design, transition this, operate it and measure to validate or improve.

Service management is also a ‘best practice’, of which my favourite definition is ‘common sense written down’. And common sense doesn’t really change, so any ‘movement’ or development (like DevOps, return-to-core, rightsize, … even Agile or Lean) can at best only marginally change our opinion of common sense, but not completely invalidate it. Thus they won’t replace ITIL, but provide a different perspective on the guidance it provides.

ITIL is nothing more than the best-known proponent of the IT service management best practice. It has been around for a long time (25 years+), is recognised globally and arguably is the most accepted of the methodologies (certainly in terms of people certified, tools sold and ‘implementation’ performed).

This does not mean ITIL is perfect (despite the nom-de-plum I’ve chosen, even I don’t believe that). I fully recognise the weaker points of ITIL: its generalisms, inconsistencies, less-than-complete or defined strategy processes, its lack of dealing with the real-world (although complimentary publications like the ABC of ICT, Planning to Implement Service Management etc., do a good job of that).

As a consultant (and trainer) it’s these imperfections that make ITIL such as rich source of work: it has to be understood and adapted before it will succeed!

But ITIL has a few things going for it that will make it hard to ‘usurp’ as the leading service management methodology:

· Its ‘completeness’
· Its ‘installed base’

ITIL (since v3) now covers a lifecycle, which means that it just about covers everything you want\need in an IT organisation. Sure, there are some glaring omission (organisation & risk management, or a better defined governance framework) but by-and-large everything is covered.

Many of the other framework focus on one particular element (PRINCE2 for project management, Agile for development, Lean Sigma for process improvement, ISO2700x for security management) which at best makes them complimentary to ITIL, not a replacement.

There are but a few other ‘complete’ frameworks out there. MOF (the Microsoft Operations Framework) is not vendor-neutral and Microsoft hardly has the right audience (too many techo’s, not enough business managers). Plus it is by-and-large based on ITIL anyway. ISO\IEC 20000 is also based on ITIL and its prescriptive nature makes it less friendly to adopt & adept (though together with the additional guidance that is being released it certainly provide a good source of content, perspective and ideas).

This leaves us with COBIT (OK, potentially TOGAF or USMBOK but this is not meant to be an exhaustive comparison). Without going in too much detail, I’d consider COBIT the biggest ‘competitor’ to ITIL. In many perspectives COBIT is better than ITIL (more consistent, contains better governance and risk, provides a quick start, has ‘default’ RACIs, …). In fact if I were to start with a greenfield organisation I might even consider using COBIT instead of ITIL … but, be honest, how often do we come across this.

And so, based on the installed base of ITIL-trained people in the market (including consultants), the number of ITIL-based tools deployed (and/or available) it is very hard to ignore ITIL as the premier service management methodology. Again, this does not mean ITIL is perfect and many of the other frameworks referred to in this blog can be used in conjunction with ITIL, but they’ll not replace it.

Thus the best alternative for ITIL is … an updated ITIL. Which bring us to our last argument: the new joint venture AXELOS who now owns ITIL. A great opportunity lies before them to invest in ITIL (and the other best practices in the portfolio) and bring an update to the market that includes lessons learned in the market, benefits from other methodologies but above all in a consistent package with supporting products (quick guides, implementation guidance, …).

Currently they’re making all the right noises, so I will remain cautiously optimistic that AXELOS will improve ITIL. However, there is a very real risk that AXELOS could instead be the death knell for ITIL too: if they overemphasise the commercial side or focus too much on the UK\home market they will restrict the use and global involvement of the community in the on-going development of these best practices.

In that case I might switch my allegiance to COBIT or USMBOK, but for now I’ll remain the ITIL Zealot.

the ITIL Zealot
July 2013