wiki

Changes

GC Enterprise Architecture/Framework/TechnologyGuide (view source)

Revision as of 10:11, 3 February 2023

6,741 bytes added ,  10:11, 3 February 2023
m
no edit summary
Line 1: Line 1: −
 
+
{{OCIO GCEA Header}}
 
<multilang>
 
<multilang>
−
@en|
+
@en|__TOC__
    
== Technology architecture ==
 
== Technology architecture ==
−
Technology architecture is an important enabler of highly available and adaptable solutions that must be aligned with the chosen application architecture. Cloud adoption provides many potential advantages by mitigating the logistical constraints that often negatively impacted legacy solutions hosted “on premises.” However, the application architecture must be able to enable these advantages.
+
Technology architecture is defined as the management and organization of technical equipment and devices of a business. Technology architecture is an important enabler of highly available and adaptable solutions that must be aligned with the chosen application architecture. Cloud adoption provides many potential advantages by mitigating the logistical constraints that often negatively impacted legacy solutions hosted “on premises.” However, the application architecture must be able to enable these advantages. Therefore, objectives for cloud solutions must be implemented in a way that supports the application architecture.
    
=== Use cloud first ===
 
=== Use cloud first ===
Line 16: Line 16:  
     * Cloud Assessment Framework
 
     * Cloud Assessment Framework
 
     * Summary of Cloud Access Scenarios and Usage Profiles
 
     * Summary of Cloud Access Scenarios and Usage Profiles
 +
    
* enforce this order of preference: software as a service (SaaS) first, then platform as a service (PaaS), and lastly infrastructure as a service (IaaS)
 
* enforce this order of preference: software as a service (SaaS) first, then platform as a service (PaaS), and lastly infrastructure as a service (IaaS)
Line 28: Line 29:  
     * Cloud Reference Architecture
 
     * Cloud Reference Architecture
 
     * Cloud Assessment Framework
 
     * Cloud Assessment Framework
 +
    
* fulfill cloud services through SSC Cloud‑Brokering Services
 
* fulfill cloud services through SSC Cloud‑Brokering Services
Line 35: Line 37:  
     <b>Tools:</b>
 
     <b>Tools:</b>
 
     * Contact Cloud COE
 
     * Contact Cloud COE
 +
    
* enforce this order of preference: public cloud first, then hybrid cloud, then private cloud, and lastly non‑cloud (on‑premises) solutions
 
* enforce this order of preference: public cloud first, then hybrid cloud, then private cloud, and lastly non‑cloud (on‑premises) solutions
Line 45: Line 48:  
         * The implementation of applications are not susceptible to latency issues, which may arise due to traffic moving through an additional circuit.
 
         * The implementation of applications are not susceptible to latency issues, which may arise due to traffic moving through an additional circuit.
 
         * The implementation of applications, which do not have voluminous transactions with an on-premises database or application.
 
         * The implementation of applications, which do not have voluminous transactions with an on-premises database or application.
−
      
     <b>Tools:</b>
 
     <b>Tools:</b>
 
     * Cloud Reference Architecture
 
     * Cloud Reference Architecture
 
     * Cloud Assessment Framework
 
     * Cloud Assessment Framework
 +
    
* design for cloud mobility and develop an exit strategy to avoid vendor lock‑in
 
* design for cloud mobility and develop an exit strategy to avoid vendor lock‑in
Line 58: Line 61:  
     * Solution Architecture
 
     * Solution Architecture
 
     * Refer YDG GC EARB  
 
     * Refer YDG GC EARB  
 +
    
=== Design for performance, availability and scalability ===
 
=== Design for performance, availability and scalability ===
Line 68: Line 72:     
     <b>Tools:</b>
 
     <b>Tools:</b>
 +
    * non-functional requirements
 +
    
* support zero‑downtime deployments for planned and unplanned maintenance
 
* support zero‑downtime deployments for planned and unplanned maintenance
Line 79: Line 85:  
     <b>Tools:</b>
 
     <b>Tools:</b>
 
     * non-functional requirements
 
     * non-functional requirements
 +
    
* use distributed architectures, assume failure will happen, handle errors gracefully, and monitor performance and behaviour actively
 
* use distributed architectures, assume failure will happen, handle errors gracefully, and monitor performance and behaviour actively
Line 88: Line 95:  
     <b>Tools:</b>
 
     <b>Tools:</b>
 
     * non-functional requirements
 
     * non-functional requirements
 +
    
