Stratégie du modèle de prestation de la solution de TI cible - Rétroaction en suspens

La stratégie : cliquer ici pour consulter la stratégie à laquelle fait référence la rétroaction.

Le présent document sera mis à jour tout au long de l’élaboration de la stratégie susmentionnée.

Registre des changements

Table des matières

• 1 Objet du document
• 2 Sujets de préoccupation
  • 2.1 Prolifération des normes de TI
  • 2.2 Gestion de cette initiative stratégique jusqu’à son achèvement
  • 2.3 Supervision des changements apportés aux produits de TI (AP, GP, discrétionnaire et dette technique)
  • 2.4 Harmonisation et analyse des écarts avec les politiques et les directives (gestion des investissements et des projets)
  • 2.5 Viabilité des ensembles de compétences
  • 2.6 Risque pour le modèle de données de référence d’entreprise et la conformité à la norme
  • 2.7 Intégration du programme d’ordinateurs centraux à la stratégie
  • 2.8 Niveau législatif et délais prescrits
  • 2.9 Comment une organisation de RH appuiera-t-elle le modèle des équipes polyvalentes DevOps?
• Les annexes
  • Annexe A – Archives

1 Objet du document

Documenter les commentaires en suspens soulevés pendant l’élaboration (examen par les pairs) de la Stratégie du modèle de prestation de la solution de TI cible.

Pourquoi?

Étant donné que de nombreux intervenants participent à l’élaboration et sont touchés par la stratégie, il faut tenir compte des deux réalités suivantes :

1. une rétroaction importante risque d’être perdue durant les examens par les pairs;
2. un consensus est peu probable.

Au cours du processus d’examen par les pairs de la stratégie, les commentaires importants qui ne peuvent être traités à ce moment-là devront faire l’objet d’un suivi, de sorte à pouvoir en tenir compte dans l’élaboration continue de la stratégie. Une stratégie, ce n’est que des mots sur une page. Si les intervenants n’y adhèrent pas, les choses ne changeront pas.

Il est peu probable qu’il y ait consensus, car il faudra faire des choix pour continuer d’avancer. Ces choix peuvent être en contradiction avec la position d’un intervenant. Afin de maintenir la transparence entre les intervenants et le responsable de cette stratégie (possiblement le DPI), une liste des choix effectués sera conservée, de même que des justifications suffisantes pour les expliquer.

2 Sujets de préoccupation

2.1 Prolifération des normes de TI

2.1.1 Résumé

Le fait de permettre aux équipes DevOps de choisir leurs combinaisons de technologies vient annuler le principe des normes et pourrait favoriser la prolifération de technologies à l’échelle de l’organisation, ce qui ferait en sorte qu’il serait plus coûteux et plus risqué pour EDSC de maintenir ses activités, ses activités de maintenance et sa viabilité à long terme.

2.1.2 Points soulevés par les intervenants

• Architecture technique
• Architecture de solutions
• Architecture d’entreprise

2.1.3 Quelles sont les mesures prises pour répondre à cette préoccupation

On s’attend toujours à ce que les équipes DevOps qui choisissent leurs combinaisons de technologies fournissent un niveau d’assurance à l’égard de la maintenance à long terme des technologies sélectionnées, y compris en ce qui concerne le respect des exigences en matière de sécurité des TI et de financement. On s’attend à ce que les processus existants soient utilisés pour fournir ce niveau d’assurance. La stratégie vise à y apporter des ajustements en portant attention aux éléments suivants :

1. Les normes devraient être examinées selon deux points de vue distincts : celui des employés d'EDSC et celui du personnel des TI. Le personnel des TI a besoin des outils nécessaires pour concevoir et configurer des solutions pour les employés d'EDSC et/ou les Canadiens.


2. De nos jours, les combinaisons de technologies deviennent désuètes beaucoup plus rapidement (après environ deux ans) et nécessitent de revoir les normes beaucoup plus souvent. Ces révisions nécessitent un engagement plus important des équipes DevOps.


3. Il faut utiliser des données empiriques pour prendre des décisions, en permettant à l'équipe DevOps d'expérimenter différentes combinaisons de technologies et de les mettre à l'essai jusqu'à l'étape de la production inclusivement. Il faut surveiller leur adoption émergente et prévoir une marge de manœuvre suffisante pour les déployer à l'échelle de l'organisation.

