La présente section aborde diverses possibilités et considérations associées à l’entretien permanent de l’architecture régionale des STI. Cela inclut la définition détaillée des responsabilités et des procédures qui doivent être prises en considération quand une architecture est utilisée et entretenue au fil des ans. Il faut bien comprendre que l’architecture régionale des STI n’est pas un ensemble statique d’extrants. Elle doit s’adapter à mesure que les plans changent, que les projets de STI sont mis en oeuvre et que les besoins et les services se développent dans la région.

À la manière des STI qui requièrent une planification de l’exploitation et de l’entretien, un plan doit être mis en place durant l’élaboration initiale de l’architecture régionale des STI afin de la maintenir à jour.

Étape 6: Entretien d’une architecture régionale des STI

Établir les responsabilités liées à l’entretien
Définir la base de référence de l’architecture
Définir le processus de gestion du changement
Élaborer un plan d’entretien de l’architecture
Entretenir l’architecture conformément au plan

Objectifs

Élaborer et mettre en oeuvre des procédures et des responsabilités afin d’entretenir une architecture des STI dans la région

Processus - Principales activités

Établir les responsabilités liées à l’entretien : Quel individu ou quel groupe d’individus sera responsable de l’entretien de l’architecture? Qui soutiendra le travail? Qui gérera ou surveillera le travail de l’entretien?
Définir la base de référence de l’architecture : Quels extrants ou quels documents seront conservés? Conserverez-vous seulement les bases de données ou les représentations graphiques de l’architecture?
Définir le processus de gestion du changement : Comment les changements seront apportés et par qui? À quelle fréquence des modifications seront-elles apportées à la base de référence de l’architecture? Qui déterminera les changements à inclure dans la base de référence? Quel groupe examinera les changements recommandés et décidera quels changements sont acceptés ou non? Qui modifiera la base de référence de l’architecture?
Élaborer un plan d’entretien de l’architecture : Ce plan documentera le processus et fournira un cadre de travail pour les activités d’entretien de l’architecture
Entretenir l’architecture conformément au plan : Déterminer, analyser, approuver, incorporer et communiquer les changements apportés à la base de référence de l’architecture conformément au plan; améliorer le plan au fil du temps pour qu’il continue de refléter avec précision le processus d’entretien de l’architecture dans la région

Intrants - Sources d'information

Plus récente version approuvée de l’architecture régionale des STI

Extrant - Résultats du processus

Plan d’entretien de l’architecture
Données de base sur l’architecture mises à jour

L’architecture régionale des STI est décrite par un ensemble d’extrants décrits de la section 3 à la section 6 du présent document d’orientation. Ces sections ont suggéré un processus pour créer l’ensemble original d’extrants qui représentent l’architecture régionale des STI. La section 8 examine le processus d’entretien de l’architecture. Ce processus est vraiment un processus d’amélioration continue qui évolue avec la région, à mesure que les intervenants utilisent l’architecture et que les besoins de la région augmentent et changent, guidés par les principes du contrôle de la configuration et de la gestion du changement. Certains aspects clés du processus abordés plus en détail ci-dessous sont les suivants :

Comprendre pourquoi l’architecture doit être entretenue
Établir les responsabilités liées à l’entretien
Définir la base de référence de l’architecture
Définir le processus de gestion du changement
Documenter le processus dans un plan d’entretien

À mesure que les projets de STI sont mis en oeuvre, l’architecture régionale des STI devra être mise à jour afin de refléter les nouvelles priorités STI et les stratégies issues du processus de planification du transport, pour rendre compte également de la portée des STI et tenir compte de l’évolution et de l’incorporation des nouvelles idées. Un processus d’entretien devrait être détaillé en fonction de la région et utilisé pour mettre à jour l’architecture régionale des STI. Il devrait être documenté dans un plan d’entretien en tant que partie intégrante de l’élaboration initiale de l’architecture. Le but du plan d’entretien est d’orienter les mises à jour contrôlées qui seront apportées à la base de référence de l’architecture régionale des STI pour que le plan puisse continuer de refléter avec précision les capacités STI existantes de la région et les plans futurs.

Veuillez noter que le processus d’entretien de l’architecture couvert dans le présent document s’applique à un vaste éventail d’élaborations d’architectures régionales et provinciales des STI. Chaque travail d’élaboration d’une architecture des STI devra s’adapter au processus afin de répondre aux besoins et aux ressources requises dans sa région particulière.

Haut de la page

8.1 Raisons de l’entretien d’une architecture régionale des STI

Toute architecture régionale des STI n’est pas statique; elle s’adapte à mesure que les plans changent, que les projets de STI sont mis en oeuvre et que les besoins et les services se développent dans la région. Une architecture régionale des STI doit être entretenue pour pouvoir refléter les STI existants et prévus, les interconnexions et d’autres aspects de l’architecture. Voici des événements qui peuvent apporter des changements dans une architecture régionale des STI.

Changements dans les besoins régionaux : Une architecture régionale des STI est créée pour soutenir la planification du transport qui vise à répondre à des besoins régionaux. Au fil du temps, ces besoins peuvent changer, et les aspects correspondants de l’architecture régionale des STI conçus pour satisfaire à ces besoins doivent alors être mis à jour. Ces changements dans les besoins doivent être exprimés dans les mises à jour apportées aux documents de planification, comme le plan stratégique des STI.
Nouveaux intervenants : De nouveaux intervenants participent au déploiement des STI, et l’architecture régionale des STI doit être mise à jour pour refléter leur présence dans la perspective régionale des composants STI, des interfaces et des flux d’information. Pourquoi des intervenants émergent-ils? Parce qu’ils pourraient représenter des organisations qui n’étaient pas en place au moment de l’élaboration initiale de l’architecture régionale des STI. Ou parce que la portée géographique de l’architecture s’accroît et touche un plus grand bassin d’intervenants. Ou encore parce que des modes ou des services additionnels de transport sont pris en considération et font interface avec les systèmes d’autres intervenants.
Changements dans l’étendue des services envisagés : La gamme des services envisagés par l’architecture régionale des STI s’accroît, peut-être parce que l’architecture des STI pour le Canada a été étendue pour inclure de nouveaux services aux utilisateurs ou pour mieux définir la manière dont les composants STI existants peuvent fournir les services aux utilisateurs. À chaque mise à jour, une architecture régionale des STI fondée sur une ancienne version de l’architecture des STI pour le Canada devrait prendre en considération ces changements. L’architecture des STI pour le Canada pourrait avoir été étendue pour inclure un service aux utilisateurs qui a été discuté dans la région, mais qui n’est pas inclus dans l’architecture régionale des STI ou qui y a été inclus, mais seulement de manière superficielle. En eux-mêmes, les changements apportés à l’architecture des STI pour le Canada ne constituent pas une raison de mettre à jour une architecture régionale des STI. Toutefois, une région pourrait vouloir tenir compte de tous les nouveaux services dans le contexte de la satisfaction de ses besoins.
L’architecture des STI pour le Canada et le logiciel Turbo Architecture ne sont pas mis à jour selon un calendrier fixe, mais à partir du processus de contrôle de la configuration des programmes qui examine les intrants des intervenants et qui travaille avec USDOT pour déterminer quand les mises à jour devraient avoir lieu. Les mises à jour apportées à l’architecture des STI pour le Canada et à Turbo Architecture sont affichées sur le site Web de Transports Canada à l’adresse http://www.tc.gc.ca/innovation/sti/fra/architecture.htm.

