Choosing the Right First Steps in DevOps Mainframe Transformation
Sometimes, you just need to get started. Especially when you have a big, challenging mainframe transformation ahead of you. You can’t get intimidated by the size of the project ahead. You can’t worry about planning everything perfectly. You can’t spend too much time trying to convince every skeptical stakeholder that the transformation will be a big success.
You just need to get started, to achieve some “quick wins”, to improve over time, and to convince the skeptics through tangible results, no matter how small they might look.
We took this approach with a recent client.
For the past 18+ months we have moved this client through a massive DevOps transformation of their mainframe application development capability.
Over this timeframe, we have made substantial progress… but it all began with a very small, very imperfect, and very isolated initial project.
In this article, we will explore why we took this approach, the challenges we faced getting this client started with their DevOps transformation, and how we chose and delivered this specific first project to just get the client started down the right path to a successful long-term transformation.
Identifying and Planning to Solve the Real Barrier to Transformation
When we first looked at this project, we saw two big challenges to overcome.
- We had to solve the technical challenges of helping this client automate and standardize their processes.
- We had to solve the people challenges of getting their teams to accept the transformation and actually use these automations.
The project’s technical challenges were big, but they were relatively easy to solve: we knew how to write the necessary automations.
But the project’s people challenges were another story… and in some ways even more important to overcome.
We knew the client’s DevOps transformation would be a failure if we couldn’t get their teams on board.
And they had good reasons to be skeptical of this transformation.
They had been following their own way of doing things for many years, sometimes decades. They knew their processes were imperfect, but they knew their processes worked well enough to get by… and they had no evidence that our proposed mainframe application automation and standardization would work at all, let alone deliver improved outcomes.
What’s more, they had already attempted to automate their processes before. The client’s 20+ mainframe application development teams had written many automation scripts. But these scripts were narrowly focused, poorly documented, and never really shared between teams.
In short: the client’s past work in this area had never added up to the sort of end-to-end automated and standardized process environment that we were talking about. Even if these teams believed that what we were attempting to achieve was possible, they had a hard time believing that it could work for them.
We took this resistance seriously. We knew we needed to overcome this resistance and convince client teams that any of their processes could be automated and standardized in even the smallest, most imperfect way—it was even more than just building great automation.
We knew if we could do this, then we could start to disarm their concerns for the larger project, and to begin to build each team’s trust and belief in our project. If we could accomplish something small, it would lay a foundation that we could build upon for the next sets of bigger and bigger challenges.
Now a quick note: we couldn’t pick a process that was too small and would look insignificant when completed. We needed to show that mainframe application automation was both possible and worth doing. So we needed to automate something that would produce a meaningful, measurable impact once it was completed.
With all this in mind, we set out to decide what elements of this client’s work we could automate first as a “proof of concept” for the project as a whole, and looked for something we could automate relatively quickly and easily, but which would still result in a meaningful process improvement once it was done.
Here is what we chose, and why.