ロックイン回避に囚われるな

アーキテクトの主要な目標の1つは、選択肢を生み出すことです。これらの選択肢により、システムは変化に耐えられ、より多くの情報が得られるまで決定を延期したり、予期せぬ事態に対応したりできます。ロックインは正反対です。あるソリューションから別のソリューションへの切り替えを困難にします。そのため、多くのアーキテクトは、コンポーネントを自由に交換および相互接続できるITシステムの世界の守護者と自らを捉えながら、ロックインを最大の敵と考えるかもしれません。

しかし、アーキテクチャはめったにそれほど単純ではありません。それはトレードオフのビジネスです。経験豊富なアーキテクトは、ロックインには回避すべきという宣言以上のものがあることを知っています。ロックインには多くの側面があり、好ましい解決策となることさえあります。それでは、Architect Elevatorに乗って、ロックインを詳しく見ていきましょう。

オープンソース・ハイブリッド・マルチクラウド == ロックインフリー？

今日、私たちがソフトウェアをデプロイしているプラットフォームはますます強力になっています。最新のクラウドプラットフォームは、写真が子犬かマフィンかを判断するだけでなく、コードをコンパイルし、デプロイし、必要なインフラストラクチャを構成し、データを保存します。

この大きな利便性と生産性向上は、まったく新しい種類のロックインをもたらします。近年、多くのアーキテクトの注目を集めているハイブリッド/マルチクラウド設定は、ロックインに対処する際に考慮する必要がある事柄の良い例です。クラウドにデプロイしたいアプリケーションがあるとしましょう。それは簡単にできますが、アーキテクトの視点からは、特にロックインに関連して、多くの選択肢とさらに多くのトレードオフがあります。

コンテナにアプリケーションをデプロイしたいかもしれません。それは良さそうですが、実行するためにAWSのElastic Container Service（ECS）を使用すべきでしょうか？結局のところ、それはAmazonのクラウドに固有です。Kubernetesの方が好きですか？それはオープンソースであり、オンプレミスを含むほとんどの環境で実行されます。問題は解決しましたか？そうではありません。これでKubernetesに縛られます。貴重なYAMLファイルのことを考えてみてください！つまり、あるロックインを別のロックインと交換したのですよね？そして、GoogleのGKEやAmazonのEKSなどのマネージドKubernetesサービスを使用する場合、特定のバージョンのKubernetesと独自の拡張機能にも縛られる可能性があります。

ソフトウェアをオンプレミスで実行する必要がある場合は、AWS Outpostsを選択することもできます。そのため、いくつかの選択肢があります。しかし、これもまた独自です。すでにロックインされている可能性のあるVMWareと統合されているため、本当に違いがありますか？新しく登場したGoogleの同等物であるAnthosはオープンソースコンポーネントから構築されていますが、それでも独自の製品です。Anthosを使い続ける限り、アプリケーションを異なるクラウドに移行できます。これはまさにロックインの定義ではありませんか？

あるいは、デプロイメントの自動化をアプリケーションの実行時環境からきちんと分離すれば、インフラストラクチャの切り替えがかなり容易になり、それらのロックインの影響を軽減できませんか？さらに、クロスプラットフォームのInfrastructure-as-Codeツールもあります。それらはこれらの懸念を完全に解消するのではないでしょうか？

ストレージのニーズには、AWS S3はどうでしょうか？他のクラウドプロバイダーはS3互換のAPIを提供しているので、独自のものであるにもかかわらず、S3はマルチクラウドに対応しており、ロックインフリーと見なすことができますか？すべてのデータアクセスを抽象化レイヤーの背後にラップし、依存関係をローカライズすることもできます。それは良い考えでしょうか？

ロックインを回避することはそれほど簡単ではなく、回避しようとしてロックインされる可能性があるようです。クラウドアーキテクチャがそれでも楽しいものであることを強調するために、Simon Wardleyによるハイブリッドクラウドに関する意見を参照させていただきます。

ロックインの様々な側面

エレベーターアーキテクト（Architect Elevatorを上下に移動する人々）は、多くの人が白黒しか見ないところにグレーの陰影を見ます。システム設計について考えるとき、彼らはロックインやカップリングのような共通の属性がバイナリではないことに気づきます。2つのシステムは、単にカップリングされているか、デカップリングされているかというわけではなく、製品にロックインされているかどうかも単純ではありません。両方のプロパティには多くのニュアンスがあります。たとえば、ロックインは多くの次元に分解されます。

