L’architecture informatique cible a valeur de directive contraignante en matière d’infrastructure informatique. Elle crée les bases de l’application efficace des exigences métiers dans les systèmes informatiques. A cette fin, elle décrit, à partir de l’architecture de gestion, les niveaux de
l’architecture du système informatique (y compris l’architecture d’application et celle des don-nées) et de l’architecture technologique.
5.3.2 Délimitations
Etendue de l’architecture : l’élaboration d’une architecture informatique décrivant tous les niveaux est un travail d’envergure nécessitant beaucoup de temps. C’est pourquoi les domaines réglés et la profondeur de leur description doivent être adaptés à l’utilisation prévue du docu-ment et à l’applicabilité organisationnelle des prescriptions (maturité de la gestion de
l’architecture). Afin d’utiliser l’architecture comme base de planification de l’infrastructure in-formatique de la cyberadministration, la priorité doit être mise sur le niveau de l’architecture du système informatique ainsi que sur la détermination des produits et des technologies utilisés en relation avec les fonctions transversales importantes pour la cyberadministration (cf. Services, chap. 2.2).
Environnement-cadre architectural : la structure adoptée ici en différents niveaux d’architecture (de gestion, d’application, des données et technologique) est conforme à l’environnement-cadre TOGAF (The Open Group Architecture Framework, Version 8.1, « Enter-prise Edition ») [57]. TOGAF est le standard architectural de l’administration fédérale [58]. Il n’existe pas encore de norme eCH en matière d’environnement-cadre architectural. Il ressort toutefois de travaux préliminaires et des connaissances acquises à ce jour que l’utilisation d’un autre environnement-cadre que TOGAF, en particulier de ceux indiqués ci-après, peut présenter des avantages :
- t-eam (toolbox for enterprise architecture management) de la société Act![59] ;
- FEA (Federal Enterprise Architecture Program, FEA Consolidated Reference Model, version 2.3, octobre 2007)[60] ;
- Zachmann Framework for Enterprise Architecture [61].
5.3.3 Contenu
Architecture informatique cible 0 Condensé
1 Contexte
Décrire le but de l’architecture informatique cible et le contexte (structure des volumes, produits et technologies des systèmes informatiques existants) dans le champ d’application de
l’architecture. Formuler les objectifs visés par l’architecture. Définir l’environnement-cadre archi-tectural à utiliser.
2 Exigences relatives à l’architecture informatique cible
Décrire les conditions-cadres déterminantes sur les plans informatique, juridique (p. ex. principe de la transparence, protection des données, archivage, sites sans barrières) et technique. Ren-voyer aux principes fondamentaux sur lesquels l’architecture repose (p. ex. architecture multiniveau, architecture orientée service).
3 Architecture de gestion
Décrire la structure des activités de gestion des affaires de l’administration concernée par l’architecture (prestations de service public / produits / processus et organisation structurelle).
Modèle de structure : cf. eCH-0075 [62].
4 Architecture d’application
Vise la standardisation des produits logiciels. A cette fin, catégoriser les applications du point de vue fonctionnel. Il est possible de prévoir une structure distinguant des fonctions ou applications transversales, spécialisées et de support. Désigner les produits standard pour chaque fonction.
5 Architecture des données
Vise la standardisation du stockage des données. A cette fin, décrire les données qui sont gérées de façon centralisée et sont accessibles aux applications et celles qui sont stockées de façon décentralisée dans chaque application. Désigner les formats de données pris en charge pour les échanges de données (référence à SAGA.ch, messages eCH, sedex).
6 Architecture technologique
Vise la standardisation des plateformes technologiques. A cet effet, désigner les canaux d’accès (p. ex. navigateur, Citrix-Client, Thin-Java-Client), les protocoles (p. ex. http V1.1), les plateformes (p. ex. J2EE, .Net), les systèmes d’exploitation pour serveurs (MS Windows Server 2003) et clients (p. ex. MS Windows XP, Linux) et les systèmes de base de données (p. ex. MySQL, MS SQL, Ora-cle) pris en charge. Désigner aussi les protocoles de communication pris en charge pour les échanges de données (référence à SAGA.ch).
7 Sécurité
Décrire l’application des exigences de sécurité dans l’architecture. Inclut les mesures de protec-tion contre les accès non autorisés (p. ex. concept de zones, identificaprotec-tion et autorisaprotec-tion) et contre les pertes de données (p. ex. disponibilité, protection contre les pannes de système).
8 Mise en œuvre
Décrire les principales étapes de réalisation menant de l’architecture informatique actuelle à l’architecture cible, les règles de mise à jour ultérieure de l’architecture et les procédures de controlling de projet (examen de la conformité de l’architecture).
9 Annexe
Bibliographie, glossaire
5.3.4 Marche à suivre
• Analyse et planification de l’élaboration de l’architecture : recenser les besoins de standardisation et planifier celle-ci en allant du général au particulier. Il s’agit notamment:
- d’établir la grille des contenus de l’architecture informatique cible en fonction de l’environnement-cadre architectural choisi, en indiquant également les domaines à ré-gler ;
- de faire l’inventaire des normes existantes et de les classer dans l’environnement-cadre ;
- de recenser les besoins de réglementation et de fixer les priorités en ce qui concerne les domaines de standardisation à traiter ;
- de planifier l’élaboration de l’architecture et d’estimer les ressources nécessaires et le ca-lendrier ;
- d’établir un mandat de travail avec planification de la marche à suivre et de désigner les personnes et les organes impliqués.
• Description de l’architecture de gestion : décrire l’administration entrant dans le champ d’application de l’architecture (organisation structurelle), son domaine d’activité et la struc-ture de celui-ci (p. ex. groupes de produits, produits ou processus de gestion, processus clés et processus de support). Décrire aussi des modèles de conception des processus métiers, prévoyant par exemple la séparation de la distribution (front-office) et de la production (back-office).
• Détermination de l’architecture technologique : analyser l’éventail des technologies disponibles. Evaluer les normes technologiques dans la perspective de la consolidation du paysage applicatif (assurer l’exploitation au moyen d’un petit nombre de technologies d’avenir interopérables). Evaluer aussi les normes technologiques prévues quant à leurs ef-fets sur l’architecture d’application (produits logiciels utilisés) et sur l’organisation de l’exploitation informatique.
• Détermination de l’architecture d’application : définir les fonctions informatiques néces-saires en évitant tout recoupement et fixer pour chaque fonction un standard reposant sur un nombre d’applications aussi réduit que possible. Il est utile à cet effet de procéder à une subdivision en applications transversales, spécialisées et de support :
- les applications transversales couvrent des fonctions assurées avec le même produit dans toute l’administration (p. ex. gestion centralisée des utilisateurs et des droits d’accès au moyen de Sun Identity / Accessmanager) ;
- les applications spécialisées prennent en charge des fonctions assurées presque exclusi-vement dans une seule unité administrative (p. ex. cadastre du bruit routier). Elles doivent exploiter les fonctions transversales existantes et non les assurer elles-mêmes (p.
ex. utiliser la gestion centralisée des utilisateurs et des droits d’accès et non se doter de leur propre gestion des utilisateurs, ou encore recourir au système de gestion des docu-ments à la disposition de toute l’administration et non archiver les docudocu-ments dans l’application elle-même). De plus, les applications spécialisées ne doivent prendre en charge que les bases de données, les systèmes d’exploitation, les protocoles, etc. de l’architecture technologique adoptée, à l’exclusion de tout autre ;
- les applications de support concernent des fonctions assurées dans toute l’administration au moyen de programmes prêts à l’emploi (p. ex. traitement d’images, navigation sur le web) ou des services web simples.
• Détermination de l’architecture des données : choisir les normes de description de mo-dèles de données. Déterminer quelles données doivent être gérées de façon centralisée et lesquelles de façon décentralisée et fixer les principes applicables en la matière (p. ex. actua-lité, compétence, mise à jour). Fixer les formats de données pris en charge.
• Description des exigences de sécurité : recenser les prescriptions à respecter en matière de sécurité et en vérifier l’applicabilité dans l’architecture informatique cible. Si nécessaire, modifier en conséquence l’architecture de gestion, l’architecture d’application, l’architecture technologique et l’architecture des données. Décrire les mesures de protection contre les ac-cès non autorisés et les pertes de données.
• Planification de la mise en œuvre : décrire les principales étapes de réalisation menant de l’architecture informatique actuelle à l’architecture cible et renvoyer aux instruments de ges-tion à utiliser (p. ex. feuille de route et portefeuille de projets relatifs à l’infrastructure informatique). Décrire aussi le processus de gestion de l’architecture. Assurer la mise en œu-vre de l’architecture par le controlling de projet (vérifier la conformité de la proposition et du concept d’architecture).
• Revue et approbation : soumettre l’architecture à l’organe décisionnel pour acceptation.
Assurer la communication relative à l’architecture.
5.4 Elaboration du portefeuille de projets