Changements dans les noms des intervenants ou des composants : Le nom d’un organisme ou le nom utilisé pour décrire son ou ses composants change. Des sociétés de transport peuvent fusionner, se fractionner ou choisir simplement un nouveau nom. Aussi, les noms des composants peuvent changer à mesure que les projets se précisent. L’architecture régionale des STI doit être mise à jour pour pouvoir utiliser correctement les noms des intervenants et des composants.
Changements dans d’autres architectures : Une architecture régionale des STI couvre non seulement les composants et les interfaces à l’intérieur d’une région, mais aussi des interfaces et des composants des régions avoisinantes. Des changements apportés à l’architecture des STI dans une région peuvent amener des changements dans l’architecture d’une région voisine afin de conserver la cohérence entre les deux architectures. Des architectures peuvent aussi se chevaucher (par exemple, une architecture provinciale des STI et une architecture régionale des STI dans la même province), de sorte qu’un changement dans une architecture nécessite un changement dans l’autre.

Il existe des changements relatifs à la définition des projets qui conduisent au besoin d’apporter des mises à jour à l’architecture régionale des STI.

Changements dus à la définition ou à la mise en oeuvre d’un projet : Au moment où il est défini ou mis en oeuvre, un projet peut ajouter, soustraire ou modifier des composants, des interfaces ou des flux d’information résultant d’une architecture régionale des STI. Puisqu’elle est conçue pour décrire la mise en oeuvre actuelle et future des STI dans une région, l’architecture régionale des STI doit être mise à jour de manière à refléter l’intégration des projets élaborés dans la région.
Changements dus à l’ajout ou à la suppression d’un projet : Il peut arriver qu’un projet soit ajouté durant le processus de planification ou supprimé lors de sa réalisation. Aussi, certains aspects de l’architecture régionale des STI associés au projet peuvent être étendus, modifiés ou supprimés.
Changements à la priorité des projets : En raison de contraintes financières ou d’autres considérations, la séquence prévue des projets peut changer. Le retard d’un projet peut avoir un effet d’entraînement sur d’autres projets qui en dépendent. Le devancement ou le retard de la mise en oeuvre d’un projet peut influer sur les autres projets qui lui sont reliés.

Toutes ces raisons d’apporter des changements à la base de référence de l’architecture régionale des STI se posent souvent ou rarement, tout dépendant de la région et des caractéristiques propres au travail d’élaboration de l’architecture. Elles devraient être prises en considération en tant qu’ensemble de facteurs, quand vient le temps d’établir la fréquence des mises à jour de l’architecture.

8.2 Décisions relatives à l’entretien

Le but de l’entretien d’une architecture régionale des STI est de la garder actuelle et pertinente pour que les intervenants puissent l’utiliser comme référence technique et institutionnelle quand ils élaborent des plans de projets de STI. Une caractéristique clé d’une architecture régionale des STI réussie est le consensus, c’est-à-dire la notion selon laquelle chaque intervenant a adhéré et continue d’adhérer à l’architecture en tant que modèle de la manière dont les composants STI ont été déployés dans une région et, plus important encore, de la manière dont ils devraient l’être.

Chaque décision relative à l’entretien dont il est question dans la présente section contribue à garder l’architecture régionale des STI pertinente à l’égard de la planification des STI et du déploiement des projets de STI, à mesure que les ressources deviennent disponibles. Les conditions dans une région changent naturellement. Un processus d’entretien efficace d’une architecture régionale des STI se développera pour refléter ces conditions changeantes et maintenir le consensus caractéristique selon lequel les intervenants trouvent l’architecture pertinente et utile.

Les décisions dont il sera question sont les suivantes :

Qui : Qui entretiendra l’architecture régionale des STI?
Quand : Quand l’architecture régionale des STI sera-t-elle mise à jour?
Quoi : Quelles parties de l’architecture régionale des STI seront mises à jour?

8.2.1 Qui entretiendra l’architecture régionale des STI?

Qui dirigera et mettra en oeuvre le travail d’entretien de l’architecture? C’est une des décisions les plus importantes relativement à l’entretien d’une architecture régionale des STI. Pour entretenir une architecture régionale des STI consensuelle, dans une certaine mesure, tous les intervenants devront y participer. Mais, en règle générale, un ou deux organismes assumeront la responsabilité d’entretenir l’architecture.

Garde Un concept important est le suivant : la responsabilité de l’entretien de l’architecture ne doit pas être déléguée à une personne, mais plutôt à un organisme ou à un groupe institutionnel de la région.

Il se peut qu’un individu soit ou ait été un champion dans l’élaboration d’une architecture régionale des STI, et c’est tant mieux. Cependant, l’entretien est un effort récurrent et à long terme. La responsabilité pourrait être déléguée à un individu à un moment donné, mais la responsabilité globale devrait être confiée à une institution ou à un organisme de la région. Ainsi, la responsabilité transcende la variabilité qui peut influer sur les activités et la carrière d’un individu. Parfois, cette responsabilité est partagée entre organismes.

Questions à se poser au moment de déterminer qui entretiendra l’architecture

Deux questions cruciales se posent lorsqu’il faut choisir l’organisme responsable de l’entretien de l’architecture régionale des STI.

L’organisme a-t-il les compétences et les ressources requises pour entretenir l’architecture régionale des STI?
L’entretien d’une architecture régionale des STI requiert un éventail de compétences. Pour évaluer adéquatement les changements apportés à l’architecture, l’organisme responsable de son entretien doit disposer d’un personnel qui connaît bien l’architecture existante, c’est-à-dire qui a une compréhension technique approfondie des différentes composantes de l’architecture et de la manière dont les changements influent sur chaque composante. En outre, le personnel affecté à l’entretien de l’architecture doit comprendre les systèmes de transport dans la région, bien que les divers organismes et intervenants qui participent au processus d’entretien les comprennent bien aussi. Le personnel de l’organisme responsable de l’entretien doit aussi comprendre les outils utilisés pour créer et mettre à jour l’architecture. Cela pourrait inclure, par exemple, la connaissance du logiciel Turbo Architecture, s’il est utilisé pour conserver des renseignements sur l’architecture. L’organisme responsable de l’entretien de l’architecture doit déjà avoir ces compétences ou les acquérir. Dans un cas comme dans l’autre, il a besoin d’un financement adéquat pour soutenir son travail d’entretien.

Disposer des ressources requises pour entretenir une architecture régionale des STI pourrait vouloir dire que les intervenants qui l’utilisent doivent partager les coûts d’acquisition de ces ressources, même si un organisme en particulier peut s’être engagé à avoir le personnel ou à obtenir les compétences nécessaires par contrat.
L’organisme qui entretient l’architecture régionale des STI a-t-il la mission et le pouvoir de maintenir la portée fonctionnelle de l’architecture?
Idéalement, l’organisme qui entretient une architecture régionale des STI assume de grandes responsabilités fonctionnelles à travers la portée complète de l’architecture. Dans ce cas, la « portée » représente la zone géographique de la région, les fonctions de transport dans la région, ainsi que le calendrier du déploiement des nouveaux composants STI et des interfaces dans la région.

Parmi les organismes pouvant assurer la responsabilité de l’entretien de l’architecture régionale des STI, mentionnons ceux-ci :

