How to modernise IT systems while ensuring they remain stable

There are countless references on the web that discuss topics like “the world of technology is changing”, and “organisations need to modernise to stay relevant”. IT leaders are constantly being told that this is “a paradigm shift”.

Are these people wrong? No. In the most, it is all good, but they tend to focus on application development, promoting modern ways of working and managing. Concepts such as agile practices, DevOps and open leadership sometimes lack the details of changes that people and operations need to make.

Let us consider how we manage changes to infrastructure or software, also known as technical change management in the context of agile. Throughout various iterations of ITIL, this discipline has rightly focused on managing the risks and impacts of changes to technical components needed to deliver a service. It does this by ensuring that changes are documented, logged, and (if necessary) approved by a competent and authorised person or group.

As the world turns to “digital”, many organisations are now finding that their change management processes are slow-moving, cumbersome and bureaucratic. Agile teams’ immediate response is either to ignore or, in some cases, to reject change management processes entirely. We have experienced such scenarios a number of times with various companies, and we strongly believe this is absolutely the worst thing to do.

Change management is an aspect of risk management, and so the change management approach should help the organisation balance risks and reward. Back in the day, software was literally shipped to stores and offices around the world. In the pre-broadband era, technology didn’t allow for the easy recall, replacement or patching of defective software.

Any defective software resulted in reputational and financial loss, so controls emerged that reflected these risks and challenges – rigorous testing, selected defined shipping dates, approval by groups and stakeholders, often multiple stages of approval beyond that, and so on. The cost of failure was high, which meant that the risk was assessed to be high and a lot of checks, balances and general rigour were introduced.

We now live and work in a different era. Nowadays, information storage, transmission and exchange costs are constantly reducing. That, coupled with agile, allows organisations, teams and individuals to harness the low costs associated with information transmission and the new extreme levels of compute power.

The general belief held by many change management professionals is that as teams get faster at doing things, the chances of slipping up – introducing a bug or missing a key compliance requirement – also increase.

We would encourage everyone to articulate changes from the perspective of the end-user. For example, “upgrading the invoicing database” is far more descriptive than “Apply patch TK421 to database DB09451”, with the added benefit that it helps IT teams to recognise how their work impacts and benefits the wider enterprise. This goes a long way to creating a shared understanding of change-related risks and rewards.

It is also important to integrate systems of engagement and systems of record. Let IT teams work with the tools they need to get their jobs done, as long as those tools can create and maintain change records in whatever IT service management tool you have deployed. This empowers IT teams to work in a self-organising way, while maintaining the proper risk and compliance posture.

Consider the design of a Formula 1 racing car. It is all about stretching the laws of physics to make the car go as fast as possible. Millions of dollars are spent on components to get it moving fast in a straight line, stick like glue to the track as it corners at 140-plus mph. But, crucially, to stop as quickly as it starts.

There is also an insane level of logging, monitoring and overall control that goes into the cars. In this fairly extreme example, the interconnectedness of systems and services often obscures the incredible complexity of underlying components. Each one is about the way it can “enable”, as opposed to “manage”, success.

That follows through to the organisations that are going through transformation. As they modernise their applications, tools, processes and ways of working, they need to stop thinking about managing change and instead think about how they enable change.

Collaboratively working together to modernise the practices that reflect the potential, as well as the limitations, of current technologies is a bold but important step. This is one of the largest challenges this area faces, a huge mindset change, but with that mindset shift to change enablement, the change teams, the agile teams and customers of the outcomes all get what they want, when they want it.

John Kendrick is an agile and digital transformation delivery specialist at DMW Group. Akshay Anand is  a product ambassador for IT service management at Axelos.