Model Driven Modernization

At it’s heart this is a requirement to modernize 1,600+ legacy applications, a requirement that is not limited to BC, it’s a consistent issue for all other Provinces and also the Federal Government.

For example as CBC reported there are critical systems, in key areas like Employment and Social Development Canada, that are pushing 60 years old, built on out-dated technologies and “rusting out”. Consequently they are on the precipice of collapse and their maintenance cost burden leaves little room for spending on new technologies like Cloud computing, a sentiment repeated by Gartner, who identified that Legacy Modernization is Holding Canadian CIOs Back from Innovation.

Rightly so therefore, BC state this as the critical success factor for this program:

“Lift-and-shift strategies to cloud have not generally been successful; we need a better approach”.

Migrating to the Cloud presents the potential to address these challenges, but not when the scope only achieves a ‘lift and shift‘ exercise, a migration-only exercise. Simply moving old code from an internal data centre to a Cloud provider does nothing to improve that code nor tackle it’s inherent legacy issues, it’s just shifting the problem from one location to another. It must also be combined with application modernization best practices to achieve the transformation business executives hope for from the investment.

However it would be impractical to attempt 1,600 individual application modernization efforts, and so our overall recommendation is one of a ‘Model Driven Modernization‘ approach, a framework for industrializing the process of mass migrations, consisting:

  1. Business Architecture for Cloud Migration – A standardized digital transformation decision process.
  2. Target Architecture Blueprints – A library of common templates for the target environment.

Business Architecture for Cloud Migration

A cloud migration project can be a relatively simple exercise, where applications are migrated ‘as is’, to gain benefits such as elastic capacity and utility pricing, but without making any changes to the application architecture, software development methods or business processes it is used for. The first step strategy review can determine what scope of exercise is needed.

As the ADM ‘Horseshoe’ model articulates, as described in this Carnegie Mellon article, a migration project can be considered with three distinct tiers of scope possible, increasing the size and length of the project with an increasing level of associated business benefit.

1. Technical architecture – The application is migrated as is to a new hardware infrastructure service without modification.

This delivers infrastructure-centric cost and performance benefits, such as autoscaling of capacity and utility pricing, addressing specific pain point scenarios, such as utilizing IaaS for disaster recovery, with the business case being the move off of obsolete hardware.

2. Application and Data Architecture – The application and data structures are also upgraded as part of the process.

This can enable the software development team to adopt Enterprise DevOps methods, achieving faster time-to-market for new innovations that wasn’t possible with the previous legacy software. The software can be re-architected from hard to modify monolithic software to change-friendly designs such as Microservices, and achieve a more integrated state that better utilizes shared services like Digital Identity sign-on and key modern features, like web front-end access.

3. Business Architecture – The business model is also transformed. The new software capabilities can then make possible new digital business models, changing how the pattern of how resources are organized to deliver new services.

Moving to Cloud can actually represent activity on all three fronts:

  1. (T) Virtualizing the platform to simply improve the underlying hardware usage. This begins at a technical migration, meaning the application is migrated ‘as is’ to a new hardware infrastructure service without modification.
  2. (A) Application Modernization, from simple re-writes to make use of native Cloud services such as AWS auto-scaling, through to wholesale transformation, such as converting COBOL code to Java. It can even enable a shift from a procedural software development method to an object oriented one.
  3. (B) Business model transformation – Changing business processes to a new operating model that best exploits these new capabilities.

As the horseshoe describes, these increases in scope mean a larger project that takes longer, because each is delivering a larger scope of business benefits, impacting a larger group of stakeholders and requiring a larger business transformation exercise, such as:

Legacy modernization best practices can address these issues, delivering business benefits including:

  • Untangle and map legacy application complexities – Build a basis of understanding of existing application and data architectures to establish more intelligent IT planning concepts in line with business and technical demands. Developers with no experience of the legacy software can be enabled to implement changes in line with business needs.
  • Extend the life of legacy applications without the risks of greenfield COTS projects – Numerous reports highlight how a COTS (Commercial Off The Shelf) approach to modernization is very high risk with expensive failure rates.
  • Align user interfaces and back-end application and data models with modern business processes – Modernization can be used to achieve IT objectives such as SOA, Cloud migration and Web-enablement of applications.
  • Leverage new technologies and tools – The overarching benefit is the transformation of software that is now resistant to change and thus innovation, as the required skills have long since retired and/or the suppliers are no longer in business. By moving it to a modern software platform new tools and techniques like ‘DevOps’ can be implemented to speed the rates of innovation.

Decision Tree

In their blog Successful Cloud Migration in Three Steps, RapidValue provides a very helpful overview of the decision process an organization can follow:

They also illustrate the Horseshoe scope in terms of the Cloud stack and the resulting Cloud operating model depending on what level of transformation is decided upon, ranging from the lift and shift scenario:

through to a complete transition to an entirely new, Cloud-based application:

The Microsoft Cloud Adoption Framework for Azure mirrors this model, where in the Cloud Migration Journey planning they describe:

  • Rehost – Often referred to as “lift and shift” migration, this no-code option lets you migrate your existing applications to Azure quickly. Each application is migrated as is, which provides the benefits of the cloud without the risks or costs of making code changes.
  • Refactor – Often referred to as repackage, this cloud migration strategy involves some change to the application design but no wholesale changes to the application code.
  • Rearchitect – Modify or extend your application’s code base to scale and optimise it for the cloud.
  • Rebuild – Rebuild an application from scratch using cloud-native technologies.

