itSMFA Bulletin February 2017 itSMFA 2017 February Bulletin | Page 5

With small, frequent point releases, systems are have reasonable situational awareness of what
growing in a more resilient way than monolithic has been changing. It is not optimal for the Ser-
releases tended to achieve.
vice Desk only to become aware of a change
when the calls start coming in. Ideally, they
Unarguably, the new methodology is highlighting the should be armed with knowledge of how to deal
shortcomings of the old. Can anyone argue today with those issues.
that a Change Advisory Board made of humans,
collating verbal assurances from other humans, is No matter how effective the first line of support
preferable to an effective, fully-automated assurance is, some issues will get to the application team.
process, seamlessly integrated with the release
Those issues will vary, as will the level of pain
pipeline?
that each is causing. Triage is required, and that
is only possible if there a clear understanding of
the business and customer perspective.
Facing a queue of two tickets, or ten tickets, or
one hundred tickets, the application team has to
decide what to do first. This is where things start
to unravel for an idealistic, full-stack, “you break
it, you fix it” devops team. Which issues are
causing business damage? Which are the most
time critical? Which can be deferred? How much
We know, then, that DevOps methods dramatically time should we spend on this stuff at the cost of
improve the speed and reliability with which moving the product forward? This is the stuff that
technology change can increase business value. But Service Management ought to be able to provide.
that’s where the arguments on both sides start to Effective Service Management in any industry
wear thin. What is that business value? How do we starts with a fundamental understanding of the
identify it, measure it, and assure its delivery?
customer. Who are they? What makes them
In my experience, there is little mention of the
customer at DevOps events. DevOps is seen,
correctly, as a new and improved way to drive
business value from software development, but the
thinking feels very “bottom up”. There is huge
willingness to drive business value, but is there
enough top-down, customer-first thinking? ITSM
commentators seem to have taken the same starting
point: drilling into minutiae of process without really
considering the value that ITSM should be looking to
bring to the new world.
To highlight why a lack of service context is a
problem, let’s take the simple example of frontline
support. When developers push out an incremental
release to a product, customers start to use it. No
matter how robust the testing of that release was,
some of those customers will encounter issues that
need support (not every issue is caused by a bug that
was missed in testing, after all).
The Service Desk will of course try to absorb many of
those issues at the first step. That is one of its
fundamental aims. To do this effectively, it needs to
5 itSMF Bulletin—February 2017
successful? What makes them tell other potential
customers how great you are? What annoys
them? What hurts them? What will trigger them
to ask for a refund? What makes them go
elsewhere altogether? And, importantly: what is
it that we are obligated to provide them with?