前置き
まずは、前提として以下のエンタープライズアーキテクチャモデルを見てください。
もうここでは、
ビジネスアーキテクチャを起点として、下位のアプリケーションアーキテクチャ
やらインフラ基盤を規定するテクノロジーアーキテクチャが定義される。
さらに、
上位のアーキテクチャは、下位の制約の影響を受ける
というのは、常識として、もう深ぼりません。
逆コンウェイの法則：TAがアーキテクチャを規定する
IaCの導入によって、本来は下位レイヤーであるはずのインフラストラクチャの構造が、上位レイヤーであるアプリケーションやビジネスアーキテクチャに制約を課すという現象が明確に可視化されるようになりました。
実はこれは「逆コンウェイの法則」の一種と捉えることができます。
1. メカニズム：インフラの密結合が組織の俊敏性を奪う
このようなシナリオは、多くの企業で実際に起こっています。
技術的な問題（インフラ層）
プロダクトチームAとBのインフラコードが、単一の巨大なTerraform Stateで管理されている。
チームAのネットワーク設定とチームBのデータベース設定が暗黙的に依存しており、簡単には分離できない状態。
結果として、インフラ基盤は物理的に共有せざるを得ない。
波及効果（アプリケーション層）
インフラ部分で密結合状態であることで、チームAがインフラに変更を加えたい場合、terraform applyを実行するとState全体がロックされ、チームBの作業がブロックされる。
このデプロイメントの密結合により、チームAとBは独立したリリースサイクルを組むことができません。
結果、本来は疎結合であるべきサービスAとBが、リリーススケジュールにおいて密結合になってしまいます。
これが疎結合になったと思った、マイクロサービスが単独でデプロイできない状態です。
最終的な影響（ビジネスアーキテクチャ層）
サービスA（例: 新規顧客獲得機能）の市場投入が、全く無関係なサービスB（例: 既存顧客のサポート機能）の改修が終わるまで待たなければならなくなる。
これにより、ビジネスの俊敏性（Time to Market）が著しく低下し、競合他社に対する競争力を失う。
本来は独立して評価されるべきチームAとBの業績評価（KPI）も、互いに足を引っ張り合うため正しく行えなくなる。
2. 戦略的意味合い：EAにおけるIaCの位置づけ
この考察が示すのは、現代のエンタープライズアーキテクチャにおいて、
インフラアーキテクチャはもはやアプリケーションやビジネスの要求に従属するだけの下位レイヤーではない
ということです。
IaCによって定義されたインフラの構造（特にその分割・結合の状態）は、組織のコミュニケーションパス、開発速度、ひいてはビジネス戦略そのものを左右する 「基盤的な制約」 となり得ます。
したがって、エンタープライズアーキテクトは、ビジネス戦略からトップダウンでアーキテクチャを考えるだけでなく、IaCの現状というボトムアップの現実を直視し、
「インフラの分割戦略が、我々のビジネスの成長を妨げていないか？」
と常に自問する必要があります。