Ministères provinciaux des Transports : Un ministère provincial des Transports pourrait assumer les responsabilités liées à l’entretien de l’architecture régionale des STI. Cette approche est pertinente dans des régions rurales, où les fonctions STI relèvent largement de la responsabilité du ministère provincial des Transports. Mais elle peut s’appliquer à d’autres régions qui disposent de ressources limitées dans l’organisation de la planification.
Sociétés de transport : Ces organisations gèrent une infrastructure de transport à l’aide d’un modèle de gestion qui pourrait être indépendant d’autres organismes.
Comités régionaux des STI : Dans certaines régions, ces groupes institutionnels prennent des décisions au sujet de l’intégration, des questions relatives aux STI, de l’exploitation ou de l’approvisionnement.

Quand un organisme est responsable de l’entretien de l’architecture régionale des STI, il peut recourir à des ententes pour créer une fonction de gestion ou de surveillance, comme un « Comité de l’entretien de l’architecture régionale des STI » ou un « Conseil sur l’entretien de l’architecture régionale des STI ». Ainsi, l’organisme peut superviser le travail d’entretien de l’architecture, qui pourrait être exécuté par des intervenants. Ce groupe pourrait avoir obtenu l’autorité de gestion du processus d’entretien. De la sorte, les intervenants participent à leur propre architecture régionale des STI, la contrôlent et sont directement responsables de la qualité du produit.

Quel groupe aidera l’organisme responsable de l’entretien dans l’évaluation et l’approbation des changements?

Il faut également déterminer qui soutiendra l’organisme responsable de l’entretien de l’architecture régionale des STI dans l’évaluation et l’approbation des changements qui seront apportés. Ce devrait être un groupe de représentants d’intervenants clés, idéalement d’organismes responsables de la circulation routière, de sociétés de transport ou d’organismes responsables de la sécurité routière. Ce groupe pourrait provenir d’un comité ou d’un organisme regroupant des intervenants clés dans l’élaboration de l’architecture, ou être récemment constitué, ou encore prendre la forme d’un comité régional des STI. Peu importe leur nom, ces entités ont un trait commun : elles réunissent souvent des représentants techniques et des gestionnaires des principales sociétés de transport de la région.

Le groupe responsable de l’évaluation et de l’approbation des changements apportés à l’architecture régionale des STI pourrait avoir un certain pouvoir de coordination pour l’intégration des systèmes dans la région. Toutefois, il n’est pas nécessaire que le groupe ait une autorisation légale ou un pouvoir de passation des marchés, puisqu’il sert surtout de moyen d’atteindre des consensus.

Haut de la page

8.2.2 Quand l’architecture régionale des STI sera-t-elle mise à jour?

Une façon de savoir quand l’architecture régionale des STI sera mise à jour est d’établir un calendrier des mises à jour ou des changements à apporter à l’architecture. Aucun calendrier ne peut s’appliquer à toutes les régions. L’établissement du calendrier dépendra de divers facteurs tels que la manière dont l’architecture est utilisée, le financement ou la dotation en personnel pour l’exécution des tâches.

À quelle fréquence l’architecture régionale des STI sera-t-elle modifiée ou mise à jour? À cet égard, il existe deux approches fondamentales, chacune ayant ses avantages et ses inconvénients : l’entretien périodique et l’entretien d’exception. Ces deux approches ne sont pas absolument exclusives. Une troisième approche pourrait être élaborée en tant que combinaison des deux autres.

Entretien périodique : Cette approche lie l’entretien de l’architecture régionale des STI à l’une des activités récurrentes du processus de planification du transport. Par exemple, il est naturel que l’architecture soit mise à jour à la même fréquence que le plan de transport régional ou que le programme de planification des immobilisations est mis à jour. La mise à jour de l’architecture pourrait survenir avant ou après la mise à jour du document de planification du transport. Si la mise à jour de l’architecture précède celle du document de planification, l’architecture révisée pourrait servir d’intrant à la mise à jour de la planification. L’inconvénient de cette approche est que les changements à l’appui des projets de STI pourraient ne pas être mis à jour au moment opportun dans l’architecture régionale des STI. Les coûts de publication et de contrôle des versions sont minimisés avec l’approche de l’entretien périodique, puisqu’il y a une nouvelle version seulement une fois dans le cycle d’entretien.
Entretien d’exception : Cette approche permet d’apporter des changements à l’architecture régionale des STI dans un processus entrepris selon les besoins. Les coûts de publication et de contrôle des versions dépendent de la fréquence à laquelle ces changements sont apportés.
Entretien périodique et entretien d’exception combinés : Cette approche est celle qui répond le mieux aux besoins des intervenants et peut-être celle qui a le plus de chances de succès relativement à l’usage de l’architecture régionale des STI. Cependant, elle est la plus coûteuse. Les demandes particulières des intervenants sont réparties immédiatement. Un processus d’analyse plus approfondi est mis en application périodiquement afin de découvrir et d’incorporer de nouvelles exigences relatives aux STI.

Nous venons d’aborder la fréquence à laquelle l’architecture régionale des STI est mise à jour. La question de savoir si la mise à jour de la base de référence de l’architecture doit être partielle (c’est-à-dire impliquer des changements graduels) ou complète est abordée à la section 8.3.1 (voir la page 161).

8.2.3 Quelles parties de l’architecture régionale des STI seront mises à jour?

Quels aspects de l’architecture régionale des STI seront entretenus? Les parties constituantes d’une architecture régionale des STI qui seront mises à jour sont désignées comme étant la « base de référence » de l’architecture. Dans la présente section, nous examinerons les différentes « parties » de l’architecture régionale des STI et détermineront si elles font partie de la base de référence.

Un des avantages d’une architecture régionale des STI est de permettre un échange efficace d’information entre des composants STI dans une région et des composants à l’extérieur de la région. L’efficacité fait référence au déploiement économique des composants STI et de leurs interfaces. Le résultat des divers déploiements de STI devrait être une contribution au fonctionnement sécuritaire et efficient du réseau de transport de surface. Chacune des parties constituantes d’une architecture régionale des STI décrite ci-dessous joue un rôle dans cette économie, et des efforts appropriés doivent être déployés pour les entretenir.

Description de la région
Cette description inclut l’étendue géographique, la portée fonctionnelle et le calendrier de l’architecture; elle aide à encadrer chacune des parties constituantes d’une architecture régionale des STI. L’étendue géographique définit les composants STI « dans » la région, quoique d’autres composants STI extérieurs à la région puissent être nécessaires pour déterminer s’ils communiquent des renseignements aux composants intrinsèques à la région. La portée fonctionnelle définit les services inclus dans une architecture régionale des STI. Le calendrier de l’architecture est le nombre d’années dont elle tiendra compte. La description de la région est habituellement incluse dans la documentation relative à l’architecture. Elle peut aussi se trouver dans une base de données qui contient les aspects de l’architecture. En tout temps, elle doit être considérée comme faisant partie intégrante de la base de référence de l’architecture.

Liste des intervenants
Les intervenants sont essentiels à la définition d’une architecture des STI. À l’intérieur de la région, ils peuvent se regrouper ou s’isoler, et tous les changements qui les touchent doivent être reflétés dans l’architecture. Aussi, les intervenants qui ne se sont pas mobilisés par le passé pourraient être sollicités pour s’assurer que l’architecture représente également leurs exigences. La liste et le profil des intervenants devraient être inclus dans la documentation relative à l’architecture et pourraient se trouver dans une base de données qui contient les aspects de l’architecture. Ils doivent être considérés comme faisant partie intégrante de la base de référence de l’architecture.

