Looking for Automation in your Cloud Transformation Journey? Check what the Experts Say

One of the most common blockers in any cloud transformation journey is the time and money that need to be invested in the cloud migration efforts and whether it will meet the desired ROI. While thinking about this, it will not be surprising if a thought for maximum automation runs across the leadership’s mind. Some organizations take automation on a serious note and keep taking one step at a time to check whether it really works. While many other give up on automation due to the fear of implementing too many cultural and technological changes in the organization.

To get rid of this dilemma and have a clear vision about the extent of automation in cloud adoption, read below the interesting facts uncovered in the fireside chat between Milan Bhatt (EVP, Cloudify Everything, Hexaware Technologies) and Anil Jaising (Cloud Strategist, Concepts and Beyond Inc.) at the World Forum Disrupt, 2021. Get to know the valuable lessons they learned from their decades of experience in framing cloud transformation strategies for several customers including Fortune 500 companies.

Milan: Cloud adoption and automation are inseparable. Automation-first is the only way to adopt cloud at scale.

Anil: Automation was already built into the DNA of many leading organizations I worked with. So, is automation really needed to accelerate cloud adoption if it is already adopted earlier in some or the other way?

Milan: The industry has done very well in some areas like the adoption of DevOps, automation in CI/CD pipeline, automation in testing, automation in monitoring, and even automation of discovery to sunset applications. However, there are many more areas where automation is still under-implemented. I would call this as the last mile problem in cloud adoption. Let us consider an example of e-commerce wherein more than half of the distribution costs are for the last mile. A similar phenomenon exists in cloud adoption. Most customers can leverage existing tools and automation for cloud adoption of 90-95% of their portfolio applications. But the last mile, that is the remaining 5%, also happens to be the core of their business. For example, for an airline company the last mile could be their reservation system, for a bank it could be their core banking system, or for an insurance company it could be their policy administration system. Very little has been done regarding the aspects of automation in reprofiling the working of these applications and their interdependencies and for modernization of these applications. This is the area where organizations, if invested smartly, can progress significantly in their cloud transformation journey.

Anil: Can you please share an example?

Milan: We can take an example of our very large financial services customer based out of North America. They have a reverse mortgage product portfolio of applications that supports all the services coming under this offering. There was a need to modernize this for an enhanced customer experience. They wanted to break this big application into microservices so that changes can be implemented quickly and also wanted to shift to a modern technology stack to get rid of WebLogic and high licensing costs. For this shift, they preferred
open-source and cloud-based PaaS services. One major challenge here was the unavailability of SMEs for this 20-year-old application. Also, very little end to end documentation was available. The customer wanted to modernize this application quickly in just one year. The application had around 4 million lines of code and there was very little visibility into the application architecture. The customer partnered with us for cloud transformation services. We built an automation suite that did discovery of the application in just a few days, profiled the entire application and its architecture in a few weeks, and did the modernization automatically in another few weeks. The end to end duration of this project was just 10 weeks wherein the customer wanted to do this in a year. This became possible due to automation. Also, the total cost came out to be just one-tenth of what the customer had estimated for this modernization. Thus, there was a considerable shrink in the timeframe, risks, and cost.

Milan: Culture and mindset change is key for such accelerated cloud adoption as it requires a clear vision. What are your views on the challenges that pop up while implementing such cultural and mindset changes?

Anil: When we talk about these large cloud transformations, what we typically tend to do is take the work
service-by-service or do a lot of pilots. We keep experimenting in the dev environment only rather than focusing on how we change right from the beginning till the production environment. Let me share my experience of this Fortune 500 bank that had about 6500 applications, 320 PB of data, and thousands of integrations into its legacy bank system. The goal we set was to try shifting a workload in the production environment very quickly to take it to AWS public cloud. Once this goal was set, it brought a big mindset change in the team.

As the first step, we analyzed all the different workloads that the bank had and then prioritized the applications for which the workloads could be taken into production for cloud migration. What we found was there were a lot of web applications based on SpringBoot. We ensured that we had all the AWS services we needed to get these workloads on the cloud.

In the second step, we focused on the people. We needed everyone to be involved, like the application teams and the support staff who could help the application teams to upgrade their talent. The support staff, called as catalysts, were also the implementation experts. We also involved the network team and database administrators, risk managers for approvals, cybersecurity experts, and the local and global regulations experts to ensure that no data is compromised. In order to do all this, we created an environment which we called as the Cloud Party. It was basically getting all these people on one floor or on a call or web to sort issues and take decisions quickly in a coordinated way for faster implementation. The idea was to neutralize friction points by getting someone to step in for resolution as soon as any team hits any friction point. This helped the teams to complete their tasks in 2-3 days that would have typically taken 3-4 months without the cloud party.

