Qu'est-ce qu'une architecture de référence ?
Qu'est-ce qu'une architecture de référence ?
- Parties attendues d'une architecture de référence
- Principes de base d'une architecture de référence
- Examiner la structure d'un système
- Aperçu attendu du fonctionnement d'un système
Pourquoi utiliser une architecture de référence
- Test d'exhaustivité de l'architecture
- Simplification des directions en cascade et des contraintes pour la gouvernance
- Répondre systématiquement aux questions importantes
- Utilisation d'une architecture de référence avec des cas d'utilisation EA standard
- Quelles industries utilisent les architectures de référence
Qu'est-ce qu'une architecture de référence ?
Une architecture de référence est une architecture générique qui identifie les contours normaux d'un système. Elle fournit les composants, les relations, les principes et les directives architecturales.
Techniquement, l'architecture de référence est considérée comme faisant partie l'architecture d'entreprise. En termes de TOGAF Continuum d'entreprise, vous trouverez des exemples fondamentaux, communs ou sectoriels.
Les meilleures architectures de référence garantissent que le problème et chaque partie importante sont exposés.
Lorsque nous examinons les architectures de référence, nous voyons souvent deux types différents : celles qui exposent la structure d'un système et celles qui montrent comment un système fonctionne. N'oubliez pas que le mot système n'a aucune connotation informatique. Vous pouvez décrire la fusion nucléaire du Soleil, un marché et une sortie de produit comme un système.
Parties attendues d'une architecture de référence
Les architectures de référence complètes incluront plus qu'un modèle. Les composants potentiels incluent :
- Portée du système d'intérêt
Limite du système et explication du problème. Peut inclure des objectifs, des buts particuliers et des défis qui doivent être résolus - Modèle(s) du système
- Composants d'un système
- Relations entre composants
- Attributs à spécifier
Naviguer inclut les attributs d'architecture de différents composants. Ils peuvent aller d'un modèle d'exploitation préféré d'un capacité commerciale à la durée de vie prévue d'une interface - Vocabulaire
Un glossaire spécialisé avec des définitions et des expressions liées au système d'intérêt
- Modèles d'architecture du système
- Principes architecturaux du système
- Bibliothèque de points de vue
- Meilleures pratiques dans le système
Les bases de l'architecture de référence
Une architecture de référence doit comprendre les composants et les relations à l'intérieur du système. Elle peut inclure l'identification des composants au-delà du champ d'application de l'architecture de référence pour expliquer comment la référence s'intègre dans un ensemble plus vaste.
Les architectures de référence peuvent être développées à différents niveaux d'abstraction. Une architecture assez abstraite peut afficher les éléments constitutifs d'une chaîne d'approvisionnement (SCOR) ou les informations nécessaires à la gestion de produits numériques (IT4IT).
Une approche courante pour une architecture de référence consiste à généraliser plusieurs solutions. La référence de la chaîne d'approvisionnement de SCOR en est un exemple : elle montre les activités communes aux différentes approches de la chaîne d'approvisionnement. La référence de SCOR montre comment assembler ces composants pour créer une solution.
Examiner la structure d'un système
Les modèles de référence qui permettent de comprendre la structure du système fournissent les bases d'un système. Ils existeront à différents niveaux de détail et identifieront les éléments centraux d'un système. Les modèles de référence de structure sont généralement des modèles statiques et sont normalement présentés sous forme de graphique simple ou de tableau.
Presque toutes les architectures d'entreprise utilisent des modèles statiques.
Exemple de modèles de référence de structure :
- Le GSRM (Modèle de référence des services gouvernementaux) du Canada
- Modèle de référence technique de l'architecture d'entreprise fédérale américaine
- Architecture de référence des capacités d'architecture d'entreprise
Nous utilisons System Structure pour tester l'exhaustivité et accélérer le développement d'une architecture unique.
Examiner la fonction d'un système
Les modèles de référence qui prennent en charge la compréhension de la fonction du système identifient le fonctionnement d'un système. Ils identifieront l'interaction des composants dans un système. Les modèles de référence de fonction sont souvent représentés dans un diagramme. Il y aura généralement un ensemble de pièces justificatives et un modèle dynamique. Des modèles fonctionnels forts peuvent être exercés.
Nous utilisons Dynamique du système pour explorer des modèles fonctionnels solides. Comprendre le fonctionnement d'un système est essentiel pour comprendre les leviers et les obstacles efficaces au changement. L'exemple ci-dessus concerne l'adoption d'un nouveau produit - pensez à un exemple qui a montré le développement de agilité d'entreprise ou supprimer la dette technique.
Pourquoi utiliser un modèle de référence
Nous simplifions la valeur de l’utilisation d’architectures de référence pour accélérer les délais de livraison et améliorer la qualité.
Avec un modèle de référence vous avez :
- confiance que tous les composants clés, relations et attributs sont pris en compte
- capacité à passer à l'identification de la source des déficiences et de leur solution
Sans architecture de référence, vous devez comprendre le système. Ensuite, tester votre modèle pour en vérifier l'exhaustivité et la précision. Tout ce temps est consacré au début de l'analyse.
Les architectures de référence facilitent la collaboration et la communication. Une architecture de référence aide les équipes à éviter les erreurs et les retards. Elle fournit une base pour la gouvernance.
Il existe d'autres utilisations puissantes qui incluent les suivantes.
- Test d'exhaustivité de l'architecture
- Simplification des directions en cascade et des contraintes pour la gouvernance
- Répondre systématiquement aux questions importantes
Test de l'exhaustivité de l'architecture
Une architecture de référence fournira toujours les composants d'un système et la relation entre les composants. Cela signifie que nous pouvons utiliser une architecture de référence pour garantir que toute analyse ou conception d'architecture prend en compte l'intégralité du système.
Lorsque des composants de la référence sont manquants dans le système, déterminez s'il existe une lacune dans le système ou si le composant n'est pas pertinent. Les composants manquants sont des lacunes dans le système.
Décision d'architecture supérieure en cascade
Le fondement de la gouvernance de l’architecture et de la gouvernance de la mise en œuvre est la capacité à faire passer une décision d’architecture de la vision et de la stratégie à la mise en œuvre.
Dans la mesure du possible, nous appliquons les décisions d'architecture aux composants d'architecture de référence. Ensuite, lorsque des travaux d'architecture ou de conception plus détaillés sont nécessaires, nous pouvons tester la conformité par rapport à une référence. Il existe un équilibre entre applicabilité et effort. Plus l'architecture de référence est applicable à un espace de problème, plus il est facile de mettre en œuvre des décisions applicables. Cependant, l'effort pour conserver un enregistrement de bout en bout des décisions augmente.
Gouvernance de la mise en œuvre de la livraison de solutions
Nous savons que le résultat le plus important du cas d’utilisation de la livraison de solutions est de permettre gouvernance de la mise en œuvre.
La profondeur de la gouvernance de la mise en œuvre dépend du degré de détail de l'état futur et de la feuille de route. Le diagramme ci-dessous fournit une visualisation de la profondeur et du niveau de détail croissants de la gouvernance de la mise en œuvre à l'aide de trois sources pour la solution.
Une solution ascendante est identifiée par les personnes directement concernées. Elle ne comblera pas de lacunes identifiées par conception. Les orientations disponibles constitueront l'architecture cible globale.
Une solution de comblement des lacunes sera identifiée soit par les personnes directement concernées, soit dans le cadre d'un plan de mise en œuvre. Ce type de solution ajoute des orientations à partir de l'écart entre l'état actuel et l'état futur. Ces orientations se résument à ce qui est censé changer (lacune) et à ce qui est censé rester le même (tout le reste). Cela fournit une limite pour la solution, où elle est censée améliorer l'organisation et où elle est censée utiliser ce qui est en place.
Les solutions élaborées à partir d'une feuille de route sont descendantes. Le lot de travail destiné à combler une lacune est inscrit sur une feuille de route. Le travail sera parrainé. Le portefeuille fournira des attentes de performance spécifiques et une stratégie de mise en œuvre. L'écart à combler peut également être affiné en fonction de tout état de transition vers lequel la feuille de route tend.
Utilisation d'une architecture de référence avec des cas d'utilisation EA standard
Il y a quatre cas d'utilisation standard d'architecture d'entrepriseChaque cas d’utilisation vise à aider un public différent à conduire un changement efficace.
Cas d'utilisation du portefeuille de soutien
Le travail d'architecture est axé sur le service au propriétaire du portefeuille. Le portefeuille existe. Il a des résultats et des contraintes clairs.
Les propriétaires de portefeuilles sont tournés vers l'avenir. Ils ont l'intention de conduire le changement et de fournir les avantages attendus dans les limites de leurs contraintes.
L'orientation future du propriétaire d'un portefeuille vers l'action nécessite un travail d'architecture qui se concentre sur la mise en œuvre du changement. Le propriétaire du portefeuille doit prendre des décisions à l'avance pour stimuler l'activité qui aboutira aux résultats dont il est responsable. Le praticien a besoin :
- Une architecture de bout en bout pour fournir un contexte, des conseils et des contraintes au portefeuille
- Une ou plusieurs descriptions d'architecture ciblées qui sont alignées sur le résultat et les principaux composants du portefeuille
Les propriétaires de portefeuilles visent un équilibre parfait entre la planification descendante et ascendante. La planification descendante garantit que les attentes en matière de performance, les contraintes et les dépendances sont couvertes. La planification ascendante capture les connaissances et la créativité locales.
Les propriétaires de portefeuille et les autres parties prenantes utilisent le feuille de route architecturale pour diriger les projets d'amélioration. Ils comprennent la dépendance et la synergie. Plus important encore, ils comprennent les points où ils peuvent s'arrêter, récolter de la valeur et changer de direction. Les points de transition incrémentiels soutiennent directement l'agilité de l'entreprise avec la création de valeur.
Dans le travail de portefeuille, les spécifications d’architecture sont axées sur les lots de travail et les principes et modèles d’architecture.
Prise en charge du cas d'utilisation de la livraison de solutions
L'architecture de mise en œuvre d'une solution repose sur une hypothèse clé : l'objectif global et les changements nécessaires pour l'atteindre sont connus. Une solution comble des lacunes connues dans le cadre de contraintes connues qui limitent la créativité et la liberté des exécutants.
L'orientation actuelle vers l'action d'un implémenteur nécessite que l'architecture se concentre sur la transmission des attentes en matière de performances et des contraintes externes. L'implémenteur se concentre sur les attentes en matière de performances et les contraintes de ses différents projets. Son travail consiste à mobiliser les ressources et à exécuter. L'implémenteur doit savoir ce qu'il est censé faire et quelles sont les limites de sa créativité. Le cas d'utilisation standard identifie les travaux d'architecture qui doivent :
- Définit comment le changement sera effectué, les contraintes applicables et les attentes en matière de performances
- Soutenir directement la gouvernance de la mise en œuvre
- Guider efficacement la mise en œuvre
Il est important de noter que l’architecture de livraison de solutions est principalement conçue pour la gouvernance de la mise en œuvre afin de soutenir les propriétaires des résultats.
Les éléments les plus importants d’une architecture de solution sont :
- Les lacunes à combler
- Les composants de la solution et leur relation
- Attentes et contraintes de performances issues d'une architecture supérieure
- Attentes et contraintes de performance qui seront appliquées à la mise en œuvre
Le livrable critique est une architecture de solution qui spécifie les lacunes dans l'état futur que la solution comblera, ainsi que les éventuelles contraintes et attentes en matière de performances. Lorsqu'une feuille de route spécifie la stratégie de mise en œuvre, l'approche de la solution doit être incluse dans l'architecture de la solution.
Une architecture de solution se distingue par ses limites. Elle aborde un espace de problème spécifique. En termes formels, il s'agit d'un système d'intérêt spécifique qui s'intègre et interagit avec d'autres systèmes. Nous ne lions pas le concept à un niveau de détail spécifique. Il suffit de dire qu'une architecture de solution sera plus détaillée que l'architecture environnante.
Quelles industries utilisent l'architecture de référence ?
Les architectures de référence sont utilisées dans tous les secteurs.
Il existe des architectures de référence spécifiques à chaque secteur, ainsi que des domaines plus spécifiques comme la chaîne d'approvisionnement, l'IA, l'infrastructure informatique, le cloud public ou les conteneurs.
L'image ci-dessus fournit un ensemble de modèles de référence pour l'homme - modèle respiratoire, modèle squelettique, modèle circulatoire, modèle digestif et système nerveux.
Comment utiliser une architecture de référence ?
Il existe trois façons d'utiliser une bonne architecture de référence.
Tout d'abord, il devrait fournir un point de départ pour les bases. SCOR décrit les processus de la chaîne d'approvisionnement et trois modèles de fabrication. Plutôt que de commencer avec une feuille de papier vierge. Vous disposez déjà des informations de base essentielles. De cette façon, vous ne perdez pas de temps à réinventer la roue lorsque vous n'en avez pas besoin. Au lieu de cela, on peut travailler sur les aspects uniques de la roue dans leur cas d'utilisation spécifique. Les roues des avions doivent accélérer de 0 à 140 MPH instantanément. Les roues du rover lunaire devaient être très légères et ne pas projeter de poussière. Les deux sont ronds, amovibles et utilisés pour diriger. Tout se résume à un cas d'utilisation.
Deuxièmement, il doit permettre de comprendre le fonctionnement d'un système. Vous n'avez pas besoin de comprendre les parties d'un système et comment elles interagissent. Au lieu de cela, il faut chercher comment l'architecture optimise les parties et les interactions pour son cas d'utilisation. Sept leviers de la transformation numérique est un excellent exemple.
Troisièmement, on devrait pouvoir utiliser la référence architecture dans la gouvernance de l'architecture. L'architecture de référence est utilisée pour évaluer une conception afin de s'assurer que la conception a pris en compte tous les besoins attendus d'un système. Par exemple, dans le GSRM, tous les permis révocables nécessitent un processus permettant d'évaluer si le titulaire du permis peut toujours conserver un permis et un processus d'appel. Peu importe qu'il s'agisse d'un permis de conduire, d'un permis médical ou d'un permis de transport de déchets nucléaires, tous les processus doivent être là.
Pour aller plus loin, regardez Utiliser des architectures de référence pour la transformation numérique.
Exemples d'architecture de référence
Il existe de nombreux exemples d’architecture de référence :
- Sept leviers de la transformation numérique fournit une architecture de référence pour transformer une entreprise
- IT4IT est une architecture de référence de l'information pour les fonctions des technologies de l'information.
- BIEN est une architecture de référence pour le secteur bancaire.
- SCOR est une architecture de référence pour la supply chain.
- APQC fournit des architectures de référence de processus métier intersectorielles ou spécifiques à l'industrie. APQC est souvent utilisé comme base pour modèles de processus métier ou modèles de capacité.
- Eulynx peut être utilisé pour les systèmes de signalisation routière.
- Le GSRM (Modèle de référence des services gouvernementaux du Canada) fournit une architecture de référence pour les services gouvernementaux.
- Architecture de référence des capacités EA est utilisé pour accélérer le développement d'une équipe EA.
- AUTOSAR est un type d'architecture de référence axée sur les composants pour les logiciels de véhicules.
- AWS dispose de nombreuses architectures de référence de structure de système, y compris un Architecture des services de sécurité.
- Le DoD américain fournit Architecture de référence zéro confiance.
Architectures de référence standard TOGAF
le Norme TOGAF comprend deux architectures de référence : l'architecture de référence technique et le modèle de référence d'infrastructure d'information intégrée. Une compréhension commune peut être obtenue à l'aide d'une terminologie normalisée. Par exemple, les normes architecturales de référence peuvent fournir un langage partagé.
Architecture de référence vs modèle de référence
La plupart des gens utilisent l'architecture de référence et le modèle de référence comme synonymes. Techniquement, ils sont distincts, mais la différence n'est pas pertinente pour la plupart des architectes d'entreprise.
D'un point de vue puriste, un modèle de référence explique une partie d'un système, et une architecture de référence explique l'ensemble du système. La distinction est liée à la portée du « système ». Cependant, presque tout le monde utilise les termes de manière interchangeable. Il serait plus utile de fournir une architecture utile qui guide le changement que de passer du temps sur des discussions sémantiques.
L'architecture d'un système est décrite comme étant représentée par un cadre architectural, qui est une encapsulation d'un ensemble minimal de pratiques et de critères. Le Cadre TOGAF propose des méthodes pour décrire et identifier les entrées d'architecture.
L'architecture de référence va encore plus loin en accélérant le processus pour un type d'architecture spécifique, en aidant à déterminer quelles approches architecturales satisferont des exigences spécifiques et en déterminant l'ensemble minimal nécessaire d'artefacts architecturaux requis pour satisfaire aux exigences des « meilleures pratiques » pour un type spécifique. architecture. Les architectures de référence mettent fortement l'accent sur la partie "modèle" du concept.
Tests pour une bonne architecture de référence
Les meilleures architectures de référence représentent les meilleures pratiques de l'industrie largement reconnues et recommandent souvent la stratégie de livraison optimale. Une architecture de référence facile à comprendre améliore la qualité et la rapidité du développement et de la mise en œuvre de l'architecture.
Considérations standard d'un bon modèle de référence :
- consortiums constitués, avec l'engagement de multiples parties prenantes
- encadre l'espace du problème
- identifie les éléments clés
- identifie les relations clés
- vous explique comment évaluer le système.
Architecture de référence des capacités d'architecture d'entreprise
Télécharger le Architecture de référence des capacités d'architecture d'entrepriseC’est la base de la construction d’une équipe d’architecture d’entreprise solide.
Votre modèle de capacité d'architecture d'entreprise est au cœur d'une cadre de capacités d'architecture d'entreprise optimisé.
