Deconstructing ITSM

20 January 2017

What should developers know about IT Service Management?

Filed under: ITSM — Joe Pearson @ 15:24
Tags: , ,

I often work with developers and others involved with developers, and often get into discussions about what “ITSM” covers and what—if anything—they ought to know about it.

This post is aimed at developers (and team leaders and scrum masters and managers), and business analysts, and project and programme managers, in the hope that it may help—or at least stimulate discussion. Comments welcome of course from ITSM specialists, especially if you think I’ve misrepresented something.

So what is IT service management? In a nutshell, it’s what has to happen to the development product after it’s deployed and goes live.

And what do developers need to do about it? In a nutshell, don’t ignore it until deployment. Don’t just provide a demo to the support desk at deployment time. And don’t try to do it all in isolation from existing service management teams and duplicate existing capabilities.


First, we call it service management (rather than app management or IT management or infrastructure management) because a service encompasses everything the user or customer needs to get value out of it—not just the application, program, package, etc but also business data, training, support channels, support tools, reporting, and so on. (Some of these may not be products under the control of the development team, of which more later.)

And we call it service management (not just service support) because it needs to be proactive and controlled, not just reactive.

IT Service Management

So, IT Service Management is what the service delivery organisation (which may or may not be part of the same organisation as the development teams) has to do to manage and maintain users getting value from the services.

In many ways ITSM looks at non-functional requirements. Performance (and capacity), availability, security, and continuity (business continuity / disaster recovery) are the four core aspects of service levels (“warranty”) that require designing for.

ITSM doesn’t begin when development finishes—that can only result in an unsupported and unmanaged service being handed to a user base unable to get proper value out of it. (In principle it begins before development begins, in the sense that IT strategy should encompass Service Strategy. This, to be fair, is not always done well and is often outside the control of developers, programme managers and the ITSM teams.)

Service requirements for a development product or feature require at least some planning and preparation. Ideally, new product requirements coming into the development organisation should include service performance and support requirements, but if they can’t be specified in enough detail at this stage they’ll need to built and iterated during development.

Success Criteria for ITSM—the end state

Before looking at the artefacts a development project or cycle might need to produce to contribute to good ITSM, let’s look at the desired end state.

Note: In most of the following I’m considering a major new application. Where a sprint is delivering self-contained new features into an existing application with an existing user base, many of the ITSM inputs will be simpler. Also, delivering an application to internal business users running critical business processes may require a lot more direct training and so on than a mobile app delivered to external consumers—but the latter case still requires ITSM planning and preparation.

ITSM for a specific service is a success if:

  • the service performs well under expected load (and you have correctly forecast the expected load)
  • the service performs reasonably under peak loads
  • the service is available when, and where, required (and you have correctly determined and agreed the availability requirements)
  • the service is secure, meeting service-specific and general—company and legislative—requirements (and you know the requirements, etc)
  • the service can be deployed efficiently and effectively, whether to a hosting platform or provisioned to a new user
  • there is in-life support:
    • a way for users to request and receive help
    • to get things fixed, to get requests fulfilled
    • the support teams have sufficient understanding and tools to diagnose user issues and resolve them (possibly passing to more expert/specialised support team levels)
    • the support teams and tools are correctly sized for the user volumes
  • the new services and technology components are integrated into service management tools and databases, in terms of monitoring, request ticket categorisation, dependency mapping, service level reporting, and so on
  • if there are external support organisations, agreements (warranties or underpinning contracts) are in place and are sufficient

Of course, these success criteria only apply when the service is live, and sometimes they can only be verified after the service or feature has been live for a while. During development sprints or phases, they need requirements management, planning, design and building, often as inputs to the service owner.

Development projects, sprints, etc are successful in ITSM terms if they manage those requirements (maintaining them per sprint—they must not be static), and plan, design, test and deploy artefacts that the service owner accepts, so that the final service product meets the above success criteria.

Artefacts—what can be worked on now

The amount of detail these suggested artefacts will need depends on the scale of the application and the nature of the user base. And the formats—demo training sessions, standalone documentation, and/or configuration data loaded into ITSM tools—will depend on the policies and capabilities of the support teams.

  • Information for support staff and processes
    • Both training sessions and documentation can be useful; neither alone will probably be enough. Support documentation is not the same as user documentation, though support staff also need to understand the user perspective.
    • Diagnostic scripts and possibly tools, to assist first-line support to isolate possible issue and gather information needed. These can also be great for self-service portals.
    • This information feeds into the incident, request, problem and change processes. The development team does not need to write or change those processes!
  • Tools for monitoring app availability and performance, supporting monitoring, alerting and diagnostics
    • Ideally, instrumentation in the app to support existing tools
  • Service level agreements (and/or depending on the stage, service level requirements (SLR), operational level agreements (OLA), underpinning contracts)
  • Server, database, network capacity projections—based on user workload and component utilisation impact per unit workload
  • Performance and availability targets

When and how to build

As with many non-functional requirements, some of the success criteria I’ve highlighted are negative—don’t be unavailable, don’t perform slowly, don’t implement something incompatible with existing service management capabilities. They are constraints affecting the entire product or service rather than features that can be delivered individually.

As such, it’s not always possible to pick and choose a subset of post-it user stories that will fit into a sprint, as the product won’t be ready for deployment unless all aspects of it can be supported. Clearly this can present a challenge to agile methods.

Not all organisations approach the challenge the same way, but as general guidance:

  • Plan early—identify constraints on the architecture and design, and non-functional requirements that need an architectural deliverable in one sprint, and perhaps a number of feature deliverables in future sprints
  • Don’t fall into the trap of performance can only be assessed once you have working code, or that support documentation can only be started once the development work is finished
  • Equally, don’t fall into the trap of making support documentation, or monitoring and diagnostic features, or service management configuration data, something static and rigid that makes it difficult to change features in future sprints
  • These ITSM deliverables must be capable of iteration—”enough” support tooling now, new and changed capabilities in future.

Test and acceptance

  • The ITSM deliverables must be tested and integrated – as new functional features are built, do the non-functional deliverables still meet the needs?
  • Sometimes, if not often, this testing will not be possible or practical to automate. You’ll need walkthroughs or support staff sign-off. (But in a major development environment, you should have ways to simulate high load, the effect of component failure, etc.)

And who does this?

Get support staff represented in the sprints, both front-line user support and back-office monitoring and maintenance. The product will be handed over to the support organisation just as much as to the customer.

Support staff are best placed to advise on the support deliverables that are needed. Development team members are best placed to create the artefacts—allocate them as you would any task, user story, card, etc.

All of this has been done before—get experts in if needed.

Last words

OK, that ended up being a pretty long post. I’ll try to write a shorter version of it some time! I hope it contains some useful pointers.

In summary, don’t “throw the product over the wall” to the support team. Support and operations are customers of the development cycle just as much as the end users. Get the service owner represented in the team in the same way as the product owner.


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

%d bloggers like this: