urbanisation-si.com

urbanisation-si.com

Le référentiel TOGAF, le patrimoine des informations et des bonnes pratiques pour toute l’entreprise

Le référentiel TOGAF récupère des informations du cycle ADM (Architecture Development Method) qui à son tour utilise les données de ce référentiel en fonction de ses besoins.

 

referentiel-togaf-structure-adm.PNG

 

La structure et le contenu des zones du référentiel TOGAF contiennent les résultats des projets, à savoir le « paysage d'architecture », la « bibliothèque de référence », la « base d'informations sur les normes » et le « journal de gouvernance » ainsi que des exigences à prendre en compte lors de la sélection d'outils pour gérer un référentiel d'architecture.

 

Exploiter une architecture mature dans une grande entreprise crée un énorme volume de production architecturale.

Une gestion efficiente de ces produits architecturaux requiert une taxonomie formelle pour différents types d'actifs architecturaux, ainsi que des processus et des outils dédiés pour le stockage de contenu architectural.

 

Un cadre structurel pour un référentiel d'architecture permet à une entreprise de faire la distinction entre différents types d'éléments architecturaux qui existent à différents niveaux d'abstraction dans l'organisation.

 

À un niveau élevé, six catégories d'informations architecturales devraient être conservées dans un référentiel d'architecture :

  • Le métamodèle d'architecture décrit l'application organisationnelle d'un cadre d'architecture, y compris une méthode de développement d'architecture et un métamodèle pour le contenu d'architecture.
  • La capacité d'architecture définit les paramètres, les structures et les processus qui prennent en charge la gouvernance du référentiel d'architecture.
  • Le "paysage d'architecture" présente une représentation architecturale des actifs utilisés ou prévus par l'entreprise à des moments particuliers.
    Le paysage consiste en des cartographies des processus métiers en BPMN, fonctionnelles et applicatives avec des profils UML. 
    Ce paysage d’architecture correspond à la vision du processus de l’urbanisation de Système d’Information.
    Ces cartographies sont indispensables à la compréhension globale du système, et constitue un instrument majeur du pilotage des évolutions.
  • La base d'informations sur les normes concerne les normes auxquelles les nouvelles architectures doivent se conformer, ce qui peut inclure les normes de l'industrie, les produits et services sélectionnés des fournisseurs ou les services partagés déjà déployés au sein de l'organisation.
  • La bibliothèque de référence fournit des directives, des modèles et d'autres types de documents de référence pouvant être utilisés pour accélérer la création de nouvelles architectures pour l'entreprise.
  • Le journal de gouvernance fournit un enregistrement de l'activité de gouvernance dans l'entreprise.

 

Paysage d'architecture

Le paysage d'architecture contient des vues architecturales de l'état de l'entreprise à des moments particuliers.

En raison du volume et des besoins variés des parties prenantes dans toute l'entreprise, le paysage d'architecture est divisé en trois niveaux de granularité :

 

  1. Les architectures stratégiques présentent une vue récapitulative à long terme de l'ensemble de l'entreprise. Les architectures stratégiques fournissent un cadre d'organisation pour les activités opérationnelles et de changement et permettent l'établissement de directives au niveau de la direction.
  2. Les architectures de segment fournissent des modèles opérationnels plus détaillés pour les zones au sein d'une entreprise.
    Les architectures de segment peuvent être utilisées au niveau du programme ou du portefeuille pour organiser et aligner opérationnellement une activité de changement plus détaillée.
  3. Les architectures de capacités montrent de manière plus détaillée comment l'entreprise peut prendre en charge une unité de capacité particulière.
    Les architectures de capacités sont utilisées pour fournir une vue d'ensemble de la capacité actuelle, de la capacité cible et des incréments de capacité, et permettent de regrouper des lots de travaux individuels et des projets dans des portefeuilles et des programmes gérés.

 

Bibliothèque de référence

La bibliothèque de référence fournit un référentiel pour contenir des documents de référence qui devraient être utilisés pour développer des architectures.

Les documents de référence détenus peuvent provenir de diverses sources, notamment :

  • Organismes de normalisation
  • Fournisseurs de produits et de services
  • Communautés industrielles ou forums
  • Modèles standards
  • Meilleures pratiques d'entreprise