>
4. Il faut aussi privilégier les bibliothèques de logiciels de source ouverte et les abonnements aux services de nuages publics plutôt que les licences d'utilisation de logiciels exclusifs, afin d'éviter de longues batailles en matière d'approvisionnement et de financement.

Les projets axés sur la TI continueront d’interagir avec l’équipe de l’architecture d’entreprise à l’étape de la planification afin de déterminer quels sont les investissements existants et réutilisables (p. ex., les solutions de TI) qui seront inclus dans la portée du projet de TI. La stratégie vise à offrir plus d’autonomie aux équipes DevOps dans le choix des combinaisons de technologies et l’obtention d’investissements individuels et réutilisables.

2.2 Gestion de cette initiative stratégique jusqu’à son achèvement

2.2.1 Résumé

Une fois la stratégie approuvée, qui gérera la liste des initiatives du projet et assurera la coordination et le suivi auprès des équipes respectives afin de mener à bien la stratégie?

2.2.2 Points soulevés par les intervenants

• CEI
• Stratégie de TI
• BGPDG

2.2.3 Quelles sont les mesures prises pour répondre à cette préoccupation

Envisager d’embaucher des gestionnaires de projet du Centre de ressources de la DGIIT ou de transférer l’aspect gestion des changements de la stratégie à un nouveau CE de DevOps.

2.3 Supervision des changements apportés aux produits de TI (AP, GP, discrétionnaire et dette technique)

2.3.1 Résumé

La stratégie vise à permettre d’apporter des changements aux produits de TI sans imposer aux secteurs d’activité le fardeau de franchir les étapes du cycle de vie des projets. À l’heure actuelle, on s’attend à ce que le responsable de produit gère les priorités relatives à l’arriéré d’un produit de TI qu’une équipe DevOps (avec l’aide du gestionnaire de produit) exécute.

Toutefois, si le responsable de produit appartient au secteur d’activité, il sera difficile d’assurer une gestion rapide de la dette technique en raison de sa nature technique (qu’un secteur d’activité ne serait pas en mesure de voir ou de comprendre).

De plus, même si certaines fonctions ne sont pas discrétionnaires (p. ex., les exigences juridiques), d’autres le sont (p. ex., les changements d’interface de l’utilisateur). Il faut exercer une surveillance pour assurer le suivi de l’affectation des efforts, mais on ne sait pas comment cette surveillance risquerait de créer un type de fardeau différent, quoiqu’équivalent, à celui de la création d’un projet.

2.3.2 Points soulevés par les intervenants

• Conseillers principaux
• Innovation
• BGPDG
• Stratégie de TI

2.3.3 Quelles sont les mesures prises pour répondre à cette préoccupation

Les trois principaux éléments de la stratégie qui suivent visent à répondre à cette préoccupation :

1. Formation adéquate à l’égard du rôle de responsable de produit (RP) et du lien qui existe entre ce rôle et les équipes DevOps dans le traitement de la dette technique et des exigences (discrétionnaires et non discrétionnaires). Bien que la dette technique soit un facteur important, si les équipes DevOps sont en mesure d’établir leurs propres priorités, elles sont souvent victimes de la suringénierie des produits de TI. Le RP devra probablement composer avec la dette technique pour faire place à certaines fonctionnalités. Il incombe alors aux équipes DevOps de promouvoir la valeur ajoutée que représente le remboursement de la dette technique. Les RP mettent constamment l’accent sur les fonctionnalités et c’est ce qui stimulera les équipes; il incombera à celles-ci de promouvoir que représente la réduction de la dette technique. Tous les produits de TI accumulent, dans une certaine mesure, une dette technique; il s’agit de trouver l’équilibre entre la création de valeur pour les utilisateurs et le remboursement de la dette technique. C’est pourquoi l’amélioration continue est importante et devrait être intégrée à chaque sprint, tout en s’assurant d’offrir de la valeur aux utilisateurs. On s’attend également à ce que les RP fassent la distinction entre les fonctionnalités discrétionnaires (p. ex., les changements apportés à l’interface de l’utilisateur) et non discrétionnaires (p. ex., les changements apportés à la réglementation), car ce sont eux qui, en fin de compte, assument la responsabilité de faire en sorte que les produits de TI soient conformes aux différents règlements et politiques.

