アーキテクチャについて

オンプレミス環境では、多くの場合、テクノロジーアーキテクチャの中心チームがあり、製品や機能を担当する他のチームがベストプラクティスに従うように、まとめ役として機能します。テクノロジーアーキテクチャチームには、通常、テクニカルアーキテクト (インフラストラクチャ)、ソリューションアーキテクト (ソフトウェア)、データアーキテクト、ネットワーキングアーキテクト、セキュリティアーキテクトなどの担当者が含まれます。多くの場合、これらのチームはエンタープライズアーキテクチャ機能の一部として TOGAFまたは Zachman Framework を使用します。

では AWS、その機能を持つ一元化されたチームを持つのではなく、チームに機能を分散したいと考えています。決定権限を分散することは、複数のチームを内部標準に準拠させるという点でリスクがあります。当社はそのようなリスクを 2 つの方法で軽減します。まず、各チームがその能力を持てるようにすることに重点を置いたプラクティス (物事のやり方、プロセス、基準、受け入れた規範) を用意し、チームが満たすべき基準の水準を引き上げているかどうかを検証する専門家を配置します。次に、基準が満たされていることを確認するための、自動チェックを実行するメカニズムを実装します。

「善意だけでは十分ではない。仕組みづくりが重要だ」- ジェフ ベゾス。

つまり、人間の最善の努力を、ルールやプロセスへの準拠をチェックするメカニズム (多くは自動化) に置き換えるということです。この分散型アプローチは、Amazon のリーダーシップ原則によってサポートされており、お客様を起点にして逆算した、すべての役割にわたる文化を確立します。逆算は、当社のイノベーションプロセスの基本です。当社はお客様とその要望を出発点として、取り組みを定義し、推進します。お客様のことを真剣に考えているチームが、お客様のニーズに応じて製品を開発します。

アーキテクチャについては、すべてのチームがアーキテクチャを作成し、ベストプラクティスに従う能力があることを想定しています。新しいチームがこれらの機能を獲得したり、既存のチームを強化したりできるように、設計を確認し、 AWS ベストプラクティスを理解するのに役立つプリンシパルエンジニアの仮想コミュニティへのアクセスを有効にします。プリンシパルエンジニアリングコミュニティの仕事は、ベストプラクティスを周知させ、わかりやすくすることです。例えば、これを実現する 1 つの方法として、ベストプラクティスを実例に適用することに焦点を当てた、ランチタイムトークが挙げられます。彼らの会話を録音して、新しいチームメンバー向けのオンボーディング教材として使用できます。

AWS ベストプラクティスは、インターネット規模で数千のシステムを実行した経験から生まれます。ベストプラクティスの定義には主にデータを活用しますが、プリンシパルエンジニアなどの専門分野に精通した人がベストプラクティスを設定することもあります。プリンシパルエンジニアは、新しいベストプラクティスが形成されるにつれて、コミュニティとして協力しながら、チームにそれを徹底させます。やがてそれらのベストプラクティスは、当社の内部評価プロセスやコンプライアンス遵守メカニズムに取り込まれて、正式なものになります。Well-Architected フレームワークは、当社の内部評価プロセスをお客様向けに実装したものであり、フィールドの役割全体で、ソリューションアーキテクチャや内部エンジニアリングチームなどのプリンシパルエンジニアリングの考えを体系化しています。Well-Architected フレームワークは、学んだことを活用できるスケーラブルなメカニズムです。

プリンシパルエンジニアリングコミュニティが取り組んでいるアーキテクチャの分散所有に従うことにより、お客様のニーズに基づいて Well-Architected のエンタープライズアーキテクチャが生まれると当社は確信しています。すべてのワークロードで Well-Architected レビューを実行するテクノロジーリーダー ( CTOsや開発マネージャーなど) は、テクノロジーポートフォリオのリスクをよりよく理解できます。このアプローチを使用して、チーム全体に関わる課題を特定し、その課題に取り組むことができます。プリンシパルエンジニアは、メカニズム、トレーニング、ランチタイムトークを活用して、特定の領域についての考えを複数のチーム間で共有することができます。