We created such an environment within a week. Once this was successful, we thought about how to scale this. For this, we had cloud parties in all the hubs globally. We did this for around 250 applications. So, in a very short time, the teams worked together on taking these applications from the dev or test environment to the production environment. This was one major mindset change that we brought to accelerate cloud adoption.

Milan: What would you advise the enterprises to create such kind of environment, a virtual environment to be precise, in the current pandemic scenario?

Anil: Let’s take the same application cloud migration example that we discussed now. We concentrated on small targets by focusing only on a few locations in the initial stages of the pandemic and conducted cloud parties virtually. We ensured having the right people on the call and had certain events built-in so that the people would be interested in joining. Once this was successful, we started scaling our efforts again in the virtual world. As the teams were working virtually, it saved a lot of costs and we could do cloud parties every month instead of every quarter that we used to conduct when we were working from the offices. So, the pandemic actually helped to work cohesively and be more productive. We could do it well and it was very successful.

Milan: As most of the companies are reluctant to adopt changes instantly, any specific blockers or lessons you would like to mention from your experience to ensure that this automation and engineering mindset is embraced and not shrunk?

Anil: Three key things I can think of to maintain consistency in such transformations

• Focus on the talent. Upgrading or upscaling the talent can be a huge winning point. This can be achieved through certifications and by educating people. The focus should be on not just the teams who are executing the tasks, but also the leaders who are supporting and sponsoring them and making the decisions. The leaders should have a clear vision of why they are going to the cloud and get educated on the cloud environment.
• Bring all the people together and have the right cloud migration goal in place. Figure out together how to achieve that goal. This ‘how’ needs to be explored during the cloud parties.
• Make efforts more pattern-based. Like in my case, we started with simple web applications and gradually went on to the high-intensive data-based ones, and then went to AI/ML based ones. As we kept going, the complexity of the applications increased. We handled that successfully and whenever there was a failure and we could not resolve it in the cloud party, the feedback loop got it fixed and we could resolve it in the next cloud party.

Top Questions the Viewers Shot at the Experts

To Milan: Can this automation of co-applications be scaled to a portfolio level?

The cloud transformation IP that we have built looks at the portfolio first. Within the portfolio, we quickly identify the candidates where we can get maximum ROI. We pick a much smaller subset, typically 5-10% of the applications, instead of doing it for all the accounts in one go. The IP can scale those and then we run it as a factory. For less-intrusive ones, we created a self-service based approach for one of our customers wherein we provided tools to the customer along with a short training on using the same.

To Anil: What is the number of people in a cloud party and where do all these cross-teams come from?

In my case, where I am talking about a very large bank, at least 1000 people across the globe attended the cloud parties. It totally depends on the size of the organization and the applications considered. Cross-teams involved the application team, some people who knew the whole pipeline right from the beginning to taking something into  production (they were experts in the development lifecycle and could act as partners or implementation experts), approvers to approve what is going into production by looking at the data and making sure that privacy laws and security are not compromised, and the network team to ensure right kind of network settings.

To Milan: Did you mean that the entire application portfolio was converted to the cloud in just 8 weeks? Did this also include API conversion and creating microservices?

Yes, the automation itself takes just a few hours. Then, we take approximately 8-12 weeks to convert an average portfolio size of 20-50 applications with about 3-4 million lines of code. This timeframe of 8-10 weeks is to ensure that we are doing the design, planning, and inception correctly by understanding the patterns, data volume requirements, and performance requirements. So, the design and blueprinting phase takes the maximum time. Once this modeling is done, the actual automation takes just a few hours. And some of the time is spent in carrying manual tasks that can’t be automated, like testing and validation, etc.

To Anil: How do you measure the success of a cloud party?

It can be measured in 2 ways – outcome and output. In my case, the output was measured based on how many applications we could take to production. From the outcome perspective, we figured out what is the ROI of the applications running into production and what are the TCO savings on the infrastructure.

To Milan/Anil: What are the limitations and risks involved in cloud adoption?

Anil: The last mile is one challenge to tackle. While moving applications, we found that some of the applications could not be moved as-is to the cloud and needed to be redesigned.

Milan: Talent is critical in driving automation for cloud transformation. The success of automation depends a lot on what level of expertise the driver has. One challenge faced by most companies is that the kind of skills needed for holistic automation reside in different silos. What is needed is the people who can understand at least to some extent the network, operating systems, database, and the applications. Equally important is identifying the right problems and ensuring ROI is big enough to automate. As far as limitations are concerned, applications in large enterprises are diverse and there can’t be a one-size-fits-all solution.