Determining whether to migrate to IaaS (“lift and shift”) or PaaS highlights the value of the first Digital Transformation planning process, to identify whether the benefits sought are purely related to the replacement of server hardware, or if transformation of software development and business process are also key goals.

This video explores the technical detail of migrating to a PaaS versus IaaS, highlighting how it frees the customer from managing core, common components like security.

Case Studies and Vendor Services

This methodology provides a framework for understanding where and how different approaches and vendor solutions can be applied, with some case studies to explain the exercise.

Scope  Scenario / Technology
1 – Technical Architecture
  1. ‘Containerizing’ legacy applications – FPComplete offers this short overview of what containerizing legacy applications involves, highlighting that this is a way to begin modernizing the deployment of the application while making minimal or no changes to the application itself.
  2. Migrating mainframes to AWS This AWS tutorial from Astadia walks through a lift and shift of mainframe COBOL code to EC2 for Cloud hosting.
  3. Migrating databases – The previous use case mentions a component part of migrating from a legacy database such as DB2, to a Cloud-based equivalent such as Aurora. This webinar from App Associates explores that scenario in detail.
2 – Application Architecture
  1. Somerset County Council Migrating on-site, VMware-based legacy apps to a combination of IaaS and PaaS on Azure and enabling implementation of Continuous Integration practices using Visual Studio Team Services.
  2. Guiness Book of Records Migrating to AWS and transforming their software to a microservices architecture.
3 – Business Architecture
  1. The Aldo case study demonstrates how they enjoyed the full three tiers of benefit: Faster performance and no more outages (1-Technical), the adoption of AWS AppSync enabled their developers to more quickly publish new features (2-Application), with this making possible new business processes across inventory management and customer engagement (3-Business).
  2. SnapDocs utilized AWS Serverless and AI technologies to digitize the mortgage closing process, previously a mainly manual workflow taking many hours of face to face meetings and taking as long as 60 days to complete. This is an example of how digital transformation can achieve a superior market product, with AI enabling value add features that go well beyond simple document digitization.

Mainframe Modernization

One key use case to highlight is the modernization of mainframes. As described earlier large enterprises such as the Federal Govt have these types of legacy systems that go back decades, running COBOL, presenting a significant modernization challenge.

Speaking at Re:invent 2018 Phil De Valance of AWS shares ‘Mainframe Modernization with AWS: Patterns and Best Practices‘.

From 08:30 he describes the patterns they have as a toolbox for modernizing to AWS and divides them into two main families; one of which deals with shutting down of mainframes (Short-term Migration) and the other which adds functionality to the mainframe (Augmentation).

Short-term Migration include emulator rehosting, automated refactoring and re-platforming for Linux, where the customer could benefit from the AWS services like Elastic Load Balancing, Auto Scaling, Amazon RDS Database, Amazon CloudWatch Monitoring.

From 22:38 he explores the Augmentation scenario, which includes replicating mainframe data to AWS so that services like data analytics can be applied, and new digital channel capabilities like mobile can be developed.

Some useful resources for further information include Patterns and Best Practices and AWS Partner Network (APN) Blog – Mainframe section.

Target Architecture Blueprints

BC defines the desired end results to be realized through a Future State Blueprint, a design model for the modernized system that will achieve the transformation benefits they are seeking, with key features of this being ‘a portfolio of common components’ and the repeated use of best practices from across governments.

A catalogue of ‘Target Architecture Blueprints’ can be developed to offer standardized hosting environments tailored for Canadian Government requirements, to support this objective and enable the speeding of mass migrations to them.

Pioneers that have recognized this include the UK’s Hackney Council, where they are developing a ‘pattern library‘ approach that seeks instead to standardize these models into reuseable templates. Their catalogue on Heroku demonstrates the early stage nature of this approach.

Canada too is also seeking to better share reuse of projects. On this page Canadian digital projects are listed as products, categorized by their lifecycle stage of Discovery, Alpha, Beta and Live. One product in production is Impact Canada, a scalable, reusable platform that creates new opportunities for innovators and entrepreneurs to help solve Canada’s biggest challenges. By open sourcing the code and methods it means this capability can be easily reused for other projects and reinventing the wheel avoided, enabling the repeated use of best practices described.

PCTF Components

A keynote example of the type of common components that could be included into these templates is Digital Identity. Typically each legacy application will embed its own proprietary user authentication system, meaning it is duplicated n times for each and every app, creating a very frustrating user experience for citizens.

By defining Identity authentication as a common component, the appropriate modules can be baked into the PaaS layer, such that this is one of the functions stripped out during the migration process, and the app instead re-engineered to call upon the common component.

Through the ‘PCTF‘ Canada is defining the standards framework for this system that could be part of the Target Architecture.

Indeed through their ‘OrgBook‘ project it is BC that is pioneering this field, through their use of ‘Self Sovereign Identity’ technologies.

Azure Blueprints

As this video demonstrates the Cloud providers like Microsoft Azure are already equipped with the capability required to implement this system. Azure Blueprints enable organizations like Government to define template packages to standardize their preferred configurations for easily and repeatable instantiation.


Show More

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button