2. Les architectures de couplage libre obligatoires visent à rendre les solutions globales plus souples aux changements en les décomposant en produits de TI plus petits, plus faciles à gérer et indépendants (c.‑à‑d. des produits de TI qui peuvent fonctionner de façon autonome dans un environnement de production). Consultez la stratégie d’adoption, d’achat et de conception pour en savoir plus. Par conséquent, les changements non discrétionnaires (p. ex., un changement de réglementation) devraient ne pas avoir d’incidence sur un grand nombre de produits de TI. Par exemple, les produits de TI qui sont des interfaces utilisateur (p. ex., les portails Web) ne seront pas touchés par les changements apportés à la réglementation, mais les moteurs de règles opérationnelles et les outils de traitement des demandes le seront.

3. Le passage à la planification et à la gestion des produits axées sur les capacités (c.‑à‑d. l’établissement de conditions à la réception de projets axés sur la TI en vertu desquelles les résultats et les paramètres doivent être approuvés par l’architecte en chef avant le début des travaux) devrait avoir une incidence sur la détermination des éléments auxquels il faut prêter attention. Ces éléments s’inscrivent dans les différents arriérés de produits de TI en fonction des capacités requises pour apporter les changements ou les améliorations nécessaires, afin d’atteindre les résultats souhaités mentionnés dans l’analyse de rentabilisation. L’architecture d’entreprise adopte une position stratégique en guidant les décisions d’investissement et en se dissociant de leur exécution.

2.4 Harmonisation et analyse des écarts avec les politiques et les directives (gestion des investissements et des projets)

2.4.1 Résumé

Une analyse doit être effectuée pour déterminer si ce modèle est conforme aux directives et aux politiques suivantes :

• Directive sur la gestion des projets d’EDSC (anglais seulement)
• Directive sur la gestion des programmes d’EDSC (anglais seulement)
• Politique sur la gestion des projets et des programmes (PGPP) (anglais seulement) d’EDSC
• Directive sur la gestion de projets et programmes du SCT
• Politique sur la planification et la gestion des investissements du SCT

2.4.2 Points soulevés par les intervenants

• Gouvernance de la DGIIT
• OASS
• Interopérabilité

2.4.3 Quelles sont les mesures prises pour répondre à cette préoccupation

Une analyse a commencé. L’examen préliminaire des politiques et des directives financières indique que nous respectons leurs exigences. Toutefois, des modifications devront être apportées aux normes de gestion de projet.

La Stratégie prévoit un collaborer étroitement avec les collègues de la DGDPF-GIPA pour résoudre ce problème.

2.5 Viabilité des ensembles de compétences

2.5.1 Résumé

Si les équipes DevOps sont responsables du maintien des produits de TI dont ils ont la charge dans les environnements de production; qu’elles ont le pouvoir de choisir leurs combinaisons de technologies; et qu’elles sont censées posséder des ensembles de compétences interfonctionnelles (p. ex., expérience utilisateur, sécurité et suffisamment d’expertise technique pour assurer le maintien de leurs solutions dans l’environnement de production), comment pouvons-nous atténuer le risque de roulement que pose une telle expertise pour l’équipe?

2.5.2 Point soulevé par les intervenants

• OASS

2.5.3 Quelles sont les mesures prises pour répondre à cette préoccupation

L’approche et l’intention en trois points :

1. Expertise partagée entre les membres
   On ne s’attend pas à ce qu’il y ait un seul membre responsable d’une fonction donnée au sein des équipes DevOps. C’est toujours l’équipe, dans son ensemble, qui est responsable. La stratégie met l’accent sur le recours à des champions, c.‑à‑d. que l’équipe comprend un membre particulièrement versé dans une compétence en particulier (p. ex., l’accessibilité). Le rôle du champion n’est pas d’être responsable de l’accessibilité; son rôle consiste à perfectionner les compétences de l’équipe en matière d’accessibilité. Par exemple, le champion documentera les ensembles d’outils et les approches que l’équipe utilise, ainsi que les tâches et les problèmes en suspens dans l’arriéré des produits de TI, et consignera ses constatations. Il abordera également les questions qui lui sont soumises. Grâce à cette approche, même si le champion doit quitter l’équipe, il aura transmis suffisamment de connaissances au reste de l’équipe et celle-ci pourra bénéficier d’une documentation suffisante pour régler les problèmes consignés par le champion. L’objectif sera toujours de perfectionner, de renforcer et d’améliorer les compétences de l’équipe.

