Comprendre la Valeur des Architectures de référence
Les architectes n’aiment rien de plus que de discuter des définitions. Si jamais vous vous retrouvez avec du temps mort dans une salle d’architectes, essayez de demander une définition de « Service » ou « architecture » et voyez quel genre de mêlée créative vous pouvez commencer. Cela étant dit, les définitions sont en effet très importantes pour que nous puissions avoir un langage commun pour communiquer l’intention et les avantages des choses mêmes dans lesquelles nous essayons de convaincre les entreprises d’investir. De ce point de vue, un certain nombre de concepts ont émergé au cours de la dernière décennie qui sont devenus une priorité pour les architectes d’entreprise autoproclamés: les cadres d’architecture et les architectures de référence. Dans les ZapFlashes précédents, nous avons discuté des frameworks d’architecture, ce qui laisse le sujet des architectures de référence intact par ZapThink. Puisque nous ne pouvons pas laisser un bon argument derrière nous, nous allons utiliser ce ZapFlash pour explorer les architectures de référence et la valeur qu’elles doivent ajouter à l’histoire de l’Architecture orientée services (SOA).
Qu’est-ce qu’une architecture de référence ?
Une définition communément admise de l’architecture de référence est qu’elle fournit une méthodologie et/ ou un ensemble de pratiques et de modèles basés sur la généralisation d’un ensemble de solutions réussies pour une catégorie particulière de solutions. Les architectures de référence fournissent des conseils sur la façon d’appliquer des modèles et / ou des pratiques spécifiques pour résoudre des classes particulières de problèmes. De cette manière, il sert de « référence » pour les architectures spécifiques que les entreprises mettront en œuvre pour résoudre leurs propres problèmes. Il n’est jamais prévu qu’une architecture de référence soit mise en œuvre telle quelle, mais plutôt utilisée soit comme point de comparaison, soit comme point de départ pour les efforts architecturaux de chaque entreprise.
D’autres affinent la définition de l’architecture de référence en tant que description de la façon de construire une classe d’artefacts. Ces artefacts peuvent prendre de nombreuses formes, notamment des modèles de conception, des méthodologies, des normes, des métadonnées et des documents de toutes sortes. Pour faire court, si vous avez besoin de conseils sur la façon de développer une architecture spécifique basée sur les meilleures pratiques ou des ensembles d’artefacts potentiels faisant autorité, vous devriez vous tourner vers une architecture de référence qui couvre la portée de l’architecture que vous cherchez à construire.
L’un des exemples les plus populaires d’architectures de référence en informatique est l’architecture Java Platform Enterprise Edition (Java EE), qui fournit une architecture de référence en couches et des modèles répondant à une gamme de problèmes technologiques et commerciaux qui ont guidé de nombreux systèmes d’entreprise basés sur Java.
Architectures de référence vs Frameworks d’architecture
Bien que la ou les définitions ci-dessus puissent sembler assez découpées, il y a beaucoup de points communs entre les concepts d’architectures de référence et de frameworks d’architecture. Pour certains, c’est là que les choses deviennent difficiles et que les définitions deviennent floues. Les cadres d’architecture, tels que le Cadre Zachman, le Cadre d’Architecture de Groupe Ouvert (TOGAF) et le Cadre d’architecture du Département de la Défense (DoDAF) fournissent des approches pour décrire et identifier les entrées nécessaires à une architecture particulière ainsi que des moyens de décrire cette architecture. Si une architecture particulière est un livre de cuisine qui fournit des conseils sur la façon de résoudre un ensemble particulier de problèmes avec une approche particulière, un cadre d’architecture est un livre sur la façon d’écrire des livres de cuisine. Ainsi, les frameworks d’architecture donnent aux architectes d’entreprise les outils dont ils ont besoin pour décrire et collecter correctement les exigences, sans imposer de type d’architecture spécifique. Plus précisément, les cadres d’architecture décrivent un exemple de taxonomie des types de « vues » architecturales qu’un architecte pourrait envisager de développer, et pourquoi, et fournissent des lignes directrices pour faire le choix de développer des vues particulières.
Cela diffère du concept ci-dessus d’architecture de référence en ce sens qu’une architecture de référence va plus loin en accélérant le processus pour un type d’architecture particulier, en aidant à identifier les approches architecturales qui satisferont des exigences particulières et en déterminant quel ensemble d’artefacts architecturaux minimalement acceptables sont nécessaires pour répondre aux exigences des « meilleures pratiques » pour une architecture particulière. Pour poursuivre notre analogie avec les livres de cuisine, si un framework d’architecture est un livre sur la façon d’écrire des livres de cuisine, alors une architecture de référence est un livre qui fournit des conseils et des meilleures pratiques sur la façon d’écrire des livres de cuisine axés sur la perte de poids, par exemple. Cela signifierait alors que l’architecture particulière que vous développez pour votre organisation serait un livre de recettes spécifique qui fournit des recettes de perte de poids ciblées pour votre organisation. En effet, si vous êtes perplexe avec les définitions, remplacer le terme « architecture » par « livre de recettes » est utile: cadres de livres de recettes, livres de recettes de référence et votre livre de recettes particulier.
De plus, la plupart des architectures de référence mettent l’accent sur la partie » modèle » de la définition d’une architecture de référence. Les cadres et les AR fournissent des pratiques exemplaires, et bien qu’on puisse soutenir que les AR fournissent davantage une méthodologie qu’un cadre, les AR ne sont toujours pas vraiment caractérisées par leur composante méthodologique. La plupart peuvent cependant être caractérisés par leur composant de modèle. De ce point de vue, les modèles sont des instances de modèles dans ce contexte. En fait, plusieurs architectures de référence pour le même domaine sont admissibles et très utiles. Les architectures de référence peuvent être complémentaires fournissant des conseils pour une architecture unique, telle que SOA, à partir de plusieurs points de vue.
La valeur d’une architecture de référence SOA
À bien des égards, les projets SOA ont désespérément besoin d’architectures de référence bien pensées. ZapThink constate un degré élevé de variabilité dans les projets SOA. Certains s’épanouissent et réussissent tandis que d’autres pataugent et échouent. Souvent, la raison de l’échec peut être attribuée à de mauvaises pratiques architecturales, à l’achat prématuré d’infrastructures et à une gouvernance et une gestion inadéquates. D’autres fois, l’échec est principalement organisationnel. Cependant, ce qui est commun dans la plupart des succès, ce sont des pratiques architecturales bien documentées et / ou communiquées et une méthode systématique pour apprendre de ses erreurs et avoir un faible coût d’échec.
De plus, nous constatons que de nombreux architectes passent une grande partie de leur temps à rechercher, à étudier, à (re)définir, à contempler et à argumenter des décisions architecturales. Dans de nombreux cas, ces architectes réinventent la roue car leurs pairs dans d’autres entreprises, ou même la même entreprise, ont déjà passé ce temps et ces efforts à définir leurs propres pratiques architecturales. Cet effort supplémentaire est non seulement inefficace, mais empêche également l’entreprise d’apprendre de ses propres expériences et d’appliquer ces connaissances pour une efficacité accrue.
De ce point de vue, les architectures de référence SOA peuvent aider ceux qui luttent avec leurs efforts SOA ou qui envisagent d’en lancer un nouveau. Les architectures de référence SOA permettent aux organisations d’apprendre des succès et des échecs des autres architectes et d’hériter des meilleures pratiques éprouvées. Les architectures de référence peuvent fournir des informations architecturales manquantes qui peuvent être fournies à l’avance aux membres de l’équipe de projet pour permettre des meilleures pratiques architecturales cohérentes. De cette manière, l’architecture de référence SOA fournit une base d’actifs dont les efforts SOA peuvent s’inspirer tout au long du cycle de vie du projet.
En effet, afin d’obtenir les avantages promis de la réutilisation des SOA, de la réduction de la redondance, de la réduction des coûts d’intégration et d’une visibilité et d’une gouvernance accrues, les entreprises doivent appliquer leurs efforts de SOA de manière cohérente. Cela signifie plus que d’acheter et d’établir l’infrastructure de certains fournisseurs en tant que norme d’entreprise ou d’adhérer à la dernière pile de normes WS-*. Les architectures de référence SOA peuvent servir de base à des efforts SOA disparates dans toute l’organisation, même si elles utilisent des outils et des technologies différents. Les bonnes architectures de référence SOA fournissent les meilleures pratiques et approches SOA d’une manière indépendante du fournisseur, de la technologie et des normes. Par conséquent, n’allez pas en chercher un auprès de votre fournisseur préféré. En fait, si vous avez obtenu votre architecture de référence SOA de ce fournisseur, vous voudrez peut-être envisager de l’abandonner au lieu de quelque chose de plus neutre pour le fournisseur.
En particulier, OASIS propose une Architecture de référence SOA (RA) qui » modélise les éléments architecturaux abstraits d’une SOA indépendamment des technologies, des protocoles et des produits utilisés pour implémenter une SOA. Certaines sections de l’AR utiliseront des éléments abstraits communs dérivés de plusieurs normes. »Leur approche utilise le concept de « modèles » pour identifier différentes méthodes et approches pour mettre en œuvre différentes parties de l’image architecturale. Bien que l’architecture de référence OASIS SOA ne soit certainement pas la seule valable sur le bloc, elle constitue certainement un bon point de départ pour ceux qui recherchent une architecture de référence SOA neutre pour les fournisseurs sur laquelle fonder leurs propres efforts architecturaux.
La solution ZapThink Take
Les architectes d’entreprise ont besoin de toute l’aide qu’ils peuvent obtenir pour s’assurer qu’ils fournissent à leur organisation des architectures fiables, agiles, résilientes et neutres vis-à-vis des fournisseurs qui répondent aux exigences en constante évolution de l’entreprise. Bien que l’art et la pratique de l’architecture d’entreprise continuent de mûrir, les entreprises devraient chercher à emprunter autant de bonnes pratiques qu’elles le peuvent et à apprendre d’autres personnes qui ont déjà suivi la voie de l’EA et de l’ASO. Si vous envisagez d’apprendre la SOA, ou toute forme d’EA d’ailleurs, au fur et à mesure, ou pire encore, auprès d’un fournisseur, vous risquez le succès complet de vos efforts de SOA. Au contraire, exploitez (gratuitement) les architectures de référence SOA afin que vous puissiez avancer à un rythme plus rapide et à moindre risque. Bernard de Chartres le dit mieux dans le dicton bien connu: « Nous sommes comme des nains sur les épaules de géants, afin que nous puissions voir plus qu’eux, et les choses à une plus grande distance, non en vertu d’une netteté de vue de notre part, ou d’une distinction physique, mais parce que nous sommes portés haut et élevés par leur taille géante. »Tenez-vous sur les épaules d’autres géants de l’architecture d’entreprise et laissez-les augmenter votre vision et votre succès.