La bibliothèque de référence doit contenir :

  • Architectures de référence
  • Modèles de référence
  • Bibliothèque de Viewpoint
  • Modèles

Remarque :

  • Les termes architecture de référence et modèle de référence ne sont pas utilisés avec soin dans la plupart des documents.
  • L'architecture de référence et le modèle de référence ont la même relation que l'architecture et le modèle.
  • L'un ou l'autre peut exister en tant qu'état générique ou spécifique à l'organisation.
  • Généralement, une architecture de référence générique fournit à l'équipe d'architecture un aperçu de son architecture de référence spécifique à l'organisation qui sera personnalisée pour une organisation spécifique.
  • Par exemple, une architecture de référence générique peut identifier le besoin de modèles de données.

 

referentiel-togaf-structure-adm-continuum-d-entreprise.PNG

 

Le continuum d'architecture ( voir l’article : Le référentiel TOGAF sous toutes ses coutures : le « Continuum d'Entreprise » et la réutilisation de l'architecture ) peut être considéré comme un schéma de classification de la bibliothèque de référence.

En tant que tel, il illustre comment les architectures de référence peuvent être organisées à travers une gamme - des architectures de base, et des architectures spécifiques à l'industrie, à une architecture spécifique à l'organisation.

 

Les besoins de l'entreprise et les besoins métier sont traités par abstraction décroissante de gauche à droite de l’image.

L'architecte trouvera généralement plus d'éléments architecturaux réutilisables vers la gauche de la gamme.

Lorsque les éléments ne sont pas trouvés, les exigences pour les éléments manquants sont passées à gauche de la plage pour incorporation.

 

Base d'information sur les normes

La base d'informations sur les normes fournit une zone de référentiel pour contenir un ensemble de spécifications auxquelles les architectures doivent se conformer.

L'établissement d'une base d'information sur les normes fournit une base non ambiguë à la gouvernance architecturale parce que :

  • Les normes sont facilement accessibles aux projets et, par conséquent, les obligations du projet peuvent être comprises et planifiées
  • Les normes sont énoncées de manière claire et non ambiguë, de sorte que la conformité peut être évaluée objectivement

Types de normes

Les normes relèvent généralement de trois classes :

  • Obligations légales et réglementaires : Ces normes sont prescrites par la loi et par conséquent une entreprise doit se conformer ou faire face à des conséquences graves.
  • Normes de l'industrie : Ces normes sont établies par des organismes de l'industrie, tels que The Open Group, et sont ensuite sélectionnés par l'entreprise pour adoption.
    Les normes industrielles offrent un potentiel d'interopérabilité et de partage entre les entreprises, mais échappent également au contrôle de l'entreprise et doivent donc faire l'objet d'un suivi actif.
  • Normes organisationnelles : Ces normes sont définies au sein de l'organisation et sont basées sur l'aspiration de l'entreprise (par exemple, la sélection d'applications standard pour soutenir la consolidation du portefeuille).
    Les normes organisationnelles exigent des processus permettant des exemptions et évolution des normes.

Cycle de vie des normes

Les normes n'existent généralement pas pour tous les temps.