Concepts d’exploitation
Il est crucial que le ou les concepts d’exploitation (qui pourraient être représentés sous la forme de rôles et de responsabilités ou sous la forme d’ensembles personnalisés de solutions applicatives), qui sont inclus dans une architecture régionale des STI, représentent la vision consensuelle de la manière dont les intervenants souhaitent que leurs STI fonctionnent dans l’intérêt des usagers du transport de surface. Les concepts d’exploitation devraient être examinés et, au besoin, modifiés pour représenter à la fois ce qui a été déployé (ou ce qui apparaissait comme étant « prévu » dans une version antérieure de l’architecture régionale des STI) et la perspective consensuelle actuelle des intervenants. Beaucoup d’activités d’entretien restantes dépendront du résultat des changements apportés. Le ou les concepts d’exploitation seront inclus dans la documentation relative à l’architecture et peut-être dans un générateur d’organigrammes, si l’approche des ensembles personnalisés de solutions applicatives est utilisée. Les concepts d’exploitation doivent être considérés comme faisant partie intégrante de la base de référence de l’architecture.

Liste des composants STI
L’inventaire des composants STI est un élément clé de toute architecture régionale des STI. Les changements dans la liste des intervenants et dans les concepts d’exploitation peuvent influer sur les composants STI. Aussi, la mise en place récente de composants STI pourrait avoir changé leur état (par exemple, en les faisant passer de l’état de composants prévus à celui de composants existants). La liste des composants STI est souvent incluse dans la documentation et les bases de données relatives à l’architecture régionale des STI. Elle fait partie intégrante de sa base de référence.

Liste des ententes
Une des plus grandes valeurs d’une architecture régionale des STI est d’établir où l’information va au-delà des limites d’un organisme, ce qui indique le besoin de conclure un ou des ententes interorganismes. Une mise à jour de la liste des ententes peut suivre une mise à jour du ou des concepts d’exploitation ou des interfaces entre les composants. La liste des ententes se trouve habituellement dans la documentation relative à l’architecture. Elle doit être considérée comme faisant partie intégrante de la base de référence de l’architecture.

Interfaces entre les composants (interconnexions et flux d’information)
Les interfaces entre les composants définissent l’information « détaillée » sur l’architecture régionale des STI. Elles décrivent comment les divers systèmes de transport intelligents sont ou seront mis en oeuvre durant le calendrier de l’architecture. Cette information se trouve généralement dans une base de données de l’architecture. Elle constitue un des aspects fondamentaux de la base de référence de l’architecture, celui qui a le plus de chances de nécessiter le plus grand nombre de changements durant le processus d’entretien.

Exigences fonctionnelles relatives aux systèmes
Des fonctions de niveau élevé sont attribuées aux composants STI. Ces fonctions, qui font partie intégrante de toute architecture régionale des STI, peuvent servir de point de départ pour la définition fonctionnelle des projets qui correspondent aux parties de l’architecture. En raison de leur niveau de détail, les exigences fonctionnelles sont généralement représentées sous la forme de feuilles de calcul électronique ou incluses dans des bases de données. Elles peuvent aussi se trouver dans la documentation relative à l’architecture. Les exigences fonctionnelles relatives aux systèmes font partie intégrante de la base de référence de l’architecture régionale des STI.

Normes STI applicables
La sélection des normes STI dépend largement des exigences en matière d’échange d’information. À mesure que les projets sont mis en oeuvre et qu’elles sont choisies en fonction de ces projets, les normes STI doivent se refléter dans l’architecture régionale des STI pour que d’autres projets puissent en bénéficier. En outre, le processus d’entretien doit examiner comment les normes STI peuvent s’être développées depuis la plus récente mise à jour et comment tout changement dans « l’environnement des normes » pourrait avoir influé sur les choix précédents de normes régionales, en particulier lorsque des normes concurrentes existent. Par exemple, si des normes « centre à centre » fondées sur le langage XML atteignent un niveau élevé de maturité, de fiabilité et de rapport coût-efficacité, une décision régionale pourrait être prise d’investir dans d’autres technologies standard (par exemple, de passer à une architecture CORBA). La description de l’environnement des normes dans la région, ainsi que l’information détaillée sur les normes qui s’appliquent à l’architecture régionale des STI doivent faire partie intégrante de la base de référence de l’architecture.

Séquence des projets
La séquence des projets est en partie déterminée par l’interdépendance fonctionnelle. Par exemple, la surveillance de la circulation doit précéder la gestion de la circulation. Cela dit, la plupart des séquences de projets relèvent de décisions locales. Vous devez examiner votre séquence de projets pour vous assurer qu’elle est compatible avec les décisions locales. De même, informez les décideurs sur cette séquence et obtenez leurs commentaires afin de l’harmoniser avec leurs propres attentes. Cette communication et cette rétroaction sont essentielles pour que l’architecture régionale des STI demeure toujours pertinente. La séquence des projets doit être incluse dans la documentation relative à l’architecture. Elle peut aussi être représentée sous la forme de feuilles de calcul électronique ou incluse dans une base de données. Elle doit aussi faire partie intégrante de la base de référence de l’architecture.

Suggestions En plus des parties constituantes de l’architecture régionale des STI dont il vient d’être question, documentez les ressources qui ont été utilisées tout au long de l’élaboration de l’architecture. Documentez également toutes les autres ressources – leurs titres, les dates de leur publication ou leurs versions et leur emplacement. Ainsi, les futurs organismes responsables de l’entretien de l’architecture seront en mesure de mieux comprendre le contexte dans lequel l’architecture a été élaborée. Gardez toujours à l’esprit que les changements apportés à ces documents peuvent influer sur l’architecture.

Haut de la page

8.3 Processus d’entretien

La présente section décrit le processus d’entretien d’une architecture régionale des STI, qui repose sur la discipline plus générale appelée « gestion de la configuration ». La section présente d’abord un résumé de la gestion de la configuration. Elle décrit ensuite le processus d’entretien d’une architecture régionale des STI et établit les liens entre la discipline générale et son application particulière aux fins de cet entretien. Le processus décrit ici est un processus suggéré ou un exemple qui peut s’appliquer à l’entretien de toute architecture régionale des STI, mais que vous devez personnaliser selon la taille et la portée de votre propre architecture. Le processus présenté doit également être adapté pour correspondre aux processus de planification du transport dans votre région (par exemple, au processus de mise à jour du plan de transport régional).

Aperçu de la gestion de la configuration

La gestion de la configuration est un processus visant à définir et à maintenir la cohérence dans le rendement d’un système, dans ses éléments fonctionnels et physiques, ses exigences et la diffusion de son information durant tout son cycle de vie. Dans le contexte de l’architecture régionale des STI, la gestion de la configuration est un processus d’identification et de maintien de la cohérence dans le contenu des renseignements sur l’architecture tout au long de son cycle de vie. En règle générale, la gestion de la configuration comporte cinq activités principales :

Planification de la gestion de la configuration – Avant de commencer, vous devez prendre certaines décisions en répondant aux questions suivantes : quels éléments de la configuration dois-je contrôler ou gérer? quand établirai-je les éléments de la configuration?; comment modifierai-je les éléments de la configuration?; quels efforts déploierai-je pour gérer les éléments de la configuration? Dans le contexte de l’entretien d’une architecture régionale des STI, la planification de la gestion de la configuration correspond au plan d’entretien de l’architecture.
Définition des éléments de la configuration – Définissez les éléments de la configuration qui doivent être établis séparément, stockés, testés, examinés, utilisés, modifiés, livrés ou entretenus. La définition des éléments de la configuration et l’établissement des identificateurs qui seront utilisés font partie intégrante du plan d’entretien de l’architecture régionale des STI.
Contrôle de la configuration – Gérez les modifications que vous apporterez à la base de référence de la configuration, le moment où vous les apporterez et la manière dont vous les apporterez.
Enregistrement et déclaration de l’état des éléments de la configuration – Enregistrez l’état de tous les éléments de la configuration et toutes les modifications approuvées que vous leur avez apportées.
Vérifications de la configuration – Vérifiez la cohérence de la documentation sur la configuration par rapport au système ou au produit. Dans le contexte d’une architecture régionale des STI, assurez-vous que les différentes représentations de l’architecture, comme les documents et la base de données, correspondent.

