DevOps in Legacy Systems

I had a discussion with one of my then-manager-colleagues 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 siloed mentality is especially prevalent in legacy systems, adding to the hurdles of an already challenging DevOps adoption.

In attempts to assume DevOps practices, most failures occur due to teams' resistance to change because leaders oversimplify the problem. That's why, in the early stages of DevOps assessment, dialogue between leaders and legacy teams is necessary to personally communicate visions and goals, address uncertainties, and formulate negotiations and agreements. This approach helps build confidence and acceptance among the people, as DevOps is ultimately a cultural shift. 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:

Full Architecture and Technology Audit

In a DevOps perspective, it is important to include a list of all supported systems (document-declared and client-deployed), the SCM branching/release strategy, and the end-to-end delivery and deployment architecture documents. In decades-old legacy systems, small automated processes and tools are most likely to be existing already and should also be accounted. Having this audit will help everyone gain an understanding of the system and underlying processes as a first step in achieving one of the core principles in DevOps, which is flow/systems thinking.

Assessment of Your System Against Automation and DevOps Toolsets

Take note of benchmark and baseline data to help define realistic targets for your roadmap. And for the metrics, not over-complicating and selecting the right kind that can be translated into business value terms that is understood by all is key to continuous improvement (examples: deployment speed, failure rates, delivery frequency, and bug recurrence rate).

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. As already said, to make it easier to define interfaces between processes of the delivery once it has been decided to automate these. 
2. Unit test coverage and an emphasis to have it against codes in tools and operations as well. In working with legacy systems in the past, a lot of deployment delays are caused by the release delivery system failing. This failure is attributed to the neglect of appropriate development practices against delivery system itself.
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.

The process of adopting DevOps to legacy systems poses unique challenges due to the ingrained practices and attitudes associated with them. Similar to any process of adaptation, achieving success is more feasible by implementing gradual adjustments that showcase tangible progress, rather than strictly adhering to a top-down approach. When individuals perceive that progress is driven by their own willingness to enhance themselves or contribute to overall improvement, their intrinsic motivation is naturally heightened. A full 100% DevOps may not be achieved, but at least there will be a motivation to get it moving.