Line 121: |
Line 121: |
| ==== * 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 ==== |
| | | |
| + | <b>Comment y parvenir :</b> |
| + | * 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 ; |
| + | * Solutions existantes réutilisées ou exploitées, et ; |
| + | * Composants existants réutilisés ou exploités. |
| + | |
| + | <b>Outils :</b> |
| + | * Architecture d'état cible |
| + | * Architecture d'État intérimaire |
| + | * Évaluation EA |
| | | |
| ==== * Mettre toutes les améliorations à la disposition de la collectivité ==== | | ==== * Mettre toutes les améliorations à la disposition de la collectivité ==== |
| | | |
| + | <b>Comment y parvenir :</b> |
| + | * 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 ==== | | ==== * 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 === | | === 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 ==== | | ==== * 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 ==== | | ==== * 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 ==== | | ==== * 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é === | | === Conception en vue de l’interopérabilité === |
| | | |
| ==== * Concevoir les systèmes comme des services hautement modulaires et indépendants ==== | | ==== * 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 ==== | | ==== * 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 ==== | | ==== * 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> |