2. Méritocratie et niveaux de maturité
   Les niveaux d’expertise des équipes DevOps seront différents d’un groupe à l’autre. L’approche de la méritocratie tient compte des différents niveaux de maturité des équipes et, ce faisant, du niveau de confiance que l’organisation devrait leur accorder. Nous envisageons actuellement d’adopter une approche de méritocratie qui favorise et encourage l’apprentissage continu pour les équipes DevOps.

3. Gestion du personnel
   Les détails relatifs à la gestion du personnel n’ont pas encore été définis et ce point devra être examiné de plus près. Au début, il est prévu que nous aurons des équipes interfonctionnelles (c.‑à‑d. que des membres provenant de différentes spécifications fonctionnelles seront regroupés en équipes), mais l’état cible penche plutôt vers le recours à des membres intégrés possédant un ensemble de compétences communes (un ensemble de compétences au niveau de l’équipe et non des compétences attribuées individuellement à des membres). Cet état cible diffère de notre environnement organisationnel fonctionnel actuel.

2.6 Risque pour le modèle de données de référence d’entreprise et la conformité à la norme

2.6.1 Résumé

L’adoption d’un mode de prise de décisions plus décentralisé et mieux réparti présente un risque que des décisions incorrectes soient prises et nuisent à la gestion des données à l’échelle de l’organisation. Les risques comprennent le dédoublement des données, l’incohérence pour les consommateurs de données et la dégradation de la qualité des données. Au fil des ans, la DGIIT a déployé des efforts pour centraliser certaines fonctions afin de réaliser des gains d’efficience et de pouvoir faire plus avec moins.

Dans le cas de l’équipe de l’analyse des données, l’accès direct à une base de données plutôt qu’à une IPA (l’exposition des données destinées à la consommation par une interface utilisateur ou une autre IPA fonctionnelle) est nécessaire en raison de la nature générale de l’analyse et de la nécessité d’avoir accès à une grande quantité de données. Une IPA peut être conçue, pour un produit, dans le seul but d’accéder au contenu de la base de données, mais :

1. Il est peu probable qu’un produit conçoive une IPA, car cela entraînerait des coûts supplémentaires.
2. On s’attend à ce que cela ait des répercussions sur le rendement.
3. Le nombre d’IPAs destinées à la consommation et à la reconstruction de données accroîtra la complexité des solutions d’analyse de données.

2.6.2 Point soulevé par les intervenants

• SDA

2.6.3 Quelles sont les mesures prises pour répondre à cette préoccupation

Cette préoccupation n’est pas abordée au niveau de la stratégie (politique d’orientation), mais il faudra en tenir compte dans le cadre de la mise en œuvre. Les éléments suivants doivent être pris en considération :

1. L’architecture de données nécessite peut-être trop une expertise spécialisée pour être intégrée de façon réaliste à tous les membres de l’équipe DevOps (comme le codage, la mise à l’essai et la sécurité). Par conséquent, les architectes de données seraient membres faisant partie de plusieurs équipes DevOps et conserveraient cette compétence spécialisée, particulièrement pour la modélisation de schémas d’IPA et de bases de données relationnelles. Cet élément s’inspire de la définition normalisée d’une équipe DevOps (anglais seulement) (voir la section 3. Ensemble cohérent de mesures).

2. Les produits de TI doivent être structurés selon l’idée qu’une grande quantité de certaines données peut être nécessaire pour être consommée par une fonction spécialisée (analyse de données). Les IPA actives ne fournissent pas le rendement nécessaire pour transférer une grande quantité de données. Les options peuvent consister à exporter la base de données dans l’environnement infonuagique et à analyser son contenu au moyen d’outils infonuagiques. Pour procéder à une analyse locale, nous pouvons télécharger les données à exporter par transfert électronique ou même par voie physique au moyen de dispositifs de stockage pour une très grande quantité de données (p. ex., exemple de service d’AWS (anglais seulement)).

