統合は、大半のエンタープライズITランドスケープにおいて、いつのまにか最大のコストとなっていますが、明細項目として姿を現すことはほとんどありません。それはプロジェクトの遅延の中に、あらゆるリリースを取り巻く慎重さの中に、そして変更が影響を及ぼすシステムをそれぞれ所有する三つのチーム間で変更を調整するために必要な会議の中に隠れています。あるプラットフォームが扱いにくいと言われるとき、それはたいてい、コードが悪いという意味ではありません。システムが絡み合っているという意味です。一つの部分について考えるには他のいくつもの部分についても考えなければならず、一つの部分を出荷しようとすれば残り全体を動かさなければならないのです。

このことが十数年前よりも今こそ重要である理由は、統合の対象範囲が何倍にも膨れ上がったからです。単一の業務能力が、中核となる記録システム、複数のサービスとしてのソフトウェアアプリケーション、データプラットフォーム、モバイルチャネル、そして独自のインターフェースで接続された一つ以上の外部パートナーにまたがることもあります。顧客は変更を四半期単位ではなく数週間単位で期待します。規制はデータフローが追跡可能かつ監査可能であることを要求します。その一方で、基盤となるシステムは、組織が所有しておらず変更もできないものが増えており、これによって適応の負担がすべて統合レイヤーへと移されるのです。

その結果、統合の品質が今やデリバリー速度の上限を決めるようになりました。境界が明確で契約が明示的な組織は、チャネルを追加したりベンダーを置き換えたりすることを、限定的で十分に理解された作業として行えます。それらを持たない組織は、そうした要求のたびに何が壊れるか誰にも予測できないため、すべてを調査プロジェクトとして扱うことになります。この違いは、才能や予算の問題ではありません。ITランドスケープが変化するように設計されていたかどうかの問題であり、その設計はほぼ完全に、システム同士をどのように対話させるかの中に宿っています。

このテーマが緊急性を増したもう一つの理由があります。より多くの能力が購入したソフトウェアや外部サービスから組み立てられるようになるにつれ、組織自身が書くコードは縮小し、物事をつなぐコードは増大します。エンジニアリングの重心は、単一のアプリケーション内部で機能を構築することから、多数のアプリケーションにまたがって振る舞いを組み立てることへと移りました。この変化は、統合を設計された資産として扱うチームには報い、各プロジェクトの最後に後付けで取り付ける付け足しとして扱うチームには罰を与えます。良好に老いていくITランドスケープとは、締め切りに追われて一つずつ接続が堆積するに任せるのではなく、誰かが接続の形を意図的に所有していたものなのです。

耐久性のある統合の第一原理は、契約が接続よりも重要だということです。接続とは、二つのシステムがデータを交換する仕組みのことです。契約とは、そのデータが何を意味するのか、どのような形を取るのか、どのような保証が成り立つのか、そして各当事者が相手について何を前提としてよいのかについての合意です。接続に注力するチームは、テストされた当日には動くものを作ります。契約に注力するチームは、両者が進化しても動き続けるものを作ります。契約は安定した表面であり、その背後で各当事者は自由に変化できるからです。

良い契約は明示的で狭いものです。それが運ぶデータを規定し、提供側がたまたま内部でどのように保存しているかといった付随的なことは規定しません。インターフェースと実装のこの区別こそがすべての要です。消費側が、貧弱に設計されたインターフェースから漏れ出た内部の詳細に依存し始めると、誰も合意しておらず誰も追跡していない結合が形成されます。提供側はもはや自由にリファクタリングできなくなります。内部の変更が今や消費側を密かに壊すからです。良く設計されたアプリケーションプログラミングインターフェースは、まさにこれを防ぐために存在します。意図的で最小限の表面を公開し、それ以外のすべてをその背後に隠すのです。

契約は構造だけでなく意味論も担います。二つのシステムがstatusというフィールドについて合意していても、その値が何を意味するのか、あるいはいつ設定されるのかについて食い違えば、依然として互換性がありません。したがって、真剣な契約設計は、意味、バージョン管理、エラー時の振る舞い、そして配信と順序に関する保証を対象とします。それは互換性を第一級の関心事として扱います。変更は後方互換性があるか、その場合には既存の消費側は影響を受けません。あるいは後方互換性がなく、その場合にはバージョン管理戦略と移行経路が必要となります。その区別を可視化し、密かに破ることを拒むことが、統合の実践が持ちうる最も価値ある習慣です。本稿の他のすべては、ある意味で、契約を誠実に保つための技法なのです。

