Difference between revisions of "GC Enterprise Architecture/Framework/ApplicationGuide"

From wiki
Jump to navigation Jump to search
(Created page with "<multilang> @en| == Application architecture == Application architecture practices must evolve significantly for the successful implementation of the GC Enterprise Ecosystem...")
 
m
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
{{OCIO GCEA Header}}
 
<multilang>
 
<multilang>
−
@en|
+
@en|__TOC__
  
 
== Application architecture ==
 
== Application architecture ==
  
−
Application architecture practices must evolve significantly for the successful implementation of the GC Enterprise Ecosystem Target Architecture. Transitioning from legacy systems based on monolithic architectures to architectures that oriented around business services and based on re‑useable components implementing business capabilities, is a major shift. Interoperability becomes a key element, and the number of stakeholders that must be considered increases.
+
Application architecture is defined as the management of software used by a business to solve problems. Application architecture practices must evolve significantly for the successful implementation of the GC Enterprise Ecosystem Target Architecture. Transitioning from legacy systems based on monolithic architectures to architectures that are oriented towards business services and re‑useable components implementing business capabilities, is a major shift. Interoperability becomes a key element, and the number of stakeholders that must be considered increases.
  
 
=== Use open source solutions hosted in public cloud ===
 
=== Use open source solutions hosted in public cloud ===
 +
 
* select existing solutions that can be reused over custom built
 
* select existing solutions that can be reused over custom built
 +
 +
If there is already an existing open-source solution for another project that can be reused for your project, it is recommended to reach out to the owner of that project and try to reuse it for your project. That way you can get the expertise as well as the lessons learned for the existing solution.
 +
 +
    <b>How to achieve:</b>
 +
    * Summarize how the architecture leverages and reuses existing architectural sections including:
 +
        * Past and/or Present Processes
 +
        * Past and/or Present Solutions
 +
        * Past and/or Present Components
 +
 +
    <b>Tools:</b>
 +
        * Target State Architecture
 +
        * Interim State Architecture
 +
        * EA Assessment
 +
 +
 +
 
* contribute all improvements back to the communities
 
* contribute all improvements back to the communities
−
* register open source software to the Open Resource Exchange
+
    <b>How to achieve:</b>
 +
    * Summarize how the team will align to the TBS Guidance on Open Source Publishing to support the production of better solutions
 +
    * Summarize how the team will leverage/has leverage the Open Source community
 +
 
 +
    <b>Tools:</b>
 +
        * Target State Architecture
 +
        * Interim State Architecture
 +
 
 +
