5 étapes vers une architecture d'entreprise minimale viable

Chez Vault Health, le CTO Steve Shi commencel'architecture d'entreprise(EA) travaille avec une étude de site de l'ensemble de l'infrastructure informatique, des applications, du système et des données, mais la limite à deux semaines avec des entretiens d'une heure sur chaque fonction.

Les clients, qu'il s'agisse d'employés ou de ceux qui paient pour un produit ou un service, doivent « adorer » le résultat de cette approche minimale viable d'EA, déclare Shi. "Si vous n'obtenez pas l'adhésion des clients, vous perdrez de l'élan, et si vous perdez de l'élan, il est plus difficile de continuer à itérer après le lancement minimum viable", dit-il.

Comme de nombreux responsables informatiques, Shi essaie de trouver un équilibre entre des études architecturales complexes qui restent inutilisées et des rapports EA rudimentaires qui manquent de portée et de profondeur suffisantes pour fournir une valeur durable. Pour trouver cet équilibre, il faut rester proche des besoins de l'entreprise, réduire les tâches fastidieuses, définir correctement la portée du projet et définir et appliquer les normes et principes architecturaux appropriés. Voici cinq étapes recommandées par les DSI qui sont des vétérans du processus.

Restez proche de l'entreprise

Le maintien d'une communication étroite avec les parties prenantes de l'entreprise est le seul moyen de savoir où une architecture d'entreprise minimale viable peut le mieux aider l'entreprise et générer des fonds pour la poursuite des évaluations EA à mesure que les besoins de l'entreprise évoluent.

Chez Carrier Global Corp., le CIO Joe Schulz mesure le succès de l'EA en fonction de mesures commerciales telles que la façon dont la productivité des employés est affectée par la qualité des applications ou les interruptions de service.

"Nous ne considérons pas l'architecture d'entreprise comme un seul groupe de personnes qui sont les gardiens, qui sont de nature plus théorique sur la façon dont quelque chose devrait fonctionner", explique Schulz. Il utilise des rapports et des informations générés par l'outil EA Lean IX pour décrire l'interconnectivité de l'écosystème ainsi que les capacités des systèmes à travers le portefeuille pour identifier les redondances ou les lacunes. Cela permet au fournisseur mondial de solutions intelligentes pour les bâtiments et la chaîne du froid de "démocratiser une grande partie de la prise de décision… (de) mettre à profit toutes les meilleures capacités de réflexion et d'investissement de notre organisation".

George Tsounis, directeur de la technologie de la société de technologie et de services de faillite Stretto, recommande d'utiliser EA pour "établir la confiance et la transparence" en informant les chefs d'entreprise des dépenses informatiques actuelles et des domaines où les plates-formes ne sont pas alignées sur la stratégie commerciale. Cela rend les futures conversations liées à l'EA « beaucoup plus faciles que si l'architecte d'entreprise travaillait en silo et n'avait pas cette relation », dit-il.

Coupez la bureaucratie

Les longs questionnaires et les entretiens basés sur des modèles sont une partie familière, et souvent malvenue, des efforts d'EE. Les praticiens d'évaluation environnementale minimum viables suggèrent d'éliminer toutes les questions qui ne fournissent pas d'informations essentielles et permettent les commentaires des utilisateurs.

Gregor Hohpe, directeur de la stratégie d'entreprise chez Amazon Web Services, l'hyperscaler dans le cloud, recommande de passer de processus d'EA "lourds, largement à sens unique" à des conversations plus simples, plus rapides et itératives avec les utilisateurs professionnels.

Au sein de la société de services financiers State Street, l'architecte en chef mondial Aman Thind tente de rationaliser le processus d'EA en ne posant que des questions précises et pertinentes, plutôt que tout dans un modèle d'EA. Se concentrer sur les questions les plus essentielles peut réduire de moitié au moins le temps nécessaire à l'examen et à la soumission de l'architecture et rendre le processus beaucoup plus efficace, dit-il. Par exemple, le cadre utilisé par une application SaaS pour fournir l'interface utilisateur est moins important que legestion des identités et des accèsprocédures qui déterminent comment les utilisateurs interagissent avec lui.

En plus d'utiliser des contrôles de conformité automatisés et des plates-formes en libre-service, Hohpe recommande d'éliminer les «listes interminables de normes qui sont largement ignorées», la tenue de réunions d'examen où tous les documents sont rétro-conçus à partir du résultat préféré de l'équipe respective, des réunions «d'alignement» sur les non- des sujets à valeur ajoutée et "la génération de tapisseries géantes à partir d'outils EA lourds qui ne sont jamais utilisés pour la prise de décision".

Chez Vault, une entreprise de soins de santé numériques, Shi trouve l'outil d'observabilité des applications New Relic précieux pour accélérer le travail d'EA en offrant une visibilité instantanée sur l'ensemble de l'architecture.

Il utilise également de nouveaux termes et processus pour éviter les ralentissements courants et faire connaître sa nouvelle approche. Un exemple est un «rapport de site» qui demande aux utilisateurs d'imaginer le produit final d'EA. Cela aide à définir les exigences critiques telles que le nombre de transactions et les types de processus qu'une application doit prendre en charge, "venant du côté client et travaillant en arrière". Plutôt que d'utiliser un processus "one and done" consistant à demander aux utilisateurs de s'entendre sur une décision technologique critique à l'avance, Shi les met au défi de confirmer ou de réviser des "hypothèses de développement" telles que le nombre d'appels de base de données qu'un système doit prendre en charge chaque jour. Cette approche accélère l'accord sur le choix des composants tels que les bases de données, dit-il.

