Cloud Migration: A Journey In Visibility, Communication, & Regulation

Problem

I had to help an organization with a cloud transformation because of some problems and difficulties I had realized. There were some prior architectural decisions that were paralyzing the IT delivery organization and cloud was a part of the solution. In a previous role within the same organization, I had been tasked with moving one of their data centers. During this, I discovered an architectural decision had been made to create independent “stacks” of systems for each development feature. This had resulted in hundreds of systems that needed to be managed, draining infrastructure resources. To make matters worse, lack of good data management meant product and development didn’t stay within their stacks causing errors and conflicts. Overall, this was just an absolute mess. it was slow to create new capabilities for customers and the quality was low.

Unfortunately, this problem was not very well known by everyone. I thought we should look at the underlying reasons behind this so that we can start to put the right piece into place. Once I established this, I had to convince everyone of the importance of making the necessary changes.

Actions taken

I proposed a three-step plan of things we needed to introduce to fix it.

The first step was to present this largely unknown problem to a few hundred people. It consisted of our leaders, managers, and other technical leaders. This presentation was a key spark that got them talking. I had to explain it clearly and straightforward because they needed to understand the pain points. They needed to see what is slowing us down and why we need to fix this problem. This helped us get some initial momentum, but, of course, this created many questions, and there was some pushback.

The second step was to deal with the concerns. The pushback came primarily from the development teams. Our infrastructure teams did not express the same concerns because they were the ones swamped with work, and they were paralyzed to the point that they could not get any exciting work done. This meant morale was low and I needed a spark to engage infrastructure in the change. I proposed a series of small changes to the platforms we were engaging with to introduce some new technologies to ease the tedious work of managing the chaos. This freed up time to focus on the more exciting work that would create capabilities for the delivery teams. By solving the original problem, we could help the team see the light at the end of the tunnel. We could show our teams the problems and have them engage and propose some solutions to help us solve the problem.

The third step was to introduce cloud capabilities into the organization to enable them to more effectively manage the environment sprawl. This was only a part of the solution as the majority of systems were not suitable for cloud migration. Instead, we built out a staging platform internally and began to work with the teams on refactoring the critical parts of the applications. This involved creating alignment across the project, development, security, architecture, and infrastructure teams as to what the target solution should be.

Lessons learned

• I learned about the importance of involving the teams in helping find the solution. Of course, I identified the problem and had an idea of how to solve it, but I wanted to know how the teams would deal with the problems. By giving the teams the capacity and the time to come up with different ways of addressing the issue would help us continue down the path to a solution.

• The human element here was simply involving our teams and adopting similar approaches to the problems we needed to solve. I knew we needed to create a spark that helped us have a sense of urgency to adopt a different change model for organizational change. This experience has now made me a subject matter expert on topics and issues like these, but at that moment, I knew that things would only get worse if we did not act quickly.

• If we did not act quickly, we were going to end up in a situation where we were going to start losing business. If our systems started consistently failing, and we could not keep up, the complexity surrounding those issues would only get worse. The infrastructure side would not be able to do their jobs, which meant development would grind to a halt.

• In this experience, I later learned that not only were infrastructure and development affected, but also our IT team was also heavily impacted. They were continually dealing with irrelevant requests that did not generate business value, and we had no traceability. Too many requests with a limited capacity to handle them showed no alignment between what the customer needed and what we created.

• Overall, one of the key learnings was that when you are dealing with that level and amount of complexity, you cannot manage that from the top. You have to empower your teams to be able to solve these problems. My role had to be taking that over and helping ensure that I was giving my teams enough air cover and finding ways to free up time to implement some of the needed changes.

• I had to go out, develop relationships, and make friends with many of the leaders on the development side of the technology organization and beyond. I brought them to the table and started conversations that, quite frankly, had not been happening up to that point. We needed to get those communication channels going so that we were not operating in those silos.