Ces activités sont réalisées durant tout le cycle de vie de l’élaboration et de l’exploitation d’un système.

8.3.1 Processus d’entretien de l’architecture

Le processus d’entretien d’une architecture régionale des STI implique la gestion du changement. Il peut être décrit à l’aide des principales activités propres à la gestion de la configuration que nous venons de présenter brièvement.

Planification de la gestion de la configuration

Avant que l’activité d’entretien commence, ses paramètres et l’information détaillée sur le processus doivent être établis. Ces paramètres, dont il a été question à la section 8.2, sont les suivants : qui entretiendra l’architecture régionale des STI? quand l’architecture sera-t-elle mise à jour?; et quelle base de référence de l’architecture sera entretenue? Ces décisions et le processus d’entretien lui-même devraient être définis dans un plan d’entretien de l’architecture, qui est le premier extrant de la planification de la gestion de la configuration. Le plan d’entretien pourrait être un document distinct ou faire partie d’un document plus large sur l’architecture régionale des STI. Il devrait être créé durant l’élaboration initiale de l’architecture. Si ce n’est pas le cas, alors le processus devrait être défini et documenté le plus tôt possible. Le plan d’entretien devrait faire partie intégrante de la base de référence de l’architecture décrite ci-dessous.

Qui entretiendra l’architecture régionale des STI?
Le plan d’entretien devrait mentionner l’organisme qui sera responsable de l’entretien de l’architecture, ainsi que le groupe d’intervenants qui examinera et approuvera les modifications apportées à la base de référence de l’architecture. De plus, le plan doit décrire les rôles et les responsabilités de chaque organisation concernée. Le rapport sur l’architecture régionale des STI d’Oahu fournit de tels renseignements détaillés.

Quand l’architecture sera-t-elle mise à jour?
Le plan d’entretien devrait établir le calendrier des mises à jour de l’architecture régionale des STI. Comme nous l’avons vu à la section 8.2.2, il existe diverses possibilités pour l’établissement de ce calendrier. Le plan d’entretien doit mentionner quand la base de référence de l’architecture sera établie et quand le processus d’entretien commencera. Généralement, la première diffusion d’une architecture régionale des STI après son élaboration initiale constitue sa base de référence. Cela coïncide avec le moment où l’architecture est prête à être distribuée et utilisée, et où des changements possibles à l’architecture commencent à prendre forme.

Quelle base de référence de l’architecture sera entretenue?
Le plan d’entretien devrait établir clairement ce qui sera entretenu. La section 8.2.3 a présenté les parties constituantes de l’architecture régionale des STI qui doivent être entretenues. En fait, ces parties sont contenues dans des bases de données (par exemple, une base de données de Turbo Architecture), des feuilles de calcul électronique, des fichiers de dessin (par exemple, PowerPoint ou Visio), des fichiers en HTML pour un site Web, etc. Définir la base de référence d’une architecture régionale des STI, c’est définir exactement les documents, les bases de données, etc. qui seront entretenus.

En plus des extrants de l’architecture régionale des STI, il pourrait être important d’établir quels documents sources ont été utilisés pour produire ces extrants. Certains documents seront sujets à une révision ultérieure. Il est important de maintenir une cohérence entre l’architecture et les autres efforts déployés. Par exemple, si l’inventaire de l’architecture régionale des STI provient de documents contenus dans les inventaires individuels d’intervenants, vous devriez inclure dans votre liste d’éléments à contrôler les dates et les numéros de version de ces documents. Parmi les autres documents sources possibles, mentionnons des rapports sur des déploiements précoces, des plans de déploiement stratégique et des rapports de suivi de l’inventaire. Il est important que les dates des rapports et que les numéros de version associés aux rapports soient enregistrés dans le cadre de la configuration gérée. Ainsi, la parution des versions subséquentes de ces documents pourrait coïncider avec une analyse visant à déterminer comment les changements sont le mieux diffusés par le biais des éléments de la configuration qui restent à contrôler afin de maintenir la configuration cohérente. Il est aussi nécessaire de noter les emplacements où les documents sont stockés – dans quel organisme, sur quel serveur Web, sur quel site Web, etc.

Les versions des composants logiciels qui ont été utilisés pour produire l’architecture pourraient aussi faire partie des éléments de la configuration, par exemple le logiciel Turbo Architecture et la version de l’architecture des STI pour le Canada utilisé. Dans le cas de ces outils, ce qu’il importe d’enregistrer en tant que partie intégrante de la configuration est le numéro de la version et la date de parution. Les mises à jour subséquentes apportées aux logiciels et aux bases de données pourraient coïncider avec une analyse sur les changements.

Un dernier aspect à prendre en considération dans la définition de la base de référence de votre architecture régionale des STI est la manière dont vous prévoyez utiliser l’architecture. Les diagrammes d’ensembles de solutions applicatives seront-ils une importante source d’interfaces lors de la définition du projet? Des diagrammes des interconnexions seront-ils utilisés? Les concepteurs du projet utiliseront-ils la représentation de bases de données pour leur définition détaillée? En examinant ces questions, vous serez à même de déterminer quelles représentations de l’architecture sont les plus importantes pour votre région.

Le Tableau 5 présente des exemples d’éléments de la configuration dont vous pourriez tenir compte dans la base de référence de votre architecture régionale des STI.

Tableau 5: Exemples d’éléments de la configuration à prendre en considération

Bases de données de Turbo Architecture
Documentation relative à l’architecture régionale des STI
Plan d’entretien (s’il s’agit d’un document distinct)
Liste des documents utilisés pour élaborer l’architecture ou avec lesquels l’architecture devrait être compatible
Documents de planification
Documents de suivi de l’inventaire
Version du logiciel Turbo Architecture
Version de l’architecture des STI pour le Canada

La définition de la base de référence dépendra largement de l’étendue et de la complexité du travail consacré à l’architecture régionale des STI. Si le travail est minime, la base de référence pourrait consister seulement en une base de données, un document sommaire sur l’architecture (qui inclurait le plan d’entretien) et la version de l’architecture des STI pour le Canada (et peut-être celle de Turbo Architecture) utilisée durant le processus d’élaboration.

Comment modifier les éléments de la base de référence?
Après avoir établi qui entretiendra l’architecture, quand elle sera mise à jour et quelle base de référence sera entretenue, voyez comment vous apporterez des modifications à la base de référence. Le changement est inévitable. Le but de la gestion de la configuration n’est pas d’empêcher que des changements surviennent, mais plutôt de permettre que les changements aient lieu de manière contrôlée afin de s’assurer que tous les éléments de la configuration sont compatibles en tout temps avec leurs descriptions. En raison de la nature d’une architecture régionale des STI (qui est un ensemble de documents et de bases de données plutôt qu’un système de composants logiciels et de matériel informatique), deux approches fondamentales peuvent servir à mettre à jour la base de référence. La première consiste à faire une mise à jour partielle, c’est-à-dire à apporter des changements graduels, à partir de demandes individuelles. La seconde approche consiste à faire une mise à jour complète à partir d’un examen périodique de toute l’architecture. Dans le dernier cas, tous les extrants de l’architecture sont examinés et modifiés à partir des intrants des intervenants au moyen du même processus qui a été utilisé lors de l’élaboration initiale de l’architecture.