Lors du déploiement de l'application, Shi évite un plan de projet générique au profit de ce qu'il appelle "un plan de séquencement macro spécifique" d'étapes construites autour de jalons tels que les tests alpha et bêta et leurs jalons de validation associés. Cela définit, pour chaque étape du déploiement, le succès en termes commerciaux tels que le chiffre d'affaires ou le taux d'adoption des utilisateurs et les leçons tirées du processus de support qui réduisent les coûts de support continus. Cela rappelle également à tout le monde, dit-il, que "le projet ne se termine pas tant que nous ne savons pas que l'architecture a fourni une valeur client mesurable".

Portez-le bien

Prenez trop de choses dans un projet d'EA minimum viable et il sera obsolète avant qu'il ne soit terminé, produisant des résultats trop tard pour satisfaire et recevoir un financement futur des chefs d'entreprise. Si vous la réduisez trop, vous n'obtiendrez pas la vision complète de la technologie et de l'activité nécessaire pour tirer le meilleur parti des investissements informatiques. Pour atteindre le bon équilibre, il faut souvent se concentrer sur une application ou un problème dans l'entreprise ou sur un domaine où les exigences évoluent rapidement en raison de nouveaux besoins commerciaux ou réglementaires.

L'analyste principal associé de Gartner Inc., Nolan Hart, appelle le champ d'application approprié de l'EE "le plus petit nombre de livrables, tels que les points de vue, les modèles de référence et les modèles de conception, qui permettent d'assurer une livraison rapide et conforme des produits et des solutions". Plutôt que de passer trop de temps à comprendre l'architecture actuelle, il recommande de «comprendre d'abord les résultats souhaités». Il n'y a aucune valeur, dit-il, à se "perdre en documentant votre architecture dysfonctionnelle actuelle pour toujours et à jamais".

Shi recommande qu'un EA minimum viable considère "tout, de l'interface utilisateur aux API qui relient les systèmes à l'architecture de données, plutôt qu'un seul composant ou service en silo". L'architecture proposée doit également être testable à l'échelle de la production, dit-il, et gérer les mêmes exigences de pointe que le système qu'elle remplace.

La portée appropriée s'applique également à l'organisation de l'EE. Plutôt qu'un groupe EA dédié, Carrier a créé des centres d'excellence pour des besoins clés tels que le CRM, le service sur le terrain, l'ERP, l'analyse et les capacités d'usine numérique. Ces centres fournissent une base simplifiée de composants de base qui lui permettent d'innover rapidement sans nécessiter un exercice d'EA pour évaluer des plates-formes distinctes pour chaque unité commerciale, explique Schulz.

Si un groupe au sein d'une entreprise n'est pas intéressé par un projet d'EE minimum viable, « il y a beaucoup d'autres personnes qui prendront votre temps », dit Hart. Faites correspondre cette demande avec les compétences d'un groupe EA pour déterminer "trois à cinq types de services que vous pouvez offrir pour fournir ces résultats commerciaux avec une approche minimale viable".

Établir et faire respecter les normes

L'application des principes de conception, ainsi que l'accent mis sur les besoins de l'entreprise, peuvent aider à raccourcir «les arguments religieux sur la meilleure solution», explique Tsounis. Les principes qu'il encourage incluent "toujours essayer de créer la solution la plus simple possible, ne pas trop concevoir, permettre une réutilisation maximale dans toute l'organisation, tirer parti des modèles de conception architecturale établis ainsi que des services basés sur le cloud avant de créer quelque chose de nouveau".

Les architectures et les normes de référence dans des domaines tels que la cybersécurité, la gouvernance des données, la gestion de la production et les meilleures pratiques de déploiement fournissent un « playbook prêt à l'emploi » pour créer efficacement des applications composables qui sont robustes, conformes et résilientes par conception, explique Thind. De telles architectures, construites à partir de microservices « très bien définis… en termes d'API, d'évolutivité et d'interopérabilité », permettent à une entreprise de remplacer n'importe quel microservice sans affecter les autres, créant ainsi une conception évolutive.

Hohpe dit que certaines normes étouffent l'innovation tandis que d'autres la stimulent. Par exemple, des interfaces uniformes sont essentielles pour créer des architectures faciles à adapter. Cependant, des normes trop strictes peuvent conduire à de mauvais choix technologiques. Il se souvient d'une équipe d'application qui a choisi XML comme interface de composant plutôt que des protocoles de communication plus rapides. Lorsqu'on lui a demandé pourquoi, l'équipe a répondu que l'équipe d'architecture en avait besoin, apparemment sans tenir compte de l'effet néfaste de l'analyse XML sur les performances de l'application.

Commencez quelque part

Si rien d'autre, dit Thind, nommez un «… un architecte en chef, un cadre évaluant les normes globales, la gouvernance globale, les plates-formes globales et la discipline globale de la conception d'applications depuis le sommet. Le simple fait d'occuper ce poste signale l'importance de l'architecture pour l'ensemble de l'entreprise et inculque les bons comportements dont nous avons besoin pour créer des organisations informatiques efficaces et innovantes.

Commencer une architecture d'entreprise minimale viable peut commencer simplement par « faire le point », dit Thind, en identifiant les dépenses excessives telles que « pourquoi avons-nous six applications différentes pour le même processus, cinq contrats différents (pour) le même outil de BI, plusieurs contrats de données de marché avec la même portée, des clusters Hadoop 24×7 pour les rapports mensuels, etc. Mais même un tel effort minimum viable peut rapporter gros. "Le simple fait de s'assurer que le bon outil est utilisé pour le bon travail et qu'il existe une normalisation et les meilleures pratiques autour de leur utilisation peut avoir un impact considérable sur le résultat net et conduire à moins de dette technique, à des besoins de support réduits et à une innovation plus rapide", a-t-il déclaré. dit.