Les nouvelles normes sont identifiées et gérées à travers un processus de cycle de vie. Généralement, les normes passent par les étapes suivantes :

  • Norme proposée : Une norme potentielle a été identifiée pour l'organisation, mais n'a pas encore été évaluée pour adoption.
  • Norme provisoire (également connue sous le nom de norme d'essai) : Une norme provisoire a été identifiée comme norme potentielle pour l'organisation, mais n'a pas été essayée et testée à un niveau où sa valeur est entièrement comprise.
    Les projets qui souhaitent adopter des normes provisoires peuvent le faire, mais dans des conditions pilotes spécifiques, de sorte que la viabilité de la norme puisse être examinée plus en détail.
  • Standard (également connu sous le nom de norme active) : Une norme définit une solution conventionnelle qui devrait généralement être utilisée comme l'approche de choix.
  • Norme de suppression progressive (également appelée norme obsolète) : Une norme de suppression progressive approche la fin de son cycle de vie utile.
    Les projets qui réutilisent des composants existants peuvent généralement continuer à utiliser les normes de suppression progressive. Le déploiement de nouvelles instances de la norme Phasing-Out est généralement déconseillé.
  • Norme retirée (également appelée norme obsolète) : Une norme retirée n'est plus acceptée comme valide dans le paysage. Dans la plupart des cas, des mesures correctives doivent être prises pour retirer la norme retirée du paysage. Le changement d'activité sur une Norme retirée ne devrait être accepté que dans le cadre d'un plan global de déclassement.

Toutes les normes doivent être révisées périodiquement pour s'assurer qu'elles se situent dans la bonne phase du cycle de vie des normes.

Dans le cadre de la gestion du cycle de vie des normes, l'impact de la modification de l'état du cycle de vie doit être abordé pour comprendre l'impact sur l'environnement d'un changement de norme et planifier les actions appropriées pour y remédier.

 

Classification des normes dans la base d'information sur les normes

Les normes de la base d'information sur les normes sont classées en fonction des éléments constitutifs du métamodèle de contenu TOGAF.

Chaque entité de métamodèle peut potentiellement avoir des normes associées (par exemple, Business Service, composant technologique).

 

Les normes peuvent concerner des blocs de construction « approuvés » (par exemple, une liste de composants technologiques standard) ou peuvent spécifier une utilisation appropriée d'un bloc de construction (par exemple, scénarios dans lesquels une infrastructure de messagerie est appropriée, normes de communication d'application définies).

 

Au niveau supérieur, les normes sont classées en fonction des domaines d'architecture TOGAF, notamment les domaines suivants :

Normes métiers :

  • Fonctions commerciales partagées standard
  • Rôles standard et définitions des acteurs
  • Normes de sécurité et de gouvernance pour les activités commerciales

Normes de données :

  • Codage standard et valeurs pour les données
  • Structures et formats standards pour les données
  • Normes d'origine et de propriété des données
  • Restrictions sur la réplication et l'accès

Normes d'applications :

  • Applications standard / partagées prenant en charge des fonctions métier spécifiques
  • Normes pour la communication et l'interopérabilité des applications
  • Normes d'accès, de présentation et de style

Normes technologiques

  • Produits matériels standard
  • Produits logiciels standard
  • Normes pour le développement de logiciels

 

Journal de gouvernance

Le journal de gouvernance fournit une zone de référentiel pour contenir des informations partagées relatives à la gouvernance en cours des projets.

