Application Modernization

'"`UNIQ--multilang-00000000-QINU`"'

Note: We are continuously improving this site. As the initiative attracts more attention, we are trying to publish the information we have as we have it. A French version will follow shortly.

Templates and discussions related to Application Modernization can be found in the GCCollab Core Technologies group. It is strongly recommended you join that group to watch for updates.

Overview

This handbook is meant to help departments navigate the Application Modernization Investment Framework; the process for:

Prioritizing at-risk technologies
Performing an analysis of departmental application portfolios
Planning for addressing the at-risk technology through modernization
Governance gating for endorsing that plan and making the associated funds available
Ongoing monitoring of status

This handbook focuses on the decisions departments must make and how they are captured. It is not meant to provide a deep analysis of different technical decisions or architectural strategies a department can use to modernize, save for those captured in policy instruments.

The Investment Frame work consists of two gates:

Gate 1: a scope of at-risk technologies has been identified and approved by governance for modernization or decommissioning Gate 2: a department's plan for modernization is ready to be endorsed by GC EARB thus authorizing the release of Application Modernization funds.

Background

Application Modernization is one of four pillars of the Workload Migration & Cloud Enablement (WLM&CE) initiative. A brief Frequently Asked Questions document can be found here.

From Budget 2018:

"$110 million over six years, starting in 2018–19, to be accessed by Shared Services Canada’s partner departments and agencies to help them migrate their applications from older data centres into more secure modern data centres or cloud solutions."

Prioritization

Content not yet completed.

Discovery

Application Porfolio Analysis

The next three steps are an opportunity for your departments to assess its portfolio of applications and document your decisions as to how you will reduce, sustain, and modernize that portfolio.

Determine Modernization Vision for the Organization

By the end of this step, you should have discussed with leadership how far you want to take your modernization journey. This will be the vision for your organization. Those who will be performing the subsequent portfolio analysis steps should understand that vision.

This is an opportunity to determine the direction for the organization; is it to largely sustain current operations and culture, or does the organization desire to modernize and be more transformative. Perhaps your organization has already begun a modernization journey. In today's IT environment cloud technologies combined with DevOps methods are having a large impact on how IT is delivered. Amongst the goals of these technologies and methods is to decrease lead time and time to market; in summary

deliver IT faster

Increase reliability
Increase security
Increase quality

This guide does not instruct an organization how to undertake its modernization journey, but instead meant to be a catalyst for establishing the vision. These changes can be wide sweeping impacting roles, responsibilities, and culture. They are not undertaken in a year, but instead must be seen as a journey of maturity and continuous improvement.

While some organizations have started this journey years ago and are ready to go "all in" on cloud and the workforce are DevOps practitioners, others have not begun the journey.

For those who have not yet begun a modernization journey the choice may be take this opportunity to start that journey. For others, they may decide to simply sustain operations as-is.

cloud maturity map will be inserted here

A simple visual for plotting you cloud adoption maturity can be found here. Most organizations start small with a few low risk applications. A team of willing and keen developers from within your existing workforce would lead an imitative to migrate those low risk workloads to the cloud. From these experiences they would use their learnings to train others to do the same. As the number of workloads grow, the need for more sophisticated methods such as automation and DevOps will need to be applied. This will facilitate scaling without impacting agility. Existing governance and roles will also need to evolve. An organization should review the [insert roles and reap document here] to ensure your organization is ready to undertake the required roles to support cloud services.

A simple scorecard has been devised to assess low risk workloads for cloud migration. This scorecard is meant to provide you a short list from which to further decide where to start. Any application can be migrated to the cloud with enough time and effort. The scorecard is meant to identify low risk and low effort migrations.

For organizations that desire to forego modernization opportunities, the decision to rehost the entire application portfolio to a new data centre provides that opportunity.

Determine Rationalization and Retirement Opportunities

By the end of this step you will have assessed your portfolio and infrastructure for rationalization and retirment oportunities.

Obsolete Repositories

There are GC applications – content management systems / web-database systems - that are no longer actively used but maintained because they may contain information that might be required in the future e.g. to respond to an ATIP request.

Departments should have an active Information Management (IM) function that can verify the actual data retention requirements applicable to a specific application.
Departments should recognize the cost of un-necessary data retention and actively dispose of data that has been deemed un-necessary. Un-necessary data is both a cost and a liability.

Obsolete Applications

Your application portfolio rates the business value of applications. Review low business value applications. Assess whether these applications remain needed:

Use access/update logs to identify applications that have received few updates in the past two years.
Identify the most recent users and inquire as to the business value of the application.

Document Migration Strategy and Targets

By the end of this step you will have analyzed your portfolio of applications, updated key data in APM, chose the migrations strategy for each application ( one of the 5 Rs ), and the target for each application ( cloud or EDC ).

During the Determine Modernization Vision for the Organization step you would have determine how far your organization wants to take its modernization journey. Part of that step was the Cloud Fit Scorecard. You should have already narrowed the target options for each application.

