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
- Regard sur 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 de 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.
Lorsqu'on examine les architectures de référence, on distingue souvent deux types d'architectures : celles qui exposent la structure d'un système et celles qui illustrent son fonctionnement. N'oubliez pas que le mot « système » n'a aucune connotation informatique. On peut décrire la fusion nucléaire du Soleil, un marché et le lancement d'un produit comme un système.
Parties attendues d'une architecture de référence
Les architectures de référence complètes comprendront plus qu'un modèle. Parmi les composants potentiels, on peut citer :
- Portée du système d'intérêt
Limites du système et explication du problème. Peut inclure des objectifs, des finalités particulières et des défis à relever. - Modèle(s) du système
- Composants d'un système
- Relations entre les composants
- Attributs à spécifier
Naviguer inclut les attributs d'architecture de différents composants. Ils peuvent aller du 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 phrases liées au système d'intérêt
- Modèles d'architecture du système
- Principes d'architecture du système
- Bibliothèque du point 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 internes du système. Elle peut inclure l'identification des composants dépassant le cadre de l'architecture de référence afin d'expliquer comment celle-ci 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 très abstraite peut représenter les éléments constitutifs d'une chaîne d'approvisionnement (SCOR) ou les informations nécessaires à la gestion des 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 SCOR pour la chaîne d'approvisionnement en est un exemple : elle présente les activités communes à différentes approches de chaîne d'approvisionnement. Elle montre comment assembler ces composants pour créer une solution.
Regard sur la structure d'un système
Les modèles de référence qui facilitent la compréhension de la structure d'un système fournissent les bases de ce dernier. Ils existent à différents niveaux de détail et identifient les éléments clés d'un système. Les modèles de référence de structure sont généralement statiques et sont généralement présentés sous forme de graphique simple ou de tableau.
Presque toutes les architectures d’entreprise utilisent des modèles statiques.
Des exemples de modèles de référence de structure incluent :
- Modèle de référence des services gouvernementaux (GSRM) 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 la structure du système pour tester l’exhaustivité et accélérer le développement d’une architecture unique.
Regard sur la fonction d'un système
Les modèles de référence qui facilitent la compréhension du fonctionnement d'un système permettent d'en identifier le fonctionnement. Ils permettent d'identifier les interactions entre ses composants. Les modèles de référence fonctionnels sont souvent représentés sous forme de diagramme. Ils sont généralement accompagnés d'une documentation et d'un modèle dynamique. Des modèles fonctionnels performants permettent de les tester.
Nous utilisons Dynamique des systèmes explorer des modèles fonctionnels solides. Comprendre le fonctionnement d'un système est essentiel pour comprendre les leviers et les freins efficaces au changement. L'exemple ci-dessus concerne l'adoption d'un nouveau produit ; pensez à un exemple qui illustre le développement de agilité de l'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, puis tester l'exhaustivité et la précision de votre modèle. Tout ce temps est consacré au démarrage de l'analyse.
Les architectures de référence facilitent la collaboration et la communication. Elles aident les équipes à éviter les erreurs et les retards. Elles constituent une base pour la gouvernance.
Il existe d’autres utilisations puissantes, notamment 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
Tester l'exhaustivité de l'architecture
Une architecture de référence fournit toujours les composants d'un système et leurs relations. Cela signifie que nous pouvons utiliser une architecture de référence pour garantir que toute analyse ou conception architecturale tienne compte de l'ensemble 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 est non pertinent. Les composants manquants constituent 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 de l'architecture de référence. Ensuite, lorsque des travaux d'architecture ou de conception plus détaillés sont réalisés, 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 problématique, plus il est facile de mettre en œuvre les décisions applicables. Cependant, la conservation d'un historique complet des décisions nécessite des efforts accrus.
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 niveau de détail de l'état futur et de la feuille de route. Le diagramme ci-dessous illustre la profondeur et le niveau de détail croissants de la gouvernance de la mise en œuvre à partir de trois sources de solution.
Une solution ascendante est identifiée par les personnes directement concernées. Elle ne comblera aucune lacune identifiée par conception. Les orientations disponibles constitueront l'architecture cible globale.
Une solution pour combler une lacune 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 s'appuie sur l'écart entre la situation actuelle et la situation future. Cette orientation se résume à ce qui devrait changer (lacune) et à ce qui devrait rester inchangé (tout le reste). Cela permet de délimiter la solution, de déterminer où elle est censée améliorer l'organisation et où elle devrait utiliser l'existant.
Les solutions élaborées avec une feuille de route sont descendantes. Le lot de travaux visant à combler une lacune est inscrit sur une feuille de route. Ce travail sera parrainé. Le portefeuille définira des attentes de performance précises et une stratégie de mise en œuvre. L'écart à combler peut également être affiné en fonction de l'état de transition visé par la feuille de route.
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'entreprise. Chaque 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. Ses objectifs et ses contraintes sont clairs.
Les propriétaires de portefeuilles sont tournés vers l'avenir. Ils entendent impulser le changement et produire les bénéfices escomptés dans les limites de leurs contraintes.
L'orientation future du responsable de portefeuille vers l'action nécessite un travail d'architecture axé sur la facilitation du changement. Le responsable de portefeuille doit prendre des décisions en amont pour stimuler les activités qui produiront les résultats dont il est responsable. Le praticien a besoin de :
- 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 recherchent un équilibre parfait entre une planification descendante et ascendante. La planification descendante garantit la prise en compte des attentes de performance, des contraintes et des dépendances. La planification ascendante met en valeur 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 les dépendances et les synergies. Plus important encore, ils savent où s'arrêter, générer de la valeur et changer de direction. Les transitions progressives favorisent directement l'agilité de l'entreprise et 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.
Cas d'utilisation de la livraison de solutions de soutien
L'architecture de livraison de solutions repose sur une hypothèse clé : l'objectif global et les changements nécessaires à sa réalisation sont connus. Une solution comble des lacunes connues, malgré des contraintes connues qui limitent la créativité et la liberté des implémenteurs.
L'orientation actionnelle actuelle d'un implémenteur exige que l'architecture se concentre sur la transmission des attentes de performance et des contraintes externes. L'implémenteur se concentre sur les attentes de performance et les contraintes de ses différents projets. Sa tâche consiste à mobiliser les ressources et à les exécuter. Il doit connaître ses attentes et 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 performance
- Soutenir directement la gouvernance de la mise en œuvre
- Guider efficacement la mise en œuvre
Il est important de noter que l’architecture de fourniture 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 performance issues d'une architecture supérieure
- Attentes de performance et contraintes qui seront appliquées à la mise en œuvre
Le livrable critique est une architecture de solution qui précise les lacunes futures que la solution comblera, ainsi que les contraintes et attentes de performance applicables. Lorsqu'une feuille de route précise 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 problématique spécifique. Formellement, 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 ce concept à un niveau de détail précis. 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 sectorielles, 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 les humains : 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 doit fournir un point de départ pour les fondamentaux. SCOR décrit les processus de la chaîne d'approvisionnement et trois modèles de fabrication. Plutôt que de partir d'une feuille blanche, vous disposez déjà des informations essentielles. Ainsi, vous ne perdez pas de temps à réinventer la roue inutilement. Au lieu de cela, vous pouvez travailler sur les aspects uniques de la roue dans votre cas d'utilisation spécifique. Les roues d'avion doivent accélérer de 0 à 225 km/h instantanément. Les roues du rover lunaire devaient être très légères et ne pas projeter de poussière. Toutes deux sont rondes, amovibles et utilisées pour la direction. Tout dépend du cas d'utilisation.
Deuxièmement, il faut comprendre le fonctionnement d'un système. Il n'est pas nécessaire de comprendre les composants d'un système et leurs interactions. Il faut plutôt chercher comment l'architecture optimise les composants et leurs interactions pour un cas d'utilisation précis. Les sept leviers de la transformation numérique est un excellent exemple.
Troisièmement, il faut pouvoir utiliser des références l'architecture dans la gouvernance de l'architecture. L'architecture de référence permet d'évaluer une conception afin de s'assurer qu'elle a pris en compte tous les besoins attendus d'un système. Par exemple, dans le cadre du GSRM, tous les permis révocables nécessitent un processus permettant de déterminer si le titulaire peut conserver son permis et une procédure d'appel. 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 présents.
Pour aller plus loin, regardez Utilisation 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 :
- Les sept leviers de la transformation numérique fournit une architecture de référence pour la transformation d'une entreprise
- IT4IT est une architecture de référence d'information pour les fonctions des technologies de l'information.
- BIAN 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 sectorielles. APQC sert souvent de base à 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 système, y compris une Architecture des services de sécurité.
- Le Département de la Défense des États-Unis fournit Architecture de référence Zero Trust.
Architectures de référence standard TOGAF
Le Norme TOGAF Comprend deux architectures de référence : l'architecture technique de référence et le modèle de référence d'infrastructure d'information intégrée. Une terminologie normalisée permet une compréhension commune. Par exemple, les normes d'architecture de référence peuvent fournir un langage commun.
Architecture de référence vs modèle de référence
La plupart des gens utilisent « Architecture de référence » et « Modèle de référence » comme synonymes. Techniquement, ils sont distincts, mais cette différence est sans importance 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, tandis qu'une architecture de référence explique le système dans son intégralité. La distinction est liée à la portée du ‘ système ’. Cependant, presque tout le monde utilise ces termes de manière interchangeable. Il serait plus judicieux de fournir une architecture utile pour guider le changement plutôt que de s'attarder 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. Cadre TOGAF propose des méthodes pour décrire et identifier les entrées d'architecture.
L'architecture de référence va plus loin en accélérant le processus pour un type d'architecture spécifique, en aidant à déterminer les approches architecturales qui répondront à des exigences spécifiques et en déterminant l'ensemble minimal d'artefacts architecturaux requis pour satisfaire aux exigences des " meilleures pratiques " d'une architecture donnée. Les architectures de référence accordent une grande importance à 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 largement reconnues du secteur et recommandent souvent la stratégie de déploiement 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 construits, 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 indique comment évaluer le système.
Architecture de référence des capacités d'architecture d'entreprise
Téléchargez le Architecture de référence des capacités d'architecture d'entreprise. C’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é.
