Sur l'architecture

Dans les environnements sur site, les clients disposent souvent d'une équipe centrale pour l'architecture technologique qui sert de superposition à d'autres équipes de produits ou de fonctions afin de s'assurer qu'elles suivent les bonnes pratiques. Les équipes d'architecture technologique comptent généralement un ensemble de rôles, notamment : architecte technique (infrastructure), architecte de solutions (logiciel), architecte de données, architecte de mise en réseau et architecte de sécurité. Ces équipes utilisent souvent TOGAF ou le cadre Zachman en tant qu'élément de la capacité d'architecture de l'entreprise.

Chez AWS, nous préférons répartir les capacités en équipes plutôt que d'avoir une équipe centralisée avec cette capacité. Il existe des risques lorsque vous choisissez de distribuer l'autorité de prise de décision, par exemple, vous assurer que les équipes respectent les normes internes. Nous réduisons ces risques de deux manières. Tout d'abord, nous avons les pratiques« [ Façons de procéder, processus, règles et autres normes acceptées. ] »  qui ont pour but de permettre à chaque équipe de profiter de cette capacité, et nous avons mis en place des spécialistes afin de garantir que les équipes ont renforcé le respect des normes. Deuxièmement, nous avons mis en place des mécanismes«Les bonnes intentions ne suffisent pas ; il faut de bons mécanismes pour tout rendre possible Jeff Bezos. Cela implique de remplacer les plus grands efforts de l'homme par des mécanismes (souvent automatisés) qui vérifient la conformité aux règles ou aux processus. ] »  qui effectuent des contrôles automatisés pour s'assurer que les normes sont respectées. Cette approche distribuée est soutenue par les principes de leadership d'Amazon, et établit une culture sur l'ensemble des rôles qui procèdent en partant de la fin« [ Le fait de travailler en partant de la fin est une étape essentielle de notre processus d'innovation. Nous commençons par les clients et ce dont ils ont besoin, afin de définir et de guider nos efforts. ] »  en partant du client. Les équipes obsédées par le client fabriquent des produits en s'appuyant sur les besoins des clients.

Pour l'architecture, cela signifie que nous prévoyons que chaque équipe soit capable de créer des architectures et de suivre les bonnes pratiques. Pour aider les nouvelles équipes à obtenir ces capacités, ou les équipes existantes à mettre la barre plus haut, nous permettons l'accès à une communauté virtuelle d'ingénieurs principaux qui peuvent évaluer leurs conceptions et les aider à comprendre ce que sont les bonnes pratiques AWS. La communauté des ingénieurs principaux travaille pour rendre les bonnes pratiques visibles et accessibles. Une solution pourrait être, par exemple, d'organiser des discussions durant le déjeuner qui se concentrent sur l'application de bonnes pratiques à de véritables exemples. Ces discussions sont enregistrées et peuvent être utilisées dans le cadre de documents d'accueil pour les nouveaux membres de l'équipe.

Les bonnes pratiques AWS émergent de notre expérience en matière d'exécution de milliers de systèmes à l'échelle d'Internet. Nous préférons utiliser des données pour définir les bonnes pratiques, mais utilisons également des experts fonctionnels en tant qu'ingénieurs principaux pour les définir. Lorsque les ingénieurs principaux voient l'émergence de nouvelles bonnes pratiques, ils collaborent afin de s'assurer que les équipes les suivent. Avec le temps, ces bonnes pratiques sont officialisées dans nos processus d'évaluation internes, ainsi que dans les mécanismes qui renforcent la conformité. Le cadre Well-Architected est l'implémentation destinée aux clients de notre processus d'évaluation interne, où nous avons codifié notre réflexion sur l'ingénierie principale à travers les rôles tels que l'architecture de solutions et les équipes d'ingénieurs internes. Le cadre Well-Architected est un mécanisme évolutif qui vous permet de tirer parti de ces connaissances.

En suivant l'approche d'une communauté d'ingénierie principale avec une propriété d'architecture distribuée, nous pensons qu'une architecture d'entreprise Well-Architected reposant sur les besoins du client peut émerger. Nos leaders en matière de technologie (tels que les directeurs techniques ou les directeurs de développement), qui effectuent des évaluations Well-Architected sur toutes vos charges de travail, vous permettront de mieux comprendre les risques au sein de votre portefeuille de technologies. Cette approche vous permet d'identifier les thèmes, pour différentes équipes, que votre organisation pourrait aborder via les mécanismes, les formations, ou les discussions de midi où vos ingénieurs principaux peuvent partager leurs idées sur les domaines spécifiques avec plusieurs équipes.