* establish architectures that supports new technology insertion with minimal disruption to existing programs and services
 
* establish architectures that supports new technology insertion with minimal disruption to existing programs and services
Line 95: Line 103:  
     <b>Tools:</b>
 
     <b>Tools:</b>
 
     * non-functional requirements
 
     * non-functional requirements
 +
    
* control technical diversity; design systems based on modern technologies and platforms already in use
 
* control technical diversity; design systems based on modern technologies and platforms already in use
Line 103: Line 112:  
     <b>Tools:</b>
 
     <b>Tools:</b>
 
     * non-functional requirements
 
     * non-functional requirements
 +
    
=== Follow DevSecOps principles ===
 
=== Follow DevSecOps principles ===
Line 112: Line 122:  
     <b>Tools:</b>
 
     <b>Tools:</b>
 
     * CICP mesh
 
     * CICP mesh
 +
    
* ensure automated testing occurs for security and functionality
 
* ensure automated testing occurs for security and functionality
Line 126: Line 137:       −
@fr|
+
@fr|__TOC__
      −
==== Architecture de la technologie ====
+
== ARCHITECTURE DE LA TECHNOLOGIE ==  
    
L’architecture technologique est un important catalyseur de solutions hautement accessibles et adaptables qui doivent être harmonisées avec l’architecture d’application choisie. L’adoption de l’informatique en nuage offre de nombreux avantages potentiels en atténuant les contraintes logistiques qui ont souvent une incidence négative sur les solutions existantes hébergées « sur place ». Cependant, l’architecture d’application doit rendre possible de tirer de ces avantages.
 
L’architecture technologique est un important catalyseur de solutions hautement accessibles et adaptables qui doivent être harmonisées avec l’architecture d’application choisie. L’adoption de l’informatique en nuage offre de nombreux avantages potentiels en atténuant les contraintes logistiques qui ont souvent une incidence négative sur les solutions existantes hébergées « sur place ». Cependant, l’architecture d’application doit rendre possible de tirer de ces avantages.
−
{| class="wikitable"
  −
|'''Utiliser d’abord le nuage'''
  −
|
  −
* Adopter l’utilisation des accélérateurs du GC pour assurer des contrôles de sécurité et d’accès adéquats;
  −
* Appliquer l’ordre de préférence suivant : logiciel en tant que service (SaaS) d’abord, puis plateforme comme service (PaaS), et enfin infrastructure comme service (IaaS);
  −
* Exécuter les services infonuagiques par l’entremise des services de courtage infonuagique de SPC;
  −
* Appliquer l’ordre de préférence suivant : le nuage public d’abord, ensuite le nuage hybride, puis le nuage privé et, enfin, les solutions sans nuage (sur site);
  −
* Concevoir la mobilité sur le nuage et élaborer une stratégie de sortie pour éviter l’immobilisation des fournisseurs.
  −
|-
  −
|'''Conception pour le rendement, la disponibilité et l’évolutivité'''
  −
|
  −
* Veiller à ce que les délais de réponse répondent aux besoins des utilisateurs et à ce que les services essentiels soient hautement disponibles;
  −
* Prendre en charge des déploiements sans temps d’arrêt pour la maintenance planifiée et non planifiée;
  −
* Utiliser des architectures distribuées, prévoir la possibilité d’échec, traiter dignement les erreurs et effectuer une surveillance active du rendement et du comportement;
  −
* Établir des architectures qui facilitent l’ajout de nouvelles technologies tout en limitant la perturbation des programmes et des services existants;
  −
* Contrôler la diversité technique – concevoir des systèmes basés sur des technologies et des plateformes modernes déjà utilisées.
  −
|-
  −
|'''Respecter les principes de développement d’applications modernes (DevSecOps)'''
  −
|
  −
* Utiliser l’intégration continue et les déploiements continus;
  −
* S’assurer que des tests automatisés sont effectués pour garantir la sécurité et la fonctionnalité;
  −
* Faire participer les utilisateurs et les autres intervenants au processus DevSecOps, qui fait référence au concept de faire de la sécurité logicielle un élément central du processus global de livraison de logiciels.
  −
|}
      +
 +
=== Utiliser d’abord le nuage ===
 +
 +