• ベンダーロックイン：これは、IT関係者が「ロックイン」と言うときに一般的に意味するものです。これは、あるベンダーから競合他社への切り替えの難しさを表しています。たとえば、Siebel CRMからSalesForce CRMへの移行、またはIBM DB2データベースからOracleデータベースへの移行に莫大な費用がかかる場合、「ロックイン」されています。このタイプのロックインは一般的であり、ベンダーは一般的に（目に見える形で、あるいは目に見えない形で）そこから利益を得ています。このロックインには、以前はライセンス料金の割引を得ていた長期的なライセンスおよびサポート契約などの商業的取り決めが含まれます。
• 製品ロックイン：関連していますが、異なるのは製品にロックインされていることです。あるベンダーの製品から別のベンダーの製品に移行する場合、通常はベンダーと製品の両方を変更するため、この2つは簡単に混同されます。オープンソース製品はベンダーロックインを回避できますが、製品ロックインは削除しません。KubernetesやCassandraを使用している場合、特定の製品のAPI、設定、機能に確実にロックインされています。専門家（特に企業）環境で作業する場合は、商業的なサポートも必要になり、再びベンダー契約にロックインされます（上記参照）。高度なカスタマイズ、統合ポイント、独自の拡張機能は、製品ロックインの形態です。これらは、たとえオープンソースであっても、他の製品への切り替えを困難にします。
• バージョンロックイン：製品にロックインされていることに加えて、特定のバージョンにロックインされている可能性もあります。既存のカスタマイズと拡張機能が壊れる場合、バージョンアップグレードは高価になる可能性があります（SAP、誰でも？）。他のバージョンアップグレードでは、本質的にアプリケーションを書き直す必要があります（AngularJSとAngular 2が思い浮かびます）。さらに悪いことに、バージョンロックインは伝播します。特定の製品バージョンには、特定の（多くの場合、古い）オペレーティングシステムバージョンなどが求められるため、移行の試みはすべてYak-shaving演習になります。ベンダーがあなたのバージョンを廃止したり、製品ライン全体を廃止したりすると、特にこのロックインを強く感じます。サポートを受けないか、大規模なオーバーホールを行うかのどちらかを選択する必要があります。そして、古いバージョンで重大なセキュリティの脆弱性が発見され、パッチが提供されない場合など、さらに悪化する可能性があります。
• アーキテクチャロックイン：特定の種類のアーキテクチャにもロックインされる可能性があります。たとえば、Kubernetesを広く使用する場合、APIを公開し、コンテナとしてデプロイできる、比較的小さなサービスを構築している可能性があります。サーバーレスアーキテクチャに移行する場合、サービスの粒度を単一の関数に近づけ、状態管理を外部化し、イベントアーキテクチャなどを利用する必要があります。このような変更は些細なものではなく、アプリケーションアーキテクチャの大幅なオーバーホールを意味します。
• プラットフォームロックイン：製品ロックインの特別な種類は、プラットフォーム、特にクラウドプラットフォームにロックインされていることです。このようなプラットフォームはアプリケーションを実行するだけでなく、ユーザーアカウントと関連するアクセス権、セキュリティポリシー、インフラストラクチャのセグメンテーションなどを保持する場合もあります。また、ストレージや機械学習サービスなどのアプリケーションレベルのサービスも提供しますが、これらは一般的に独自です。これらのサービスから離れることは、プラットフォームロックインを軽減する方法のように見えるかもしれませんが、クラウドに移行する主な動機の一つを否定することになります。ソフトウェア以外の関係者は、これを板挟みになっていると呼びます。
• スキルロックイン：開発者が特定の種類の製品やアーキテクチャに精通するにつれて、スキルロックインが発生します。異なる製品やテクノロジーの開発者を再教育（または採用）するのに時間がかかります。スキルが利用できるかどうかは今日のITショップの主要な制約の1つであるため、このタイプのロックインは非常に現実的です。一部のニッチなエンタープライズ製品では、開発者の供給が特に限られているため、開発者のコストが上昇します。この効果は、カスタム言語を使用する製品、あるいは皮肉にも「設定のみ」/ノーコードフレームワークで特に顕著です。
• 法的ロックイン：コンプライアンスなど、法的理由で特定のソリューションにロックインされる場合があります。たとえば、データセンターが自国以外にある場合、データを別のクラウドプロバイダーのデータセンターに移行できない可能性があります。ソフトウェアプロバイダーのライセンスでは、システムが正常に動作するとしても、システムをクラウドに移行できない場合があります。それでも実行することを決定した場合、ライセンス条項に違反することになります。法的側面は、一般的に想定されているよりも多くのエンジニアリングの側面に浸透しています。小型エンジンの航空機は、1970年代に設計され、鉛を多く含む燃料を燃やすエンジンを搭載している可能性があります。新しいエンジンの設計は、高い法的責任を負います。
• メンタルロックイン：最も微妙でありながら最も危険な種類のロックインは、思考に影響を与えるものです。特定のベンダーとアーキテクチャで作業した後、意思決定に仮定を吸収する可能性があり、これにより代替オプションを拒否する可能性があります。たとえば、スケールアウトアーキテクチャが線形にスケールしないため（ハードウェアを2倍にしてもパフォーマンスが2倍にならないため）、非効率であるとして拒否する可能性があります。技術的には正確ですが、この考え方は、効率ではなくスケーラビリティが主な推進力であるという事実を無視しています。あるいは、頻繁な変更により欠陥が増えることを観察したため、短いリリースサイクルを嫌うかもしれません。そして、コーディングは高価で時間のかかる、エラーが発生しやすいものだと聞かされたことがあるでしょう。そのため、構成を介してすべてを行う方が良いでしょう。