* register open source software to the [https://code.open.canada.ca/en/index.html Open Resource Exchange]
 +
    <b>How to achieve:</b>
 +
    * Summarize how the architecture will leverage the Open Resource Exchange.
 +
    * Summarize how the architecture will utilize APIs to support Open Data feeds
 +
 
 +
    <b>Tools:</b>
 +
        * Target State Architecture
 +
        * Interim State Architecture
  
 
=== Use software as a service (SaaS) hosted in public cloud ===
 
=== Use software as a service (SaaS) hosted in public cloud ===
 
* choose SaaS that best fit for purpose based on alignment with SaaS capabilities
 
* choose SaaS that best fit for purpose based on alignment with SaaS capabilities
 +
    <b>How to achieve:</b>
 +
    * Summarize how the recommended SaaS is the best fit for purpose based on alignment with SaaS capabilities of SaaS provider and Dept/SSC
 +
 +
    <b>Tools:</b>
 +
        * Option analysis
 +
 
* choose a SaaS solution that is extendable
 
* choose a SaaS solution that is extendable
 +
    <b>How to achieve:</b>
 +
    * Summarize how the recommended SaaS is extendable
 +
 +
    <b>Tools:</b>
 +
        * Option analysis
 +
        * EA Assessment
 +
 
* configure SaaS and if customization is necessary extend as open source modules
 
* configure SaaS and if customization is necessary extend as open source modules
 +
    <b>How to achieve:</b>
 +
    * Summarize how the recommended SaaS can be customized through Open Source modules.
 +
 +
    <b>Tools:</b>
 +
        * Option analysis
 +
        * EA Assessment
  
 
=== Design for Interoperability ===
 
=== Design for Interoperability ===
 
* design systems as highly modular and loosely coupled services
 
* design systems as highly modular and loosely coupled services
 +
    <b>How to achieve:</b>
 +
    * Summarize how the architecture supports the implementation through:
 +
        * Simple independent functions
 +
        * Highly modular
 +
        * Loosely coupled
 +
        * Deployed into a container that has just a single application with  the ability to build the smallest image
 +
 +
    <b>Tools:</b>
 +
        * Target State Architecture
 +
        * Interim State Architecture
 +
 
* expose services, including existing ones, through APIs
 
* expose services, including existing ones, through APIs
 +
    <b>How to achieve:</b>
 +
    * Summarize how the architecture exposes functionality as services and these services are accessible through common methodologies
 +
    * Summarize how the architectures aligns to the Government of Canada Standards on APIs
 +
 +
    <b>Tools:</b>
 +
        * Target State Architecture
 +
        * Interim State Architecture
 +
 
* make the APIs discoverable to the appropriate stakeholders
 
* make the APIs discoverable to the appropriate stakeholders
 +
    <b>How to achieve:</b>
 +
    * Summarize which APIs will be published to the ESDC API  store
 +
    * Summarize which APIs will be published to the  GC API store
 +
    * Summarize the rational for not publishing APIs to an API store
 +
 +
    <b>Tools:</b>
 +
        * Target State Architecture
 +
        * Interim State Architecture
 +
 
=== ''Design for Interoperability, Proposed amendment Jan 8, 2021'' ===
 
=== ''Design for Interoperability, Proposed amendment Jan 8, 2021'' ===
 
* ''design systems as highly modular and loosely coupled services''
 
* ''design systems as highly modular and loosely coupled services''
 +
    <b>How to achieve:</b>
 +
    *
 +
 
* ''make all services available through a well-defined interface, such as an application programming interface (API)''
 
* ''make all services available through a well-defined interface, such as an application programming interface (API)''
 +
    <b>How to achieve:</b>
 +
    *
 +
 
* ''all APIs with potential for cross-departmental, inter-jurisdictional, or public consumption must be published to the GC API Store''
 
* ''all APIs with potential for cross-departmental, inter-jurisdictional, or public consumption must be published to the GC API Store''
 +
    <b>How to achieve:</b>
 +
    *
 +
 
* ''use the Canadian Digital Exchange Platform (CDXP) for data exchange where suitable (e.g., GC Event Broker for asynchronous messaging)''
 
* ''use the Canadian Digital Exchange Platform (CDXP) for data exchange where suitable (e.g., GC Event Broker for asynchronous messaging)''
  
  
−
@fr|
+
@fr|__TOC__
  
−
==== Architecture d’application ====
+
== ARCHITECTURE D'APPLICATION ==  
 
Les pratiques d’architecture d’application doivent évoluer considérablement pour assurer la réussite de la mise en œuvre de l’architecture cible de l’écosystème d’entreprise du GC. La transition des anciens systèmes basés sur des architectures monolithiques vers des architectures axées sur les services opérationnels et sur des composants réutilisables mettant en œuvre des capacités opérationnelles constitue un changement majeur. L’interopérabilité devient un élément clé, et le nombre d’intervenants dont on doit tenir compte augmente.
 
Les pratiques d’architecture d’application doivent évoluer considérablement pour assurer la réussite de la mise en œuvre de l’architecture cible de l’écosystème d’entreprise du GC. La transition des anciens systèmes basés sur des architectures monolithiques vers des architectures axées sur les services opérationnels et sur des composants réutilisables mettant en œuvre des capacités opérationnelles constitue un changement majeur. L’interopérabilité devient un élément clé, et le nombre d’intervenants dont on doit tenir compte augmente.
−
{| class="wikitable"
+
 
−
|'''Utiliser les solutions de sources ouvertes'''
+
=== Utiliser les solutions de sources ouvertes hébergées dans le nuage public ===
−
''' hébergées dans le nuage public'''
+
 
−
|
+
==== * Choisir des solutions existantes qui peuvent être réutilisées plutôt que des solutions personnalisées ====
−
* Choisir des solutions existantes qui peuvent être réutilisées plutôt que des solutions personnalisées;
+
 
−
* Mettre toutes les améliorations à la disposition de la collectivité;
+
    <b>Comment y parvenir :</b>
−
* Enregistrer les logiciels ouverts dans l’Échange de ressources ouvertes.
+
      * Résumer comment l'architecture exploite et réutilise les solutions, composants et processus existants, notamment :
−
|-
+
        * Les processus existants sont réutilisés ou optimisés ;
−
|'''Utiliser les logiciels sous forme de service (SaaS)'''
+
        * Solutions existantes réutilisées ou exploitées, et ;
−
'''hébergés dans le nuage public'''
+
        * Composants existants réutilisés ou exploités.
−
|
+
 
−
* Choisir les logiciels sous forme de service qui conviennent le mieux à l’utilisation prévue en fonction de son alignement sur les capacités SaaS;
+
    <b>Outils :</b>
−
* Choisir une solution SaaS extensible;
+
        * Architecture d'état cible
−
* Configurer le SaaS et, s’il faut le personnaliser, l’étendre en tant que module source ouverte.
+
        * Architecture d'État intérimaire
−
|-
+
        * Évaluation EA
−
|'''Conception en vue de l’interopérabilité'''
+
 
−
|
+
==== * Mettre toutes les améliorations à la disposition de la collectivité ====
−
* Concevoir les systèmes comme des services hautement modulaires et indépendants;
+
 
−
* Présenter les services, y compris les services existants, au moyen d’IPA;
+
    <b>Comment y parvenir :</b>
−
* Rendre les IPA accessibles aux parties prenantes concernées.
+
      * Résumer comment l'équipe s'alignera sur les directives du SCT sur l'édition open source pour soutenir la production de meilleures solutions
−
|}
+
      * Résumer comment l'équipe tirera parti/a tiré parti de la communauté Open Source
 +
 
 +
    <b>Outils :</b>
 +
        * Architecture d'état cible
 +
        * Architecture d'État intérimaire
 +
 
 +
==== * Enregistrer les logiciels ouverts dans l’Échange de ressources ouvertes ====
 +
 
 +
    <b>Comment y parvenir :</b>
 +
      * Résumez comment l'architecture tirera parti de l'Open Resource Exchange.
 +
      * Résumer comment l'architecture utilisera les API pour prendre en charge les flux de données ouvertes
 +
 
 +
    <b>Outils :</b>
 +
        * Architecture d'état cible
 +
        * Architecture d'État intérimaire
 +
 
 +
=== Utiliser les logiciels sous forme de service (SaaS) hébergés dans le nuage public ===
 +
 
 +
==== * Choisir les logiciels sous forme de service qui conviennent le mieux à l’utilisation prévue en fonction de son alignement sur les capacités SaaS ====
 +
 
 +
    <b>Comment y parvenir :</b>
 +
      * Résumer comment le SaaS recommandé est le mieux adapté à l'objectif en fonction de l'alignement avec les capacités SaaS du fournisseur SaaS et du département/SSC
 +
 
 +
    <b>Outils :</b>
 +
        * Analyse des options
 +
 
 +
==== * Choisir une solution SaaS extensible ====
 +
 
 +
    <b>Comment y parvenir :</b>
 +
      * Résumez comment le SaaS recommandé est extensible
 +
 
 +
    <b>Outils :</b>
 +
        * Analyse des options
 +
        * Évaluation EA
 +
 
 +
==== * Configurer le SaaS et, s’il faut le personnaliser, l’étendre en tant que module source ouverte ====
 +
 
 +
    <b>Comment y parvenir :</b>
 +
      * Résumez comment le SaaS recommandé peut être personnalisé via des modules Open Source.
 +
 +
    <b>Outils :</b>
 +
        * Analyse des options
 +
        * Évaluation EA
 +
=== Conception en vue de l’interopérabilité ===
 +
 
 +
==== * Concevoir les systèmes comme des services hautement modulaires et indépendants ====
 +
 
 +
    <b>Comment y parvenir :</b>
 +
      * Résumer comment l'architecture prend en charge la mise en œuvre à travers :
 +
        * Fonctions indépendantes simples
 +
        * Hautement modulaire
 +
        * Couplage lâche
 +
        * Déployé dans un conteneur qui n'a qu'une seule application avec la possibilité de créer la plus petite image
 +
 
 +
    <b>Outils :</b>
 +
        * Architecture d'état cible
 +
        * Architecture d'État intérimaire
 +
 
 +
==== * Présenter les services, y compris les services existants, au moyen d’IPA ====
 +
 
 +
    <b>Comment y parvenir :</b>
 +
      * Résumer comment l'architecture expose les fonctionnalités en tant que services et ces services sont accessibles via des méthodologies communes
 +
      * Résumer comment les architectures s'alignent sur les normes du gouvernement du Canada sur les API
 +
 
 +
    <b>Outils :</b>
 +
        * Architecture d'état cible
 +
        * Architecture d'État intérimaire
 +
 
 +
==== * Rendre les IPA accessibles aux parties prenantes concernées ====
 +
 
 +
    <b>Comment y parvenir :</b>
 +
      * Résumez les API qui seront publiées dans le magasin d'API d'ESDC
 +
      * Résumez les API qui seront publiées dans le magasin d'API GC
 +
      * Résumez la raison de ne pas publier d'API dans un magasin d'API
 +
 
 +
    <b>Outils :</b>
 +
        * Architecture d'état cible
 +
        * Architecture d'État intérimaire
  
 
</multilang>
 
</multilang>

Latest revision as of 12:38, 11 January 2023

GC Enterprise Architecture GC Enterprise Architecture Review Board, GC EARB
GC Service & Digital Target Enterprise Architecture When to come
Enterprise Architecture Framework Forward Agenda
Business Capability Model (BCM) Past Sessions
Exemplar and Reference Architectures 10 Things You Need to Know
Enterprise Solutions Governance for Digital Solutions
Working Groups EA and GC EARB Overview – Presentation
Other References

Application architecture[edit | edit source]

Application architecture is defined as the management of software used by a business to solve problems. Application architecture practices must evolve significantly for the successful implementation of the GC Enterprise Ecosystem Target Architecture. Transitioning from legacy systems based on monolithic architectures to architectures that are oriented towards business services and re‑useable components implementing business capabilities, is a major shift. Interoperability becomes a key element, and the number of stakeholders that must be considered increases.

Use open source solutions hosted in public cloud[edit | edit source]

  • select existing solutions that can be reused over custom built

If there is already an existing open-source solution for another project that can be reused for your project, it is recommended to reach out to the owner of that project and try to reuse it for your project. That way you can get the expertise as well as the lessons learned for the existing solution. 

   How to achieve:
    * Summarize how the architecture leverages and reuses existing architectural sections including:
       * Past and/or Present Processes
       * Past and/or Present Solutions
       * Past and/or Present Components

   Tools:
       * Target State Architecture
       * Interim State Architecture
       * EA Assessment


  • contribute all improvements back to the communities
   How to achieve:
    * Summarize how the team will align to the TBS Guidance on Open Source Publishing to support the production of better solutions
    * Summarize how the team will leverage/has leverage the Open Source community

   Tools:
       * Target State Architecture
       * Interim State Architecture

   How to achieve:
    * Summarize how the architecture will leverage the Open Resource Exchange.
    * Summarize how the architecture will utilize APIs to support Open Data feeds

   Tools:
       * Target State Architecture
       * Interim State Architecture

Use software as a service (SaaS) hosted in public cloud[edit | edit source]

  • choose SaaS that best fit for purpose based on alignment with SaaS capabilities
   How to achieve:
    * Summarize how the recommended SaaS is the best fit for purpose based on alignment with SaaS capabilities of SaaS provider and Dept/SSC

   Tools:
       * Option analysis
  • choose a SaaS solution that is extendable
   How to achieve:
    * Summarize how the recommended SaaS is extendable

   Tools:
       * Option analysis
       * EA Assessment
  • configure SaaS and if customization is necessary extend as open source modules
   How to achieve:
    * Summarize how the recommended SaaS can be customized through Open Source modules.

   Tools:
       * Option analysis
       * EA Assessment

Design for Interoperability[edit | edit source]

  • design systems as highly modular and loosely coupled services
   How to achieve:
    * Summarize how the architecture supports the implementation through:
       * Simple independent functions
       * Highly modular
       * Loosely coupled
       * Deployed into a container that has just a single application with  the ability to build the smallest image 

   Tools:
       * Target State Architecture
       * Interim State Architecture
  • expose services, including existing ones, through APIs
   How to achieve:
    * Summarize how the architecture exposes functionality as services and these services are accessible through common methodologies
    * Summarize how the architectures aligns to the Government of Canada Standards on APIs

   Tools:
       * Target State Architecture
       * Interim State Architecture
  • make the APIs discoverable to the appropriate stakeholders
   How to achieve:
    * Summarize which APIs will be published to the ESDC API  store
    * Summarize which APIs will be published to the   GC API store 
    * Summarize the rational for not publishing APIs to an API store

   Tools:
       * Target State Architecture
       * Interim State Architecture

Design for Interoperability, Proposed amendment Jan 8, 2021[edit | edit source]

  • design systems as highly modular and loosely coupled services
   How to achieve:
    *
  • make all services available through a well-defined interface, such as an application programming interface (API)
   How to achieve:
    *
  • all APIs with potential for cross-departmental, inter-jurisdictional, or public consumption must be published to the GC API Store
   How to achieve:
    *
  • use the Canadian Digital Exchange Platform (CDXP) for data exchange where suitable (e.g., GC Event Broker for asynchronous messaging)


Retrieved from "https://wiki.gccollab.ca/index.php?title=GC_Enterprise_Architecture/Framework/ApplicationGuide&oldid=87728"