Servicing in a Cloud World

To kick things off on this rather derelict looking blog ;-), I wanted to start with a topic that I’ve been discussing with several customers recently, namely ‘Servicing in a Cloud World’. Why? Because it’s super important and requires a step change in the way IT organisations react to change, and communicate/engage this with their end-users.

Widespread adoption of Cloud technologies is almost old news now, organisations have been, and are currently, actively migrating services to a variety of cloud models. This includes anything from IaaS to PaaS to SaaS and they are therefore handing responsibilities over to the provider on a sliding scale. The most extreme end of this scale is any SaaS based solution as the provider not only manages/administers the solution for you, but also owns the roadmap which includes both feature additions and deprecations.

The following diagram taken from the “Change Management for Office 365 clients” guide by Microsoft, illustrates the difference between a traditional release model vs a servicing release model:

clip_image001

In a traditional release model with infrastructure/platform or services managed and administered by the organisation, typically releases happen after several months of planning, developing and testing. The actual “release” is then usually governed through change/release management processes which would generally involve some form of impact assessment as well as a mechanism by which to alert the target user base that the release is coming. This may then be supported by engagement through training / user guides, etc.

clip_image002

In a servicing release model where the infrastructure/platform or service is managed and administered by the provider, releases typically happen much faster and much more aggressively. This is due to the provider being incentivised (generally through a PAYG subscription approach) to be innovative on the platform to retain or attract new custom. As illustrated in the figure, this means the each stage of the lifecycle of the release is generally much smaller. This model is advantageous for organisations as it means they can leverage capability much sooner rather than having to invest in the planning/development and testing themselves. A well-understood benefit of Cloud, right?!

Onto the point of this post; organisations typically have well-defined and robust change and release management processes grown through many years of managing and delivering services out to their userbase (as discussed earlier in reference to the traditional release model). They are experts at managing changes and releases that are under their own control. However, it is crucial that organisations adapt these processes in reaction to the “servicing world”. These include gaining a full understanding of the providers roadmap in the following areas:

  • Minor / Major Changes
  • Feature additions
  • Feature modifications
  • Feature deprecations
  • New product releases (in the same portfolio)
  • Servicing (which can include downtime)
  • Maintenance

As noted earlier, these releases are typically much more frequent than previous, and will require roles and responsibilities across the IT org to adapt – making sure that they not only focus on the actual release but to understand how this will impact end users as well, who will likely require support as the frequency of change and adoption of new features/technologies will be unfamiliar.

To provide some support to this post, Office 365 Message Centre averages about 12-15 “notifications” per week (note, this changes frequently!) – anything from a new product, a feature change or a service announcement. Ultimately, as more services move to Cloud – the roles and responsibilities within IT need to adapt accordingly as IT professionals work to support their organisations operating in a cloud servicing world.

Advertisements