Sur l’architecture

Dans les environnements sur site, les clients possèdent souvent une équipe centrale pour l’architecture technologique, qui supervise les autres équipes dédiées aux produits ou aux fonctionnalités afin de vérifier qu’elles ont adopté 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 Zachman Framework dans le cadre d’une capacité d’architecture d’entreprise.

Chez AWS, nous préférons répartir les fonctionnalités entre plusieurs équipes dédiées plutôt que de ne recourir qu’à une seule équipe centralisée pour toutes les fonctionnalités. Il existe des risques lorsque vous choisissez de répartir les décisions. Par exemple, il faut vérifier que les équipes respectent les normes internes. Nous réduisons ces risques de deux manières. Tout d’abord, nous avons des pratiques (façons de procéder, processus, règles et autres normes acceptées) qui visent à permettre à chaque équipe de se charger de cette fonctionnalité comme il se doit, et nous avons recours à des experts afin de vérifier que les équipes dépassent les exigences. Ensuite, nous mettons en œuvre des mécanismes qui effectuent des vérifications automatisées pour vérifier que les normes sont respectées.

Cela implique d’avoir recours à des mécanismes (souvent automatisés) qui vérifient la conformité aux règles ou aux processus plutôt que de faire appel à la bonne volonté des employés. Cette approche distribuée est soutenue par les principes de leadership d’Amazon et établit une culture à travers tous les rôles qui partent du client. Le travail à rebours est un élément fondamental 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. 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 à s’approprier ces fonctionnalités, ou les équipes existantes à mettre la barre plus haut, nous activons l’accès à une communauté virtuelle d’ingénieurs en chef qui peuvent vérifier 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 naissent de notre expérience dans l’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 en chef voient l’émergence de nouvelles bonnes pratiques, ils collaborent afin de vérifier 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.