Difference between revisions of "Application Modernization"

From wiki
Jump to navigation Jump to search
Line 417: Line 417:
 
* Rehausser la qualité
 
* Rehausser la qualité
  
 +
Plutôt qu’indiquer à l’organisation comment lancer son processus de modernisation, le présent Guide fait office de catalyseur pour permettre la mise en œuvre de la vision. Ces changements peuvent avoir de larges répercussions et des incidences sur les rôles, les responsabilités et la culture. Leur mise en œuvre prend plus d’une année et doit être perçue comme faisant partie du processus visant la maturité et l’amélioration continue.
 +
Alors que certaines organisations ont lancé ce processus il y a plusieurs années, sont prêtes à s’investir à 100 % dans les technologies d’informatique en nuage et ont formé leur effectif au développement et aux opérations (DevOps), d’autres organisations n’ont pas encore entamé le processus de modernisation.
 +
Les organisations qui n’ont pas encore lancé leur processus de modernisation pourraient profiter de cette occasion pour le faire. Les autres organisations pourraient simplement décider de maintenir leurs opérations telles quelles.
 +
 +
Un schéma vous aidant à préparer la maturation des efforts d’adoption de services d’informatique en nuage est accessible ici. La plupart des organisations commencent par de petits projets réalisés sur quelques applications à faibles risques. L’équipe de développeurs motivés et enthousiastes de votre effectif actuel devrait alors diriger l’initiative visant à transférer ces charges de travail à faibles risques vers l’informatique en nuage. Forts de leur expérience, ces développeurs devraient ensuite mettre à profit leurs connaissances pour former d’autres personnes à faire la même chose. Alors qu’augmente le nombre de charges de travail, il deviendra nécessaire d’avoir recours à des méthodes plus sophistiquées, comme l’automatisation et les DevOps. Cela facilitera la mise à l’échelle sans avoir d’incidences sur la flexibilité. Il faudra aussi faire évoluer la gouvernance et les rôles actuels. L’organisation devra passer en revue les [insérez ici le document décrivant les rôles et les données recueillies] pour s’assurer d’être prête à mettre en œuvre les différents rôles qui sont nécessaires au soutien des services informatiques en nuage.
 +
 +
