DevOps in a Legacy World

In a recent survey conducted jointly by Ensono and the Cloud Industry Forum, 89% of the respondents stated that legacy systems were impeding their ability to execute a successful digital transformation. It would appear, based on this evidence, that legacy, at least in IT terms, is a negative concept.  Legacy is something that must be overcome, something that creates barriers to progress.

Legacy has become negative because we see it as ‘yesterday’s world’, the stuff we have to look after but don’t want to, the unwelcome aging aunt at the 21^stbirthday party.  There is, though, another way of looking at legacy.  Without ‘legacy’ systems many of us would not be in the jobs we are in because the organisations we work for would not exist.  Legacy created the place we are in.  It enabled us to arrive in this place and, in many cases, is keeping us here.

Somebody once said the last mainframe would be switched off in 1996.  Mainframes are still keeping many organisations alive but we shouldn’t see them as life support.  They are an integral element of business and yet they are viewed, along with a lot of other technology, as legacy and, therefore, not capable of supporting a DevOps approach.

What is really stopping DevOps in a legacy world?  It is often argued that all the techniques and technology we see as necessary for DevOps are new, but the reality is that they aren’t. Development environments, test environments, release cycles, environment copying … these all come from mainframes. Many were forgotten in the sudden emergence of client/server computing where development rigour was abandoned in a rush of freedom that came from developers suddenly having access to local computing power and development tools.  With the loss of the rigour came the concept of ‘throwing the Dev project over the wall to Ops’ which goes some way to explain why DevOps then began to re-emerge, driven by Operations, to recover from this ill-disciplined approach.

One of the issues is that DevOps is now seen as the new approach and often something that the ‘legacy guys’ in their ‘non-agile’ world will not comprehend. This creates a divide between the teams, a divide that has, unfortunately, been legitimised by philosophies such as Bi-Modal Operations which openly espouses two speed IT.  Organisations adopting Bi-Modal Operations often end up with clear divides between the Mode 1 and Mode 2 teams meaning that there is often cultural clashes between the teams as they operate to different imperatives.

Engendering cultural change has long been recognised as the key to unlocking success in DevOps but the cultural change needs to be established across the entire organisation and not simply in pockets which often ignore the legacy systems.  Some legacy systems may well be in their sunset period but the same should not apply to the staff the maintain them.  The systems may not justify investment and change but the teams that maintain them should be developed and invested in.  These are the people who will help with either the replacement of these legacy systems or who will be part of the process of modernising the systems.

This leads to another question. What makes a system ‘legacy’? For example, many organisations still operate core functions on mainframe technology and this is often regarded as legacy and investment in the systems and the associated staff reduced. The issue is that placing systems into the ‘legacy’ category should be a big decision but it is often an emotive one that arises through the opinions of various pockets of people within the business.

In many organisations there are ‘legacy’ systems running on fully supportable systems and yet, in the same organisations, there are often critical business systems running on unsupported environments but there is often little or no differentiation between the operating environments and the assigning of the ‘legacy’ tag.  As the decisions around the perceived status and value of the applications is often emotive, so are the decisions around the teams that support them and this can lead to divided teams.

The answer to effectively transforming the culture of an IT team is to embrace the entire team.  Separating teams based on the technology they support is not an effective approach.  For any team to function we don’t need a collection of superstars, we need a collection of like-minded individuals with a shared philosophy and a deep knowledge and passion for what they do.  A team needs a leader certainly, but it needs people who can lead situations and it needs to foster a culture of exploiting every individual’s talent.  It needs people capable of pushing the boundaries safe in the knowledge that there is a support mechanism in place if they fail.

The notion of embracing the entire team is often overlooked by many organisations who believe that to introduce DevOps they must import DevOps gurus and place them into the existing team.  This misses the point.  What organisations really need is to invest in educating and empowering the existing team, including those running the ‘legacy’ systems.  These teams will have a deep and intimate knowledge of the business and its culture and that knowledge is needed to drive cultural change.  Organisations who try to engender cultural change by replacing the existing teams rarely succeed.  Bringing in complete teams from an external source is an even greater recipe for failure, especially if the majority of that team comes from another organisation.

In many organisations, bringing a functional team in wholesale into, for example, a financial trading organisation, can short circuit a process because the team already know each other and the initial learning curve is cut.  Where the team is imported as part of a process of change, however, this lengthens or even endangers the change process.

The incoming team will have collective views and these will embed themselves into the recipient organisation, often taking little account of the organisation’s own culture or other external influences.  What occurs at this point is the continuation of the culture from the previous organisation which, whilst creating a different culture, rarely introduces the level of change that was originally sought.

Organisations that succeed in change are those that encourage all staff to engage. They see the need to create legacy together and be proud of legacy and see it as the platform upon which change can be built.  To return to the analogy at the head of this article, people need to grab the old aunt at the birthday party and dance with her – she can probably teach us dance steps we have never known and we can develop those for more modern music.

Arrange a Conversation