The customer is a global shipping giant, headquartered in France, that acquired another shipping company. Consequently, it also acquired shadow IT systems (referred to as ‘Agency Systems’), that were not centrally managed, from the merger. In an attempt to organize these systems, and bring in centralized governance, the company embarked on a cloud transformation journey.

As part of this initiative, its Singapore business was planning to deploy the Agency workload onto an AWS environment. Through the Agency to Cloud (A2C) program, all Legacy Shadow IT applications were transferred to the cloud, giving centralized access to users from anywhere.

The previously existing application was a Visual Basic 6 client application running on Windows that was deployed locally and had a back end (MS Access database), which was shared by multiple BUs. There were extended outages and downtime during individual client deployments.  Since this was a client-server application, scaling to allow seamless access to a wider audience within the organization was a challenge.

Additionally, release cycle times for changes were longer and business requirements had to be consolidated to reduce the risk of deployment-related outages. The business identified the potential risk associated with relying on the legacy non-scalable database (MS Access), especially from a data loss perspective. MS Access was also unsupported by Microsoft at this time which could cause potential security risks.

The overall objective was to have a centralized, scalable, container-ready solution with a modern Cloud Database platform and technology solution that would accelerate rollouts and their frequency with minimal risk, caused by outages, during feature roll-outs.

The 1CH team conducted a detailed analysis of the existing code base and through a series of workshops, collaborated on creating the requirements of business users. The solution was architected to be deployed on AWS for centralized management and governance. The web application was also designed for micro-services deployment. The technology for the API middleware was finalized as Java Spring boot, a ReactJS-based frontend, and RDS MySQL as the backend database.

Existing Git-labs were leveraged as the git repository for the application code used for the deployment automation, with CI/CD pipeline integration with Jenkins. For infrastructure as code, Terraform was used with Code Commit as the git repository, and Jenkins was leveraged for the deployment pipeline. Individual pipelines for Dev, QA, and Production were implemented. Database credential rotation was also implemented along with PingFederate-based authentication for the application.

Services used:

• Code Repo
• Code Commit
• CloudFormation
• Jenkins
• Terraform
• Ansible

Accessibility during the pandemic:  The application modernization paved way for accessibility across devices for users which enabled remote work, boosting productivity, especially during the pandemic. The cloud-deployed application enabled maintenance and access control to be handled efficiently and governed centrally.

Avoided risk of loss by modernization: With the Application being converted from a locally deployed client-server architecture to a cloud-deployed Web application using modern RDS MySQL as the database technology, the risk of data loss was completely avoided.

Accelerated Deployments:  By deploying pipeline-based deployment that used CI for release, including SonarQube quality gates for SAST, the deployment became highly risk-free and reduced the frequency of updates to as and when required instead of once per year.

Future-Proofing with Container Readiness: With applications architected as individual services, separate deployment packages, and service endpoints, the application is ready to be deployed as soon as it is ready into a Kubernetes infrastructure without additional effort from the application team.