最も古い統合スタイルはポイントツーポイントです。システムAが何かを必要とするとき、システムBを直接呼び出します。数個のシステムであれば、これはまったく妥当です。問題は、可能な接続の数がシステムの数よりもはるかに速く増加すること、そして各直接リンクが二つのコンポーネントを時間と知識の面で縛り付けることです。AはBがどこにあるかを知っていなければならず、Bが利用可能なときに利用可能でなければならず、Bが遅い、あるいは不在である場合に対処しなければなりません。それを成長するランドスケープ全体に掛け合わせると、おなじみのスパゲッティにたどり着きます。特注リンクの密なメッシュであり、そこに触れるすべての糸をたどることなしには誰もシステムを変更できないのです。

過去十年で成熟した対応策は、通信をハードに配線するのではなく仲介すること、そしてますますそれをイベント駆動にすることです。AがBを直接命令する代わりに、Aは事実、つまり注文がなされた、支払いが完了した、住所が変更された、といったことを公開し、それを気にかけるあらゆるシステムがその事実を購読します。公開側は、誰がそのイベントを消費するかを知りませんし、気にもしません。消費側は、生産側に触れることなく追加したり削除したりできます。この逆転こそが疎結合の本質です。システムはもはや互いに依存せず、両者の間を行き交うイベントについての共有された明示的な契約に依存するのです。

メッセージベースおよびイベント駆動の統合は、システムを時間の面でも疎結合にします。耐久性のあるブローカーに置かれたメッセージは、消費側の準備ができたときに配信されます。つまり、遅い、あるいは一時的に利用できない下流のシステムが、もはや上流のシステムを止めることはありません。この非同期性は単なる性能上の小手先ではありません。それは障害モデルを変えます。バックプレッシャー、リトライ、バッファリングが、連鎖的な障害に取って代わるのです。ストリーミングプラットフォームやマネージドメッセージングサービスの台頭に見られる業界全体の潮流は、まさにこの、同期的なリクエスト連鎖から、システムが観測し反応するイベントのフローへの移行です。これは普遍的に適切なわけではなく、呼び出し側が本当に即座の回答を必要とする場合には同期呼び出しが依然として正しい選択です。しかし、多数のシステムを統合する際の既定の姿勢としては、直接配線よりもはるかに回復力があることが実証されています。

疎結合はしばしば目標として引き合いに出されますが、実行に移せるほどの精度で定義されることはほとんどありません。実際には、それにはいくつかの明確な次元があり、良いアーキテクチャはそのそれぞれに注意を払います。場所の結合があります。あるシステムは別のシステムがどこにあるかを知る必要があるのか、それとも移動可能な論理的な宛先を指定するのか。時間の結合があります。両システムが同時に利用可能でなければならないのか、それとも独立して進めるのか。フォーマットの結合があります。両者は共有された表現に縛られているのか、それとも仲介レイヤーが両者の間を翻訳するのか。そして知識の結合があります。一つのシステムが別のシステムと連携するために、その内部についてどれだけ理解する必要があるのか。あらゆる統合上の決定がこれらのいずれかを締め付けたり緩めたりします。目指すべきは、要件が許す限りそれぞれを緩く保つことです。

いくつかの設計原則が直接的に導かれます。直接接続するのではなく仲介すること。そうすれば、ブローカー、ゲートウェイ、あるいは統合レイヤーがシステム間の差異を吸収し、各システムに対話すべき単一の安定したものを与えます。境界を明示的に所有すること。外部のモデルを自分自身の語彙へと翻訳する腐敗防止レイヤーは、パートナーやベンダーの設計が自分の設計に染み込んで支配することを防ぎます。インターフェースを小さく保つこと。公開するあらゆるフィールドは、守らなければならない約束だからです。通信を冪等かつリトライに寛容にすること。あらゆる分散システムでは、メッセージが時折二度到着したり順序が入れ替わったりするからであり、完全な配信を前提とした設計は、負荷の下でデータを破損させる設計だからです。命令ではなく事実を動かすことを選ぶこと。そうすればシステムは何が起きたかを告知し、他のシステムに何をすべきかを決めさせます。境界を越えて手を伸ばし、自分のものではない作業を統制しようとするのではなく。

