Part 3 | Application Rationalization Customer Scenarios – How Motifworks Helped Clients Transform their Businesses
For a deeper understanding of the Application Rationalization process and the factors that affect decision making please refer to this article. The following article will take you through 3 customer scenarios of App Rationalization & Modernization and how Motifworks’ unique solutions for each reaped desired business outcomes.
Scenario 1: Assisting a Healthcare Customer Build Cloud Migration & Modernization Roadmap for their IT Applications
The customer’s core IT systems were hosted by a managed service provider and the client was amidst negotiating an extension to the contract with the service provider. The client had compelling reasons to consider other hosting options and cloud was the top among them. The applications supported the core business of the client, were of disparate technologies and some obsolete, so they decided to take this opportunity to modernize their IT systems in the cloud while migrating off of the service provider’s infrastructure. They selected Azure as the Cloud provider.
Fast forwarding to the Application Rationalization process here is some examples and reasoning to fit an application in the client’s portfolio to a particular ‘R’.
The client used WordPress for content management and integrated it with a .NET application to support certain business activities. They also had licenses for EPIServer, a CMS Software-as-Service solution, and had hosted CMS content in a subsite. The EPI Server license allowed provisioning additional subsites but had not been fully utilized.
To consolidate technologies and capitalize existing licenses it made sense to abandon WordPress and migrate the templates and application to EPIServer subsite. It meant additional work since new templates had to be created but the one time effort paid off since there were no recurring hosting charges in Azure for the WordPress app and no environment maintenance overheads since it was offloaded to the SaaS provider.
A core business application, a certification app, was in scope of migration. This application was used by majority of their customers and was one of their “bread winners”. The app experienced peak usage during certain time of the month and year when the customers had to get certified to stay compliant. Agility in publishing new features of the app was also a primary business objective. At first it was considered best to be rewrite the app using cloud native services to reap the benefits provided by Azure, and to meet the business objectives.
But after evaluating the effort to rewrite, it was clear there was not ample time to complete it before the service provider’s contract expired. The application had to be migrated before the contract expired. As a result, in a two-step process, the application code was Reused and deployed to App Service & Azure SQL Server, both Azure native services, with minimal changes to the app. After all the applications were migrated off of the Managed service providers infrastructure, and as part of step 2, the client internal teams were trained on Azure and the application was Rewritten using Azure serverless technologies like Logic App, Azure functions & DevOps.
Retain was not an option since the client had to migrate off the service provider’s infrastructure and none of the applications qualified to the Retain category anyhow. The remaining applications mainly internal systems, low impact to the business, just had to be functional so these applications server were Rehosted in Azure with minimal impact to the apps.
Scenario 2: Getting a Healthcare Customer’s Mission Critical Apps ready for COVID-19 Pandemic
Another client we worked with this year is also in the healthcare domain specializing in emergency medical response. The application in context was mission critical, receiving and responding to emergency medical requests from its customers. The application had exhausted the limits of the infrastructure it was hosted on. Due to COVID the demand on the systems grew and at the same time the business was planning to service markets in the US that were still untapped.
The client was expecting a 90% growth in its usage in the next 6-9 months and given its criticality had high SLA demand and DR requirements for business continuity. They were faced with a challenge whether to upgrade and/or scale out their on-premises infrastructure or investigate the cloud for the future needs of the app. We began our engagement with the client by assessing the application, its technical stack, application architecture and dependencies. Cost was going to play a major decision factor in choosing cloud as its new home.
After analyzing, we realized the application had multiple components spanning from a web portal, middle tier APIs, SQL database, Queues, integration with external systems, notifications, and reporting. The client was willing to consider Rewriting the app if the TCO in Azure was not prohibitive.
Multi – R strategy
We recommended a combination of Reuse, Rearchitect & Rewrite strategy. Since HA & DR were goals of the new architecture we considered leveraging Azure PaaS services to employ the inherent benefits of Premium plan, i.e. HA and DR, since Azure deploys duplicate instances of the PaaS services, to a different datacenter for HA and to a different Region for DR.
For that reason, certain parts of the app had to be Rearchitected and Rewritten to leverage Azure PaaS services. Service Bus, API Management, Azure Functions, Azure SQL Server with Geo-Replication was part of the new architecture. The web portal code was Reused and deployed to App Services with autoscaling to meet the fluctuating demand & DevOps was put in place. The TCO in Azure was lucrative, the system could scale out based on current and new demand and multiregional deployment provided DR capabilities.
Scenario 3: A Re-insurance Client Well-Ahead in the Cloud Journey Looking to Standardize their Application Architectures
The client had migrated the first of servers to Azure as Rehost to modernize the aging the infrastructure and considerably reduce their co-locations costs. Their Re-insurance process was supported by three separate applications with much of the functionality overlapping with each other. The systems had grown organically over a period. The demand on the applications varied, peaking during the month and year end when the insurance contracts were generated. The client wanted to standardize the Azure architectures and leverage tooling they had in house and in the initial phase wanted to minimize rewriting the applications due to time, resource, and cost constraints. The new architecture would provide the blueprint for applications following it.
Rearchitect, Rewrite, Retain
Right off the bat Rehost and Repurchase were ruled out. We recommended two options to host the web layer, App services with autoscaling and AKS. Both options required minimum changes to the code and supported burst demand. The customer chose AKS for ease of deployment and to remain cloud agnostic. The middle tier where most of the grunt work was being done, processing data from multiple internal data sources, had to scale on demand so were Rewritten as Azure functions. The on-premises integration platform SSIS was considered as technical debt and Retained on premises to be addressed in future phases of modernization.