Les objectifs de la phase H « Gestion de la maintenance et des évolutions » de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework) - urbanisation-si, modelisation-metier, processus-metier, expression-des-besoins

Les objectifs de la phase H « Gestion de la maintenance et des évolutions » de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

L'objectif d'un processus de gestion des modifications de l'architecture est de s'assurer que l'architecture atteint sa valeur métier cible initiale.

Cela inclut la gestion des modifications de l'architecture de manière cohérente et architecturée.

Il vous faudra donc vous assurez que l'architecture d'entreprise est bien capable de répondre aux exigences actuelles et que son cycle de vie est maintenu.

Ce processus prévoit généralement la surveillance continue telles que les demandes de gouvernance, les nouveaux développements technologiques et les changements dans l'environnement métier.

Lorsque des changements sont identifiés, la gestion du changement déterminera s'il faut initier formellement un nouveau cycle d'évolution de l'architecture.

De plus, le processus de gestion des changements d'architecture vise à établir et à soutenir l'architecture d'entreprise mise en œuvre en tant qu'architecture dynamique ; c'est-à-dire, avoir la flexibilité d'évoluer rapidement en réponse aux changements aussi bien métier que technique.

La surveillance de la croissance et du déclin des entreprises est un aspect essentiel de cette phase.

L'utilisation de l'architecture d'entreprise est la partie la plus importante du cycle de développement de l'architecture.

Trop souvent, l'entreprise s'est retrouvée avec une architecture d'entreprise qui fonctionne pour l'organisation d'hier, mais ne peut pas redonner une capacité suffisante pour répondre aux besoins de l'entreprise d'aujourd'hui et de demain.

Dans de nombreux cas, l'architecture continue à s'adapter, mais les solutions sous-jacentes peuvent ne pas l'être, et certains changements sont nécessaires.

L'architecte d'entreprise doit être consciente de ces exigences de changement et considère cela comme une partie essentielle du renouvellement constant de l'architecture.

La mesure de la capacité et des recommandations pour la planification est un aspect clé de cette phase.

Bien que l'architecture ait été conçue pour fournir une architecture d'entreprise stable avec une capacité déterminée pendant le cycle de vie, la croissance ou la baisse de l'utilisation doit être continuellement évaluée pour garantir une valeur métier maximale.

Le processus de gestion de la valeur et du changement, une fois établi, détermine :

Les circonstances dans lesquelles l'architecture de l'entreprise, ou des parties de celle-ci, seront autorisées à changer après le déploiement, et le processus par lequel cela se produira
Les circonstances dans lesquelles le cycle de développement de l'architecture sera à nouveau initié pour développer une nouvelle architecture

Le processus de gestion des modifications d'architecture est très étroitement lié aux processus de gouvernance de l'architecture de l'entreprise et à la gestion du contrat d'architecture entre la fonction d'architecture et les utilisateurs métier de l'entreprise.

Dans la phase H, il est essentiel que l'organe de gouvernance établisse des critères pour juger si une demande de changement justifie juste une mise à jour de l'architecture ou si elle justifie de commencer un nouveau cycle de la méthode de développement d'architecture (ADM).

Il est particulièrement important d'éviter l’intégration des dernières technologies juste pour la beauté de la chose et être tendance technologiquement parlant, et l'organe de gouvernance doit continuer à chercher des changements qui sont directement liés à la valeur et aux métiers de l'entreprise.

Un rapport de conformité d'architecture doit indiquer si la modification est conforme à l'architecture actuelle. Si elle n'est pas conforme, une dérogation peut être accordée avec une justification valable. Si le changement a un impact important sur l'architecture, alors une stratégie pour gérer son impact devrait être définie.

Les directives pour établir ces critères sont difficiles à prescrire, car de nombreuses entreprises acceptent le risque différemment, mais au fur et à mesure que le niveau de maturité de la gouvernance s'améliore, les critères deviennent clairs pour des besoins spécifiques.

L'architecture est pilotée par le changement

L'objectif principal du développement de l'architecture d'entreprise à ce jour a été la direction stratégique et l'architecture descendante ainsi que la génération de projets pour atteindre les capacités de l'entreprise.