これらすべての根底には、単一の試金石があります。各コンポーネントは、それ単独で変更し、デプロイし、考えることができるか。答えがイエスであれば、ITランドスケープは一片ずつ進化でき、それが大規模システムが変化する唯一の持続可能な方法です。答えがノーであれば、あなたが持っているのはアーキテクチャというよりも、複数のシステムに見えるだけの単一の分散プログラムであり、それが含意するすべての脆さを持ち、独立性は一つも持ちません。疎結合を目指した設計とは、ITランドスケープが成長するにつれてその答えをイエスに保ち続ける、意図的で継続的な作業なのです。

統合の失敗は組織間で驚くほど一貫しており、これは心強いことです。なぜなら、それは予見できることを意味するからです。名前を付けられるほど頻繁に繰り返されるものがいくつかあります。

分散モノリス。システムは別個のデプロイ可能なサービスに分割されているものの、共有データベース、同期呼び出しの連鎖、あるいは漏れ出た内部モデルを通じて非常に密に結合しているため、それらは一緒にリリースされ、一緒に故障しなければなりません。これは両者の最悪を合わせたものです。多数のシステムの運用上の複雑さと、一つのシステムの硬直性です。それはほとんど常に、所有権と変更の真の境界に沿ってではなく、技術的な線に沿って分割することから生じます。

共有データベース。二つのシステムが同じテーブルを読み書きすることで統合します。それは効率的に感じられ、そして変更にとっては壊滅的です。データベーススキーマが、誰も設計せず誰もが依存する暗黙の契約となるからです。どちらのシステムも、他方を危険にさらすことなくストレージを進化させることができず、その結合は破綻するまで目に見えません。

密かな破壊的変更。提供側がバージョン管理なしにフィールド、意味、あるいはエラー時の振る舞いを変更し、消費側が原因から遠く離れたところで表面化する形で故障します。これは契約違反であり、互換性が善意の問題ではなく明示的で強制された規律でなければならない理由です。

おしゃべりで脆い同期連鎖。単一のユーザー操作が、多数のシステムにまたがるブロッキング呼び出しの長い連続を引き起こします。エンドツーエンドの信頼性はすべてのリンクの積であるため、連鎖全体はそのどの部分よりも信頼性が低くなり、一つの遅いコンポーネントが上流のすべてを止めてしまいます。

住まいのない統合ロジック。変換やルーティングのルールが、どのチームも所有せず、どのテストもカバーしないスクリプト、ストアドプロシージャ、スケジュールジョブの中に蓄積します。ITランドスケープは依然として動きますが、誰もそれを理解しておらず、あらゆる変更が考古学の営みとなります。

失われたメッセージ。あるシステムが、配信が失敗したときに何が起こるかを顧みることなく公開または消費します。リトライもなく、デッドレターの経路もなく、冪等性もなく、再生する手段もありません。通常の負荷の下では欠点がないように見えます。ストレスや部分的な障害の下では、密かにデータを落としたり二重処理したりし、その損害は数週間後に、帳尻の合わない照合の中で発見されます。これは統合への信頼を最も頻繁に蝕む失敗モードです。その症状が静かで、原因が、いかなる分散システムも守れない完全な配信という前提の中に埋もれているからです。これらすべてに共通する筋は同じです。誰も明示しなかった結合または前提が作られ、したがって誰も管理していない、ということです。それらに名前を付けることが、それらを設計で排除する第一歩であり、成熟した実践は、出荷される前にまさにこのリストと照らし合わせてあらゆる新しい統合をレビューします。

Nashuaは統合を、まず第一にアーキテクチャの規律として、そして第二に技術の選択として扱います。取り組みは、既存のランドスケープを読み取れるようにすることから始まります。システム、それらの間のフロー、そして何よりも、共有データベースや放置されたジョブに潜む文書化されていないものを含む結合をマッピングします。この地図こそが本当のリスクの在り処であり、それを表面化させることで、会話がツールの一覧から、境界についての意図的な決定の集合へと変わります。境界が明確になって初めて、API、イベントストリーム、メッセージキューといった仕組みの問いが答えられるようになります。正しい仕組みは、緩めようとしている結合に完全に依存するからです。

そこからの作業は、上で述べた原則に従います。契約は明示的に設計され、意図的にバージョン管理されます。それにより、提供側は消費側を壊すことなく進化でき、両者は何に依存してよいかを正確に知ることができます。システムが互いに命令するのではなく変化に反応する必要がある場合、Nashuaは統合レイヤーを通じて仲介されるイベント駆動およびメッセージベースのパターンを好み、ポイントツーポイントのリンクを、各システムが一度対話するバックボーンで置き換えます。即座の回答が本当に必要な場合には、明確なタイムアウト、リトライ、障害時の振る舞いを備えた良く設計された同期インターフェースが使われます。全体を通じての目標は、安全に変更できるソフトウェアです。すなわち、独立してリリースし、置き換え、考えることができるコンポーネントであり、望みによってではなく契約と腐敗防止レイヤーによって互いから保護されているものです。