On a élaboré une [[gccollab:file/view/1994079/encloud-fitness-scorecardfr|fiche de pointage simple] pour évaluer les charges de travail à faible risque en vue de la migration vers l’informatique en nuage. Cette fiche de pointage vous fournira une courte liste pour vous aider à décider par où commencer. Il est possible de transférer les applications vers l’informatique en nuage si l’on consacre le temps et les efforts nécessaires à la réalisation de cette tâche. La fiche de pointage vise à relever les migrations à faibles risques et les migrations nécessitant peu d’efforts.
 +
 +
Les organisations qui ne souhaitent pas profiter des possibilités de modernisation peuvent tout simplement décider de réhéberger le portefeuille d’applications en entier dans un nouveau centre de données.
 +
 +
==== <big>Déterminer les possibilités concernant la rationalisation et le retrait</big> ====
 +
 +
À l’issue de cette étape, vous aurez analysé votre portefeuille et votre infrastructure afin de relever les possibilités de rationalisation et de retrait.
 +
 +
===== <u>Dépôts désuets</u> =====
 +
Certaines applications du GC qui ne sont plus activement utilisées, comme les systèmes de gestion du contenu et les systèmes de base de données Web, sont tout de même conservées étant donné qu’elles comportent des renseignements qui pourraient être nécessaires à l’avenir, p. ex., répondre à une demande d’accès à l’information et de protection des renseignements personnels (AIPRP).
 +
* Les ministères devraient disposer d’une fonction active de gestion de l’information (GI) permettant de vérifier les exigences réelles en matière de conservation des données qui s’appliquent à une application précise.
 +
* Les ministères devraient reconnaître les coûts associés à la rétention inutile des données et travailler de façon active à l’élimination des données jugées inutiles. Les données inutiles engendrent des coûts et représentent un passif.
 +
 +
===== <u>Applications désuètes</u> =====
 +
Votre portefeuille d’applications évalue la valeur opérationnelle des différentes applications. Passez en revue les applications qui ont une faible valeur opérationnelle. Déterminez si elles demeurent nécessaires : 
 +
* Utilisez les fonctions d’accès ou de mise à jour des journaux pour relever les applications ayant fait l’objet d’un petit nombre de mises à jour au cours des deux dernières années.
 +
* Relevez les utilisateurs les plus récents et renseignez-vous sur la valeur opérationnelle de l’application visée.
 +
 +
==== <big>Stratégie et cibles concernant la migration de documents</big> ====
 +
À l’issue de cette étape, vous aurez analysé votre portefeuille d’applications, mis à jour les données principales de la GPA, déterminé une stratégie de migration pour chacune des applications (l’un des « 5 R ») et fixé un objectif pour chacune des applications (informatique en nuage ou centre de données organisationnelles (CDO).
 +
 +
Dans le cadre de l’étape de détermination de la vision de la modernisation au sein de l’organisation, vous devrez déterminer jusqu’où votre organisation souhaite aller dans le cadre du processus de modernisation. Cette étape prévoit le remplissage de la feuille de pointage sur l’adaptation à l’informatique en nuage. Vous devrez avoir déjà précisé les options ayant été ciblées pour chacune des applications.
 +
 +
===== '''<u>Choisissez la stratégie d’atténuation qui convient</u>''' =====
 +
Pour chacune des applications, déterminez votre stratégie de migration (les « 5 R »).
  
  
 
</multilang>
 
</multilang>

Revision as of 12:44, 29 November 2019


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[edit | edit source]

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

  • Prioritizing at-risk technologies
  • Engaging with partner departments
  • Performing an analysis of departmental application portfolios
  • Planning for addressing the at-risk technologies through modernization
  • Governance gating for endorsing modernization/migration 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.

The Investment Framework also consists of four phases:

Prioritization: priorities for modernizing at-risk technologies are selected and endorsed by governance.

Engagement: notify impacted departments, distribute templates to capture technical details, modernization/migration strategies, costing details and reporting dashboard.

Discovery: departments analyze their application portfolios to determine their strategies for modernizing at-risk technologies including a plan and cost estimates.

Execution: departments work with their partners to execute the modernization strategies identified during the discovery phase.

The image below provides a pictorial view of a department's journey through the Investment Framework, or can also be found here in downloadable document form.

Application Modernization Investment Framework
Application Modernization Investment Framework - Departmental Journey

Background[edit | edit source]

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[edit | edit source]

Priorities for investment from the Application Modernization and Workload Migration funds are based upon identifying high business value applications that are impacted by at-risk technologies. These at risk technologies can include, amongst other things, end of life software, end of life infrastructure, outdated architectures, to be decommissioned facilities such as data centres, etc…

To stabilize the IT landscape and ensure continuity of services to Canadians, TBS and SSC are working in collaboration with GC departments that demonstrate a readiness to modernize applications and migrate them to end state hosting platforms (cloud or enterprise data centres).

Departments may identify applications of high business value that are impacted by technology risks as a priority investment. If endorsed by governance, those priorities will be eligible for access to Application Modernization funds and support from the Workload Migration program.

To facilitate the prioritization process, a GCEARB Gate1 (Prioritization) template has been provided for departments to complete. This template, once completed, can be brought forward to your Departmental Architecture Review Board before being brought forward to request endorsement by governance (WLM Working group, GC EARB, ADM CEPP, and DM CEPP). The request for endorsement is a department’s opportunity to make a strong business case for investment to address at-risk technologies.

The endorsement of priority at-risk technologies must be supported by the departments’ Application Portfolio Management (APM) data, readiness to proceed with the application modernization framework (described on this page), and the strategy that will be used to modernize (rehost, replatform, refactor, replace and to which hosting platform; data centre or cloud services)

In 2018, the following data centre facilities were identified as at-risk technologies to be decommissioned and the applications to be migrated or modernized to a new data centre or cloud services.

The first wave of workload migration projects began in 2018:

  • Tunney’ Pasture DC (Statistics Canada)
  • Dorval DC (Environment and Climate Change Canada)
  • Aviation Parkway DC (22 partner department tenants)
  • St. Laurent DC (Canada Revenue Agency and Canada Border Services Agency)
  • Booth Street DC (Natural Resources Canada)
  • Goldenrod DC (Department of National Defence)

(insert approved wave 2 list of priorities Oct. 10)

Governance[edit | edit source]

WLM Governance.png

Engagement[edit | edit source]

Once priorities are reached and the impacted partner departments are notified, the Application Modernization starter kit package, along with application modernization handbook and FAQ documents are provided. This package contains GC EARB Gate 1 (Prioritization) template, App Mod Cost estimates template (used to identify funding requirements), Departmental & Data Centre View dashboard, Application Risk Review dashboard, and Business case template. Partner departments are provided guidance/assistance throughout the engagement journey.

Partner Departments are endorsed by governance (WLM Working group, GC EARB, ADM CEPP, and DM CEPP) and funding becomes available to initiate the discovery phase. A Memorandum of Understanding between the Government of Canada’s Chief Information Officer (GC CIO) and the Deputy Head of a department will be agreed upon by both parties to secure the funding.

Discovery[edit | edit source]

Application Portfolio Analysis[edit | edit source]

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[edit | edit source]

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 is 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 .png

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 initative 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[edit | edit source]

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

Obsolete Repositories[edit | edit source]

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 unnecessary data retention and actively dispose of data that has been deemed unnecessary. Unnecessary data is both a cost and a liability.
Obsolete Applications[edit | edit source]

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[edit | edit source]

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[edit | edit source]

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

Strategy Alternative 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). X1 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
1Appropriate when addressing end of life OSes
Rehost (lift and shift)[edit | edit source]

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)[edit | edit source]

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 popular 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)[edit | edit source]

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 only be applied to high business value applications.