要約すると、ロックインは完全に二者択一的なものではなく、様々な種類があることを理解することで、より意識的なアーキテクチャの意思決定が可能になります。このリストは、オープンソースソフトウェアを使用すれば魔法のようにロックインが解消されるという一般的な誤解も解きます。オープンソースはベンダーロックインを軽減できますが、その他のほとんどのロックインの種類は残ります。これはオープンソースが悪いという意味ではありませんが、ロックインに対する魔法の解決策ではありません。

モデルを用いたより良い意思決定

経験豊富なアーキテクトは、より多くのグレーゾーンを見抜くだけでなく、優れた意思決定規律を実践します。これは重要です。なぜなら、私たちは一般的に信じているよりもはるかに悪い意思決定者だからです。もし疑問があれば、カネマンの「ファスト&スロー―あなたの意思決定を支配する2つのシステム」 (Thinking, Fast and Slow) をざっと読むことをお勧めします。

意思決定を改善する最も効果的な方法の1つは、モデルを使用することです。シンプルでさえ、特にシンプルなモデルは、驚くほど意思決定の改善に効果的です。

シンプルだが示唆に富むモデルは、偉大な科学者の特徴ですが、過剰な詳細化と過剰なパラメータ化は、しばしば凡庸さの印です。

-- ジョージ・ボックス

だからこそ、経営コンサルタントに愛されている有名な2×2マトリックスを笑うべきではありません。それは最もシンプルであり、したがって最も効果的なモデルの1つであり、すぐにわかるでしょう。

モデルに関する2つ目の重要な点があります。一般的な信念は、不確実性の中で、ほぼ「場当たり的に対応する」しかないと言っています。結局のところ、すべてが変化しているからです。しかし実際は逆です。多くの相互依存性、高い不確実性、そして小さな確率に対処しなければならない場合、私たちの一般的に悪い意思決定はさらに悪化します。したがって、これはモデルが意思決定に不可欠な構造と規律をもたらすのに最も役立つところです。ロックインをどの程度受け入れるかを決めることは、まさにこのカテゴリに当てはまります。そこで、いくつかのモデルを使用してみましょう。

2x2マトリックスによるロックインの表現

シンプルなモデルは、「ロックイン＝悪い」というスティグマを克服するのに役立ちます。まず、何にもロックインされないことは難しいことを認識する必要があります。したがって、ある程度のロックインは避けられません。第二に、競合製品では提供されていない独自の機能やユーティリティの形で、同等の見返りが得られる場合、ある程度のロックインを喜んで受け入れるかもしれません。

これらの要素を非常にシンプルなモデル、つまり2×2マトリックスで表現してみましょう。

このマトリックスは、以下の軸に沿って選択肢を概説しています。

• 切り替えコスト（別名「ロックイン」）：別のソリューションに移行するのがどのくらい難しいか？
• 独自のユーティリティ：代替案と比較して、ソリューションからどれだけ得られるか？

これで、4つの象限をそれぞれ検討できます。

