Sur l'architecture

Dans les environnements sur site, les clients possèdent souvent une équipe centrale pour l'architecture technologique, qui chapeaute les autres équipes dédiées aux produits ou aux fonctions afin de s'assurer qu'elles ont adopté les bonnes pratiques applicables. Les équipes dédiées à l'architecture technologique sont souvent composées d'un ensemble de rôles tels que l'architecte technique (infrastructure), l'architecte de solutions (logiciel), l'architecte de données, l'architecte de réseau et l'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 répartir les décisions. Par exemple, il faut s'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 nous attendons à ce que chaque équipe ait la capacité 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 examiner 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 nous 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 travaillent ensemble afin de s'assurer que les équipes les suivent. Avec le temps, ces bonnes pratiques sont officialisées dans nos processus d'examen interne, 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'examen 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 examens Well-Architected sur toutes vos charges de travail, vous permettront de mieux comprendre les risques au sein de votre portefeuille de technologies. À l'aide de cette approche, vous pouvez identifier les thèmes sur les équipes que votre organisation pourrait traiter 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.