DevOps in Legacy Systems

I had a discussion with one of my then-manager-colleague about ensuring the movement of a planned item even if the only available team member has no expertise to take it on. The simple answer is to get that team member to a starting point with the help of the experienced ones, through a non-heavy pair work format, just enough to give them momentum. It is possible that the task won't be completed on time, but at least they got it moving.

In practice this is always easier said than done since we always fall to the mindset of either: "It is going to be faster if the expert will do it" or "I'll just take this non priority item which I have expertise on rather than mess up that very critical one". This somewhat silo mentality is especially prevalent in legacy systems, adding to the hurdles on its already challenging DevOps adoption.

In attempts to assume DevOps practices, most of the failures are caused by the teams' resistance to change because of the leaders oversimplifying the problem. That is why at the initial stages of DevOps assessment, dialogue between leaders and legacy teams is required so that visions and goals are personally communicated, uncertainties are addressed, and negotiations and agreements are formulated, which in turn will help earn the people's confidence and acceptance towards it. DevOps is a culture after all. It is also worth noting that a DevOps team/person is not necessary where creating one turned out to be problematic for some because the bottleneck just got transferred to another entity.

An attitude of shared responsibility is an aspect of DevOps culture that encourages closer collaboration. It’s easy for a development team to become disinterested in the operation and maintenance of a system if it is handed over to another team to look after. If a development team shares the responsibility of looking after a system over the course of its lifetime, they are able to share the operations staff’s pain and so identify ways to simplify deployment and maintenance (e.g. by automating deployments and improving logging).  - Martin Fowler

Here are some of what needs to be resolved and considered when deliberating on adopting DevOps:

Architecture and technology audit. In DevOps POV, it is important to include: list of supported systems (document declared and client-deployed), SCM branch strategy and end-to-end delivery process flow definition. In a decade old legacy systems, small automated processes and tools are most likely to be existing already and should also be accounted.

Assessment of your system against automation tool-sets, taking note of benchmark and baseline data to help define realistic targets for the metrics. And speaking of metrics, selecting the right kind that can be translated in business value terms and is understood by all is key to continuous improvement. Examples: deployment speed, failure rates, delivery frequency, bug recurrence rate, etc.

Interface agreements. When teams are at their exploratory work, be it in automation or trying out new tools, establishing standards on how they will send their data across the entire delivery process will promote parallel development and help in traceability. Most importantly, these data interfaces will protect their autonomy where implementation is being left to their discretion, as long as the ending output adheres to the standard format that is compatible to the next phases of the pipeline. Given that, a part of these interface agreements must include counter-checking mechanisms.
But, whether a DevOps initiative will push through or not, it is always beneficial for an organization maintaining a legacy system to already start investing on the following:

1. Standards and best practices.
2. Unit test coverage including codes involved in operations, to get the earliest feedback at the most fundamental level.
3. Automation and development of specialized tooling that will cater to the system's automation needs.
4. Technical debt repayment.
5. Exploring the possibility of cloud and containerized solutions.

Porting legacy systems to DevOps is especially hard because of the associated practices and attitude that came with it. Just like in any acclimatization process, small adaptations with demonstrative progress is more effective rather than having a strict top-down approach. People are inherently motivated if the progress is a result of their own volition to the improvement of self or otherwise. 100% in full DevOps may not be achieved, but at least there will be a motivation to get it moving.

----------------------------------------------------------------------------------------------------------
This article was originally published in LinkedIn