Choose the Appropriate Migration Strategy

For each application you need to determine you migration strategy (aka the 5Rs).

Strategy	Altnerative Name	Full Description	Data Centre	Cloud
Retire	Decomission	Retire, decommission, sunset application. Eliminate it from the portfolio.
Rehost	Lift and shift	Redeploy applications to a different hardware environment and change the application’s infrastructure configuration. Also called Lift-and-shift. Move the solution as is, or with minor changes, to a new hosting environment (small investment of resources).	X	X
Replatform	Lift, shift, and tinker	Change OS / Middleware. Requiring some level of application change (medium investment of resources to change).	X*	X
Refactor	Re-architect	Application will be redesigned. Sections of the application will be re-written for improvement/optimization purposes (medium to large investment of resources to change).		X
Replace	Repurchase	Replace application's functionality by a new solution acquired or developed by department (medium to large investment of resources). The application will be decommissioned once replaced.		X

Address end of life OSes

Rehost (lift and shift)

With a rehost migration strategy, the application undergoes no changes and is migrated as-is to a new data centre or cloud. This is the simplest and least effort migration strategy.

For workloads migrating to cloud, it is strongly advised that, at the very least, the resources (network, compute, storage) be optimized and reduced to the smallest size possible. Additionally using reserved instances for production workloads and turning off unused servers during off-hours will help ensure a lower monthly bill from your cloud provider.

Replatform (lift, shift, and tinker)

With a replatform strategy, the application undergoes minor changes as it is migrated to a new data centre or cloud. Replatforming strategies may include, but as not limited to:

Addressing end of life (EOL) software such as those deprecated by IT Policy Implementation Notice ITPINs

Move to Platform-as-a-Service (PaaS). For commoditized services such as databases, web servers, file servers, container orchestration, moving to a PaaS allows for a serverless architecture. A serverless architecture negates the need to manage and patch operating systems, middleware and manage server instances. This also reduces an organization's IT LifeCycle Management burden. Users sometimes worry that using PaaS will cause vendor lock-in. By using PaaS that have alternatives elsewhere in the market will avoid lock-in. Being able to extract your business data and business rules from a PaaS is key to avoiding lock-in. Most cloud providers offer database, web server, and file server platforms. While migrating from one to another may not be completely painless, migration tools and APIs exist to allow for this possibility.

Containers is an increasingly populate method to deploy applications. If your application is stateless, moving it to a container will not only help portability, but also help with your organization's adoption of DevOps practices.

Refactor (Re-Architect)

Refactoring is the most costly and time consuming of all strategies. This is an opportunity to take full advantage of cloud-native architectures by introducing elastic scaling of resources.

Adding disaster recover capabilities is other option for refactoring.

Migrating away from less common OSes such AIX, UNIX, or Solaris may require extensive changes to the application.

Due to the high cost of refactoring, this strategy should be applied to high business value applications.

Replace (Repurchase)

This is an opportunity to determine if Software-as-a-Service solutions for some of the COTS or custom built application you may have running today. Migrating to SaaS is an opportunity to access the latest version of that service and to lower lifecycle management burden. For example, if you operate a legacy email application, you may want to take the opportunity to replace it with Office 365.

Choose Your Migration Target

Choose the target, or where the application will be migrated to, for each application.

Enterprise Data Centre (EDC): a new data centre with low technical risks

Cloud: a public cloud service provider available from the SSC Cloud Broker

Identify Data Centre

Ensure applications are correctly allocated to its current legacy data centre. The data centre is an essential reporting dimension when TBS tracks your portfolioès progress.

Identify Mission Critical Applications

Ensure mission critical applications are correctly identified.

Identify Operating Systems

Ensure the operating systems for each application are correctly identified. This will be used to ensure all operating systems beyond end-of-life are addressed through a replatform.

Generate Portfolio Analysis Dashboard

Request that TBS generate a dashabord of your application portoflio. This will ensure your decisions have been correctly reflected. A sample of the dashabord that is generated is found here:

Engage SSC Project Manager and WLM Factory

It is likely you have already been working with your SSC Project Manager. If not, talk to your Service Delivery Manager. At this point it would be prudent to work with a supplier qualified on the WLM Factory to help with planning and cost estimates.

Document Project Milestones

Document Cost Estimates

(insert cost estimates summary here )

Gate2: GC EARB Endorsement and MoU to Release Funds

At this point the discovery phase is completed. The analysis and planning undertaken as part of discovery will be presented to GC EARB as part of requesting endorsement for releasing funds for the execution phase.

The generic template for the presenting your discovery analysis and funding approval to move to execution can be found here.

As part of the GC EARB a CIO will explain their migration strategy and target choices. This includes how those choices align to the Cloud First policy requirement (requirement 6.4.2) and meeting requirement 6.1.1 of the Directive..

If and when endorsement is provided by GC EARB, approval will be requested from the GC CIO. A Memorandum of Understanding between the GC CIO and the deputy head of the requesting department will be agreed to by both parties.

Execution

Content not yet completed