Maintenir un référentiel partagé d'informations de gouvernance est important, car :

  • Les décisions prises au cours des projets (telles que les écarts de normes ou la justification d'une approche architecturale particulière) sont importantes pour conserver et accéder de façon continue.
    Par exemple, si un système doit être remplacé, la visibilité des décisions architecturales clés qui ont façonné la mise en œuvre initiale est très précieuse, car elle mettra en évidence des contraintes qui pourraient autrement être obscurcies.
  • De nombreuses parties prenantes sont intéressées par les résultats de la gouvernance du projet (par exemple, d'autres projets, les clients du projet, le Conseil d'architecture, etc.).

Contenu du journal de gouvernance

Le journal de gouvernance doit contenir les éléments suivants :

Journal des décisions : journal de toutes les décisions importantes sur le plan architectural qui ont été prises dans l'organisation. Cela comprend généralement :

  • Sélections de produits
  • Justification des principales caractéristiques architecturales des projets
  • Les écarts de normes
  • Changements du cycle de vie des normes
  • Modification des demandes d'évaluation et d'approbation
  • Évaluations de réutilisation

Évaluations de la conformité : Aux étapes clés du contrôle des progrès d'un projet, une revue formelle de l'architecture sera effectuée. Cet examen permettra de mesurer la conformité du projet aux normes d'architecture définies. Pour chaque projet, ce journal devrait inclure:

  • Aperçu du projet
  • Aperçu de l'avancement (chronologie, état, problèmes, risques, dépendances, etc.)
  • Listes de contrôle de l'architecture terminées
  • Évaluation de la conformité aux normes
  • Actions recommandées

Évaluations de la capacité : Selon leurs objectifs, certains projets effectueront des évaluations de la capacité opérationnelle, informatique ou d'architecture. Ces évaluations devraient être effectuées périodiquement et suivies pour s'assurer que les progrès appropriés sont réalisés. Ce journal devrait inclure :

  • Modèles et modèles de référence pour l'exécution des évaluations de capacités
  • Évaluations de la capacité d'entreprise
  • Capacités informatiques, maturité et évaluations d'impact
  • Évaluations de maturité d'architecture

Calendrier : Le calendrier devrait afficher un calendrier des projets en vol et des sessions d'examen formel à tenir contre ces projets.

Portefeuille de projets: Le portefeuille de projets devrait contenir des renseignements sommaires sur tous les projets en vol relevant de la gouvernance architecturale, notamment:

  • Le nom et la description du projet
  • Portée architecturale du projet
  • Rôles et responsabilités architecturales associés au projet

Mesure du rendement : Basé sur une charte pour la fonction d'architecture, un certain nombre de critères de performance seront typiquement définis.

Le journal de mesure du rendement doit saisir les mesures relatives à la gouvernance du projet et à toute autre mesure du rendement liée à la charte d'architecture afin que la performance puisse être mesurée et évaluée de façon continue.

 

Le référentiel d'entreprise

Bien que le référentiel d'architecture contienne des informations concernant l'architecture d'entreprise et les artefacts associés, un nombre considérable de référentiels d'entreprise prennent en charge l'architecture.

Ceux-ci incluent les exigences de stockage du référentiel des exigences et les blocs de construction de solution de stockage des solutions de stockage (SBB).

Les résultats métier des besoins seront reflétés dans le référentiel de solutions au fil du temps.

Lorsque cela se produit, les exigences sont respectées et archivées à des fins d'audit.

Référentiel d'exigences

Le référentiel des exigences est utilisé par la phase de gestion des exigences de la méthode de développement d'architecture (ADM) pour enregistrer et gérer toutes les informations relatives aux exigences d'architecture.

Les exigences répondent aux nombreux types d'exigences d'architecture ; c'est-à-dire, les exigences stratégiques, de segment et de capacité qui sont les principaux moteurs de l'architecture d'entreprise.

Les exigences peuvent être collectées à chaque étape du cycle de développement de l'architecture et doivent être approuvées à travers les différentes phases et processus de gouvernance.

Référentiel de solutions

Le référentiel de solutions contient les Building Building Blocks (SBB).

 

Dépôts externes

Modèles de référence externes

De nombreux modèles de référence de l'industrie peuvent aider à comprendre le rôle et le développement des architectures de référence. Les exemples incluent MDA d'OMG, FEA pour le gouvernement américain, TMF de l'industrie des télécommunications, modèles de référence SOA d'OASIS et The Open Group.

Normes externes

Ceux-ci se rapportent à l'industrie, aux meilleures pratiques ou aux normes formelles définies utilisées par les principales organisations. Les exemples incluent les normes ISO, IEEE, OMG et gouvernementales.

Approbations du conseil d'architecture

Les décisions prises par le Conseil d'architecture qui affectent l'architecture de l'entreprise sont souvent consignées dans les procès-verbaux des réunions.

Ces PVs sont souvent conservées dans des archives de documentation qui sont exclues du référentiel d'architecture pour des raisons légales ou réglementaires.

 

Conclusion

Un soin particulier doit être apporté à la diffusion des éléments stratégiques dans le référentiel d'architecture.

La qualité des informations (lisibilité, disponibilité, pertinence, structure) conditionne l'efficacité de son utilisation.

Patterns, guides, méthodes, exemples seront d'autant plus acceptés s'ils fournissent une réelle valeur ajoutée et une aide concrète aux équipes opérationnelles.

 

Rhona Maxwel

@rhona_helena

 

"Si tu as une pomme, que j’ai une pomme, et que l’on échange nos pommes, nous aurons chacun une pomme. Mais si tu as une idée, que j’ai une idée et que l’on échange nos idées, nous aurons chacun deux idées."

Georges Bernard Shaw

 

 

Articles conseillés :

 

La vision dynamique des exigences de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework) 

 

La structure de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

 

Les concepts du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

 

Le diagramme de classe UML du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)



23/01/2018
0 Poster un commentaire

A découvrir aussi


Inscrivez-vous au site

Soyez prévenu par email des prochaines mises à jour

Rejoignez les 757 autres membres