Le processus visant à modifier la base de référence de l’architecture régionale des STI est composé de cinq étapes, comme l’illustre la Figure 28. Les sections qui suivent examinent chaque étape du processus (qui peut s’appliquer aux deux approches permettant d’entretenir l’architecture). Le travail consacré aux étapes du processus dépendra de la portée et de la complexité de l’architecture régionale des STI.

Figure 28: Processus de définition du changement

Définir le changement
Les principaux aspects de la définition du changement sont les suivants :
- Qui peut demander un changement?
- Comment la demande de changement est-elle documentée?
La première décision consiste à déterminer qui peut demander un changement. Dans certaines régions, la réponse est « n’importe qui ». Cette approche est préconisée dans le plan d’entretien d’Inland Empire. Permettre à quiconque de demander un changement est propice à l’établissement d’une architecture « consensuelle », puisque tous les intervenants ont ainsi l’occasion de fournir des commentaires ou des suggestions. Mais cette approche a également un inconvénient : si pratiquement tout le monde peut soumettre une demande de changement, la région risque d’être submergée de demandes qui obligeront les rares ressources disponibles à examiner tous les changements proposés et à les approuver ou les rejeter. Une approche de rechange susceptible d’intéresser des régions plus vastes consisterait à limiter les demandes de changement aux membres du comité ou du conseil de l’entretien de l’architecture ou aux membres d’autres comités clés sur les STI. Dans cette optique, tout changement suggéré est approuvé par un intervenant clé. Cette approche est incluse dans le plan d’entretien de l’architecture de Northeastern Illinois. Elle présente l’avantage de répartir les ressources requises pour produire ou évaluer les changements parmi les groupes d’intervenants.

Le plan d’entretien pourrait aussi tenir compte du moment où une demande de changement est soumise. Par exemple, il pourrait déterminer quand des changements à l’architecture régionale des STI devraient être apportés afin d’assurer le financement à un projet au moyen du processus de planification des immobilisations. Aussi, le plan pourrait établir les types de changements qui seront apportés à l’architecture.

Il est recommandé de créer un formulaire simple de demande de changement contenant au moins les renseignements suivants :
- Nom du changement
- Description du changement
- Raison d’être du changement
- Nom de la personne ou de l’organisation qui demande le changement
- Coordonnées de la personne ou de l’organisation qui demande le changement
- Date de la demande de changement
En tant que partie intégrante du processus de gestion de la configuration, ces renseignements devraient être conservés dans un journal ou une base de données qui pourrait contenir les champs d’information additionnels suivants : Numéro du changement (identificateur unique)
- État du changement (accepté, rejeté ou reporté)
- Type de changement (mineur ou important)
- Partie de la base de référence touchée par le changement (par ex., des cases à cocher pour les éléments document, base de données, site Web, inconnu)
- Commentaire sur l’état du changement
- Date de l’état du changement
Le formulaire de demande de changement pourrait être disponible sur le site Web de l’architecture régionale des STI, et toute personne souhaitant suggérer un changement pourrait le télécharger. Une façon moins formelle pourrait être de soumettre une demande de changement dans un courriel contenant les renseignements susmentionnés. La formalité du processus crée un journal de vérification de tous les changements examinés, de même qu’un registre des changements approuvés, rejetés et reportés. Ce journal de vérification pourrait s’avérer fort utile lors des évaluations futures des améliorations ou des changements à apporter aux systèmes.

Cette description des demandes de changement s’applique à des suggestions qui pourraient provenir de l’examen de l’architecture par un intervenant ou des effets de projets individuels. Dans le cas d’une mise à jour complète de la base de référence d’une architecture régionale des STI, la demande de changement pourrait indiquer la nature de la mise à jour et les interactions entre les intervenants qui produiront un ensemble de changements.
Évaluer le changement
Selon l’approche de la mise à jour partielle ou des changements graduels, chaque demande de changement doit être évaluée afin de déterminer ses répercussions sur la base de référence de l’architecture régionale des STI. Cette évaluation pourrait être faite par l’individu qui suggère le changement ou par quelqu’un d’autre (par exemple, la personne ou le groupe de personnes responsables de l’entretien de l’architecture). Puisqu’une évaluation adéquate d’un changement requiert une connaissance approfondie des éléments de la base de l’architecture régionale des STI qui seront touchés, il est habituellement de mise qu’elle soit faite par un membre du comité de l’entretien ou une personne désignée. Si le changement proposé risque d’avoir des répercussions sur d’autres intervenants, un membre du comité de l’entretien devrait demander à ces intervenants de confirmer leur acceptation de la modification. Si la situation l’exige, une réunion ou une téléconférence avec les intervenants concernés pourrait avoir lieu pour discuter du changement suggéré. Dans le cas d’une mise à jour complète de la base de référence de l’architecture, l’évaluation du changement est faite selon le principe du consensus parmi les intervenants.
Approuver le changement
Quand on a recours à l’approche de la mise à jour partielle de la base de référence de l’architecture régionale des STI, les changements proposés devraient être soumis au comité de l’entretien en même temps que les recommandations en vue de les approuver, de les rejeter ou de les reporter. Cela pourrait se faire de manière informelle au moyen de courriels ou lors de rencontres individuelles périodiques. Le plan d’entretien devrait mentionner comment les approbations auront lieu et toutes les procédures qui seront utilisées aux fins de la prise de décisions. Les approbations nécessitent-elles le consensus unanime de tous les membres du comité de l’entretien? L’approbation d’un changement proposé requiert-elle l’avis de tous les intervenants touchés par ses répercussions, ou d’une majorité seulement des membres du comité? Le recours à une procédure en particulier dépend largement de la nature de l’établissement des consensus dans la région. L’approbation d’un changement par tous les intervenants touchés par ses répercussions constitue une approche valable qui pourrait convenir dans de nombreuses situations. Par exemple, si une modification à une interconnexion entre un centre de gestion du trafic et un centre de transit est suggérée, alors son approbation par les organismes concernés pourrait être consensuelle et amplement suffisante. Un consentement unanime n’est pas recommandé, car il est plus difficile à maintenir et pourrait ralentir considérablement le processus, toutes les parties concernées devant réagir ou assister aux réunions. Dans le cas d’une mise à jour complète de la base de référence de l’architecture régionale des STI, l’approbation vient des commentaires obtenus des intervenants lors de l’examen de chaque intrant.
Mettre à jour la base de référence
Cette activité consiste à incorporer les changements dans les documents relatifs à la base de référence de l’architecture régionale des STI, les fichiers Web et les bases de données. Cela requiert les mêmes compétences et les mêmes techniques que celles utilisées pour créer la base de référence initiale. Quand on a recours à l’approche de la mise à jour partielle, tous les changements doivent être entrés par une ou plusieurs personnes assignées, puis vérifiés au moyen du processus décrit dans le plan d’entretien. Si l’on procède à une mise à jour complète de la base de référence de l’architecture, les nouvelles versions des documents, les fichiers Web et les bases de données sont distribués aux intervenants aux fins d’un examen plus approfondi. De plus, le journal des changements apportés est mis à jour, tout comme l’établissement de la version de tous les documents relatifs à la base de référence de l’architecture, comme il est décrit dans le plan d’entretien. Dans certains cas, les changements pourraient être mis en veilleuse jusqu’à ce qu’il y ait un volume suffisant pour une mise à jour efficace.
Aviser les intervenants
La dernière étape du processus d’entretien consiste à aviser les intervenants des changements apportés à la base de référence de l’architecture régionale des STI ou de ses mises à jour, qu’elles soient complètes ou partielles. Pour ce faire, l’organisation responsable de l’entretien de l’architecture devrait créer et maintenir à jour une liste de tous les intervenants concernés. En tant que partie intégrante du processus d’entretien, cette liste devrait être examinée et mise à jour périodiquement afin de tenir compte des changements dans le personnel et les coordonnées (par exemple, les numéros de téléphone et les adresses de courrier électronique). La tâche d’aviser les intervenants des changements ou des mises à jour apportés à la base de référence de l’architecture peut être exécutée de diverses façons (envoi d’un document papier, envoi d’un courriel, site Web, etc.). Chaque méthode a ses avantages et ses inconvénients. Ce qui convient le mieux à une région repose sur les méthodes usuelles de communication qui y sont utilisées. Une méthode qui satisfait à un vaste éventail de besoins consiste à créer un site Web, où l’information sur l’architecture est disponible, et à prévoir un endroit sur ce site Web pour afficher les changements ou les mises à jour. Il est possible de combiner cette méthode avec l’envoi de courriels pour informer les intervenants inscrits sur la liste qu’un changement a été apporté à la base de référence, ou qu’une mise à jour a été faite, et que des renseignements sont disponibles sur le site Web. Sur l’avis et le site Web, il serait bon d’afficher la nouvelle version et la date de parution des éléments de la base de référence, de même qu’un bref aperçu du changement apporté.