• **使い捨て:** 独自のユーティリティがなく、簡単に交換できるコンポーネントは、最も心配する必要のないものです。そのままにしておくことも、問題が発生した場合は簡単に交換することもできます。ありふれたものにとっては悪い場所ではありません。たとえば、ほとんどの開発者向けIDE（EMACSはおそらく顕著な例外です！）はこのカテゴリに分類されます。自由に組み合わせたり、あまり執着したりしないでください。写真やその他の個人データのクラウドストレージも、スマートフォンのデバイスをこのボックスに大きく移動させましたが、これについては後で詳しく説明します。
• **受け入れられたロックイン:** 対角線上のコンポーネントは、特定の製品またはベンダーにロックインしますが、その代わりによりユニークな機能やユーティリティを提供します。一般的に、ロックインが少ない方が好ましいですが、このトレードオフは十分に許容できる可能性があります。Google Cloud BigQueryやAWS Bare Metal Instancesなどの製品を使用する場合、ロックインされていることを承知の上で、得られる見返りを基に意識的な決定を下しているでしょう。小規模なアプリケーションの場合、移行の可能性が低く、開発と運用にかかる労力が大幅に削減されるため、ネイティブのAWSサービスを喜んで使用することもあります。
• **注意:** 最も好ましくないボックスは、ロックインするが独自のユーティリティをあまり提供しないボックスです。従来のリレーショナルデータベースがこのボックスに分類される場合があります。独自のデータベースを使用することで収益が本当に増加しますか？そうではありません。しかし、移行には多くの労力がかかるため、移行が必要になる可能性が低いことを確認する必要があります。宇宙空間に打ち上げた組み込みシステムのために特定のハードウェアを選択した場合、それはおそらく問題ありません。移行の可能性は非常に低いです。
• **理想的:** 最も優れたものは、独自のユーティリティを提供する一方で、簡単に切り替えることができるものです。それは目指すべき理想のように聞こえますが、このボックスはやや矛盾していることを認めなければなりません。ソリューションが独自のユーティリティを提供する場合、定義上、競合製品にはそれがなく、移行が難しくなります。S3はこのカテゴリに適した例かもしれません。複数のクラウドベンダーが同じAPIを採用しているため、たとえばGCPへの切り替えは比較的容易です。それでも、各実装には、ローカル性、パフォーマンスなどにいくつかの明確な利点があります。差別化された製品間でこの種の移植性を保護するために、APIを著作権または特許で保護しないことが重要です。

モデルは確かにシンプルですが、ソフトウェア（そしておそらくハードウェア）コンポーネントをこのマトリックスに配置することは、価値のある作業です。それはあなたのエクスポージャーを視覚化するだけでなく、様々な利害関係者にあなたの意思決定を効果的に伝えます。

4つの象限の日常的な例として、あなたは様々な量のロックインとユーティリティを提供する次のアイテムを使用することにしたかもしれません（右上から反時計回り）。

• あなたの愛する**iPhone**は、ベンダーのエコシステムにロックインしますが、独自のユーティリティも提供するため、この**受け入れられたロックイン**は問題ないでしょう。
• あなたの**携帯電話事業者との契約**はあなたを単一のネットワークにロックインしますが、他のネットワークと比べて大きなユーティリティを提供しません。**注意**を払う方が良いでしょう。
• あなたの**携帯電話充電器**は標準のコネクタを使用しています。残念なことに、多くのiPhoneはそうではありませんが、幸いなことにアダプターケーブルを使用することで、このガジェットは依然として**使い捨て**です。
• **メッセージングなどの多くのアプリ**は、友人がいることなど、ユーティリティを提供しますが、電話の連絡先リストを使用するなど、切り替えを容易にするように設計されています。それは**理想的**です。

「独自のユーティリティ」に関する1つの注意点は、すべてのベンダーが何らかの独自の機能を提供することです。それによって差別化を図っているからです。しかし、ここで重要なのは、その機能があなたとあなたの組織にとって具体的な独自の*価値*に変換されるかどうかです。たとえば、一部のクラウドプロバイダーは、驚異的なグローバルネットワークを介して数十億ユーザーのサービスを実行しています。それは印象的で独特ですが、100万人の顧客にサービスを提供することで十分満足しており、単一の国でのビジネスに制限されている可能性のある平均的な企業にとっては、ユーティリティではない可能性が高いです。速度制限の厳しい小さな国でフェラーリを購入する人もまだいますが、どうやらすべての意思決定が完全に合理的ではないようです。しかし、フェラーリはクラウドプラットフォームよりも多くの方法でユーティリティを提供しているかもしれません。

