Piège #16 Juste le schéma d'architecture

Nous avons tous vu un praticien présenter avec un schéma d'architecture soigneusement rédigé qui montre comment certains éléments d'un système devraient être liés à l'avenir. Nous regardons respectueusement l'image, apprécions l'élégance. Ensuite, nous procédons à la création d'un système qui ne montre que des relations superficielles avec le diagramme.

Pourquoi? Tout ce qui comprend un architecture utile manquait:

• lacunes qui indiquent quel changement est nécessaire
• des contrôles qui atténuent les risques pour l'entreprise
• des spécifications qui contraignent les concepteurs, les réalisateurs, les exploitants et les futurs architectes
• tout ce qui met en évidence comment le futur écosystème offrira une meilleure valeur que ce que nous avons aujourd'hui

Ces diagrammes soigneusement élaborés représentent généralement une partie de l'écosystème complet. Trop souvent, le diagramme est rempli de choix de conception arbitraires faits pour soutenir les préjugés du praticien.

Une bonne architecture permet de prendre des décisions éclairées pendant le processus de développement de l'architecture et limite la conception, la mise en œuvre et le choix opérationnel. Un diagramme pourrait faire ces choses.

Vous ne pouvez pas gouverner à partir d'une boîte et d'une ligne

Habituellement, la livraison basée sur l'image court-circuite la riche compréhension dans l'esprit des parties prenantes, des décideurs et des principaux contributeurs qui évoluent au cours du développement. Ce dommage se produit parce que peu de diagrammes peuvent représenter plus d'un seul problème. Lorsque nous nous concentrons sur ces diagrammes, nous évitons implicitement les compromis complexes et devenons obsédés par une seule optimisation.

Les diagrammes déguisés en architecture regorgent de spécifications et de contrôles injustifiés. Injustifié parce que la règle ne fait que « se tenir seule ». Libre de tout contexte, le diagramme spécifie un fournisseur de services, un logiciel ou un emplacement opérationnel. Les bons architectes voient cela et doivent retenir le cri de pourquoi ?

Les meilleures pratiques associent explicitement une spécification à un but, un objectif ou une autre exigence et le choix de conception à la spécification. Sans ce lien, comment pouvons-nous évaluer l'adéquation du choix de conception à l'objectif ?

Nous avons tous entendu l'excuse "mais le diagramme n'est qu'une vue". Dans notre pratique EA Capability, nos yeux roulent. S'il s'agit d'un vue architecturale où est le référentiel qui conserve les informations qui mettent en évidence les préoccupations, les exigences, les préférences, les relations et l'analyse. Vous avez deviné dans la tête du praticien où l'examen par les pairs et la réutilisation sont impossibles.

Conexiam Naviguer utilise le Solution Development Notebook, ou SDN, pour soutenir activement les équipes de changement et de mise en œuvre et aider les gestionnaires de portefeuille à contrôler les initiatives de changement et à mesurer la valeur. Dans chaque SDN, l'architecte doit identifier les conseils essentiels pour l'exécutant, le propriétaire et le gestionnaire de portefeuille.