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