ロックインの実質的なコスト

このシンプルなマトリックスが非常に役立ったため、もう1つ作成しましょう。前のマトリックスは、*切り替えコスト*を単一の要素（または次元）として扱います。優れたアーキテクトは、それが2つの次元で構成されていることを認識しています。

このマトリックスは、切り替えのコストと切り替えを行う可能性（または必要性）を区別しています。可能性が低くコストも低いものはあまり気にしなくてもよいでしょう。一方、切り替えコストが高く、切り替えの可能性が高いものは良くなく、対処する必要があります。対角線では、コストがかかりますが、発生する可能性が低いオプションに賭けています。そこで、変更の範囲を制限したり、保守予算を増やすなどして保険をかける必要があります。リスクを受け入れることもできます。OracleからDB2への移行、またはその逆を本当にどれくらいの頻度で行う必要がありますか？最後に、切り替えは可能性が高いが安価な場合、俊敏性が実現します。変化を受け入れ、実行コストを低く抑えるようにシステムを設計します。奇妙なことに、この象限は、多くの小さな変更がすぐに積み重なるにもかかわらず、左上隅よりも注目されることが少ないです。それは私たちの貧弱な意思決定が機能している証拠です。「もしも」というありそうもないドラマの方が注目を集めます！

ロックインの可能性について議論する場合、切り替えを促す様々なシナリオを考慮する必要があります。ベンダーが倒産したり、価格を上げたり、規模や機能のニーズをサポートできなくなったりする可能性があります。興味深いことに、ロックインを減らすという願望は、交渉ツールとして機能することがあります。ライセンス更新の交渉では、製品から切り替えることが現実的で安価であることをベンダーに示唆することができます。これにより、あなたのBATNA（交渉合意に対する最善の代替案）が低いことを伝えたため、より低い価格で交渉できる可能性があります。これは、実際には使用することを意図していないアーキテクチャオプションです。冷戦における武器の備蓄のような抑止力です。偽装して実際にロックインを減らさないこともできますが、ベンダーがあなたのブラフを呼ぶ場合（たとえば、ウォータークーラーで開発者とチャットする場合など）、優れたポーカープレイヤーである必要があります。

ロックインの軽減：ストライクプライス

最初の段階からもう一度オプションのアナロジーを取り入れると、ロックインを回避することでオプションが得られる場合、切り替えのコストはオプションの権利行使価格になります。それはオプションを実行するために支払う金額です。達成したい切り替えコストが低いほど、オプションの価値が高くなり、したがって価格も高くなります。最小限の切り替えコストで「緑色のボックス」にすべてのシステムを配置することを夢見ていますが、必要な投資が実際には元が取れない場合があります。

たとえば、多くのアーキテクトは、データベースベンダーまたはクラウドプロバイダーにロックインされないことを好みます。しかし、切り替えの可能性は実際どれくらいですか？おそらく5％、またはそれ以下でしょう？半手動の移行で50,000ドル（たとえば）の切り替えコストをゼロ近くに下げるには、どれだけの費用がかかりますか？おそらく、節約できる2,500ドル（50,000ドル×5％）よりもはるかに多くの費用がかかります。したがって、切り替えコストの最小化は唯一の目標ではなく、簡単に過剰投資につながる可能性があります。それは過剰保険をかけることと同じです。控除額をゼロにするために莫大な保険料を支払うと安心できますが、それは多くの場合、最も経済的ではなく、したがって合理的でない選択です。

最終的なモデル（今回は行列ではありません）は、スイッチのコスト削減にどれくらい投資すべきかを判断するのに役立ちます。次の図は、あなたが負う可能性のある責任を示しています。これは、スイッチングコストとそれが発生する可能性の積を、必要な upfront investment （青線）で割ったものです。

オプションに投資することで、スイッチの可能性を減らすか、実行コストを減らすかのいずれかで、確実に責任を軽減できます。たとえば、Hibernateのようなオブジェクトリレーショナルマッピング（ORM）フレームワークを使用することは、データベースベンダーロックインを軽減できる小さな投資です。各データベースベンダーのネイティブストアドプロシージャ構文に変換されるメタ言語を作成することもできます。これにより、依存することなくデータベースのパフォーマンスを最大限に活用できますが、比較的起こりにくいシナリオに対して、多大な upfront effort が必要になります。

