Enterprise Release Management Tools Group Test

The ITSM Review will be performing a deep dive review of Enterprise Release Management tools.

This article provides an introduction to Enterprise Release Management (ERM) and a high level summary of typical functionality.

Notes

  • This group test will be conducted by Rebecca Beach, our ITSM Analyst, and Rob Spencer, Change and Release specialist and vice-chair of the UK itSMF Transition SIG.
  • We’ve also included a few examples of providers who offer ERM capabilities – please let me know of any other suggestions.
  • If any suppliers wish to participate in our Group Test please contact us before 30th September 2014.
  • Learn more about our Group Tests.
  • Read our back catalogue of completed Group Tests.

Thanks, Martin


Introduction to Enterprise Release Management

By Rob Spencer

How do organisations plan tens or hundreds of releases a year across project delivery, vendor patching, infrastructure changes and more? How do they manage competition for access to test environments, ensure they spot colliding production releases in good time and avoid overbooking their test teams?

How do they articulate this enterprise-wide release roadmap to senior stakeholders, customers and IT staff?

Traditional answers to these questions usually take the form of project plans and spreadsheets. They rely on regular meetings between project office, operations & technical staff to keep them in sync, and are rarely, if ever, accurate in real time.

Today, a new breed of release management planning tools is emerging. Enterprise Release Management tools are agnostic of functional requirements or constituent change requests, and they don’t manage the actual deployment of code. They simply allow the entire IT organisation to track and manage the entire portfolio of releases across all environments. They have the scope breadth of a Change Schedule, but go into more detail.

At their simplest, they are a single source of the truth for the multitude of spreadsheets they replace, but most can pivot this data to provide people with the information they care about in customised and intuitive views – from CIO roadmaps to a test manager’s forward work plan.

Ultimately, they give Service Operations a reliable, realtime view of all upcoming releases with at-a-glance assurance that the right governance has been completed for each. And since they span both development and operations, many are starting to be called DevOps Release tools.

ERM

What does an Enterprise Release Management tool do?

  • Plans (and scopes) a release – Allows the construction of an end to end release plan following a user-customisable structure which could map to eg. an organisations’ project governance gateways. Should be able to record both governance activities/milestones as well as physical activities in multiple environments (deployments, test runs etc). Ideally should be templatable and re-usable.
  • Plans ALL releases – Takes the individual releases and plots them against a common timeline to spot resource over/under utilisation, go-live collisions and tells operations when to brace for action.
  • Manages environment & resource usage – Pivots the data from all releases and show an environment – or resource -centric view of the same data. Helps answer questions such as “what’s happening in our Pre-Prod environment next week?” or “can I deliver everything I promised?”
  • Presents data in various views depending on audience – The steering committee has different needs to those of a test manager, and the project needs to be able to see anything relevant with a few clicks. Does the tool allow varying levels of detail to be presented over user-defined timescales in a clean and coherent way no matter the format?
  • And not forgetting… – Role based access to stop people from seeing the wrong things (or changing them), the ability to dynamically import and update change requests from other tools (data exchange mechanisms such as XML and RESTful APIs are becoming the norm in service tools).

Methodology

To test these, we’re constructing an entire fictitious company with a busy year of releases including new system deliveries, infrastructure refreshes, monthly & quarterly patching to cloud and on-premise services. We’re covering both agile and waterfall development & delivery methodologies, and even introducing some DevOps practice. We’re sharing this case study with the participating vendors, and we’re also going to make our own spreadsheet versions of the plans (which we won’t share with the vendors in advance). Our case study also includes some fairly thorny problems which a typical organisation could encounter eg. scheduling conflicts, people not following process and people whose idea of planning is far removed from the reality of their customers’ needs.


Here are some tools we are aware of in this area.

If anyone knows of any others please leave a comment below or drop us a line. I will update the list as we find new suggestions. Thanks, Martin

Assessment Criteria for Request Fulfilment

We will soon begin our review of Request Fulfilment offerings in the ITSM market place. Our goal is to highlight the key strengths, competitive differentiators and innovation in the industry.

In my previous article I looked at what ITIL 2011 had added to the process, and some of the pitfalls we may have seen in trying to implement Request Fulfilment in the past.

I would now like to take a look at what this means, in practical terms, when approaching Request Fulfilment – what should we be looking for?

At the recent UK itSMF ITSM Software Tools Forum event in Manchester, vendors spoke to the audience at length about transitioning from IT focussed decisions, to business outcomes, and this is an area where Request Fulfilment could come into its own, especially in the sphere of interaction by non-IT users.

But a transition is a gradual thing, and the importance of the concept of conformance should not be forgotten. I think it remains an important element for any vendor’s toolset to be comparable to identified, accepted benchmarks, as well as unpicking the practicalities of deployment a solution.

Principles vs. Process

What is more important at this stage, is the ease of which a tool’s capability can be displayed.

Demos at shows are slick and well prepared and I dare say a lot of us have had to go through the rigours of setting up demos and knowing what to click, how and where.

What we are looking for vendors to do is demonstrate to us how easy is it to start from scratch, ideally with meaningful options for an end user to start with.

Suggested Criteria


It is probably too much of an extreme to launch from recognisable standards and certification/verification platforms, to merely focussing on the look and feel of menus and options for end users in one fell swoop.

So for that reason, I am including a need to understand how vendors align to accepted best practice standards.

Overall Alignment

  • Have our target vendors aligned to ITIL and if so, to which version?
  • How do the set up roles and users to perform functions?
  • What demo capabilities can they offer potential customers?

 Request Models

  • What request workflows are available out-of-the-box
  • How easy is it to develop more specific workflows?
  • What additional administration is required for deeper customisation? At what cost?

Menu Selection

  • How is your self-help portal set up?
  • How do you incorporate new service descriptions for your users?
  • How much administration is needed to do the more bespoke work?

Request Status Tracking

  • Show us how any request is tracked throughout its lifecycle?
  • Who can see it, and when, and which teams can change it/move it on its way?

Prioritising & Escalating Requests

  • Show us how your tool prioritises requests and how they can be escalated?
  • What kind of other factors can affect a ticket (for example breaching SLAs and the escalation from that point)?
  • If a request becomes something more complex, how does your tool allow the alteration of the request (for example, a Change)

Financial & Other Approvals

  • Demonstrate a request model that includes alternative approvals (other than immediate manager)

End-to-End Co-ordination to Closure

  • We don’t expect tools to prescribe exactly how organisations manage their Request Fulfilment processes, just as we don’t follow ITIL blindly BUT during the course of the review, we want to understand how  a request can move through its lifecycle, end-to-end.
  • We want to understand the simple (out of the box), the medium and the complex (and the related additional costs that might be involved to get an organisation there).

I think it is rare that anything is utilised completely “out-of-the-box” these days, and that organisations will always have a requirement for some level of customisation. Request Fulfilment is certainly a process that could lend itself to quite intricate customisation, to the point of over-complication.


What is your view? What have we missed?

Please leave a comment below or contact us. Similarly if you are a vendor and would like to be included in our review please contact us. Thanks, Ros.