2.7 Intégration du programme d’ordinateurs centraux à la stratégie

2.7.1 Résumé

Les programmes de l’AE et des ordinateurs centraux ne sont actuellement pas configurés pour les modes de pratique agiles et DevOps. Comment le programme d’ordinateurs centraux peut-il mettre en œuvre ces pratiques de façon réaliste?

2.7.2 Point soulevé par les intervenants

• Avantages et solutions de gestion de cas

2.7.3 Quelles sont les mesures prises pour répondre à cette préoccupation

Les réflexions actuelles portent sur les sujets suivants :

• Définir une vision de l’architecture cible pour les environnements de transition des systèmes existants. Cela permet de fournir une orientation et d’établir des attentes raisonnables pour les équipes DevOps qui travaillent dans des environnements non infonuagiques. La vision de l’architecture cible vise à fournir des architectures de référence et des exigences intégrées dans la portée des projets axés sur les TI qui touchent les programmes d’ordinateurs centraux, p. ex., une couche d’intégration pour exposer certaines fonctions et données au moyen d’IPAs accessibles au public, que d’autres solutions TI peuvent utiliser (c.‑à‑d. le « schéma en goulot d’étranglement (anglais seulement) » dont vous avez peut-être entendu parler).

• Cerner un projet pilote durant la mise en œuvre de la stratégie pour en tester la faisabilité.

2.8 Niveau législatif et délais prescrits

2.8.1 Résumé

Dans le monde de l’AE, il faut composer avec de grands projets législatifs dans le cadre desquels, conformément à l’esprit de la stratégie, les travaux commencent habituellement avant d’avoir obtenu les approbations officielles, afin d’être en mesure de respecter les délais prescrits. Néanmoins, comment cette stratégie tiendra-t-elle compte du contexte législatif dans son ensemble?

2.8.2 Point soulevé par les intervenants

• Avantages et solutions de gestion de cas

2.8.3 Quelles sont les mesures prises pour répondre à cette préoccupation

Les réflexions actuelles portent sur les sujets suivants :

• La stratégie vise à s’éloigner de la planification préalable et de l’exécution rigide du plan, et à favoriser un cycle empirique d’essai, d’observation et de correction du tir. Nous ne voulons pas improviser notre façon de livrer la marchandise. Toutefois, le processus d’établissement des points de contrôle dans le cadre du CVGP qui nous oblige à demander l’autorisation de travailler doit changer afin de nous permettre de débuter les travaux, d’évaluer nos progrès au moyen de changements techniques réels et de rajuster nos efforts de planification à partir de ces données empiriques. Par conséquent, la planification et l’établissement d’attentes à l’intention de la haute direction sont utilisés dans le cadre d’une progression tangible des changements logiciels (en apportant des modifications qui n’atteindront pas nécessairement l’environnement de production).

• La capacité de déployer des changements logiciels plus rapidement permet aux utilisateurs finaux de ressentir les modifications législatives plus rapidement (objectif 2 de la MPA : Souplesse des politiques). Nous pouvons raccourcir la boucle de rétroaction entre les Canadiens et les décideurs (ou les législateurs).

2.9 Comment une organisation de RH appuiera-t-elle le modèle des équipes polyvalentes DevOps?

2.9.1 Résumé

La stratégie fait appel à de petites équipes polyvalentes DevOps (maximum de neuf membres). Comme il s’agit d’équipes polyvalentes, les membres n’assument pas une fonction en particulier comme le codage, la mise à l’essai ou la conception de l’architecture. Tous les membres doivent posséder ces compétences et les perfectionner. Cela est différent de la composition des équipes fonctionnelles de type « matrice » que nous avons actuellement (ce sont les divisions fonctionnelles concernées qui affectent du personnel aux équipes interfonctionnelles).

2.9.2 Point soulevé par les intervenants

• RH de la DGIIT

2.9.3 Quelles sont les mesures prises pour répondre à cette préoccupation

À dét.

Les annexes

Annexe A – Archives

La présente annexe renferme une liste des préoccupations qui ont été abordées et supprimées du présent document.