New Blog - 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
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 st birthday 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
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
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
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.