Ceux d’entre nous chargés de travailler sur des sujets de plus haut niveau, tels que l’Architecture d’entreprise et la stratégie, redoutent lorsqu’on leur pose la simple question – » que faites—vous ? »Lorsque les livrables manquent de tangibilité et de clarté, les réponses à cette question laissent le questionneur hébété et presque désolé pour le répondant. Un terme commun jeté dans la réponse, en tant qu’espace réservé à l’incertitude et à l’incomplétude, est l’architecture de référence.
Ce terme peut signifier beaucoup de choses ou quoi que ce soit pour différentes personnes. Si elle n’est pas définie, elle donne l’impression de peluches et de flous qui engendrent frustration et gaspillage. Les personnes chargées de la mise en œuvre peuvent remettre en question votre capacité à ancrer les concepts et la pensée dans la réalité et le concret. Par conséquent, les définitions sont utiles. Voici ma définition d’une architecture de référence:
L’articulation de considérations, d’options et de normes connues pour guider la conception d’un produit, d’une solution ou d’un système, sur la base d’observations issues d’enquêtes, d’expériences et d’expérimentations, dans un langage et un format visuel familiers au public cible.
La vérité est qu’une fois que l’intention, la valeur et le contexte de l’utilisation sont clairs pour un public donné, avoir une définition formelle n’a pas d’importance.
La vraie question est —
» que voulons-nous faire ? »
Deuxièmement—
» que voulons-nous que les gens (qui qu’ils soient) fassent? »
Avoir des réponses claires à ces questions est le début d’une réflexion sur le sens et la livraison de l’architecture de référence. L’intention, le contenu, le public et la valeur doivent être clairs. Le mot « référence » suggère que le résultat fournit des orientations et des normes à partir de l’observation, de l’expérience et de l’expérimentation, par opposition à une définition de ce qui doit être construit. Une » architecture » suggère qu’elle est structurée, cohérente et vérifiable.
Il existe différentes définitions de l’architecture de référence sur Internet, mais la règle de clarté ci-dessus (intention, contenu, public, valeur) peut être trouvée dans chacune. Considérez une définition alternative à la mienne qui apparaît comme le meilleur résultat dans une recherche Google:
(1) Clarifier le support et le format de ce qui va être livré, par exemple « un document ». Cela informe sur les outils nécessaires, la nature du travail à effectuer et les compétences des contributeurs à impliquer. D’autres moyens de livraison pourraient être une présentation ou une base de connaissances pouvant être consultée.
(2) Convenir de la structure et de l’échelle de ce qui va être livré, par exemple « un ensemble de documents ». Un produit livrable peut être insuffisant, mais l’échelle du domaine système en question peut nécessiter que le produit livrable soit décomposé en plusieurs documents.
(3) Identifiez le public principal et le ou les intervenants, par exemple le » gestionnaire de projet « . Avoir une compréhension du type et du format des informations qu’ils consomment régulièrement. Le statu quo pourrait également jouer un rôle ici. Dans certains cas, l’architecture de référence est « transmise » aux lignes hiérarchiques en tant que politique, tandis que dans d’autres cas, elle est traitée comme une « agréable à avoir », dans l’espoir qu’elle décrit la meilleure façon et les alternatives à envisager.
(4) Identifier les autres parties intéressées qui pourraient avoir besoin d’utiliser l’architecture de référence. Est-il nécessaire de créer différentes vues ou couches? Y a-t-il un besoin et un espace pour former les autres sur la façon d’interpréter et d’appliquer l’architecture de référence?
(5) Indiquez clairement ce que le public/lecteur doit faire du document, p. ex. » référez-vous aux meilleures pratiques. »Les résultats doivent fournir ce qu’ils disent sur la couverture, y compris les preuves et les liens vers les sources pour validation. Une architecture de référence pourrait également permettre d' » apprendre » de l’expérimentation de manière cohérente et exploitable.
(6) Clarifiez le domaine de pertinence. Une architecture de référence sans domaine spécifique est une philosophie de principes directeurs de niveau supérieur plutôt qu’une architecture. Une architecture, même une architecture de référence, doit être liée à un domaine. Plus ce domaine est petit, plus l’architecture de référence est pertinente et exploitable.
(7) La valeur prévue de l’architecture de référence doit être communiquée, car cela aide le public à juger de son objectif et de ses limites, par exemple « sélectionnez la meilleure méthode de livraison. » Les équipes de mise en œuvre savent alors où aller lorsque cette décision doit être prise.
(8) Avoir des exemples du domaine et énoncer les technologies pertinentes permet de clarifier le contexte de l’architecture de référence.
(9) Les alternatives et les sources de composants et de capacités à considérer lors de la mise en œuvre doivent être bien documentées et liées.
Une architecture de référence n’est pas nécessairement un bloqueur avant le démarrage d’un projet technologique. Il peut être développé en parallèle ou après la livraison, servant de documentation d’une autopsie et des leçons apprises. S’il est créé avant le début d’un projet, il nécessite des enquêtes, des essais et des expériences afin d’informer les bonnes pratiques. Vous trouverez ci-dessous une taxonomie suggérée des classes possibles d’architecture de référence, en fonction du public, de la solution et des lacunes actuelles dans les connaissances au sein d’une organisation ou d’une équipe de projet.
L’acronyme des cinq aspects différents d’une architecture de référence est LA MUSIQUE, qui s’est avérée mémorable dans les conversations à tout niveau organisationnel ou domaine de compréhension:
- embership : la liste et la catégorisation des éléments d’architecture considérés comme pertinents pour le domaine.
- sauge: histoires d’utilisateurs, analyses de rentabilisation, processus, flux de travail et moyens d’expliquer les activités du domaine.
- tructure : comment les différents éléments d’un domaine sont interconnectés pour soutenir l’utilisation.
- nteraction (ou intégration) : les interfaces et les messages échangés entre les éléments d’architecture lors de l’utilisation.
- ontrols : les contraintes et les politiques utilisées pour régir les interactions.
Maintenant, cela ne suggère pas que toutes les architectures de référence doivent fournir 25 documents ou sous-sections, couvrant chacun des domaines identifiés. Cela montre qu’il y a probablement 25 domaines différents où les considérations, les options et les responsabilités doivent être articulées dans une organisation ou un projet. Cela changera en fonction de votre public. Il n’y a pas de flou ou de flou dans les architectures de référence. Elles sont le résultat d’efforts exploratoires et sont les résultats tangibles d’une recherche appliquée à court terme.