アーキテクチャ

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

AWS では 1 つの中心チームに職能を持たせるのではなく、その職能を複数のチームに分散することが望まれています。決定権限を分散することには、複数のチームを内部標準に準拠させるといった点でリスクがあります。当社はそのようなリスクを 2 つの方法で軽減します。第 1 に、AWS には各チームにその機能を持たせることに焦点を当てたプラクティス« [ 方法、プロセス、標準、受け入れられている基準です。 ] »  があり、チームが満たすべき基準のバーを上げることを確実にするためにエキスパートを配置しています。第 2 に、基準を確実に満たすための自動チェックを実行するメカニズム« [ 意志だけでは絶対にうまくいかない。成し遂げるには適切なメカニズムが必要です。Jeff Bezos。つまり、人間の努力に置き換えるメカニズム (多くの場合、自動化) がルールやプロセスに遵守しているか確認することです。 ] »  を導入しています。この分散型アプローチは、Amazon のリーダーシッププリンシプルによって支持されており、お客様を起点に物事を考える« [ Working backwards(お客様を起点に物事を考える) は当社のイノベーションプロセスの基本となる部分です。AWS では、お客様とその要望を起点に当社の取り組みを定義して進めます。 ] »  という文化を、すべてのロールにわたって確立します。お客様のことを真剣に考えているチームが、お客様の要件に応じて商品を開発します。

それをアーキテクチャに当てはめて、各チームがアーキテクチャを構築してベストプラクティスに準拠できるようにします。新しいチームがそれらの職能を獲得したり、既存のチームが水準を高めたりすることができるように、それらのチームがプリンシパルエンジニアの仮想コミュニティを利用して、エンジニアに設計を評価してもらったり、AWS のベストプラクティスを理解するのを助けてもらったりすることができるようにします。プリンシパルエンジニアリングコミュニティの仕事はベストプラクティスを周知させ、わかりやすくすることです。その方法の例としては、ベストプラクティスを実例に適用することについてランチタイムトークで取り上げます。その話を録音して、新しいチームメンバー向けのオンボーディング教材として使用できます。

AWS のベストプラクティスはインターネットの規模で多くのシステムを運用してきた当社の経験から生まれました。ベストプラクティスを定義するには主にデータを活用しますが、プリンシパルエンジニアなど専門分野に精通した人がベストプラクティスを設定することもあります。新しいベストプラクティスが顕在してくると、チームがそれらに従うことができるようにプリンシパルエンジニアがコミュニティとして活動します。やがてそれらのベストプラクティスは当社の内部評価プロセスやコンプライアンス遵守メカニズムに取り込まれて正式なものになります。Well-Architected フレームワークは当社の内部評価プロセスをお客様向けに実施しているものであり、ソリューションアーキテクチャといったフィールド職や内部エンジニアリングチームでのプリンシパルエンジニアリングの考えが体系化されています。Well-Architected フレームワークは当社が学んだことをお客様に活用してもらうためのメカニズムであり、拡張可能です。

プリンシパルエンジニアリングコミュニティが取り組んでいるアーキテクチャの分散所有に従うことによって、お客様の要件に基づいて優れた設計のエンタープライズアーキテクチャが生まれると当社は確信しています。テクノロジーリーダー (CTO や開発マネージャーなど) がお客様のワークロードのすべてに対して優れた設計の評価を実施することで、お客様のテクノロジーポートフォリオのリスクがよくわかるようになります。この方法ですべてのチームに関わる課題を特定して、その課題に取り組むことができます。プリンシパルエンジニアはメカニズムや、トレーニング、ランチタイムトークを活用して、チーム間の特定の領域について考えを伝えることができます。