To port or not to port to the cloud? Two more CAST iron exemplars

In addition to the points made by made by Subhada Reddimassi, Head of Modernization and Cloud at Wells Fargo Bank, on the value of Software Intelligence to porting legacy applications to the cloud, two other speakers added considerable value to the story during the same session. These were Jens Ewelt, Head of Azure Services at Volkswagen Financial Services, and Sreejit Roy, Global App Modernization Leader at IBM.

Ewelt’s topic was a subject likely to be close to the heart of many businesses - moving a large portfolio of applications working across the board from business banking, leasing and insurance, through to consulting, and mobility, with a large number of the built on Microsoft’s own applications servers.

The project revolves around moving to a Platform as a Service (PaaS) strategy built on the Azure Stack, but not on Azure services out in the public cloud, although moving out to the cloud is the long term goal. For now, the migrated applications will be housed in a new data center in Braunschweig, Lower Saxony and the aim is to modernize and re-factor some 120 mainly Windows Server applications, rather than simply lift and shift them. The timescale is an aggressive two years.

Scalability and costs are two of the prime reasons for the move, as the old data center was built around different hardware and infrastructure, said Ewelt: 

With Azure Stack and Azure Hub, we have one appliance in our data center, which makes the whole infrastructure for the applications. So time-to-market is important, because from the business point of view in our company we are talking about online banking, used cars, internet-facing applications. And as you know maybe from your own company, internet-facing should be fast, you can't wait weeks to make a change to the production, so continuous delivery and continuous improvement is a very important part. And now with Azure Stack, we only have to put the slider from two to three or four servers and the performance is there.

Old ones, new ones – all in together

Those applications range from new ones in service less than two years, through to classic legacy apps found in financial services that are over 20 years old. That means big code differences, which in turn mean potential migration issues. So Volkswagen decided to use CAST, because, when looking to move to PaaS, the source code of the applications definitely requires some detailed analysis.  Not only did this save what Ewelt called a massive amount of hard, manual labour, it also provided a wide range of dashboards covering the detailed analyses being carried out:

The good thing is, you use it via the internet, so you don't have to instal something on your desk, only a small agent.

The process involves taking the source code of an application, and the source code of the builds being used and run these through the agent which generates metadata about the application. The CAST website then provides an analysis of the code itself, the relationship with third party applications and services, security levels and the application’s performance. With these overviews of individual applications, it also became possible to grade them in terms of the time and resources budget each required for re-factoring. In addition, the use of CAST allowed Ewelt’s team to ensure that the security capabilities of each application, and the interaction between them, is maintained at least at the level required by the regulatory regimes that apply to Volkswagen.

The third important part for Ewelt is the results on code quality. Using CAST has promoted the building of development teams because not only does identify technical issues, it is also good at building organizational and community links, which for Ewelt is an important capability.

So for now the company is running Azure Stack as an on premise environment, but the long term goal is definitely to run on public cloud services to gain the advantages of cost and scalability. There was a nod towards the classic observation made at these times – that other public cloud service providers are available, and the session moderator, consultant and advisor to CAST, Bob Hoey, made it clear that the CAST software intelligence tools also work with AWS, Google and IBM cloud service providers, among others.

IBM as a modernizer for big systems users

IBM provided the last speaker, though not via its cloud services operation, but instead from the company’s large, international consulting practice, where Sreejit Roy is the Global Application Modernization Leader. His role is to help IBM’s largest clients transform their core customer-built applications to multi-vendor hybrid clouds.

Working with some of the largest and most sophisticated enterprises on developing their cloud strategies has given Roy significant insight into development strategies, design offerings, and the methodologies and capabilities required to help move such businesses to the cloud. Roy’s focus was on cost, data consistency and data modernization, particularly in relationship to people, and it is here that an important role for CAST has been developed:

We are using CAST software to reduce the time to transition from when people move out across projects, and we have started to use CAST in this new domain about creating a knowledge base, keeping it updated. And our studies have shown that it is going to benefit us in our in our ability to transition as people move in and out.

In IBM's view, cost is not the primary driver and instead is seen as one of the outcomes which clients are looking for. Equal - or even bigger - drivers are factors like speed to value, having business requirements met, or they have complex IT systems still working at the end of life. Cost reduction using modernization is certainly important, but the need for them to modernize is wider and reaches across multiple parameters.

He also pointed to the oft-forgotten factor that modernization does not automatically equal the cloud. As a Systems Integration house, it is not unusual for IBM to find that modernization could also be in situ, remaining on premise, or it could be in cloud. Only then does cost become an important component in the decision on which route modernization takes.

He also observed that two distinct flavours of agility need to be considered carefully. One he termed "agility in IT" – the ability to deliver more and more technical options in a much-reduced time. The other, which he now tries to focus all IBM clients on, is business agility - where modernization makes the business, process-wise, run much faster.

He picked out a number of factors that IBM has learned so far from this approach, which together are building a consistent pattern.  Most importantly, any modernization needs the right set of business outcomes, and as an example he used a long-established Indian bank where the CEO set the business objective as `get the new, younger generation of Indians to become customers’. That meant not only leapfrogging its established banking competitors but also the new crop of internet banks. To do that the business outcome needed to be creating a bank able to provide not just the latest internet banking but also provide a platform to sell a plethora of Financial Services:

Today, they are definitely a step ahead of the banks which were born on the internet and came much later. So that's how our clients are aligning their modernisation journeys to business outcomes and not looking at only technology.

He observed that, having completed `thousands’ of modernisations, IBM has been able to codify much of what it has learned into a set of modernization patterns that can be applied across most requirements in most business sectors. The company claim is that the patterns provide a much less risky approach to modernization.

The role of CAST in managing the influence of individual people, if and when they change roles, is that it becomes the prime mover in the development of operating models, structures and architectures, all based around what the data demands. Roy said: 

For an operating model, this is where CAST comes in very handy. Once you have identified the architecture you run the tool, you identify the interdependencies. Then you start identifying where and how the data is to be retained, and the data decides the operating model. Then the operating model, once you have decided, decides the structure and the architecture.