==== * Adopter l’utilisation des accélérateurs du GC pour assurer des contrôles de sécurité et d’accès adéquats ====
 +
 +
    <b>Comment y parvenir :</b>
 +
      * Résumez le profil d'utilisation du cloud sur lequel l'architecture s'aligne et pourquoi
 +
      * Résumer sur quel modèle de connexion cloud l'architecture s'aligne-t-elle et pourquoi
 +
 +
    <b>Outils :</b>
 +
      * Architecture de référence cloud
 +
      * Cadre d'évaluation du cloud
 +
      * Résumé des scénarios d'accès au cloud et des profils d'utilisation
 +
 +
==== * Appliquer l’ordre de préférence suivant : logiciel en tant que service (SaaS) d’abord, puis plateforme comme service (PaaS), et enfin infrastructure comme service (IaaS) ====
 +
 +
    <b>Comment y parvenir :</b>
 +
      * Résumez la façon dont l'architecture, basée sur l'outil d'évaluation du Cloud Right TBS, permet un modèle de service cloud de la façon dont :
 +
        * L'architecture peut être implémentée à l'aide d'un environnement GC SaaS, qui a été identifié comme un ajustement possible, ou
 +
        * L'architecture peut être implémentée à l'aide d'un environnement SaaS public, qui a été identifié comme un ajustement possible, ou
 +
        * L'architecture peut être implémentée à l'aide d'un environnement GC PaaS, qui a été identifié comme un ajustement possible, ou :
 +
        * L'architecture peut être implémentée en utilisant l'environnement Public PaaS, qui a été identifié comme un ajustement possible.
 +
 +
    <b>Outils :</b>
 +
      * Architecture de référence cloud
 +
      * Cadre d'évaluation du cloud
 +
 +
==== * Exécuter les services infonuagiques par l’entremise des services de courtage infonuagique de SPC ====
 +
 +
    <b>Comment y parvenir :</b>
 +
      * Confirmez que l'équipe acquiert des services cloud via SSC Cloud Brokering Services. Veuillez inclure le numéro de demande SSC
 +
 +
    <b>Outils :</b>
 +
      * Contacter Cloud COE
 +
 +
==== * Appliquer l’ordre de préférence suivant : le nuage public d’abord, ensuite le nuage hybride, puis le nuage privé et, enfin, les solutions sans nuage (sur site) ====
 +
 +
    <b>Comment y parvenir :</b>
 +
    * Résumez comment l'architecture, basée sur l'outil d'évaluation TBS Right Cloud, permet le cloud public, notamment :
 +
        * Les données, gérées par l'architecture, sont de type PBMM ou inférieur, et les parties prenantes n'ont pas soulevé de préoccupations concernant le déploiement dans le cloud public.
 +
        * Un modèle d'établissement des coûts/budget disponible pour prendre en charge un modèle de dépenses opérationnelles. Les coûts augmenteront et diminueront avec la consommation de ressources.
 +
        * La mise en œuvre d'applications pouvant fonctionner dans un environnement cloud et de tout matériel virtualisé ou dédié requis est disponible dans un environnement cloud.
 +
        * La mise en place d'application(s) pouvant fonctionner sur les offres standardisées et les SLA du cloud public.
 +
        * La mise en œuvre des applications n'est pas sujette aux problèmes de latence, qui peuvent survenir en raison du trafic passant par un circuit supplémentaire.
 +
        * La mise en œuvre d'applications, qui n'ont pas de transactions volumineuses avec une base de données ou une application sur site.
 +
 +
    <b>Outils :</b>
 +
    * Architecture de référence cloud
 +
    * Cadre d'évaluation du cloud
 +
 +
==== * Concevoir la mobilité sur le nuage et élaborer une stratégie de sortie pour éviter l’immobilisation des fournisseurs ====
 +
 +
    <b>Comment y parvenir :</b>
 +
      * Récapitulatif de la façon dont l'architecture permet l'exécution d'une stratégie de sortie de ce fournisseur
 +
 +
    <b>Outils :</b>
 +
      * Architecture de solutions
 +
      * Voir YDG CEAI GC
 +
 +
=== Conception pour le rendement, la disponibilité et l’évolutivité ===
 +
 +
==== * Veiller à ce que les délais de réponse répondent aux besoins des utilisateurs et à ce que les services essentiels soient hautement disponibles ====
 +
 +
    <b>Comment y parvenir :</b>
 +
      * Résumer comment l'architecture est capable de répondre aux exigences de temps de réponse de l'utilisateur et d'atteindre les objectifs de temps de réponse de l'utilisateur, notamment :
 +
        * La capacité de tracer comment les exigences et les objectifs de temps de réponse seront atteints.
 +
        * Les exigences de capacité (par exemple, trafic normal attendu, trafic de pointe, augmentation du trafic attendue, etc.) que l'architecture doit respecter.
 +
        * La capacité de tracer comment les exigences de disponibilité et les objectifs seront atteints.
 +
 +
    <b>Outils :</b>
 +
      * Prérogatives non fonctionnelles
 +
 +