Cependant, l'architecture d'entreprise ne fonctionne pas dans le vide. Il existe généralement une infrastructure et des activités existantes qui fournissent déjà de la valeur.

Il y a aussi probablement des moteurs de changement qui sont souvent ascendants, basés sur la modification de l'infrastructure existante pour améliorer les fonctionnalités.

L'architecture d'entreprise modifie ce paradigme par une approche descendante stratégique à un degré, bien que la livraison d'incréments rende l'équation plus complexe.

Les manières de changer l'infrastructure existante devant être intégrées :
. Changement stratégique dirigé vers le haut pour améliorer ou créer de nouvelles capacités
. Modifications ascendantes pour corriger ou améliorer les capacités (opérations et maintenance) pour la gestion des infrastructures sous gestion des opérations

La gouvernance devra gérer la coordination de ces demandes de changement, et il doit y avoir un processus de retours d’expérience pour permettre de résoudre les problèmes liés aux incréments récemment livrés et de modifier et de planifier les changements apportées aux architectures cibles.

Un processus de retours d’expérience garantit que les erreurs sont faites une fois et ne sont pas répétées.
Elles peuvent venir de n'importe où et de n'importe qui et couvrir n'importe quel aspect de l'architecture d'entreprise à n'importe quel niveau (stratégie, définition d'architecture d'entreprise, transition ou projet).
Souvent, un retour d’expérience liée à l'architecture d'entreprise peut être le résultat indirect d'une expérience apprise ailleurs dans l'organisation.

Le Conseil d'architecture évalue et approuve les demandes de changement (RFC Request For Comment).
Une RFC est généralement en réponse à des problèmes connus, mais peut également inclure des améliorations. Un défi pour le conseil d'architecture lors du traitement d'un RFC est de déterminer s'il doit être approuvé ou si un projet dans une architecture de transition résoudra le problème.

Lors de l'évaluation de l'intégration d'un projet ou d'une solution dans l'architecture, il peut également se produire lorsqu'une solution innovante ou une RFC entraîne une modification de l'architecture.

En outre, il existe de nombreux facteurs liés à la technologie pour les demandes de changement d'architecture.

Par exemple :

Nouveaux rapports technologiques
Réduction des coûts de gestion des actifs
Retrait de technologie
Initiatives de normalisation

Ce type de demande de changement est normalement gérable principalement à travers les processus de gouvernance de la gestion des changements et de l'architecture d'une entreprise.

En outre, il existe des facteurs opérationnels pour le changement d'architecture, notamment :

Les développements du métier
Exceptions métiers
Innovations commerciales
Innovations technologiques d'entreprise
Changements stratégiques

Ce type de demande de changements entraîne souvent un redéveloppement complet de l'architecture, ou au moins une itération d'une partie du cycle de développement de l'architecture, comme expliqué ci-dessous.

Le processus de gestion du changement d'architecture d'entreprise

Le processus de gestion des modifications de l'architecture d'entreprise doit déterminer comment les modifications doivent être gérées, quelles techniques doivent être appliquées et quelles méthodologies sont utilisées.

Le processus nécessite également une fonction de filtrage qui détermine les phases du processus de développement de l'architecture qui sont affectées par les exigences.
Par exemple, les modifications qui affectent uniquement la migration peuvent ne présenter aucun intérêt pour les phases de développement de l'architecture.

Il existe de nombreuses approches valables pour la gestion du changement, et diverses techniques et méthodologies de gestion pouvant être utilisées pour gérer le changement.

Par exemple des méthodes de :

gestion de projet telles que PRINCE2,
gestion de service telles que ITIL,
conseil en gestion telles que Catalyst, ...

Une entreprise qui a déjà mis en place un processus de gestion des changements dans un domaine autre que l'architecture (par exemple, dans le développement de systèmes ou la gestion de projet) peut très bien être capable de l'adapter à l'architecture.

L'approche est basée sur la classification des changements architecturaux requis dans l'une des trois catégories suivantes :

