Architecture fédérée du gouvernement du Canada, Première itération

Architecture conceptuelle

La vision des exigences communes pour l'architecture fédérée définit ce que doit faire l'infrastructure de GI/TI du gouvernement du Canada ou, en d'autres termes, ses « fonctionnalités ». L'architecture conceptuelle définit comment l'infrastructure de GI/TI s'y prendra. Bref, elle décrit les « capacités » détaillées de l'infrastructure.

L'architecture conceptuelle sert en quelque sorte de plan pour la conception et le déploiement des composantes communes et partagées de l'architecture fédérée. Elle offre également un mécanisme qui permet aux ministères de répondre à leurs besoins opérationnels particuliers, tout en utilisant des composantes communes.

Objectif

L'objectif de l'architecture conceptuelle est d'assurer un juste équilibre dans l'infrastructure de GI/TI entre, d'une part, les mandats des ministères et organismes et, d'autre part, les intérêts de l'ensemble du gouvernement. Cet équilibre est requis, pour faire en sorte que les mandats des ministères et organismes ne soient pas compromis par les infrastructures communes, tout en leur permettant de réaliser des progrès appréciables dans la gestion et le partage de l'information et des services afin de mieux répondre à l'évolution des besoins et des conditions des citoyens et des clients.

L'architecture conceptuelle consiste en un ensemble de principes et de meilleures pratiques permettant d'ériger l'infrastructure stratégique de GI/TI et de gérer les actifs informationnels du gouvernement du Canada qui découlent de la vision des exigences communes. Cette architecture conceptuelle est donc un plan directeur de haut niveau, qui tient compte des éléments opérationnels et des « domaines » technologiques correspondants - c'est-à-dire les grands ensembles de capacités technologiques - permettant de répondre aux exigences de l'architecture.

Principes d'architecture

Les principes d'architecture jouent un rôle fondamental pour l'architecture fédérée. Ils sont en quelque sorte « intemporels », car ils définissent un système de valeur (alors que les méthodologies changent fréquemment, les valeurs, elles, ne changent pas). Les principes d'architecture sont stables. Une fois établis, ils n'ont besoin que de légers ajustements pour tenir compte de l'évolution des stratégies et des priorités opérationnelles. Si des modifications importantes sont requises, on évalue minutieusement leur impact dans le cadre d'un processus formel de gestion du changement.

Chaque principe est constitué de quatre parties : un court nom, une brève description, la justification du principe (habituellement formulé en terme opérationnel pour ce qui est des principes techniques) et les conséquences (positives et négatives) de l'adoption du principe.

Les principes d'architecture suivants ont été élaborés d'après les exigences particulières énoncées dans la vision des exigences communes. Ils visent essentiellement à orienter le développement des systèmes d'information et de l'infrastructure technologique, à l'appui de l'initiative du Gouvernement en direct, palier 1.

Principe d'architecture 1 : réduction de la complexité de l'intégration

L'architecture fédérée doit favoriser la réduction de la complexité et permettre une intégration aussi généralisée que possible. Nous devons restructurer les systèmes d'applications afin qu'ils soient « hautement modulaires » et « faiblement couplés » si on veut en utiliser les composantes.

Justification :

