アーキテクチャの強固な力と弱い力
優れた技術設計上の意思決定は、コンテキストに大きく依存します。共通の目標に向かって定期的に協力するチームは、定期的にコミュニケーションを取り、変更を迅速に交渉することができます。これらのチームは強固な力の整合性を示し、その強固な力を利用した技術と設計上の意思決定を行うことができます。より大規模な組織でズームアウトするにつれて、独立して働き、協調が少ないチームや部門間には、ますます弱い力が存在します。これらの強固な力と弱い力の違いを認識することで、より良い意思決定を行い、各レベルに適切なガイダンスを提供し、より多くの権限を持つチームを迅速に動かすことができます。
2021年11月10日
Evanは経験豊富なアーキテクト兼テクノロジーリーダーであり、組織がテクノロジーの提供と維持をより成功させるための取り組みを行っています。彼は、大規模な組織におけるコミュニケーションと意思決定の経路を横断し、人々が複雑さを管理するのを支援することに時間を費やしています。
以前はThoughtworksのテクニカルディレクターを務めていたEvanは、現在、オーストラリアに拠点を置くビジネス管理プラットフォームMYOBのアーキテクチャ責任者を務めています。
テクノロジーガバナンスと「優れたアーキテクチャ」とは、多くの場合、「ワンサイズフィッツオール」のアプローチで考えられています。多くの組織は、すべてのレベルで同じ厳格なガバナンスを適用しようとしており、テクノロジーの選択肢を制限し、チームの権限を弱めています。一方、すべてのレベルでチームに完全な自律性を認めている組織もあり、チームは一切の制約なしに独自の選択を行うことになります。どちらのアプローチも理想的ではありません。
具体的な例として、統合アーキテクトが長年、アーキテクチャのすべてのレベルで「真の」統合アプローチを目指していることを見てきました。彼らは「ベストプラクティス」を挙げて、すべてのレベルでのシステム間の相互作用について、非常に緩やかな結合、下位互換性のあるインターフェース、慎重なカプセル化を義務付けています。この普遍的なアプローチは多くの場合、不必要な複雑さと遅延を生み出していますが、より迅速に進み、これらの要件を容易にすることが許されるのはどこでしょうか？
MYOBのチーム
MYOBでは、現代的なデジタル製品組織の確立された原則に従ってチームを編成しています。チームは当社の製品機能とビジネス機能に合わせられ、ソフトウェアとインフラストラクチャの計画、デリバリー、保守、サポートのあらゆる側面を担当しています。
チームは、関連する機能をまとめたドメインにグループ化され、ドメインレベルで機能するリーダーシップと支援の役割がいくつかあります。ドメインはさらに、垂直領域と呼ばれるはるかに大きな組織単位にグループ化されています。垂直領域は、顧客基盤の主要なセグメントを表しています。
もちろん、それ以外にも、組織全体が効果的にデリバリーするための足場を提供する支援機能と内部プラットフォームがあります。しかし、この簡略化されたモデルは、テクノロジーガバナンスについて推論するのに役立ちます。
この記事では、この構造がどのようにテクノロジーの選択と設計上の意思決定に影響を与えるか、スコープ（または「影響範囲」）に応じて適切なアプローチが異なる可能性があることを説明したいと思います。私が好む概念モデルは、組織の異なる部分間の引力の力です。
ドメイン内 = 強固な力
ドメイン内には複数のチームがあり、それぞれがドメイン内のいくつかの機能と基盤となるシステムを担当しています。場合によっては、各チームが明確に境界が定められたシステムの管理者であるため、これは完全に整合しています。実際には、多くの場合、レガシーの理由から、一部のシステムの管理がチーム間で共有されるため、これは不完全です。ドメイン内のチームには、非常に強力な整合力が働きます。
ドメイン構造は、機能がまとまったシステムをまとめることを目的としています。それらは密接に関連しており、同じ概念を扱っており、共通のドメイン専門知識に依存しており、顧客のニーズを満たすために同時に変更されることがよくあります。
単一チームのメンバーは通常、同じシステム全体で作業しているため、作業方法、標準、テクノロジーの選択、設計の方向性について、非常に明確で整合性のある方法が必要です。これは最も強力な整合力です。
同じドメイン内のチーム間では、整合力は依然として非常に強力です。知識の共有は容易かつ流動的です。例えばスキーマに関するシステム間の交渉は比較的容易です。ドメイン内のシステムを横断する機能を提供する必要がある場合、多くの場合、同じ人が各統合ポイントの「両側」を実装します。
つまり、ドメイン内のシステム間の「プライベート」な相互作用（API呼び出し、イベント、データファイル）は、結合がより緊密であっても、深刻なコストを伴うことはありません。結合をある程度緊密にすることで、バージョン管理や下位互換性への取り組み、共有依存関係の回避にかかる労力を削減できます。ドメインレベルでのシステム間の結合は、常にあらゆる犠牲を払って克服しなければならない悪の化身ではありません。実際、この範囲での結合は役立つ場合があります。
垂直領域内 = 弱まった力
中間段階には、複数のドメインを持つ垂直構造があります。あるドメインの人々と別のドメインの人々との間の社会的距離は広がっています。これにより、交渉と整合性の達成はより困難で遅くなり、必然的にテクノロジーの選択とアプローチに影響を与えます。
組織全体 = 弱い力
組織全体にズームアウトすると、垂直領域間の整合力は非常に弱くなります。ほとんどの場合、各垂直領域の作業の優先順位付けが意図的に独立しているため、状況全体にわたって変更を原子的に行うことは非常に困難です。このレベルでの作業の調整は必然的にはるかに遅く、制限されます。そのため、設計上の意思決定とアプローチはそれに応じて調整する必要があります。
このモデルをどのように適用するか？
スコープに応じて異なる可能性のあるテクノロジーの意思決定の領域をいくつか調べることで、このモデルをより具体的にしましょう。以下のリストは網羅的なものではなく、考慮すべき興味深い例をいくつか示したものです。
テクノロジーの選択
ドメイン（強固な力）
単一のドメイン内では、合意されたテクノロジーの選択肢は少数のセットである必要があります。
これは、必要な各クラスのテクノロジーに対して、多くの場合、Default Trial Retireに従います。
テクノロジーリーダーシップによる非公式なガバナンスは通常非常に効果的です。
垂直領域（弱まった力）
垂直領域レベルでは、複数のドメインの異なるニーズに対応するために、合意されたテクノロジーの選択肢がわずかに多くなります。
垂直領域は、人々を優先度の高い作業により近づけることができるため、テクノロジーの整合性を保つことが重要です。
ソリューションオプションと提案をより正式に共有することで、選択肢の効果的な整合性が維持されます。
組織全体（弱い力）
テクノロジーの選択肢を整合させ、管理するための最も弱い力は、組織全体レベルにあります。
MYOBのテクノロジーレーダーは、優先されるテクノロジーに関して方向性を設定します。
ソリューションオプションと提案は、対話を促し、整合性を向上させます。
共有コードとインフラストラクチャ
ドメイン（強固な力）
単一のドメイン内、3～5チームにわたっていても、高い帯域幅の通信と、権限のあるリーダーシップまでの短い距離が必要です。
つまり、共有コードまたはインフラストラクチャに変更を加える必要がある場合、迅速に情報提供を行い、変更の準備をすることができます。
共有コードとインフラストラクチャによって導入される結合の影響は少なく、多くの場合、メリットがコストを上回ります。
垂直領域（弱まった力）
コード、アーティファクト、インフラストラクチャの共有は、垂直領域レベルで管理できることがよくありますが、導入されるドラッグは注意深く監視する必要があります。
組織全体（弱い力）
組織全体レベルでの共有コードは、非常に安定していて、非常に役立つものに限られています。これらのものは、ほとんどが配布およびバージョン管理が可能で、慎重に変更できるライブラリに限られています。
共有インフラストラクチャも同様です。組織全体レベルでは、共有インフラストラクチャは非常に高い価値を持つ必要があり、適切にカプセル化されている必要があります（「サービスとして」、セルフサービス）。単一チームのニーズに対応するためにコアな変更が必要になることはめったにありません。
コード貢献モデル
ドメイン（強固な力）
プラクティスとテクノロジーに関して高い整合性を持つ単一のドメイン内では、チームがチームの境界を越えてコードに貢献することは非常に妥当な場合があります。これは、ドメイン全体に及ぶ一種のコレクティブコード所有権に拡張されます。
各システムの管理は、依然として明確に理解する必要があります。通常、1つのチーム内に保持するのが最適です。
垂直領域（弱まった力）
垂直領域内では、コードの貢献がシステム間で行われることは一般的です（例：ソース管理でのプルリクエスト）。必要な遅延とやり直しは少量です。
組織全体（弱い力）
組織全体レベルでは、垂直領域を横断する貢献を効果的に管理することは、多くの場合非常に困難であり（場合によっては有害です）。
これは、システムが複雑な性質のものであり、正確性、パフォーマンス、プライバシー、コンプライアンスの点で非常に重要または機密性の高い場合に特に当てはまります。
まったく新しいシステム機能を確立する場合、ペアプログラミングで共同作業を行うことで、垂直領域を横断してうまく機能することがあります。ただし、機能が確立され、他の垂直領域からの変更の需要が増加すると、それらのシステムを拡張および構成できるようにするための投資が必要です。これらの変更は、多くの場合、アーキテクチャ上の性質のものであり、「コア」と複雑なサブシステムを分離し、モジュール性を導入して、拡張の管理を容易にします。
統合パターン
ドメイン（強固な力）
単一ドメイン内で所有されているシステムは、密接に連携して変更するのが比較的容易です。例えば、インターフェースの後方互換性を維持するための労力が（多少）軽減されます。
データベースレベルの統合など、「禁止されている」アプローチでさえ、単一ドメイン内のシステムへの影響は少なくなります。故意にそのようなシステムを構築すべきではありませんが、存在する場合、影響を単一ドメイン内に限定できます。
垂直領域（弱まった力）
垂直方向の複数のドメインにまたがる調整が必要な変更はまれですが、絶対に必要な場合は管理できます。APIコントラクトの拡張・縮小変更は、影響が垂直方向内に限定されている場合に非常に効果的です。
組織全体（弱い力）
MYOB全体に公開されるAPIとインターフェース（イベントなど）については、公開スキーマ、バージョン管理、後方互換性、コントラクト、廃止戦略に最大限の注意を払う必要があります。
密結合統合（ETL、データベース統合など）の影響は非常に大きく、絶対に避けるべきです。
結論
規模の大きな組織では、毎日数十もの技術的な意思決定が行われます。長年にわたり、私たちは、すべての意思決定を厳しく中央管理することなく、チームが業務に沿った意思決定を行うことを可能にし、支援することに努めてきました。「整合性のある自律性」の達成は容易ではなく、絶え間ないバランス調整が必要です。シンプルなモデルは、チームが状況に応じた適切な意思決定を行うのに役立ちます。この記事では、MYOBにおいて、どのようにテクノロジーガバナンスアプローチを組織構造とダイナミクスに整合させてきたかを説明しています。組織内のこれらの整合力の影響を認識することで、何が容易で何が困難かを理解し、その結果としてより良い技術選択を行うことができます。
謝辞
この記事は、MYOB内部のブログ投稿として始まりました。これは素晴らしい議論を促し、アイデアを洗練するのに役立ちました。MYOBの同僚であるHeaton Cai氏と、ThoughtworkersのRebecca Parsons氏、Birgitta Böckeler氏、Mark Taylor氏、Peter Gillard-Moss氏に、ドラフトに対する洞察力のあるフィードバックを感謝します。
大幅な改訂
2021年11月10日:公開