Ressources associées à la gestion de la configuration

Quelles sont les ressources nécessaires à la gestion de la configuration? Dans le contexte de l’entretien d’une architecture régionale des STI, les mêmes compétences personnelles utilisées pour travailler avec l’architecture des STI pour le Canada et Turbo Architecture sont requises pour gérer les éléments de la configuration inclus dans le plan de gestion de la configuration. En plus des ressources humaines, il faut des serveurs de fichiers, des sites Web ou d’autres lieux centraux d’entreposage des copies électroniques des éléments de la configuration. Toutes ces ressources doivent être « verrouillées » ou pour « simple lecture » et protégées pour que des changements ne soient pas apportés à des versions publiées de bases de données et de documents. Tout changement requiert un nouveau numéro ou une nouvelle date de version et, donc, une nouvelle copie de l’élément de la configuration distincte de la version précédente.

Haut de la page

Définition des éléments de la configuration

À chaque élément de la configuration doit correspondre un identificateur unique. Cet identificateur doit apparaître sur l’élément d’une certaine manière pour que ce dernier puisse être identifié et suivi. Dans le contexte de l’entretien de l’architecture régionale des STI, on peut suffixer un numéro de version et la date dans le nom du fichier de la base de données ou du document électronique, ou les entrer dans un document imprimé. L’identificateur peut aussi apparaître dans un en-tête ou un pied de page dans des documents et des diagrammes. De cette façon, toute personne qui lit un document ou consulte une base de données (par exemple, à l’aide de Turbo Architecture) saura de quelle version il s’agit.

Il est également sensé d’avoir un document contrôlé qui énumère tous les éléments de la configuration et les versions qui ont constitué la base de référence de l’architecture dans le temps. L’historique de l’entretien peut aussi être inclus. Il vaut la peine d’enregistrer tous les liens d’interdépendance entre les éléments de la configuration, et ce, pour trois raisons majeures. Primo, vous voulez savoir quels sont les éléments sous le contrôle de la configuration et pouvoir les localiser. En les marquant avec un identificateur unique, c’est possible. Secundo, vous voulez suivre à la trace l’état de chaque élément à mesure qu’il change. Tertio, si un changement est apporté à l’un de vos éléments de la configuration, vous voulez pouvoir déterminer les répercussions de ce changement sur les autres éléments.

Contrôle de la configuration

Le contrôle de la configuration renvoie au processus visant à identifier, à évaluer et à approuver les changements (tel qu’il est défini dans le plan d’entretien de l’architecture), puis à mettre à jour la base de référence de l’architecture régionale des STI et toute la documentation connexe. Tout ajout fait après la parution initiale sera noté à l’aide d’un nouveau numéro de version et une nouvelle date (identificateur). Le contrôle inclut également une mise à jour et une nouvelle version de la liste globale des éléments de la configuration qui documente les versions actuelles de tous les éléments.

La base de référence d’une architecture régionale des STI contient des bases de données, des documents, voire d’autres extrants à l’appui, comme des feuilles de calcul électroniques et des fichiers de dessin. Le processus de contrôle de la configuration et de mise à jour de ces données peut devenir compliqué, puisqu’il a de fortes chances d’être beaucoup plus qu’une simple représentation des mêmes données. Par exemple, si une base de données contient l’inventaire de l’architecture et qu’un document relatif à l’architecture contient un tableau qui présente cet inventaire, ces deux représentations des mêmes données doivent être conservées en harmonie. L’élimination de ce genre de dédoublement n’est pas vraiment une solution, parce qu’une représentation de la base de données de l’architecture est nécessaire pour gérer un grand nombre d’éléments et de connexions. Mais une certaine forme de documentation est aussi requise afin de rendre l’information plus facile à comprendre et à utiliser pour les intervenants. La solution consiste à être conscient du dédoublement et à mettre en place un plan pour le gérer. Parce que les changements peuvent influer sur de nombreuses parties constituantes de la base de référence de l’architecture régionale des STI, les changements apportés dans chacune de ces parties devraient être coordonnés avec les changements ou les mises à jour dans les autres parties. Cela vaut particulièrement lorsqu’on recourt à l’approche des changements graduels pour entretenir l’architecture.

Suggestions En recourant à l’approche des changements graduels, il est aussi possible de changer plus souvent la version de la base de données que la version des documents. Cela peut être approprié si les intervenants utilisent plus souvent la base de données que les documents (par exemple, pour établir des correspondances entre l’architecture régionale des STI et des projets). Des notes pourraient être ajoutées dans la liste des éléments de la configuration.

Enregistrement et déclaration de l’état des éléments de la configuration

Le processus d’enregistrement et de déclaration de l’état des éléments de la configuration permet de s’assurer que toute l’information pertinente sur un élément (documentation et historique des changements) est mise à jour et détaillée autant qu’il est nécessaire. Cela inclut l’état de tous les changements en suspens. Le but primaire du processus d’enregistrement et de déclaration de l’état des éléments de la configuration est de diffuser l’information relative aux éléments de la configuration requises pour soutenir les efforts existants et futurs de contrôle des changements. Un système typique d’enregistrement et de déclaration de l’état des éléments de la configuration implique l’établissement et le maintien d’une documentation durant tout le cycle de vie de chaque élément. Idéalement, la déclaration de l’état a lieu en conjugaison avec le contrôle des changements.

Le principal avantage du processus d’enregistrement et de déclaration de l’état des éléments de la configuration est qu’il fournit une méthodologie de mise à jour de toute la documentation pertinente permettant de s’assurer que la configuration la plus récente se reflète dans la base de données sur la définition des éléments de la configuration. Il rend compte de l’état actuel de tous les changements proposés et approuvés. Le but du processus d’enregistrement et de déclaration de l’état des éléments de la configuration est de fournir aux décideurs des données le plus à jour possible. En ayant la plus récente information sur un élément de changement ou sur la manière dont des changements ont été mis en place, on diminue le travail de recherche aux fins des futures activités de contrôle des changements, si l’on instaure un nouveau changement ou si l’on répète un changement qui a eu des effets négatifs ou inattendus.