• les applications complexes qui comportent de nombreuses fonctions pour les données et les transactions sont difficiles à gérer, et.les modifications présentent un risque;
• les applications comportant des modules très couplés ou liés peuvent créer des problèmes de défaillance par dépendance;
• pour s'adapter aux exigences géographiques multiples des utilisateurs (utilisateurs répartis dans divers emplacements) et tirer profit de la puissance de traitement répartie, les applications doivent être déployées sur de nombreux serveurs;
• les composantes réutilisables doivent être déployées indépendamment de l'environnement servant au déploiement;
• on trouve sur le marché (ou on trouvera d'ici peu) des composantes permettant de réaliser de nombreuses fonctions opérationnelles.

Conséquences :

La réduction de la complexité de l'intégration présente les caractéristiques suivantes :

• développement d'applications compatibles et en composantes;
• il faut réduire au minimum le nombre de fournisseurs, de produits et de configurations, pour une souplesse maximale dans la mise en œuvre des modifications;
• on doit réduire au minimum les configurations des composantes architecturales et dissuader les adaptations ou « personnalisations » du matériel et des logiciels, que ce soit pour des raisons de conditions locales ou transitoires ou autres;
• maintien d'une « discipline de configuration », ce qui signifie sacrifier la performance et les fonctionnalités dans certains cas;
• dépendance accrue à l'égard des « sous-ensembles d'infrastructures » vendus par les fournisseurs;
• composantes ou modules d'infrastructure ou d'application plus petits et plus nombreux;
• moins de modifications;
• concept essentiel pour la conception en composantes des applications et de l'infrastructure;
• moins de redondance entre les applications et les composantes de l'infrastructure;
• établissement d'une « culture de la réutilisation », grâce à l'emploi d'incitatifs;
• la construction et l'intégration de composantes réutilisables doivent devenir une méthode courante de développement;
• la gestion des composantes doit devenir une compétence essentielle;
• on doit faire de la conception et de l'analyse de la logique opérationnelle une composante systémique de l'environnement des applications. En d'autres mots, les applications doivent être conçues de telle sorte que les composantes employées pour définir la logique opérationnelle puissent être réutilisées lorsqu'elles sont disponibles, et on ne devrait créer une composante de la logique opérationnelle que si elle n'existe pas;
• partage des systèmes et des composantes de systèmes;
• établissement de normes pour la configuration physique.

Principe d'architecture 2 : approche holistique

L'information est un actif pour le gouvernement. Sa valeur est bonifiée lorsque l'on peut y accéder et l'utiliser pour accélérer le processus décisionnel. On peut accroître davantage cette valeur par la collaboration interministérielle, compte tenu des limites imposées par la loi et le respect des renseignements personnels. L'infrastructure doit favoriser une approche dite du « gouvernement holistique », tout en respectant les rôles et les mandats propres au gouvernement fédéral.

Justification :

• l'information n'est pas exploitée à sa pleine valeur lorsqu'elle demeure dans des poches isolées;
• l'information doit être partagée, afin de maximiser l'efficacité des décisions opérationnelles dans l'ensemble du gouvernement et chez les partenaires externes;
• le processus décisionnel doit se faire plus rapidement, compte tenu de la réduction du cycle des processus opérationnels;
• pour que le processus décisionnel soit plus efficace, il faut accroître l'intégrité et la pertinence des données;
• l'approche pangouvernementale à l'égard de l'infrastructure est la meilleure façon d'utiliser au maximum les investissements en TI, en éliminant les infrastructures et les services de soutien en double, et en réalisant des économies d'échelle lorsque cela est approprié;
• à mesure que les processus opérationnels gouvernementaux évoluent, on pourra plus facilement et plus rapidement adapter l'infrastructure des TI pour faciliter cette évolution, si elle est conçue dans le cadre d'une approche de « gouvernement holistique ».

Conséquences :

L'approche holistique présente les caractéristiques suivantes:

• détermination et exploitation de la « chaîne de valeurs » informationnelle;
• unification de la gestion des données et de l'information;
• restructuration des données afin d'en faciliter l'accès et la gestion;
• identification et spécification des sources autorisées;
• promotion de la compréhension de l'« infostructure » dans le gouvernement;
• établissement de dépôts de données afin de faciliter la disponibilité de l'information pour les processus décisionnels;
• accélération de la « cadence » de l'information et établissement d'une politique sur le partage de l'information;
• programmes et services offrant l'accès des ministères et organismes à des données/informations précises;
• élaboration d'un mécanisme normalisé pour évaluer les autres possibilités techniques;
• établissement de règles et de critères de décision pour déterminer quand les exigences propres à un ministère, à l'égard de l'infrastructure commune, ont préséance sur l'approche pangouvernementale;
• mise de l'avant de solutions pouvant s'appliquer dans l'ensemble du gouvernement;
• organisation des systèmes opérationnels et des bases de données par sujet, et non par ministère, division ou unité;
• acceptation du fait que les décisions peuvent prendre plus de temps, tout comme la mise en œuvre des solutions;
• abandon occasionnel, par les ministères et organismes, de leurs propres préférences au profit de l'intérêt supérieur de l'ensemble du gouvernement fédéral.

Principe d'architecture 3 : systèmes dirigés par les événements opérationnels

Les systèmes doivent être conçus pour être dirigés par les événements opérationnels. Ce principe s'applique aux différents systèmes, qu'ils soient de type manuel, processus ou application. De plus, les systèmes d'applications doivent conserver les données opérationnelles nécessaires afin de permettre au gouvernement de recréer tout événement opérationnel.

Justification :

• permet à l'infrastructure de s'adapter davantage aux nouveaux processus opérationnels gouvernementaux, car les changements apportés à ceux-ci se traduisent par l'ajout, la suppression ou la modification d'événements opérationnels;
• renforce le lien entre l'infrastructure et les processus opérationnels;
• les systèmes sont conçus pour se conformer aux événements réels, au lieu de dicter les interfaces utilisateur requises;
• il est plus facile de réorienter les processus opérationnels lorsqu'il y a des modifications;
• permet de conserver les données les plus importantes, du point de vue juridique et sous l'angle de la responsabilité.

Conséquences :

Les systèmes dirigés par les événements opérationnels présentent les caractéristiques suivantes :

• remplacement de la logique par lot (ou logique du différé) par la logique dirigée par les événements;
• remplacement du traitement par lot par le traitement asynchrone;
• réflexion davantage systémique, car le traitement dirigé par les événements transgresse habituellement les limites classiques des systèmes;
• passage à un modèle « dynamique » de prestation d'information;
• rétention des données pendant de longues périodes et accès à ces données pour les systèmes opérationnels;
• on doit s'assurer que la planification des plans antisinistres et de reprise des activités tient compte des données et des systèmes critiques.

Principe d'architecture 4 : sources autorisées définies

Toute l'information doit provenir de « sources autorisées » définies. Ces sources joueront le rôle de « gardiens » de l'information. Les données autorisées doivent être accessibles et disponibles pour être réutilisées par tous les systèmes et/ou processus opérationnels y ayant droit.

Justification :

• les données doivent être disponibles rapidement et elles doivent être exactes; par conséquent, elles doivent être saisies et validées une seule fois, à la source;
• l'information doit être utile, utilisable et fiable pour qu'elle ait une quelconque valeur pour le gouvernement et les citoyens;
• l'utilisation de systèmes dirigés par les événements signifie que l'information doit être validée à la source.

Conséquences :

L'utilisation de sources autorisées définies présente les caractéristiques suivantes :

• les ministères ont la responsabilité des données qu'ils ont saisies à l'aide de leurs systèmes d'applications;
• les propriétaires des données sont responsables de leur définition et de leur qualité;
• on doit établir des procédures pangouvernementales pour gérer l'accès des données et en assurer la sécurité et l'intégrité;
• des règles entièrement définies de vérification des données doivent s'appliquer aux transactions en temps réel.

Principe d'architecture 5 : sécurité, confidentialité, protection de l'information et protection des renseignements personnels

Les systèmes de TI doivent être mis en place conformément aux politiques et lois gouvernementales touchant la sécurité, la confidentialité et le respect des renseignements personnels. L'information doit être protégée contre tout accès non autorisé, déni de service et modification, que ce soit intentionnel ou accidentel.

Justification :

• contribue à protéger l'information sur les clients;
• accroît la confiance du public;
• protège les biens du gouvernement;
• assure le respect des exigences en matière de financement public;
• réduit au minimum l'utilisation inadéquate des données, laquelle peut avoir de graves conséquences opérationnelles et juridiques;
• réduit au minimum les atteintes à la sécurité, lesquelles peuvent entraver l'intégrité du gouvernement et menacer sa viabilité.

Conséquences :

Le principe de sécurité, de confidentialité, de protection de l'information et de protection des renseignements personnels présente les caractéristiques suivantes :

• identification, publication et mise à jour des politiques applicables pour la gestion de l'information;
• contrôle du respect des règles et lois applicables;
• on doit s'assurer que les concepteurs, développeurs, etc., comprennent bien les exigences de sécurité, de confidentialité et de protection des renseignements personnels;
• mise en œuvre d'approches/politiques afin de réduire au minimum l'utilisation inadéquate des données;
• mise en œuvre d'approches/politiques afin de réduire au minimum les atteintes à la sécurité;
• politique clairement articulée en ce qui touche l'utilisation de l'information.

Principe d'architecture 6 : utilisation de normes et technologies éprouvées

Les solutions de TI doivent utiliser des technologies commerciales fiables, basées sur les normes. On doit éviter autant que possible l'adaptation et la personnalisation des logiciels achetés. On accordera la priorité aux produits qui respectent les normes de l'industrie et les principes de l'architecture ouverte. Lorsque plusieurs normes s'appliquent, l'ordre de priorité suivant prévaudra :

i. Normes approuvées et provisoires du gouvernement du Canada; rapports techniques (p. ex., Critères communs du Centre de la sécurité des télécommunications)

ii. Normes nationales du Canada et normes de l'Association canadienne de normalisation

iii. Normes internationales (c.-à-d. ISO) et recommandations de l'Union internationale des télécommunications

iv. Autres normes élaborées par des organismes publics, y compris les normes du Groupe IETF et les spécifications des consortiums industriels

v. Normes de facto

Justification :

• réduit la dépendance à l'égard de fournisseurs peu fiables et/ou peu performants;
• réduit les risques;
• assure un soutien robuste des produits;
• permet l'utilisation accrue de composantes normalisées et partageables, et de solutions disponibles dans le commerce;
• permet au gouvernement d'influer sur les normes et les tendances de l'industrie, et de demeurer à jour dans ce domaine;
• les programmes et logiciels ajoutés peuvent être sélectionnés d'après leurs « fonctionnalités », leur correspondance aux exigences opérationnelles et la rapidité de leur livraison;
• procure plus de souplesse pour le remplacement des produits.

Conséquences :

L'utilisation de normes et technologies éprouvées présente les caractéristiques suivantes :

• on doit établir des critères pour identifier d'une part les fournisseurs peu fiables ou peu performants, et d'autre part les produits standard;
• il faut délaisser les produits « faibles » actuellement utilisés;
• on doit déterminer si un programme ou un logiciel s'insère bien dans l'architecture;
• il se peut que l'on doive modifier les pratiques de travail et le déroulement des opérations, afin d'accroître la conformité avec les normes;
• les fournisseurs apportent des modifications aux logiciels achetés et les conservent dans leurs produits de base;
• il convient de procéder à un changement de culture, afin d'établir des normes et d'en contrôler le respect.

Principe d'architecture 7 : coût total de possession

L'établissement du coût total de possession pour les applications et les technologies (matériels et logiciels) doit chercher un équilibre entre deux ensembles de facteurs : d'une part, les coûts de développement, de soutien, de reprise après sinistre et de retrait, et d'autre part, les coûts associés à la souplesse, à l'évolutivité, à la facilité d'utilisation/de soutien pendant le cycle de vie de la technologie ou de l'application.

Justification :

• permet d'implanter des solutions de qualité supérieure;
• réduit le coût total de possession;
• permet d'améliorer la prise de décisions pour la planification et les budgets;
• le coût total de possession comprend la construction, l'exploitation et la maintenance des systèmes intégrés pangouvernementaux.

Conséquences :

Le principe de coût total de possession présente les caractéristiques suivantes :

• les concepteurs et les développeurs doivent adopter une vision systémique;
• on doit rechercher une sous-optimisation sélective, en vue de l'optimisation du système global;
• on doit élaborer des moyens pour établir le coût total de possession;
• un partage accru de l'information liée au coût total de possession des projets.

Principe d'architecture 8 : plan de croissance

Dans les plans pour les TI, on doit planifier, concevoir et prévoir la croissance et l'expansion des services (exigences connues) dans tout le gouvernement.

Justification :

• plus grande rentabilité;
• ce principe reconnaît le fait que le matériel coûte moins cher que la main-d'œuvre;
• réduit les coûts de maintenance;
• permet de réagir plus rapidement à la croissance et au changement.

Conséquences :

Le principe de planification de la croissance présente les caractéristiques suivantes :

• il faut changer la culture afin d'instaurer la réflexion adaptative;
• on doit élaborer des moyens de prévoir la croissance en fonction des tendances historiques;
• on doit également planifier la capacité.

Principe d'architecture 9 : adoption de méthodes formelles d'ingénierie

Le gouvernement doit employer des pratiques, méthodes et outils formels pour les travaux d'architecture et d'ingénierie à toutes les étapes de la conception, de la mise en œuvre et de la construction des systèmes de GI/TI.

Justification :

• réduit les coûts de formation;
• réduit la dépendance à l'égard de la gestion et du personnel des projets;
• permet la mise en place de points de référence pour les mesures de rendement;
• permet d'accroître l'assurance de la qualité;
• assure la répétitivité et l'uniformité.

Conséquences :

Le principe d'adoption de méthodes formelles d'ingénierie présente les caractéristiques suivantes :

• on doit convenir des pratiques et des méthodes à utiliser;
• il faut élaborer une fonction de définition des processus;
• il faut aussi élaborer des cours de formation sur les pratiques et les méthodes à employer;
• le contrôle de la conformité s'impose.

Principe d'architecture 10 : élargissement de l'environnement des services et de l'information

Dans la mesure du possible, l'intégration de l'infrastructure de GI/TI doit permettre au gouvernement du Canada d'offrir son information et ses services aux citoyens, aux entreprises et aux autres gouvernements (provinciaux, municipaux et étrangers).

Justification :

De nombreux services auxquels les citoyens et les entreprises s'attendent de la part de leurs gouvernements nécessitent la coordination de ceux-ci avec leurs partenaires et les autres paliers de gouvernement. Afin de répondre efficacement à ces attentes et offrir le niveau de service escompté, l'environnement gouvernemental de l'information et des services doit inclure un certain nombre de partenaires et d'autres paliers de gouvernement. Un environnement élargi et fiable pour l'information gouvernementale accroît également les canaux potentiels par lesquels les clients peuvent obtenir de l'information et des services.

Conséquences :

Le principe d'élargissement de l'environnement de l'information et des services présente les caractéristiques suivantes :

• on doit identifier les programmes du gouvernement du Canada qui doivent être optimisés;
• on doit identifier les partenaires;
• on doit élaborer les modalités de partage de l'information et des services;
• on doit déterminer l'information et les services qui doivent être partagés;
• on doit revoir les politiques et les lois existantes;
• enfin, on doit analyser l'environnement actuel afin de cibler et prioriser les tâches à accomplir.

Principe d'architecture 11 : mécanismes de prestation multiples

Il s'agit d'offrir aux clients, pour accéder aux services gouvernementaux, des mécanismes qui répondent à leurs préférences.

Justification :

• Les citoyens, les entreprises et les partenaires veulent que le gouvernement fédéral leur fournisse des mécanismes de prestation qui tiennent compte de leurs préférences et conditions particulières.
• Selon la nature des programmes exécutés, des particularités des transactions et de la sensibilité de l'information transigée, certains services nécessiteront des mécanismes particuliers.
• L'utilisation de mécanismes multiples de prestation constitue une protection contre les défaillances touchant un point d'accès unique et permet d'offrir les services vitaux, même en cas de défaillance.

Conséquences :

Le principe du maintien des mécanismes multiples de prestation des services présente les caractéristiques suivantes :

• on doit pouvoir accéder aux produits et services de nombreuses façons, mais ceux-ci doivent néanmoins être offerts aux utilisateurs d'une manière intégrée et uniforme;
• on doit recourir à des normes communes de présentation et d'exploitation pour ce qui est de la protection des renseignements personnels, de la sécurité et de l'uniformité de la qualité du service, peu importe le mode de prestation;
• les clients peuvent avoir accès simultanément à plusieurs canaux de prestation, notamment en cas de défaillance d'un mécanisme de prestation électronique de services;
• les applications doivent être conçues de façon à être indépendantes des mécanimes et des modes de prestation.

Principe d'architecture 12 : gouvernement accessible

Afin de répondre à la diversité sans cesse croissante de la société canadienne, le gouvernement du Canada doit être accessible à tous les citoyens.

Justification :

Il incombe au gouvernement fédéral de s'assurer qu'il peut offrir des services à tous les citoyens. Par conséquent, le gouvernement doit être accessible à tous et répondre à leurs exigences particulières en matière d'accès.

Conséquences :

Le principe du gouvernement accessible présente les caractéristiques suivantes :

• on doit présenter et configurer l'information afin de faciliter l'interaction des citoyens avec le gouvernement et l'obtention d'information;
• on doit faire en sorte que l'information soit affichée et adaptable, afin de répondre aux besoins et aux préférences d'accès d'un large éventail de citoyens;
• on doit s'assurer que les lignes directrices pour les interfaces avec les citoyens ne soient pas assujetties à des hypothèses restrictives sur la répartition géographique, la langue, les compétences en informatique ou les capacités physiques ou cognitives;
• on doit adopter un large éventail de principes afin de promouvoir l'accessibilité;
• on doit chercher à établir un « concept universel », ce qui, dans le contexte de la technologie, désigne la conception des produits, des systèmes, des processus et des environnements. En d'autres mots, on doit recourir autant que possible à des composantes utilisables par tous, sans qu'il soit nécessaire d'adapter ces composantes à l'ensemble du système; elles doivent néanmoins offir la capacité d'une adaptation (ou personnalisation) technique sur une base individuelle.

Les sous-principes associés au concept universel qui seraient applicables dans l'architecture et inclus dans l'infrastructure de GI/TI par l'Équipe responsable de l'architecture principale et les équipes responsables de l'architecture par domaine sont les suivants :

• Utilisation équitable : accommoder tous les utilisateurs, pour ce qui est des réseaux électroniques. Cela veut dire que les services doivent être offerts simultanément à tous, peu importe leurs besoins d'accessibilité.
• Utilisation souple : tout en mettant de l'avant un certain degré de normalisation et de compatibilité avec les diverses technologies électroniques de l'information, on doit répondre à un large éventail de préférences et de capacités individuelles.
• Utilisation simple et intuitive : on doit s'assurer que les systèmes sont faciles à comprendre et à utiliser, peu importe l'expérience, les connaissances, les capacités linguistiques ou le niveau de concentration des utilisateurs.
• Information perceptible : il faut communiquer l'information de manière efficace, peu importe les capacités physiques et/ou sensorielles de l'utilisateur, afin qu'ils puissent utiliser efficacement et confortablement cette information, avec un minimum de fatigue.

Principe d'architecture 13 : robustesse

L'infrastructure doit être robuste, adaptée et fiable, avec un degré approprié de redondance afin de prévenir toute défaillance du système.

Justification :

• le gouvernement fédéral offre de nombreux services essentiels; ces services doivent être disponibles sur demande et dans des délais très serrés, particulièrement en temps de crise;
• afin d'assurer les niveaux prévus de services opérationnels, il sera nécessaire de sous-optimiser certaines parties de l'infrastructure, en sélectionnant les technologies les plus stables qui comportent moins de fonctionnalités;
• il sera également nécessaire de sous-optimiser le coût total de possession, afin d'atteindre les niveaux voulus de services opérationnels.

Conséquences :

Le principe de robustesse présente les caractéristiques suivantes :

• la conception de l'infrastructure doit tenir compte des points probables de défaillance et prévoir des composantes redondantes et de relève.

Matrice des exigences de l'architecture fédérée et principes d'architecture

La matrice suivante présente les exigences de l'architecture fédérée et leur lien par rapport aux principes d'architecture décrits ci-dessus.

Matrice des éléments opérationnels et des principes d'architecture

La matrice ci-dessous illustre les liens entre les éléments opérationnels et les principes d'architecture.