したがって、興味深い関数は赤線、つまり upfront investment に潜在的な責任を加えたものです。それがあなたの総コストであり、最小化するべきものです。ほとんどの場合、upfront investment が増えるにつれて、最適な範囲に近づきます。ロックイン軽減への追加投資は、実際には総コストの上昇につながります。理由は簡単です。特に可能性の低いスイッチの場合、投資収益率は減少します。アーキテクチャを非常に柔軟にすると、過剰投資のゾーンに閉じ込められる可能性があります。Yagni（You Ain't Gonna Need It）の人々はスペクトルの反対側を目指しているかもしれません。よくあることですが、コツはちょうど良いバランスを見つけることです。

ロックイン回避の総コスト

ロックインされた状態のコストと潜在的なペイオフをかなり把握したので、ロックインを回避する総コストを詳しく見ていく必要があります。以前のモデルでは、ロックインの回避は単純なコストであると仮定していました。しかし実際には、このコストはいくつかの構成要素に分解できます。

• 労力：これは、人時単位で行われる追加作業です。クラウドプロバイダーのロックインを軽減するために、Kubernetesの上でコンテナにデプロイすることを選択した場合、この項目には、新しいツールの学習、Dockerファイルの作成、Kubernetesの設定などの労力が含まれます。
• 費用：これは、製品ライセンス、外部プロバイダーの雇用、KubeConへの参加など、追加の現金支出です。
• 未利用：この間接コストは、ロックインを回避すると、多くの場合、ベンダー固有の機能を使用できなくなるために発生します。その結果、使用するソフトウェアから得られるユーティリティが減少します。これは、欠けている機能を構築するためにより多くの労力が必要になることを意味したり、製品の弱点を引き起こしたりする可能性があります。
• 複雑さ：複雑さは方程式の中心的な要素であり、あまりにも頻繁に無視されています。ロックインを軽減するための多くの取り組みは、追加の抽象化レイヤー（JDBC、コンテナ、共通API）を導入します。すべて有用なツールですが、そのようなレイヤーは別の可動部分を付け加え、システム全体の複雑さを増大させます。これは、新しいチームメンバーの学習努力とシステムエラーの可能性を高めます。
• 新たなロックイン：あるロックインを回避することは、別のロックインを犠牲にすることがよくあります。たとえば、AWS CloudFormationを回避して、複数のクラウドプロバイダーをサポートするHashiCorpのTerraformまたはPulumiを使用することを選択する場合があります。ただし、これで追加のベンダーからの別の製品にロックインされ、それがあなたにとって問題ないかどうかを検討する必要があります。

ロックイン回避のコストを計算する際には、アーキテクトは盲点を避けるためにこのリストを簡単に確認する必要があります。また、ロックイン回避の試みは、リーキーな抽象化と非常に似ており、リーキーである可能性があることに注意してください。たとえば、Terraformは優れたツールですが、そのスクリプトは多くのベンダー固有の構成を使用しています。そのため、実装の詳細が「リーク」し、あるクラウドから別のクラウドへのスイッチングコストが明らかにゼロにならないようにします。

まとめ

多くの理論を踏まえた上で、いくつかの具体的な例を見てみましょう。

思考の速度でのアーキテクチャ

ロックインについて非常に多くの時間を費やすことができるように思えるかもしれません。一部の人は、私たちのやり方を「学問的」だと片付けることさえあります。私は繰り返し、それが悪いことだと考えることができず、なぜなら私たちの大部分がそこで教育を受けたからです。それでも、古くからの白黒のアーキテクチャ手法の方がシンプルで、おそらく効率的ではないでしょうか？

実際、思考は非常に速く起こります。この記事で示されているすべてのモデルを実行するのにほんの数分しかかからず、十分に文書化された意思決定が得られます。紙切れやホワイトボード以外の特別なツールは必要ありません。高速なアーキテクチャ思考の重要な要素は、単に集中する能力です。

数週間前にスケジュールされ、通常は十分な情報に基づいた決定を下すための実際の専門知識を持っていない人が出席しない、長時間の運営委員会の会議のために、精巧なスライドデッキを準備する労力と比較してください。

エレベーターアーキテクトは、会議を待つよりも考える時間を費やしたいと考えています。