デリバリーの実践がアーキテクチャを補強します。契約テストがインターフェースの両側を誠実に保ち、破壊的変更が本番に到達する前に捕捉します。これによって互換性は、規律の問題から、パイプラインが自動的に強制するものへと変わります。自動化されたビルドとリリースのパイプラインは、デプロイを小さく、頻繁で、可逆的なものにします。これは、境界が一つのコンポーネントを一度にデプロイできるほど十分に清潔である場合にのみ可能です。可観測性はフローに組み込まれ、イベントとメッセージにまたがる相関を伴うため、問題は事後に症状から推測されるのではなく、その源までたどることができます。統合ロジックには住まいが与えられます。放置されたジョブの散在ではなく、所有され、テストされ、バージョン管理された場所であり、それによってITランドスケープは、それを引き継ぐ人々にとって読み取れるものであり続けます。

同じくらい重要なのは、Nashuaがしないと決めていることです。単純な呼び出しの方が明快な場面でイベントストリームに手を伸ばすことはなく、別々である理由のないシステムをサービスに分割することもなく、緩めるに値する結合を持たない問題にブローカーを追加することもありません。先に述べた失敗モードは、怠慢についてであると同時に過剰についてでもあり、抑制は技芸の一部です。これらのいずれも風変わりなものではなく、それこそが要点です。耐久性のある統合は、小さな原則の集合を一貫して適用し、それぞれがいつ当てはまるかを知ることから生まれます。そしてNashuaの貢献は、その一貫性と、ランドスケープがどこで破綻するかを見てきた経験をもたらすことにあります。それによって、構築されるものは、出荷される当日に単に動くようにされたものではなく、変化するように設計されたものになるのです。

Nashuaがもたらす違いは、単一の技術ではなく、変更可能性を最優先の要件として扱い、デリバリーの重圧の下でもそれを堅持する考え方です。多くのサプライヤーは、デモンストレーションで動く接続を構築できます。三年後、三十の統合を経て、当初のチームが去り、業務が誰も予期しなかったものを求めてきたときにも、依然として容易に変更できるITランドスケープを設計できるのは、はるかに少数です。その長い時間軸こそ、契約、疎結合、仲介された通信という規律がその真価を発揮するところであり、いかなる特定の製品よりも、深く辛抱強いエンジニアリングの経験が価値を持つところなのです。

そして、作業が何を前提としてよいかを変える実践上の帰結もあります。取り組みが、まだ存在しない能力を必要とする場合、調達サイクルやベンダーのロードマップを待つ必要はありません。enterprise platformは、エージェンティック・エンジニアリングを通じて、ほとんどあらゆる機能を迅速に取り込めるように作られています。必要なものは平易な言葉で記述され、素早く生成されますが、常に確固たるアーキテクチャ原則の範囲内で、厳格な品質保証の下で行われるため、速度が一貫性、セキュリティ、あるいは制御を犠牲にすることは決してありません。その効果は、単に便利であるにとどまらず、戦略的です。それは内製か購入かの境界線を動かし、選択肢を安価に保ち、戦略が棚にたまたまあったものに屈するのではなく、アーキテクチャが戦略に従うことを可能にします。

それらを結びつけるのは判断力です。呼び出しよりもイベントの方が適する場面を知り、境界を腐敗防止レイヤーで守るべき場面を知り、破壊的変更が移行に値する場面とそうでない場面を知り、バージョン管理戦略に投資すべき場面と、より単純な経路が十分に誠実である場面を知ることです。これらの決定は棚から買うことができず、そして積み重なります。単一の健全な選択はほとんど目に見えません。ITランドスケープの生涯にわたって一貫してなされた千の選択は、リリースのたびに脆くなっていくシステムと、しなやかであり続けるシステムとの違いなのです。良く、一貫してなされれば、それらは新しいチャネル、パートナー、規制を、危機としてではなく通常の作業として吸収するITランドスケープをもたらします。それがNashuaの目指す成果です。単に機能する統合ではなく、業務が必要とする限りにわたって安全に変更できるシステムであり、それこそが結局のところ、統合の唯一意味を持つ尺度なのです。