Dans le cas d’une petite architecture régionale des STI, les seuls éléments de la configuration pourraient être un document ou une base de données de Turbo Architecture. Cela pourrait signifier que l’enregistrement et la déclaration de l’état des éléments de la configuration équivalent à déclarer la version de deux éléments. Par exemple, « ruralRegArchV1-6-3-09.tbo » et « ruralRegionarchV1-7-3-09.doc » sont les versions les plus récentes de « l’architecture régionale des STI en milieu rural ». Cet état pourrait être transmis par téléphone, lettre, courriel ou télécopieur aux intervenants concernés simplement pour les informer que ces fichiers sont les plus récents. Quand on utilise l’approche des changements graduels apportés à la base de référence de l’architecture régionale des STI, une autre chose généralement déclarée durant le processus d’enregistrement et de déclaration de l’état des éléments de la configuration est la liste des changements en suspens ou devant être apportés à l’architecture. Dans une petite région, il risque de ne pas y avoir beaucoup de changements et, donc, très peu de changements en suspens. Ainsi, en plus d’établir la version la plus récente de l’architecture, la région pourrait déclarer que deux changements ont été reçus des intervenants A et B, que ces changements n’ont pas encore été mis en place, mais qu’on s’attend à ce qu’ils le soient au cours des six prochains mois. Quand on utilise l’approche de la mise à jour complète de la base de référence de l’architecture régionale des STI, les changements en suspens sont recueillis, mais ils ne sont probablement pas déclarés jusqu’au moment où ils sont décrits sommairement dans le journal des changements, soit lorsque la base de référence est complètement mise à jour.

Vérification de la configuration

Dans la discipline générale de la gestion de la configuration, la vérification de la configuration permet d’analyser les éléments de la configuration et leur documentation respective pour s’assurer que cette dernière reflète la situation actuelle. Dans le cas d’une architecture régionale des STI, les éléments de la configuration sont la documentation. Ainsi, cette étape du processus est une étape simple qui se penche sur deux aspects de l’architecture :

vérifier l’exactitude du rapport de l’enregistrement et de la déclaration de l’état des éléments de la configuration;
vérifier si les différentes représentations des renseignements sur l’architecture (par ex., la base de données et les données) sont en harmonie.

Une telle vérification convient davantage à l’approche des changements graduels, car elle peut résulter en de nombreuses petites mises à jour apportées aux éléments de la configuration. Toutefois, il peut aussi être intéressant d’y recourir lorsqu’on termine la mise à jour complète de la base de référence de l’architecture.

8.3.2 Travail nécessaire à l’entretien de l’architecture régionale des STI

Quelle somme de travail est nécessaire pour entretenir une architecture régionale des STI? Cela dépend de divers facteurs :

Combien d’activités nécessitent l’utilisation de l’architecture? Plus une architecture est utilisée pour soutenir la planification et les activités d’élaboration des projets, plus grand sera le niveau des changements requis. La région s’oriente-t-elle vers une mise à jour importante de son plan à long terme? Y a-t-il un niveau élevé d’investissements technologiques dans la région? Les activités se limitent-elles à un organisme de la région ou impliquent-elles plusieurs organismes?
Quelle est l’approche utilisée pour entretenir l’architecture? L’approche des changements graduels ou l’approche de la mise à jour complète de la base de référence?
Quel est le cycle de mise à jour de l’entretien? Les changements sont-ils incorporés régulièrement? La révision de l’architecture a-t-elle lieu à chaque cycle de planification?
Quelle taille et quel niveau de complexité l’architecture a-t-elle? Plus une architecture est grande, plus il faut consacrer d’efforts à son entretien.

Afin d’établir le travail à exécuter, vous pourriez examiner les scénarios d’entretien suivants :

L’organisation responsable de l’entretien reçoit les demandes de changement, puis elle les examine périodiquement avec le comité de l’entretien (par exemple, tous les trois mois).
Le nombre de changements proposés durant chaque période dépend de l’utilisation de l’architecture (de l’examen qu’en font les intervenants pendant qu’ils l’utilisent) et de sa complexité (du nombre d’éléments ou de connexions qui peuvent être changés). La création d’une demande de changement devrait exiger peu de temps, soit moins d’une heure. L’enregistrement des changements dans un journal exige aussi peu de temps. Périodiquement, les changements sont évalués et soumis au comité de l’entretien. L’évaluation devrait, elle aussi, se faire rapidement. Au cours d’une réunion d’une heure ou deux, les membres du comité peuvent examiner les changements proposés et prendre des décisions. La quantité de travail requise pour mettre à jour la base de référence varie selon la portée du changement. Par exemple, il faut plus de temps et de travail pour ajouter un intervenant, des composants de l’inventaire et des connexions que pour changer l’état de quelques flux d’information. Encore une fois, la somme de travail requise par toutes ces activités dépend du nombre de changements envisagés.
L’organisation responsable de l’entretien reçoit les demandes de changement et les conserve jusqu’à ce qu’une mise à jour soit apportée un certain nombre d’années après que l’architecture initiale ait été achevée.
Ce scénario est semblable au précédent quant au temps requis par chaque changement. La principale différence est le nombre de changements à incorporer. La somme de travail dépend largement de choses comme le niveau des investissements STI dans la région. Une façon de limiter le temps consacré à l’évaluation et à l’approbation des changements proposés est de demander au personnel de produire un résumé des changements et de recommander des décisions (approuver, rejeter ou reporter des changements). Cela permettra aux membres du comité de l’entretien de se concentrer, lors des réunions, sur les changements qui requièrent le consensus des intervenants.
À chaque cycle de mise à jour, les intervenants se réunissent dans le cadre d’un ou de plusieurs ateliers pour examiner et mettre à jour l’architecture.
Il s’agit ici de l’approche de la mise à jour complète de la base de référence de l’architecture. Dans cette approche, du temps sera consacré à réunir les intervenants dans le cadre d’un ou de plusieurs ateliers pour qu’ils examinent et mettent à jour l’architecture. Des changements découleront naturellement de ces rencontres et ils seront incorporés en bloc à l’architecture. Le niveau de travail nécessaire à la préparation et à la tenue de ces rencontres dépendra de leur nombre et des efforts consacrés à la présentation de l’architecture aux intervenants.

Combien tout cela coûtera-t-il? Nous sommes tous confrontés à la nécessité de procéder à une planification budgétaire et, donc, de nous en tenir à l’essentiel. Le coût associé à l’entretien d’une architecture régionale des STI dépendra de la manière dont vous l’utiliserez. Le fait de rémunérer une ou des personnes pour mettre à jour la base de données, le site Web et la documentation peut être minime, comparativement au coût associé au temps consacré par tous les intervenants pour examiner et approuver les changements proposés. Réfléchissez aux scénarios décrits plus haut et déterminez l’approche qui convient le mieux à l’entretien de votre architecture régionale des STI. Vous pouvez décider d’allouer des ressources financières dans vos prochains budgets pour couvrir le coût d’entretien de votre architecture régionale des STI (personnel, équipement, entrepreneurs, etc.).

[ Précédente : Chapitre 7 ]

[ Suivante : Annexe A ]