==== * Prendre en charge des déploiements sans temps d’arrêt pour la maintenance planifiée et non planifiée ====
 +
 +
    <b>Comment y parvenir :</b>
 +
      * Résumez comment l'architecture est capable de prendre en charge les déploiements sans temps d'arrêt pour la maintenance planifiée et non planifiée, notamment :
 +
        * La maintenance Windows prévue pour la solution pour prendre en charge les sauvegardes et la durée de la maintenance Windows.
 +
        * La procédure de planification, d'ordonnancement et d'exécution du temps d'arrêt planifié.
 +
        * La capacité d'être déployé d'une manière qui minimise ou limite les interruptions de service, et qui est connue sous le nom de déploiements sans temps d'arrêt.
 +
        * Les mesures acceptables pour les temps d'arrêt imprévus.
 +
 +
    <b>Outils :</b>
 +
      * Prérogatives non fonctionnelles
 +
 +
==== * Utiliser des architectures distribuées, prévoir la possibilité d’échec, traiter dignement les erreurs et effectuer une surveillance active du rendement et du comportement ====
 +
 +
    <b>Comment y parvenir :</b>
 +
      * Résumez comment l'architecture utilise les architectures distribuées, qui supposent qu'une panne se produira, gèrent les erreurs avec élégance et surveillent activement, notamment :
 +
          * La capacité de tracer comment les exigences et les objectifs de recouvrabilité seront atteints ; et,
 +
          * La capacité à être déployé dans un environnement distribué.
 +
 +
    <b>Outils :</b>
 +
      * Prérogatives non fonctionnelles
 +
 +
==== * Établir des architectures qui facilitent l’ajout de nouvelles technologies tout en limitant la perturbation des programmes et des services existants ====
 +
 +
    <b>Comment y parvenir :</b>
 +
      * Résumer comment l'architecture permet l'insertion de nouvelles technologies avec un minimum de perturbations
 +
 +
    <b>Outils :</b>
 +
      * Prérogatives non fonctionnelles
 +
 +
==== * Contrôler la diversité technique – concevoir des systèmes basés sur des technologies et des plateformes modernes déjà utilisées ====
 +
    <b>Comment y parvenir :</b>
 +
      * Résumer l'état des normes technologiques (émergentes, de référence, de confinement ou de retrait) des produits requis/recommandés pour mettre en œuvre l'architecture. Pour les produits à l'état de confinement ou à la retraite, veuillez fournir une justification pour la sélection de ces produits
 +
      * Identifier les nouvelles normes technologiques requises par l'architecture
 +
 +
    <b>Outils :</b>
 +
      * Prérogatives non fonctionnelles
 +
 +
=== Respecter les principes de développement d’applications modernes (DevSecOps) ===
 +
 +
==== * Utiliser l’intégration continue et les déploiements continus ====
 +
 +
    <b>Comment y parvenir :</b>
 +
      * Résumer comment l'architecture peut être déployée suivant une approche d'intégration continue
 +
      * Résumer comment l'architecture peut être déployée suivant une approche de déploiement continu.
 +
 +
    <b>Outils :</b>
 +
      * Maille CICP
 +
 +
==== * S’assurer que des tests automatisés sont effectués pour garantir la sécurité et la fonctionnalité ====
 +
 +
    <b>Comment y parvenir :</b>
 +
      * Résumer les tests automatisés de sécurité et de fonctionnalité qui seront/ont été exécutés sur la solution.
 +
 +
==== * Faire participer les utilisateurs et les autres intervenants au processus DevSecOps, qui fait référence au concept de faire de la sécurité logicielle un élément central du processus global de livraison de logiciels ====
 +
 +
    <b>Comment y parvenir :</b>
 +
      * Résumer le rôle et les responsabilités des utilisateurs et autres parties prenantes dans les processus DevSecOps.
 +
 +
    <b>Outils :</b>
 +
      * Charte de projet
    
</multilang>
 
</multilang>
Iaketepe
16

edits

Retrieved from "https://wiki.gccollab.ca/Special:MobileDiff/42657...89987"