re:Invent 2025: Capability-firstアーキテクチャでビジネス意図とテクノロジーを結ぶ設計手法
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Capability-first architecture: Bridging business intent to technology (ARC202)
この動画では、AWS re:InventにおいてMukund RaoとSushanth Mangaloreが、テクノロジー選択の複雑さに対処するためのcapability frameworkを紹介しています。現代のクラウド環境では240以上のAWSサービスと25,000の製品が存在し、choice paralysisが発生しています。このフレームワークは3つのC—capability、characteristics、constraints—を中心に構成され、ワークロードを論理的なcapabilityに分割し、各capabilityのアーキテクチャ特性を特定します。テクノロジーではなくビジネスインテントを起点とし、段階的な進化を重視します。Architectural Decision Records（ADR）による意思決定の文書化、isolation boundariesによる特性の保護、そしてWell-Architected Frameworkを基盤とした実践的なアプローチが示されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
セッション概要：テクノロジー選択のメタな視点を得るために
おはようございます。皆さん、re:Invent の素晴らしいスタートを切られていることを願っています。ようこそ、そして今後の1時間を私たちと一緒に過ごしていただくことを選んでいただき、ありがとうございます。カンファレンス全体で多くの興味深いセッションが開催されていることは承知していますので、本日のトピックに入る前に、このセッションが何についてのものであり、何についてのものではないかを簡単に説明したいと思います。
このセッションは、特定の製品、サービス、テクノロジー、またはアーキテクチャパターンについてのものではありません。皆さんは今週を通じて、これらのトピックに関する多くのディープダイブセッションに参加されることになります。その代わりに、re:Invent の週の始まりとして、製品およびサービスの発表をナビゲートし、エクスポでのパートナーからのソリューションとイノベーションを探索し、生成 AI とエージェンティック AI のすべてに関わっていく中で、圧倒されることがあるかもしれません。そのことを念頭に置いて、私たちはこのセッションを設計しました。これは、クラウドコミュニティのテクノロジープラクティショナーと意思決定者として、テクノロジーの選択とテクノロジーシステムアーキテクチャについてのメタな視点を得るために、一歩引いて考えるのに役立つものです。
次に、私たちは皆さんに、シンプルなメンタルモデルと実践的なフレームワークを提供したいと考えています。これは、特にこの継続的なテクノロジー破壊の時代において、テクノロジーをナビゲートするために使用できるものです。私の名前は Mukund Rao で、Amazon Web Services のワールドワイドビジネスコンサルティングソリューションズアーキテクトです。過去5年間、私は異なるサイズ、規模、業界の数百の顧客と、また私たちの戦略的な AWS パートナーの一部と協力する機会に恵まれてきました。これらの顧客がテクノロジー最新化を通じたビジネス変革を実行するのを支援してきました。AWS での時間を含めて、私は AWS エコシステムで約16年を過ごしてきました。その大部分は、ハンズオンのエンジニアリングアーキテクトとして、また AWS 顧客として AWS 上でシステムを構築・スケールしてきました。ここで私の視点を共有できることは素晴らしいことです。そして、今日は Sushanth が一緒にいます。
本日のセッションの構成方法は以下の通りです。まず、私が why、つまりなぜ capability framework が必要なのかについてのコンテキストを設定します。その後、Sushanth が capability framework が何であるかについて詳しく説明します。その後、このフレームワークを適用して、いくつかの実践的な例とユースケースをトレースしていきます。よくある質問について議論し、その後、まとめます。これが本日の構成です。では、時計を巻き戻して 約20年前の2005年に戻ってみましょう。
2005年から現在へ：テクノロジーの制約から選択肢の過剰へ
当時、テクノロジストとビルダーとして、私たちの人生ははるかにシンプルでした。なぜなら、選択肢が少なかったからです。プログラミング言語は一握りしかありませんでした。サーバーは単にアプリケーションサーバーまたはベアメタルマシンを意味していました。リレーショナルデータベースはほとんどのユースケースを満たしていました。アーキテクチャパターンに関しては、私たちはプレゼンテーション層、ビジネスロジック用のアプリケーション層、データ層を備えたシンプルな3層アーキテクチャの時代に生きていました。これらのシステムをスケールする必要がある場合、CPU またはメモリのいずれかであれ、単により多くのリソースを投入して、垂直にスケールしていました。もちろん、これはシステムをスケールする最も効率的な方法ではなく、独自の課題がありましたが、重要なのは、私たちはテクノロジーの制約の中で生きていたということです。そして、これらの制約は実際に明確性を強制していました。私たちはテクノロジーの決定についてより意図的で慎重でした。そして、私たちのシステムはより推論しやすかったのです。
今日に至るまで、私たちは人生のほとんどのことと同じように、目がくらむほどの選択肢に満ちた世界に生きています。水のような単純なものを例に挙げてみましょう。近所のスーパーマーケットの飲料コーナーに入ると、本当にたくさんの選択肢に囲まれています。水、炭酸水、ソーダ、エナジードリンク、砂糖不使用、シュガーレス、その他もろもろです。これはテクノロジーにも同じことが言えます。私たちはテクノロジーが豊富にある時代に生きています。AWS だけでも、今日時点で 240 以上の完全に認定されたサービスがあり、この週を通じて行われるすべての発表により、このリストはさらに増える可能性があります。
compute のような単純なものを例に挙げても、様々なタイプとサイズの EC2 インスタンスを起動する 900 以上の組み合わせを超えて、コンテナオーケストレーションプラットフォームとサーバーレスオプションもあります。データについても、かつては単なるリレーショナルデータベースだったものが、今では多くの選択肢を提供しています。私たちは polyglot persistence と purpose-built data engines の時代に生きています。ドキュメントストレージ、時系列データベース、そして最近では、新しいクラスのアプリケーションをサポートする vector database と knowledge database の利用が増えています。それはサービス自体だけではありません。marketplace を見ると、選択肢は引き続き拡大しています。
marketplace には、6,000 以上の独立系ソフトウェアベンダーによって公開された約 25,000 の製品とサービスが含まれています。これはサービスとソリューションの膨大な選択肢を表しています。アーキテクチャの風景そのものが大きく拡大しています。かつての 3 層アーキテクチャのシンプルさは、高度に分散した microservices、application mesh、event-driven architecture、real-time streaming architecture、そして今では agent application パターンが発展している cloud-native architecture へと進化しました。データの側面でも、かつての従来型の data warehouse は、data lake、lake house、medallion lake house、zero ETL architecture を含む最新のデータアーキテクチャへと変わりました。
この拡大はアプリケーションとデータを超えて広がっています。セキュリティや他の領域を見ると、Zero Trust security のような多くのパターンがあります。今日、利用可能なアーキテクチャパターンは本当にたくさんあります。このサービス、ソリューション、アーキテクチャパターンの選択肢があることで、ビジネスに莫大な可能性がもたらされた一方で、複雑さも増し、私たちが「choice paralysis」と呼ぶ新しい種類の課題を生み出してしまいました。ビジネスはテクノロジーの迷路に陥り、インターネット検索に迷い、ドキュメントに埋もれ、意見ベースのインターネットフォーラムからアーキテクチャのガイダンスを受けています。
その結果、ビジネスは複数のベンダーを評価することになり、長い評価サイクルと実現しない概念実証が生じています。私たちが気づいているのは、テクノロジーからの価値実現に遅延が生じているということです。これに加えて、私たちが「shiny-new-toy syndrome」と呼ぶものがあります。ビジネスがあらゆる新しいテクノロジーパターンを採用したいという状況です。これは、問題に無理やり合わせるソリューションを作成してしまう結果につながっています。次に、より多くのリソースを消費し、無駄を招く、拡散した非効率なアーキテクチャを作成してしまい、これは持続可能性の問題にもなっています。
ビジネスとテクノロジーの関係性の変化と「choice paralysis」
テクノロジーとビジネスの関係を見つめることは価値があります。なぜなら、テクノロジーの目的は ビジネスの成果をサポートすることだからです。過去数十年間、この関係は劇的に変わってきました。今日の時代において、テクノロジーによる差別化だけでは十分ではなくなりました。これはおそらく10年前は普通のことでしたが、今日ではそうではありません。テクノロジーはあらゆるデジタルファーストなビジネスの最前線に、そして中核に位置するようになっています。これは私たちが継続的に目にしているトレンドであり、パンデミック以降、加速しています。
その結果、ビジネスはより少ないリソースでより多くのことをしなければならなくなっています。これにマクロ経済的な状況と、今日の私たちが生きている動的な世界、そして増加するAIワークフォースを加えると、企業はより速く革新し、より激しく競争しなければなりません。このようなシナリオを考えると、ビジネスの意図を テクノロジーの選択肢に、これまで以上に速く変換することが極めて重要になっています。ビジネスとテクノロジーが互いに一致し、足並みを揃えて進むことについて話すとき、AWS アーキテクトとしての私たちにとっては、それは非常に陳腐に聞こえます。デジタルトランスフォーメーションのプレイブックで何度も何度も繰り返される、最も古い決まり文句の一つのように聞こえます。
しかし、現実はこうです。AWS アーキテクトとしての私たちの視点からすると、ビジネスはテクノロジーの選択肢に囲まれ、 麻痺しており、分散化し動的になっていくアーキテクチャの複雑さの増加によって常に圧迫されています。これに生成AIによって再定義されている新しいビルディングブロックを加えると、さらに多くの選択肢が生まれ、問題がさらに増幅されます。このような文脈において、進化可能なアーキテクチャの必要性があります。
進化可能なアーキテクチャの必要性：適応性、技術的負債、進化の中心
この概念は新しいものではなく、1970年代からシステム設計に存在しています。 しかし、今日は特により重要で、関連性があり、緊急性があります。なぜなら、多くのビジネスを混乱させ続けるAI製品、サービス、ツールの大量流入があるからです。evolutionary architectures について話すとき、それはまた、アーキテクチャをどのように見るかを再考する必要があることも意味します。アーキテクチャを単なる統合と、一緒に機能するツールやサービスの集合として見るだけでは十分ではありません。
むしろ、私たちはそれらを生きたシステムとして見始める必要があり、それらを継続的に、費用対効果的に、そして効率的に進化させるための計画を持つ必要があります。これが、アーキテクチャをどのように見るかを再考するために私たちが行う必要がある最大のマインドセットシフトです。そのために、これからの数分間、私たちは2つのソースからの教訓を取り上げます。1つは、私たち自身のカスタマージャーニーからの教訓です。AWS上であらゆる種類のカスタマージャーニーを目にします。マイグレーションからモダナイゼーション、そして完全なクラウドネイティブになることまで、そしてどの戦術が機能し、どの戦術が機能しないかを観察します。私たちはそれに対する可視性を得ています。
次に、進化生物学からいくつかの教訓を引き出そうと思います。なぜなら、自然は何百万年もの間、私たち人間が存在する前から、そして agentic AI テクノロジーが存在する前から、進化の実験を行ってきたからです。そこで、チャールズ・ダーウィンのこの時代を超えた名言を強調したいと思います。「種の中で生き残るのは、最も強いものでも、最も知能の高いものでもなく、変化に最も適応できるものである。」これは非常に深い、そして時代を超えた名言であり、テクノロジーとテクノロジーアーキテクチャにも当てはまります。これが本日の最初の教訓と重要なポイントへと導きます。それは、アーキテクチャの適応性です。
アーキテクチャの適応性について話し、自然を見てみると、進化は一夜にして起こるものではないことがわかります。進化には何百万年もかかり、テクノロジーにも同じことが言えます。アーキテクチャの進化は一夜にして起こるものではなく、段階的に起こります。何百万年かかるべきだと言っているわけではありません。そんなことになったら、本来の目的が台無しになってしまいます。むしろ、適応可能な変更のセットが必要だということを言っているのです。アーキテクチャの適応性について話すとき、非常に明らかなことが一つあります。それは、顧客がどの程度適応性に成功しているかを実際に示す要因があるということです。それは、彼らのモダナイゼーション・イニシアティブの成功率です。
AWS でより成功している顧客を見ると、彼らはモダナイゼーションと進化を継続的なプロセスとして扱っています。彼らはそのための計画を立て、最終的には段階的な変更を行います。段階的な変更、これが重要なキーフレーズです。その反対も真実です。ほとんどの組織がモダナイゼーション・イニシアティブに失敗していることに気づきます。それは、彼らが全てを一度にやろうとするか、すべてを一度に行おうとするからです。彼らは、アーキテクチャを有機的に進化させるための実際の計画なしに、システムを書き直そうとします。これは皆さんに覚えておいてもらいたい最も重要なことの一つです。適応性が鍵なのです。
2 番目の教訓は、私が進化のコストと呼ぶものについてです。そのコストは通常、技術的負債の形で支払われます。技術的負債が何であるかは知っていますし、それはアプリケーション層、データ層、不十分なドキュメンテーション、または異なるサービスの脆弱な統合など、多くの層から生じる可能性があります。しかし、何であれ、技術的負債は、財務的負債と同様に、すべてが悪いわけではありません。インテリジェントに負債を負い、それを返済する計画がある限り、皆さんは良い立場にいます。皆さんは、財務的負債と同じように、自分たちを沈める大きな負債を抱えたくはありません。
また、技術的負債を測定できることも重要です。なぜなら、測定しなければ、未知のコストを抱えることになるからです。ここのビジュアルは、この悪循環をとても良く説明しています。進化の計画がなく、プロアクティブな適応性と段階的な変更について考えていなければ、今日または明日、技術的負債を抱えることになります。アーキテクチャを静的なシステムとして扱えば、それはより多くの複雑性をもたらし、その複雑性がこのサイクルに流れ込み、延々と続いていきます。多くの組織が技術的負債を真摯に扱っていないことに気づきました。そして時間が経つにつれて、彼らのシステムがどれほど保守不可能になるかという理由で、それはビジネス成果にも表れ始めるのです。
ですから、技術的負債に対処することは非常に重要です。そして、3番目で最後のレッスンは、私が「進化の中心」と呼ぶものについてです。ここまでで、私たちは進化可能なアーキテクチャがなぜ必要なのか、そして小さく、適応可能で段階的な変更を加えることでアーキテクチャをどのように進化させるのか、そしてそのコストに対処する方法を確立してきました。当然のことながら、アーキテクチャをどのように進化させるのか、そしてアーキテクチャを何を中心に進化させるのかという質問が出てきます。
その質問が出てくると、自然な傾向としてテクノロジーに行きたくなります。そして、残念ながらそれが多くの組織で見られる現実です。しかし、先ほど議論したように、アーキテクチャの進化をテクノロジーに固定してしまうと、移動するターゲットを追い続けることになります。なぜなら、今日の最新で最高のものが、数年後には時代遅れになってしまうからです。代わりに、進化の正しい方法は、アーキテクチャの進化の中心として、私たちが「ケーパビリティ」と呼ぶものを固定することです。そうすることで、アーキテクチャをはるかに良く進化させることができます。
ケーパビリティとは何か：ワークロードを論理的なサブユニットに分割する
ケーパビリティが何であるのか、そしてこのケーパビリティフレームワークが何であるのかについて学ぶために、私は今、Sushanth をステージに招待します。ありがとうございます、Mukund。皆さん、こんにちは。私の名前は Sushanth Mangalore で、AWS のソリューションアーキテクトです。私は、AWS 上で大規模な消費のためにソフトウェアと SaaS 製品を構築する独立系ソフトウェアベンダーの顧客と一緒に仕事をしています。このロールを引き受ける前は、ソフトウェアアーキテクトまたはアプリケーションアーキテクトとして働いていました。そして、クラウドアーキテクチャとソフトウェアアーキテクチャの間に多くの類似点があることに気づいています。
あなたのソフトウェアとそれが実行されるインフラストラクチャは一緒になって、消費者に統一された経験を提供します。消費者はそれらを2つの別々のものとしては見ていません。彼らはそれを1つのものとして消費しています。ですから、ソフトウェアアーキテクチャからのいくつかのレッスンを借りることは、クラウドアーキテクチャを定義する際に本当に役に立つことができます。そして、今日のセッションを進めていく中で、これをテーマとして見ることになります。それでは、3つの C の心的モデルを提供したいと思います。最初の C から始まり、それはケーパビリティです。
典型的なエンタープライズを考えてみてください。エンタープライズは1つ以上のワークロードを持つことができます。ここで、ワークロードを、ビジネス価値を提供するために一緒に来るリソースとコードの集合として定義します。しかし、その定義から、ワークロードは単一ページアプリケーションのようなシンプルなものかもしれません。または、多くの動く部分を持つ大規模で複雑なシステムかもしれません。CRM ソリューション、e コマースシステム、または銀行ソリューションのようなものを想像してください。一部の組織では、1つのワークロードが彼らのビジネス全体である可能性があります。
大規模で複雑なシステムをアーキテクチャする際には、ワークロードを小さく、より管理しやすい部分に分割したり、整理したりして、それぞれの部分に対して的を絞ったソリューションを用意することが役に立ちます。そこで、ケーパビリティという考え方をご紹介したいと思います。ワークロードケーパビリティは、ケーパビリティとして特定したワークロードの各部分に対するビジネスインテントを表しています。これらは、独立して対応策を立てることができる論理的なサブユニットです。
ケーパビリティはビジネスインテント、つまり、ビジネスが一定期間にわたって提供する必要があるものを表しています。今日はある一連のテクノロジーでこれらのケーパビリティを実装することを選択できますが、将来、より新しく、より高速で、より安価で、より効率的なオプションが利用可能になったときに、それらのテクノロジーを切り替える能力を保持しています。そして、それは必ず起こります。このようにして、ケーパビリティを独立して進化させることができるアプローチを取ることで、ワークロード全体が恩恵を受けることになります。
ケーパビリティという言葉は、様々な文脈で聞いたことがあるかもしれませんが、このセッションの残りの部分では、ケーパビリティという言葉を、明確に定義されたビジネスインテントを持つワークロードの論理的な部分を意味するものとして使用します。ワークロードレベルでは、Well-Architected Framework があり、これはワークロードを Well-Architected Framework の6つのピラーで定義される共通のアーキテクチャ次元全体でベースラインします。
Well-Architected Framework という考え方を、ワークロードに影響を与えている高リスク項目を特定し、対処するためのレビューメカニズムとして聞いたことがあるかもしれません。しかし、Well-Architected Framework を構成する原則とガイドラインはすべて、いつでも使用できるようになっています。計画と設計の段階でも使用することができますし、Well-Architected Framework を早期に採用すればするほど、ワークロードが well-architected になるまでの道のりが早くなります。
ワークロードが本番環境に到達する時点で、well-architected という観点では既に半分の道のりを進んでいます。Well-Architected は基礎となるレイヤーを提供し、その well-architected の基礎の上に、個々のケーパビリティをアーキテクチャし、それらに対して的を絞ったソリューションを提供することができます。では、ワークロードをケーパビリティにどのように整理するのでしょうか？
いくつかの異なるテクニックがあり、どれもとても効果的です。最初のテクニックはビジネスオーナーシップで、特に非常に大規模なワークロードに適用できます。例えば、e-commerceソリューションのようなものを考えてみてください。商品推奨機能はProduct Marketing Departmentが所有し、カスタマーサポートチャットボットはCustomer Successが所有するかもしれません。これらのビジネスユニットはそれぞれ独自の成功基準、独自のビジネスゴール、独自の予算、独自のスキルとスタッフを持っています。このようにして、これらの機能の周りに境界を引いて、ケイパビリティとして定義することができます。
さて、これはConway's lawと衝突することがあります。Conway's lawは、ビジネスが構築するソフトウェアは組織のコミュニケーション構造を反映するということを述べています。もし組織がすでにビジネスに合わせたチームを構築しているのであれば、通常はアーキテクチャに到達するのが簡単で、ビジネスインテントが満たされていることを確認できます。もし非常に大規模なテクノロジーセンターオブエクセレンスやテクノロジーに合わせたチームを持っているのであれば、時々それらのテクノロジーに合わせたチームによって行われたテクノロジーの選択が、ビジネスインテントをどのように達成するかに影響を与えたり、制限したりすることがあります。確かに解決するのは難しい問題で、ここで本当に解決できるようなものではありませんが、ワークロードをケイパビリティで整理する際に心に留めておくべきことです。
次のテクニックはソフトウェアアーキテクチャから借用しており、domain-driven design、つまりDDDのアイデアを使用しています。DDDはワークロードをbounded contextで整理するというアイデアを推進しており、各bounded contextはビジネスドメインを表します。Event stormingはbounded contextやドメイン境界を特定するための人気のあるテクニックです。これは主要なステークホルダーが集まってbounded contextを特定する1日のワークショップです。これらのbounded contextを特定したら、それらはワークロードのケイパビリティになることができます。
次のテクニックはDDDほど形式的ではありません。基本的な優れたアーキテクチャプラクティスを活用しているだけで、私はそれをArchitecture 101と呼びます。共通の目的を達成する関連する機能をまとめて、それをケイパビリティにグループ化します。これは私がfunctional cohesionと呼ぶものです。このようにしてケイパビリティを特定したら、ワークロード内の他のケイパビリティから隔離し、疎結合にします。私たちはケイパビリティを特定するための2つの駆動要因として、couplingとcohesionを活用しています。このようにして、各ケイパビリティは独立して運用および進化させることができます。
最後に話したいテクニックはdistinguishing traitsです。Distinguishing traitsはワークロードの一部で、それらを際立たせる特定の品質を示しています。これらは通常、競争上の優位性またはビジネス差別化要因に変わります。最も簡単な保険見積もりプロセスやe-commerceで最速のチェックアウトのようなものを提供することを想像してみてください。これらはすべて、誰かがあなたのソリューションまたは市場に出ている他のものを使用する理由です。distinguishing traitsを念頭に置いてソリューションを必要とするワークロードの部分を特定したら、それらの機能の周りに境界を引いてケイパビリティとして定義することができます。
ワークロードをどのようにケーパビリティに分割するかに関わらず、このセッションの後半でも話しますが、区別される特性が本当に重要になってきます。これらのテクニックのいずれか一つ、または組み合わせを使用して、ケーパビリティに到達することができます。重要なのは、ワークロード全体を一つの巨大なものとして解決するのではなく、代わりにそれをより小さな部分に分割して、それぞれに対してより簡単に解決策を立てるということです。このようなアプローチがない場合、ワークロード全体、あるいはエンタープライズ全体にわたって共通のテクノロジーセットで標準化しようとする、いわゆるブロードストロークなアプローチで解決しようとするのが非常に一般的です。これは、システムの一部に対してテクノロジーの選択が最適でなくなる状況につながる可能性があり、より良いオプションが存在する場合もあります。
機能要件と非機能要件：dialogue-based discoveryによる特性の発見
それでは、ワークロードをケーパビリティに分割する方法がわかったので、ケーパビリティを構成するものについて話しましょう。ケーパビリティは二つの要素で構成されています。機能要件 と非機能要件、つまり NFR があります。
機能要件はよく理解されており、通常はよく述べられています。プロダクトチームはビジネスと話し合い、エピック、ユーザーストーリー、要件仕様書の形式で文書化し、エンジニアリングチームがそれを構築します。一方、非機能要件は、セキュリティ、可用性、パフォーマンスがすべて重要であることを誰もが認識していますが、通常は事前にはよく述べられていません。エンジニアリングチームがそれらを発見し、後付けにならないようにする必要があります。私たちのアプローチは、非機能要件を第一級のステータスに昇格させることを推奨しています。テクノロジーの決定を行う際には、これらが最前線にあるべきです。
ビジネスが非機能要件をよく述べていない場合はどうなるでしょうか。その場合、それらを発見または引き出す必要があります。ここで使用するテクニックは、dialogue-based discovery と呼ばれています。ビジネスインテントは複数のレベルに存在する可能性があります。 ワークロードレベルでは、通常は何らかの CXO 目標またはボードレベルの目標と一致しています。利益率を改善したい、またはトップラインの収益を増やしたいということもあります。あるいは、リスク削減イニシアチブやコンプライアンスイニシアチブの一種である可能性もあります。ケーパビリティレベルでは、ビジネスインテントはより焦点を絞った傾向があります。ビジネスと話し合い、特定のケーパビリティで何を達成しようとしているのかを理解しようとします。そして、このような用語を耳にするでしょう。
顧客満足度を向上させたいという例を考えてみましょう。顧客が不満を感じる理由はさまざまです。ショッピングカートが放棄されていることに気づくかもしれません。多くのインシデントやチケット、または多くの苦情を受け取っていることに気づくかもしれません。しかし、私たちアーキテクトにとっては、不満の原因が何であるかを理解し、ビジネスにより具体的な質問をする必要があります。「ユーザーは重要なユーザージャーニーでエラーを見ていますか？」「アプリケーションは遅いですか？」「ユーザーが必要とするときにアプリケーションは利用できませんか？」このような質問を通じて、特定の品質に到達することで、非機能要件を発見することができます。
これらの各ステートメント ですね、ビジネスが平易な英語で述べたものは、非機能要件につながる可能性があります。顧客満足度のシナリオでは、パフォーマンス、レジリエンス、可用性に行き着きました。しかし、これらは決して網羅的ではありません。ユーザーの不満を引き起こしている可能性のある他の理由、例えばシステムの使いやすさやレスポンシブネスもあるかもしれません。しかし、これだけではエンジニアが構築するには十分ではありません。エンジニアが追求できる具体的なメトリクスや SLO が必要です。そこでもう一段階掘り下げて、「99 パーセンタイルでページロード時間が 2 秒でも大丈夫か」とか「システムが数分間、例えば 1 ヶ月に 5 分間ダウンしても大丈夫か」といった、より具体的な質問をします。そうすることで、エンジニアチームが今追求できるより具体的な SLO に到達します。
これが、ビジネスの意図から非機能要件に到達する方法です。しかし、ビジネスとの会話を終えて、十数個の NFR を手にしたと想像してみてください。すべてが素晴らしく聞こえます。パフォーマンスが欲しい、セキュリティが欲しい、レジリエンスが欲しい、コスト効率が欲しい、そして本当に除外したいものは何もありません。しかし、これらの NFR を並べて見始めると、それらが互いに健全な緊張関係にあることに気づくでしょう。冗長インフラと高価なハードウェアを備えた、高いパフォーマンスと高いレジリエンスを持つシステムを構築している場合、それは明らかにコスト効率に反します。これがトレードオフです。
このトレードオフの会話を持つ必要があります。なぜなら、私たちが「アーキテクチャ特性」と呼ぶもの、つまり 2 番目の C に到達したいからです。 アーキテクチャ特性とは、私が言うところの交渉の余地のない NFR であり、あなたの機能の成功にとって不釣り合いなほど重要で不可欠なものです。これらはあなたの機能を定義するものであり、達成したいと思う願望的な非機能要件とは別のものです。これらはあなたの機能が成功するために重要です。本当に、これらの中から少数のものを追求したいのです。文字通り、片手で数えられるくらいの量です。6 つか 7 つくらいを追求し始めると、エンジニアリングが難しくなります。過度に設計されたシステムに終わるかもしれませんし、それらの重要性を全体的に薄めてしまうかもしれません。
アーキテクチャ特性：トレードオフを理解し、AWSサービスを選択する
本当に、それらをターゲットにして達成できるように、限定的に保ちたいのです。 これを例で理解しましょう。トレーディングシステムというワークロードを想像してください。
トレードを実行できるオーダー管理という機能を持つシステムです。このシナリオでは、ビジネスとの会話を持って、スケーラビリティ、信頼性、パフォーマンス、規制コンプライアンスが、あなたの重要な非機能要件、つまりアーキテクチャ特性であると判断します。これらを達成する際に、他の非機能要件をトレードオフする必要があるかもしれません。先ほど述べた理由から、コストをトレードオフする必要があるかもしれません。これは高性能ハードウェア、冗長インフラ、高いスケーラビリティを必要とする複雑に設計されたシステムです。コストはこれらの特性と相反しています。シンプルさはどのシステムにとっても良いことですが、あなたが操作している本質的なドメインがシンプルさを達成しにくくしています。どれだけ多くのテクノロジーを投入しても、ソリューションは常に複雑になります。
敏捷性というのは、別のトレードオフが必要になる可能性があります。高い信頼性、高いパフォーマンス、スケーラビリティのためにシステムをエンジニアリングしている場合、新しい変更がリグレッションを引き起こさないようにしたいのです。新しい変更を細心の注意を払って検証する必要があり、それは長いリリースサイクルをもたらす可能性があります。これは許容できることです。なぜなら、これらのアーキテクチャ特性の有効性を優先し、他の特定の品質をトレードオフしているからです。この下には、まだ well-architected baseline があります。 well-architected framework は、AWS 上のすべてのワークロードが持つべきアーキテクチャ次元を提供しています。しかし、アーキテクチャ特性はこれをさらに一歩進めて、あなたの能力を強化し、何があなたを差別化させ、競争優位性になるかを示しています。
では、同じワークロード内の別の機能を見てみましょう。今回は、トレードのエンドオブデイレポートで、これは次のビジネスデーまたは次のマーケットデーの開始前にあなたのトレーダーにメールで送信されます。この状況では、コスト効率性、実装の容易さ、保守の容易さを優先しています。それを達成する際に、実はスケーラビリティをトレードオフする可能性があります。レポート生成が大規模にスケーラブルである必要はありません。なぜなら、バッチ処理できるからです。パフォーマンスが高度に最適化される必要もありません。なぜなら、ユーザーはレポート生成にどのくらい時間がかかったかは気にせず、次の日の終わりまでまたは次の日の開始前に受信箱に受け取ることだけを気にしているからです。
この場合、同じワークロード内の別の機能が、完全に異なる特性のセットをもたらしています。これらの機能は一緒になって、ワークロードの全体的な目標を達成します。全体は部分の合計より大きいのです。全体はあなたのワークロードで、部分はあなたの機能です。私はこれをサッカーのようなチームスポーツと並行して考えようとしています。 チームを構成する複数の選手がいて、各選手はチーム内で彼らがプレーする役割に対して成功させる特定のスキルまたは技術的属性を持っています。チームのコーチは、ゲームに勝つ意図を持ってマッチデーに向けて彼らを標準的なドリルのセットを通じて実行します。これが私が Well-Architected Framework と同等だと考えるものです。
あなたのワークロード内の各機能は Well-Architected Framework から等しく恩恵を受けます。しかし、これを超えて、特定のポジションまたはチーム内の特定の役割に合わせた個別のドリルもあります。ゴールキーパーは独自のドリルを持っています。 フォワードは独自のドリルを持っているので、シュート練習、フリーキック、そしてそのすべてを行います。これらが私が機能とそれらの特定の特性と同等だと考えるものです。一緒に、選手たちはチームが彼らの目標を達成するのを助けます。チームスポーツでは、マーキープレイヤーまたはフランチャイズプレイヤーという考え方もあります。そのプレイヤーが素晴らしい日を過ごせば、あなたのチームが勝つ可能性が高いことを知っています。同様に、あなたのワークロード内では、フラッグシップ機能のような特定の機能を持つ可能性があり、ワークロードの成功はその 1 つの機能に依存しています。
時々、特定の機能に特別な注意を払う必要があり、その機能により多く投資していることに気づくかもしれません。これは正常です。そうは言っても、 これはすべて AWS サービスにどのように結びついくのでしょうか？私たちはここで AWS サービスに関する技術的選択を簡素化するためにいます。AWS サービスは、定義からだけでサービスのアーキテクチャ特性を示しています。ここで強調されている単語を見ると、Amazon S3 はオブジェクトストレージサービスであり、スケーラビリティ、データ可用性または耐久性、セキュリティ、パフォーマンスをその際立った特性として提供しています。あなたのソリューションがオブジェクトストレージを必要とし、あなたの機能のために達成しようとしている特性が S3 が提供するものと一致する場合、あなたはあなたのサービスを見つけたのです。
このようなことは、私たちのサービス全体で見られるようになっています。ECS と EKS のどちらかという質問に答えるたびに1ドルもらえたら、かなり裕福になっていたでしょう。ECS はデプロイメントのシンプルさ、管理性、スケーリングを提供します。ですから、ワークロード内でそのようなものを探しているのであれば、ECS が正しい選択肢かもしれません。
最後の例として DynamoDB を見てみましょう。これは完全にマネージドされた、サーバーレス、高性能で、非常にスケーラブルなサービスです。データストレージとデータアクセスパターンが DynamoDB が提供するものと一致し、実現しようとしている機能の特性が DynamoDB が提供するものと合致している限り、DynamoDB はアーキテクチャに適した選択肢かもしれません。
ここまでで、アーキテクチャの特性を使ってサービスを選択できることがわかりました。ここでは、いわゆる jobs-to-be-done のアプローチを取っています。このアイデアに詳しい方であれば、あなたは仕事を持っていて、その仕事をするためにサービスやプロダクトを雇うわけです。この場合の仕事は、実現しようとしている機能と、その機能のために達成しようとしている特性によって定義されます。そのサービスが仕事をしてくれなければ、いつでも解雇することができます。
制約の力：選択肢をシンプルにし、倹約的なアーキテクチャを実現する
これで、3番目の C である制約に到達します。制約というのは、ビジネスまたはエンタープライズに固有のものです。これらは予算、タイムライン、手元にあるスキル、そしてリスクといった懸念事項に関連するものです。 制約は通常、アーキテクチャを構築しているチームのコントロール外にあります。これはあなたのビジネスに固有のものであり、一夜にして変えられるようなものではないため、これと一緒に働くことを学ぶ必要があります。
制約にはネガティブなニュアンスが伴うことがあります。制約はあなたに制限を課し、柔軟性を減らし、選択肢を限定します。しかし、制約に対して別の見方をしたいのです。制約は実は、あなたにとって有益なものになり得るのです。制約は、ソリューションにおける創意工夫を促し、倹約を推進します。 数年前の re:Invent で、当社の CTO である Werner Vogels が、frugal architect というアイデアを紹介しました。制約は実は、アーキテクチャの選択において倹約的になるのを助けてくれるのです。
オプションを制限するということを、今度はポジティブな意味で言っているのに気づくかもしれません。オプションを制限することが実際にしてくれるのは、選択肢をシンプルにするということです。それはあなたのソリューション空間を狭め、テクノロジーの選択にもっと早く到達することを可能にします。もし制約があなたのテクノロジー選択肢の一部を完全に排除しているなら、残されたものがあなたのソリューション空間です。このようにして、選択肢の過剰さという問題を解決し、実は制約を私たちの有利に使うことができるのです。
これらの制約は、私が本質的な制約、または事業に内在する制約と呼ぶものです。しかし、人工的な制約や偶然に導入される制約も存在します。それらは通常、エンタープライズガイドラインの形で現れます。「ベンダーロックインを避ける」「これらのサービスは承認されていない」「私たちは特定のテクノロジーショップである」といったステートメントに馴染みがあれば、これらは決して珍しくなく、ほぼすべてのエンタープライズに存在しています。それらは通常、特定のテクノロジーと特定のアーキテクチャパターンの使用を強制または制限しています。
最も一般的には、それらは非常に良い意図で存在しています。これらは過去の研究、過去の評価、過去の経験、または標準化の取り組みに基づいています。しかし、その結果として起こりうるのは、人工的に制限を課すことであり、その結果として最良のソリューションをもたらすような方法で機能をソリューションすることができなくなるということです。代わりに私たちが推奨するのは、あなたの3つのC、つまりケーパビリティ、制約、そして特性を使ってテクノロジーの決定に到達し、その後それらをエンタープライズガイドラインに対して評価することです。もしあなたのエンタープライズガイドラインが実際にあなたのソリューションを改善しているなら、ぜひエンタープライズガイドラインから参考にしてください。
決してアーキテクチャレビューボードと喧嘩をしたり、すべてのガイドラインを捨てたりするべきだと言っているわけではありません。いいえ、それらはまだ非常に重要です。しかし、私たちが推進しているのは、それらを石に刻まれたものにして、進んでいない時代に立ち止まらせるべきではないという考え方です。あなたのエンタープライズガイドラインはあなたのソリューションにアドバイスを与えることができますが、あなたが3つのCを通じて行う新しい発見と、あなたが確立した意図性があなたのテクノロジー選択の背後にあるべきであり、それがエンタープライズガイドラインにフィードバックされるべきです。そうすることで、それらは停滞したままにならず、同様に継続的に進化していくのです。
エンタープライズガイドラインが古くなっていたり、5年前のものであったり、もはや目的に適さなくなっているというのはよくあることです。これはあなたがエンタープライズガイドラインを継続的に進化させるための意図的な強制機能です。
Architectural Decision Records（ADR）：アーキテクチャの意図をドキュメント化する
そして、これが起こるときは本当に幸運なことがあります。私たちはアーキテクチャの背後にある意図を確立するために、すべてこの時間をかけてきました。最後のステップをおろそかにしたくないんです。これは重要なステップです。テクノロジストとして、私たちはドキュメンテーションがあまり好きではありません。しかし、ここで提案しているのは、ページ単位でドキュメンテーションを書くことではなく、代わりに、おそらくあなたたちの多くがすでに馴染んでいるコンセプトを使うことです。それは Architectural Decision Records、つまり ADR です。ADR はアーキテクチャをドキュメント化するための軽量なベースです。ADR とアーキテクチャ図があれば、アーキテクチャをドキュメント化するのに必要なすべてだと言えます。Confluence ページや wiki にページ単位でドキュメンテーションを書く必要はなく、アーキテクチャを理解することができます。
ADR に不慣れな方のために、ADR を構成するものについて説明したいと思います。まずタイトルから始めます。ここでは、アーキテクチャの決定が何のためのものなのかを定義し、達成しようとしている機能を指定します。ステータスはさまざまなステージを通ります。proposed、under review、accepted、または rejected です。Rejected された決定も周りに置いておくのは良いことです。なぜなら、すでに評価されて rejected されたものについて、同じ評価サイクルを再度経ることは避けたいからです。ADR がもう必要でなくなった場合は、deprecated にすることもできます。
次のステージはコンテキストです。ここでは、問題ステートメントを詳細に説明します。ここで、あなたの決定を支配しているすべてのことを指定します。最後に、決定セクションでは、テクノロジーの選択肢として何を使用しているか、最終的に下した決定を指定します。決定と一緒に、この決定の結果もドキュメント化したいと思います。この決定の結果は何ですか？どのようなトレードオフをしなければなりませんでしたか？決定が予想通りに進まない場合のフォールバック オプションは何ですか？場合によっては、いくつかの代替案を評価していることもあり、それらをドキュメント化するのは有用です。なぜなら、それらはフォールバックになる可能性があるからです。最終的な決定にわずかに及ばなかった何かが密接に関連している場合、決定が予想通りに進まなければ、その代替案が実際のアーキテクチャの選択肢になる可能性があります。
これらの標準的な ADR フィールドに加えて、追加のフィールドをドキュメント化することもお勧めします。決定に関与しているステークホルダーをドキュメント化することをお勧めします。この決定を下すのに実際に関わった人たち。なぜなら、これらの決定は決して1人では下されないからです。あなたがアーキテクトであっても、おそらくこれを自分で思いついたわけではありません。通常、プロダクト チームが関わっていて、エンジニアリング チームが関わっていて、アーキテクチャが関わっています。この決定を下すのに実際に関わった人たちの名前を記載してください。それはまた、決定の背後にある説明責任と確信を設定します。もし誰かを責める必要があれば、どこに行けばいいかわかります。
さらに、特性と制約を別のフィールドとしてドキュメント化することもお勧めします。もちろん、それらをコンテキスト内に記載することもできます。しかし、時々コンテキストが非常に冗長になると、それらはそこで失われる可能性があります。制約と特性を独自のフィールドとして表面化させれば、最初の場所でこの決定を駆動したものについての共有理解が生まれます。
実践例：e-commerceシステムとAmazon Rufusにおける3つのCの適用
では、実際の例を見ていきましょう。e-commerce システムのようなワークロードを取り上げて、product catalog という機能に焦点を当てます。product catalog について、私たちのビジネス意図は、多様な製品コレクションを最高レベルのユーザー体験で提供したいということです。そのために、ビジネスチームと話し合い、scalable、reliable、performant といったアーキテクチャ特性 がこの機能の成功に本当に重要だと判断しました。これが採用につながるわけです。また、いくつかの制約条件も抱えています。 コンテナを使いたいのですが、本番環境でコンテナワークロードを実行した経験が非常に限定的です。また、多くの地域にわたって様々な製品をサポートしたいのですが、特定の種類の製品だけを販売しているわけではありません。
こうした状況を踏まえて、アーキテクチャの決定に至りました。まず、検討した選択肢を見てみましょう。 最初は serverless first という考え方から始めたのですが、初日から何百万人ものユーザーがこの機能を使い、24 時間ずっと使い続けると考えられます。ですから、autoscaling を備えた provisioned compute の方がうまくいくと考えました。コンテナベースのアーキテクチャを使いたいのです。VM に直接デプロイするのは避けたいのですが、コンテナの旅を始めたばかりなので Kubernetes の経験が全くありません。これが compute の側面です。
データベースについては、relational database を検討したのですが、サポートしたい製品タイプの数が多く、サポートしたい地域の数も多いため、データモデルを標準化するのが非常に難しいことがわかりました。ですから、relational database は一旦除外しました。ストレージについては、network file system を検討しました。
しかし、私たちが扱うのはほとんどが product image や product video のような静的データです。そのため、network file system はコスト効率が良くないことがわかりました。最終的に私たちが採用したソリューションは、コンテナベースのアーキテクチャです。 Amazon ECS with Fargate を選びました。これは必要なスケーラビリティを提供し、アプリケーションを reliable で performant なものにするよう設計できます。
それに加えて、DynamoDB が提供する特性が私たちが達成しようとしている特性と一致しているため、NoSQL をデータベースとして選びました。DynamoDB のデータアクセスパターンとデータシェイプを私たちのために機能させることができます。最後に、object store を選びました。object store は静的データに対して最適化されており、Amazon S3 は私たちが達成したいアーキテクチャ特性と一致する特性を提供しているからです。
ここでは、ワークロードから capability に至るまでのプロセスを、3つの C—characteristics、capabilities、constraints—を使って、どのようにアーキテクチャの選択に到達するかを示しています。別の例でこれを素早く強化してみましょう。時間の都合上、Amazon Rufus のような別の例を取る方法をお見せします。Amazon Rufus を使ってショッピングをお手伝いしてもらったことがあるかもしれません。例えば、e-commerce 企業がこの capability を構築したいとしましょう。
アーキテクチャの characteristics は、cost-effective で、maintainable で、agile である必要があり、制約としては in-house の AI/ML スキルが限定的で、今日は Cyber Monday なので時間があまりないということです。 この3つの C が与えられたとき、self-host するかどうかを評価することができます。スキルがないので、Amazon Bedrock で対応する方が良いでしょう。同様に、commercial vector database を構築・保守したくないので、Amazon Bedrock を使う方が良いでしょう。このようにして意思決定に到達するわけです。
よくある質問：conflicting characteristicsとgreenfield/brownfieldシナリオ
次に、よくいただく質問の1つは、複数の capabilities を持つワークロードがあり、これらの capabilities が conflicting characteristics を持つことがあるということです。どのようにこれを考え抜き、characteristics が相互に打ち消し合わないようにするかということです。 ワークロード内に複数の capabilities を持つことができます。同じ characteristics のセットを持っている場合、通常は共通の目標を達成するために一緒に機能します。しかし、conflicting characteristics を持っている場合、例えば capability A が performance に最適化されていて capability B がそうでない場合、capability B は実際に capability A を足を引っ張ることができます。
彼らは well-defined interfaces を通じて通信します。これを解決する方法はいくつかあります。まだ well-architected baseline があります。 これはすべての capabilities に均一に影響を与え、すべてに影響を与えるので、互いに大きく離れていてはいけません。しかし、それに加えて、すでに capability A を performance に最適化しているので、capability A は自分の characteristics を保護する必要があります。これが次の概念につながります：isolation boundaries です。
Isolation boundaries は、各 capability が他の capabilities と相互作用している場合でも、自分の characteristics を保護することを可能にする概念的なアイデアです。これらはさまざまな形で実装することができます。circuit breakers、exponential back-offs and retries、queuing、asynchronous communication のようなものがあります。アプリケーションコードを通じて実装することもできます。Good fences make good neighbors であり、同様に isolation boundaries は capabilities が自分の characteristics を保護するのに役立ちます。
次によく受ける質問は、ADRが有用であることは誰もが理解していて、その有用性についてはコンセンサスがあるということです。しかし多くの組織では、ADRを始めることか、あるいは一定期間にわたって継続的に実施することのいずれかに問題を抱えています。次は、そこにどう取り組むかについてお話しします。ADRは言うは易く行うは難しです。もちろん、私たちは皆ドキュメンテーションが嫌いなので、実際にADRプロセスを始めるには追加の努力が必要に感じられます。しかし、AWSで見てきたカスタマージャーニーに基づいて、私たちが整理した3つのシンプルなティップスがあります。
まず、シンプルなクロスファンクショナルチームから始めてください。ビジネス、プロダクト、エンジニアリング、そしてビジネススタークホルダーとの対話が必要です。そうすることで、そのシステムのためにどのような機能を構築しているのかが分かります。そして、チームはリーンに保ってください。大きなチームを作ってしまうと、意思決定に行き詰まってしまいます。それは意図ではありません。リーンなクロスファンクショナルチームである必要があります。2番目の側面はプロセスについてです。これらのADRを保存するためのプロセスが必要であり、最も重要なことに、それは一元化されていて、アクセス可能である必要があります。
3番目に重要なことは、バージョン管理が必要だということです。なぜなら、実際に進化の流れを見ることができるからです。時間とともにどのように意思決定がなされてきたかを見ることができる必要があります。
最後に、ガバナンスは重要です。結局のところ、もし単に週次のページにADRの束があるだけなら、それは必ずしも誰もがそのガイダンスに従うことを意味しません。これらのADRを強制することができる必要があります。これを行う方法は、AWS Organizations やサービスコントロールポリシーなどのAWSサービスを活用するといった簡単なことです。これらを使うことで、特定のAWSアカウント内でどのサービスを起動できるかを制御することができます。さらに、AWS Configのようなサービスを使用して、より細かい粒度での強制を行うことができます。
このフレームワークについてお客様からよく受ける質問は、それがグリーンフィールドシナリオ、ブラウンフィールドシナリオ、またはその両方に適用されるかどうかということです。このフレームワークはグリーンフィールドとブラウンフィールドの両方のソリューションに等しく適用可能です。ただし、これらの特性にアプローチする方法は異なります。グリーンフィールドの機能の場合、ほとんどの場合、予測に基づいて作業を行い、定性分析と呼ぶものを行っています。ビジネスと協力して、機能を構築するためのアーキテクチャ特性を特定しますが、誰もまだ本番環境でアプリケーションを使用していません。実際の使用パターンや、アプリケーションまたは機能が本番環境でどのように実際に使用されるかは分かりません。
実際に本番環境に入って、その使用状況を目にするまでは、ほぼ予測に基づいて作業することになります。アーキテクチャの特性に到達するために、確かに市場調査も行いますが、本質的には正しい選択をしたことを願っているだけです。一方、brownfield では、すでに本番環境で明確に定義されたメトリクスと使用パターンが確立されています。スケーラビリティやパフォーマンスの能力を最適化すれば、今日のスケーラビリティとパフォーマンスのレベルが正確にわかります。それを改善する必要がある場合は、そこから始めるベースラインがあります。
この場合、実際のメトリクスを使用しているため、定量分析を使用する能力が得られます。このようにして、brownfield は実は greenfield と比べて利点になることもあります。エンジニアは greenfield のソリューションで作業するのが好きです。なぜなら、彼らのすべてのアイデアを実装するための白紙の状態が得られるからです。しかし brownfield には greenfield と比べて独自の利点があります。brownfield と greenfield の両方で、ワークロードを capability に分割する機会があります。ただし、各シナリオのアーキテクチャの特性を決定する方法は異なります。実は、brownfield の状況で今日のワークロードが capability に分割されていない場合は、このセッション後に、大きなワークロードをより小さな capability にどのように分割できるかを再検討するのは良い時期かもしれません。
まとめ：capabilityを中心に据えた規律あるアーキテクチャ実践
それでは、この 3 つの C のフレームワークを見てきたので、それをまとめましょう。常に capability から始めてください。デフォルトの反応とトレンドは technology から始めることですが、そうしないでください。capability から始めて、特に non-functional capability に細心の注意を払ってください。なぜなら、このアプローチではそれらが第一級市民である必要があると提案しているからです。次に、これらの capability から特性を抽出します。特性を選びすぎないようにしてください。ほんの一握りだけにしてください。特性を取得した後、technology の選択肢を絞り込みます。ご覧のように、特定の technology について考え始めるのは 3 番目のステップまでではありません。それは選択肢を絞り込むときです。
選択肢を絞り込むときは、3 つの C と enterprise guidelines を組み込んだ意思決定フレームワークを念頭に置いてください。これは覚えておくべき重要なことです。その後、ビジネスに応じて architectural patterns に到達します。ここで理解すべき最も重要なことは、アーキテクチャが決定されたときに仕事が終わるわけではないということです。実は、それが最初の反復が始まるときです。アーキテクチャを評価する必要があります。私たちが言ったように、architecture evolution は継続的なプロセスです。これを何度も繰り返すことで、長期間にわたってアーキテクチャをより有機的で一貫性のある方法で進化させることができるため、ビジネスの成果を迅速かつ動的にサポートできるようになります。
re:Invent でのこの 1 週間を終えるとき、新しい製品、サービス、機能、ソリューション、そしてもう 1 つの architectural pattern についての膨大な情報を得ることになると思います。しかし、最初にしていただきたいことは、アーキテクチャを生きたシステムとして見始めるようにマインドセットをシフトさせることです。進化が起こっていることを認識してください。その進化は反応的ですか？積極的にできることはありますか？進化の計画をステップ 1 として立ててください。capability をアーキテクチャの進化の中心に据えてください。私たちが議論してきたように、それは technology ではなく、3 つの C と capability です。段階的かつ積極的に進化させるための計画を立ててください。
ADRについては、いくつかのヒントを提供していますので、ぜひADRに取り組んでみてください。実は、顧客がナレッジベースのADRアプリケーションを構築し始めているのを目にしています。ですから、それが実際に最も簡単に構築できるものかもしれません。最後に、AWSのアカウントチームに相談してください。AWS アーキテクトとして、私たちはAWS上の数千の顧客ジャーニーを見ることで、何がうまくいき、何がうまくいかないかを知ることができます。私たちはこれらすべてから学んでいますし、それをあなたたちと共有するためにここにいます。ですから、ぜひAWSチームに相談してください。
結局のところ、重要なのは建築実践に対する規律あるアプローチです。テクノロジーではなく、機能に焦点を当て、アーキテクチャを進化させるためのアプローチの一貫性を保つこと。それが重要なのです。それでは、ご参加ありがとうございました。お手数ですが、携帯電話を取り出して、フィードバックをいただけると幸いです。
これがフレームワークであり、また、これに関するワークショップも行っています。このワークショップがあなたの特定のユースケースにこのフレームワークを適用するのに役立つと感じられましたら、アカウントチームに連絡していただければ、彼らがそれを促進してくれます。最後に、AWSコンソール内にADRツールが欲しいという方は、フィードバックでそう示してください。来年はそれが実現しているかもしれませんから。それでは、ご参加ありがとうございました。さらに詳しくお話しされたい場合は、私の右側、あるいはあなたの左側の廊下にいますので、お気軽にお声がけください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion