Principes directeurs d’architecture TI

Les organisations qui choisissent d’orienter leurs efforts afin de maximiser leurs impacts en utilisant l’architecture TI élaborent généralement un ensemble de principes directeurs. Ces principes découlent eux-mêmes de la vision, de la mission et des valeurs fondamentales de l’organisation.

L’UQAM publie sa vision, sa mission et ses valeurs au grand jour. Il peut être complexe d’établir un lien entre ces énoncés à très haut niveau et des principes directeurs qui se veulent des guides concrets et faciles à interpréter. Toutefois, c’est précisément ce que nous entreprenons ci-dessous. La lecture de ces principes doit donc être accompagnée de celle des énoncés institutionnels afin d’en comprendre le sens, la portée et le raisonnement.

À quoi servent les principes directeurs?

Les principes directeurs d’architecture TI visent à offrir un cadre de référence – un guide – permettant de soutenir les efforts, les projets, les priorités ainsi que les décisions techniques d’architecture, de design ou de conception.

En lisant ces principes, il devrait devenir possible de favoriser certaines pistes de solution par rapport à d’autres.

Les principes ont été réfléchis en se basant sur l’exemple donné par quelques unes des organisations les mieux outillées au niveau architecture d’entreprise tel que le Conseil du Trésor.

Les principes directeurs

Standardisation et interopérabilité

Standardiser les éléments des systèmes d’information de façon à ce qu’ils soient interopérables, reconnus et largement utilisés au sein de l’organisation.

  • Offrir des APIs ouverts.
  • Offrir des données ouvertes.
  • Établir des standards de structure, de classification et de configuration.
  • Éviter la duplication des données, des APIs, des modèles, etc.
  • Minimiser le traitement manuel des données.

Retour sur investissement

Lorsqu’on doit en faire, maximiser la valeur du développement interne de logiciels.

  • Favoriser les projets collectifs (inter-facultaires, inter-organisationnels) avant les projets isolés à une unité.
  • Favoriser la réutilisation avant l’acquisition et l’acquisition avant le développement.
  • Prioriser la qualité de nos logiciels internes pour favoriser la réutilisabilité et l’amélioration des solutions existantes.
  • S’assurer d’avoir des responsables pour chaque application en utilisation.
  • Favoriser les projets de documentation, de nettoyage et d’évolution des systèmes en place.
  • Favoriser l’exploitation des systèmes dans leur forme technique la moins coûteuse en termes de ressources.

Les données en tant qu’actif

Traiter les données comme un actif institutionnel à part entière.

  • Identifier les propriétaires des ensembles de données utilisées.
  • Définir les sources autoritaires et assurer l’intégrité des données.
  • Rendre les données faciles à partager, faciles d’accès et faciles à trouver.
  • Utiliser des formats de stockage ouverts et accessible par des langages et interfaces standards.
  • Développer les politiques de conservation, de protection et de classification des données.
  • Créer un registre de classification des informations institutionnelles.

Couplage minimisé

Permettre le remplacement d’un élément sans devoir modifier les autres.

  • Minimiser le couplage entre les éléments en privilégiant des couches d’abstraction.
  • Assurer l’indépendance face aux systèmes d’exploitation, technologies propriétaires et caractéristiques spécifiques.
  • Assurer l’indépendance face aux fournisseurs (menottage technologique).
  • Utiliser des standards reconnus et ouverts.

Simplicité

Faire en sorte qu’il soit trivial de cerner le rôle, de planifier l’entretien et de faire usage d’une application ou d’un service.

  • Restreindre le rôle de chaque système à son utilité principale.
  • Simplifier les processus et éviter de dupliquer les façons de faire.
  • Simplifier l’entretien et l’opération des solutions.
  • Éviter les dédoublements de fonctionnalités et de données.
  • Définir des interfaces simples et conviviales.
  • Contrôler la croissance de la dette technologique.
  • Favoriser l’utilisation des composants sans état (stateless).
  • Minimiser les vérifications sans effet ou dédoublées pour faciliter les changements ultérieurs.
  • Éviter de mettre en place des éléments pour des besoins ultérieurs hypothétiques.

Logiciel libre

Lorsqu’on utilise le logiciel libre, l’utiliser de la bonne façon (contributions, éviter les forks, soumettre les changements), et promouvoir le logiciel libre.

  • Lors de l’utilisation du code source ouvert, minimiser le menottage à des licences fermées ou restrictives.
  • Favoriser les contributions de l’UQAM (code source, applications, corrections à des librairies, documentation, données, etc.) à la communauté libre.
  • Favoriser la participation de la communauté libre dans les projets de l’UQAM.

Automatisation

Réduire la charge opérationnelle qui repose sur les ressources humaines.

  • Automatiser les opérations et processus manuels.
  • Favoriser les projets ou les initiatives visant à réduire la charge opérationnelle.
  • Éviter de mettre en place des éléments qui nécessitent un entretien, une surveillance ou toute opération manuelle.
  • Automatiser tous les tests unitaires et fonctionnels.
  • Automatiser l’intégration et le déploiement (CICD).
  • Transformer les processus en code.

Disponibilité et robustesse

Maximiser la disponibilité, la résilience et la robustesse des solutions.

Disponibilité et performance :

  • Minimiser les ressources utilisées en période creuse.
  • Implanter des systèmes extensibles horizontalement selon la charge.
  • Implanter des systèmes de surveillance et de protection (applicative, d’infrastructures, etc.)
  • Implanter des systèmes réactifs qui répondent aux défaillances dès qu’elles sont détectées.

Résilience et robustesse :

  • Implanter des systèmes redondants.
  • Assurer que les responsabilités soient octroyées à des équipes et non pas à des personnes.
  • Minimiser le nombre de défaillances et le temps de rétablissement.
  • Planifier et tester les plans de recouvrement.
  • Documenter les niveaux de services et de performance pour chaque application ou service.
  • Créer des éléments sans état (stateless) lorsque possible.

Sécurité

Assurer la sécurité des systèmes et des informations.

  • Restreindre l’accès des données aux personnes autorisées.
  • Entretenir un registre des systèmes et des accès privilégiés.
  • Restreindre les surfaces d’attaques des systèmes.
  • Intégrer des mécanismes centralisés de contrôle d’accès.
  • Intégrer des mécanismes centralisés de surveillance, de journalisation et d’audit.
  • Établir des normes de sécurité et assurer leur respect.
  • Minimiser le délai nécessaire à la modification des accès.
  • Intégrer les considérations de sécurité dans l’architecture des solutions.
  • Automatiser le déploiement des mises à jour de sécurité.

Pérennité

Gérer le cycle de vie des solutions technologiques.

  • Sélectionner des technologies pérennes et des versions à support prolongé.
  • Décommissionner les technologies désuètes.
  • Identifier les coûts de support et maintenance dès la phase de sélection ou de conception d’une solution.
  • Réduire les dépendances et contrôler les versions des dépendances mises en production.
  • Suivre l’évolution et ne pas accuser de retard au niveau des produits et dépendances utilisés.

Articles au sujet des principes directeurs