Changement de simplification : un changement de simplification peut normalement être géré via des techniques de gestion du changement.
Changement incrémental : un changement incrémentiel peut être géré par des techniques de gestion du changement, ou il peut nécessiter une réorganisation partielle, en fonction de la nature du changement.
Réorganisation du changement : Un changement de réarchitecture nécessite de remettre toute l'architecture dans le cycle de développement de l'architecture.

Une autre façon de considérer ces trois choix est de dire qu'un changement de simplification d'une architecture est souvent motivé par une exigence de réduction des investissements ; un changement progressif est motivé par une exigence de tirer une valeur additionnelle de l'investissement existant ; et une réorganisation du changement est motivée par une exigence d'augmentation des investissements afin de créer une nouvelle valeur pour l'exploitation.

Pour déterminer si une modification est une simplification, une incrémentation ou une réarchitecture, les activités suivantes sont entreprises :

Enregistrement de tous les événements pouvant affecter l'architecture
Allocation et gestion des ressources pour les tâches d'architecture
Le processus ou le rôle responsable des ressources d'architecture doit évaluer ce qui doit être fait
Évaluation des impacts

Vous pouvez appliquer la règle suivante :

Si le changement a une incidence sur deux parties prenantes ou plus, il est probable qu'il nécessitera une refonte de l'architecture et une réentrée à l'ADM.
Si le changement n'a d'impact que sur un acteur, il est plus susceptible d'être candidat à la gestion du changement.
Si le changement peut être autorisé dans le cadre d'une dispense, il est plus susceptible d'être candidat à la gestion du changement.

Par exemple :
. Si l'impact est significatif pour la stratégie d'entreprise, il peut s'avérer nécessaire de refaire toute l'architecture de l'entreprise, ce qui implique une approche de réarchitecture.
. Si une nouvelle technologie ou de nouvelles normes émergent, alors il peut être nécessaire d'actualiser l'architecture technologique, mais pas toute l'architecture de l'entreprise - donc un changement incrémental.
. Si le changement est au niveau de l'infrastructure - par exemple, dix systèmes réduits ou modifiés en un seul système - cela ne changera peut-être pas l'architecture au-dessus de la couche physique, mais cela modifiera la description de base de l'architecture technologique. Ce serait un changement de simplification géré via des techniques de gestion du changement.

En particulier, un cycle de rafraîchissement (réaménagement partiel ou complet) peut être requis si :
. Les fondements de l’architecture doivent être réorientée avec la stratégie métier.
. Des changements substantiels sont requis pour les composants et les directives à utiliser dans le déploiement de l'architecture.
. Les normes importantes utilisées dans l'architecture du produit sont modifiées, ce qui a un impact significatif sur l'utilisateur final ; par exemple, des changements réglementaires.

Si un cycle de rafraîchissement est nécessaire, une nouvelle demande d’étude d'architecture doit être émise (pour passer à un autre cycle).

Conclusion

Les étapes de la phase H sont les suivantes :

Établissement du processus de réalisation de la valeur
Déployer les outils de surveillance
Gérer les risques
Fournir une analyse pour la gestion du changement d'architecture
Développer les exigences de modification pour atteindre les objectifs de performance
Gérer le processus de gouvernance
Activer le processus pour implémenter le changement

Rhona Maxwel

@rhona_helena

"Nous commençons à vieillir quand nous remplaçons nos rêves par des regrets."

Sénèque

Articles conseillés :

TOGAF pour les nuls.

Le processus des itérations ADM (Architecture Development Method), le moteur de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)

La phase A Vision du cycle de la méthode ADM (Architecture Development Method) de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)

Comment mettre en œuvre la phase B Métier de la méthode ADM (Architecture Development Method) du framework d’Architecture d’Entreprise TOGAF (The Open Group Architecture Framework)

Comment mettre en œuvre la phase C Système d’Information et la phase D Technique de la méthode ADM (Architecture Development Method) du framework d’Architecture d’Entreprise TOGAF (The Open Group Architecture Framework)

Comment mettre en œuvre la phase E Opportunités et Solutions de la méthode ADM (Architecture Development Method) de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)

Comment mettre en œuvre la phase F Planning de migration de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)