Replace (Repurchase)[edit | edit source]

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[edit | edit source]

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[edit | edit source]

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[edit | edit source]

Ensure mission critical applications are correctly identified.

Identify Operating Systems[edit | edit source]

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[edit | edit source]

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

Sample Application Portfolio Analysis

Engage SSC Project Manager and WLM Factory[edit | edit source]

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 (Roadmap)[edit | edit source]

Sample Roadmap for Modernization

Document Cost Estimates[edit | edit source]

An App Mod Cost estimates template has been devised to identify cost estimates. A Memorandum of Understanding between the GC CIO and the Deputy Head of a department will be agreed upon by both parties to secure the funding for execution phase. The MoU generic template can be found here (insert template).

Gate2: GC EARB Endorsement and MoU to Release Funds[edit | edit source]

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.

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.

Reporting Requirements[edit | edit source]

As per section 3: Reporting Requirements of the signed MOU between your department and TBS, the executive project dashboard is due at the end of each quarter. Please find the Executive project dashboard tool to be used to report the status of your modernization strategies to the TBS Oversight Team. This is a standard template that is used to monitor projects with further instructionsif required can be found here: .

Execution[edit | edit source]

Once priorities are reached the impacted partner departments are notified, and Application Modernization starter kit package, along with application modernization handbook and FAQ documents are provided. This package contains GC EARB template, App Mod Cost estimates template (used to identify funding requirements), Departmental & Data Centre View dashboard, Application Risk Review dashboard, and Business case template.

Partner departments are provided guidance/assistance throughout the engagement journey.

Partner Departments are endorsed by governance (WLM Working group, GC EARB, ADM CEPP, and DM CEPP) and funding becomes available to initiate the discovery phase. A Memorandum of Understanding between the Government of Canada’s Chief Information Officer (GC CIO) and the Deputy Head of a department will be agreed upon by both parties to secure the funding.

Lessons Learned[edit | edit source]

Change is hard. Cloud requires a major culture shift in the organization, especially in IT as it means radical transformation to some roles. Do not underestimate the fear that people will have. Organizational change management must be at the forefront.

Strong support required by deputy head and all levels of senior leadership. Due to the magnitude of change required and the underlying complexity, the senior management table MUST demonstrate consistent, strong leadership to ensure success.

Cloud is a journey, not a destination. It is very complex, and will take longer than you think. Start now, before you have all of the information. BUT – start smaller and simple, avoid serious injury when you fall. Because you will fall. Learn to crawl before trying to run. Fully embracing cloud will take years.

Partner with others. Having an integrated project team with SSC has been key success factor. Leverage the expertise of industry and of others that have gone before you.

Strong support required by deputy head and all levels of senior leadership.

Shallow pool of resources with the required expertise. Resources are routinely targeted by other departments and private sector. Ability to attract and retain talent is key, and is very challenging in public sector environment.

Products may not be as advertised. While the products may be released as GA, and have been tested on the open market, they do not necessarily function as intended. There may be a lot of back and forth with the vendor (in our case MS) in order to get the functionality you were expecting - add some contingency time to your project for this.

Voice your concerns immediately. You have to watch your costs like a hawk and have a strong understanding of what the costs should be - more importantly, you have to voice your concerns immediately to the vendor so that they can investigate and adjust. eg Log analytics

Be like water You have to work with a singular vision and purpose, but you have to be like water otherwise. The landscape in the cloud is ever changing - gone are the days of set it and forget it. Also, politically, there are always changes too - so you must be prepared to pivot when needed. eg. Pathfinder, APDC Closure, desktop, etc...

References[edit | edit source]

TB Policies & Standards[edit | edit source]

Policy on Management of Information Technology

Policy on Government Security

Direction for Electronic Data Residency, ITPIN No: 2017-02

Direction of the Secure Use of Commercial Cloud Services: Security Policy Implementation Notice (SPIN)

Guidance[edit | edit source]

Government of Canada Digital Playbook (draft)

Government of Canada Security Control Profile for Cloud-Based GC IT Services

Government of Canada Cloud Security Risk Management Approach and Procedures

CSE ITSG-22 Baseline Security Requirements for Network Security Zones in the Government of Canada

CSE ITSG-38 Network Security Zoning – Design Consideration for Placement of Services within Zones

CSE ITSG.30.031 V2 User Authentication Guidance for Information Technology Systems

CSE ITSG.40.062 Guidance on Securely Configuring Network Protocols

Blog[edit | edit source]

The GC Accelerators - Accelerating the Secure Adoption of Cloud Services

Part 1: Application Modernisation — Making IT Delivery Less Effort

Part 2: Application Modernisation — Understanding Modernisation Strategies

Part 3: Application Modernisation — Assessing Your Portfolio

Part 4: Application Modernisation — Choosing Your Target

Part 4 ¾: Application Modernisation – Continuous Modernisation

5–4–3–2–1 — Cloud!