エンタープライズITの歴史の大半において、統合は時折発生する出来事でした。システムは大規模で、長命で、数が少なかったのです。二つのシステムを接続することは、始まりと終わりのあるプロジェクトであり、組織の境界はおおむねそのシステム群の境界でもありました。そうした世界はもう存在しません。今日の平均的な大企業は、数百のアプリケーションを運用しており、その大半はサービスとして提供され、IT部門ではなくベンダーが所有しています。新たな能力は構築ではなくサブスクリプションによって到来し、それぞれのサブスクリプションは周囲のあらゆるものとデータを交換することを前提としています。

これはアーキテクチャの重心を変えます。能力が自社で構築されていた時代には、難しい判断は何を構築するかについてのものでした。能力が購入される時代には、難しい判断は購入したものがどのように接続され、互いについてどれだけ知っているかについてのものになります。ベスト・オブ・ブリード、MACH、あるいは単に実務的な調達として表現されるかを問わず、コンポーザブルな戦略は、各部分を結びつける統合の質に依存します。組織は優れたアプリケーション群を組み立てることはできても、注文、顧客、在庫が各境界で微妙に異なる意味を持てば、依然として一貫性を欠いた体験を提供してしまうのです。

これが今重要になるのには、特定の理由があります。変化の速度が、密結合に対する許容度を追い越してしまったのです。システムが十年に一度置き換えられていた頃には、置き換えのたびに書き直さねばならない脆弱な統合も乗り越えられました。システムが絶えず追加され、入れ替えられ、廃止される今、密結合された接続の一つひとつが繰り返し課される税金となります。かつて貧弱な統合のコストは時折支払われては忘れられるものでした。それが今では四半期ごとに支払われています。遅延するプロジェクトとして、誰も予測しなかったところまで波及する変更要求として、そして誰もコアシステムに安全に触れられないという緩やかな認識、あまりに多くの他のものがそのデータの正確な形に依存しているがゆえの認識として。だからこそ統合アーキテクチャは、デリバリー上の細部から、ビジネスがどれだけ速く変化できるかを左右する取締役会レベルの制約へと移ったのです。

統合アーキテクチャの第一原則は、接続とは関係性であり、永続的な関係性には契約が必要だということです。二つのシステム間のインターフェースは、どちらか一方の実装上の細部ではありません。それは、何が、どのような形で、どのような意味で、どのような保証をもって交換されるかについての共有された合意です。その合意が明示的であれば、双方はそれを守る限り自らの内部を自由に変更できます。合意が暗黙的で、たまたま届いたデータを検査して知るものであれば、あらゆる内部変更がどこか別の場所で破壊を引き起こしうる潜在的リスクとなります。APIは、コードの断片としてではなく、公開された約束として理解するのが最善です。

第二原則は疎結合であり、しばしば口にされる一方で、理解されることは少ないものです。結合とは、あるコンポーネントが別のコンポーネントについて知り、それと共に変化しなければならない度合いのことです。それには複数の次元があります。データ形式における結合、タイミングにおける結合、場所における結合、技術における結合、そしてシステムが公開する内部モデルにおける結合です。よく設計されたインターフェースはそのすべてを最小化します。利用側は、提供側がどこで動いているのか、どんな技術を使っているのか、まさにこの瞬間に利用可能なのか、あるいはどのようにデータベースを構造化しているのかを知る必要はないはずです。知る必要があるのは契約だけです。疎結合とは依存の不在ではありません。それは、生の内部を通じてではなく、安定した、意図的に狭められたインターフェースを介して媒介される依存です。

第三原則は、インターフェースは実装ではなくドメインを表現すべきだということです。提供側のテーブル構造、内部コード、あるいは技術的な癖を漏らすインターフェースは、あらゆる利用側に提供側の私的な世界を理解することを強います。注文、出荷、顧客、請求といったビジネスの言葉で表現されたインターフェースは、その私的な世界を隠し、背後の実装が作り直されても安定を保ちます。これが統合レイヤーの持つより深い意味です。統合レイヤーとは、単に接続が物理的に通過する場所ではなく、企業システム群の意味が明示的かつ一貫したものにされる場所であり、それによって異種混在のシステム群が、それらをまたいで動く必要のあるすべてに対して、単一の一貫したインターフェース群を提示できるようになるのです。

ここ数年の支配的な変化は、リクエストとレスポンスをデフォルトとする姿勢から、イベントを第一級の存在として扱う姿勢への移行です。同期モデルでは、あるシステムが別のシステムに何かを求め、待ちます。これは問い合わせにとっては自然ですが、両者を時間的に結合します。呼び出し側は、呼び出される側が利用可能で高速でない限り先に進めません。イベント駆動の統合はこれを逆転させます。あるシステムは起きた事柄についての事実を公開します。注文が発注された、支払いが完了した、住所が変更された、といった事実です。そして他のシステムは、それぞれ自らのスケジュールでその事実に反応します。公開側は誰が聞いているかを知らず、気にかけもしません。この時間的な疎結合こそが、企業システム群が負荷を吸収し、部分的な障害を許容し、生産側に触れることなく新たな利用側を追加することを可能にするのです。

メッセージベースおよびストリーミングのプラットフォームは、これを大規模に実現できるよう成熟してきました。耐久性のあるログとメッセージブローカーが基盤を提供し、イベントのストリームを共有された真実の源泉として扱うという規律は、ニッチから主流へと広がりました。これと並んで、API-firstは願望ではなく運用上の前提となりました。契約は実装に先立って設計され合意され、ますますその契約は機械可読な仕様で記述され、ドキュメント、クライアントコード、検証を生成するようになっています。OpenAPIが同期APIに対して成し遂げたことを、同等の仕様が今や非同期のイベントベースのインターフェースに対して成し遂げつつあります。

さらに二つの動きに触れておく価値があります。第一は、APIをプロジェクトの副産物としてではなく製品として扱うことです。API製品にはオーナーがあり、ライフサイクルがあり、顧客として扱われる利用者群があり、内部向け、パートナー向け、公開のいずれであれ、意図的なバージョン管理方針があります。第二は、横断的な関心事、すなわちセキュリティ、スロットリング、可観測性、変換を一元化するマネージド統合プラットフォームとゲートウェイの台頭です。これによりそれらは、あらゆる接続で再実装されるのではなく、一度だけ解決されます。この潮流は単一の技術に向かうのではなく、階層化された能力の集合へと向かっています。同期トラフィックのためのゲートウェイ、非同期フローのためのブローカーとストリーム、そしてすべてのアダプターを手作業で構築することなくチームがフローを組み立てられるようにする統合プラットフォームです。

優れた統合アーキテクチャを際立たせるのは、どの技術を使うかよりも、どの性質を保証するかです。第一は、後方互換性の規律を伴う、明示的でバージョン管理された契約です。利用側は、無言の変更によって壊されるという恐れなしにインターフェースに依存できなければならず、提供側は、すべての利用側にまたがる同期リリースを調整することなく進化できなければなりません。これは、デフォルトでは追加的な変更、破壊が避けられないときには明確なバージョン管理、そして新旧が共存する定められた期間を意味します。バージョン管理戦略のないインターフェースは、スケジュールを待つ破壊にほかなりません。

第二の性質は、冪等性と不完全な配信への耐性です。ネットワークは失敗し、メッセージは再送され、重複が届きます。厳密に一度だけの、順序どおりの、常に成功する配信を前提とする統合は、現実がそれに反した最初のときにデータを破損させる統合です。同じイベントを二度受け取っても無害になるように、そしてイベントを再処理できるように操作を設計することは、例外的なケースではありません。それは非同期なものすべてにとっての基本線です。

第三は、オーケストレーションとコレオグラフィの間の意図的な選択です。オーケストレーションは中央の調整役をプロセスの責任者に据えるもので、明快で推論しやすい一方、結合を一箇所に集中させます。コレオグラフィはコンポーネントが中央の指揮者なしにイベントに反応することを許すもので、高度に疎結合ですが、全体として観測し推論するのは難しくなります。抽象的にはどちらが正しいというものではありません。技量とは、どこでどちらを使うかを知ることです。明確なオーナーと監査可能な状態を必要とするプロセスにはオーケストレーションを、多数の独立した利用側にまたがる事実の伝播にはコレオグラフィを。

第四は、共有される意味についての抑制です。企業システム群全体にわたる共通の語彙は価値がありますが、あらゆるエンティティのための単一の普遍的モデルを定義し、それをあらゆる場所に押しつけようとする野心は、自らの重みの下で崩壊しがちです。成熟したアプローチはドメイン駆動設計から借りてきます。同じ言葉が正当に異なる意味を持つ境界づけられたコンテキストを認識し、その境界で翻訳し、原則としてあらゆる場所にではなく、真に摩擦を減らす場所に正規の定義を保つのです。統合レイヤーの仕事は意味を媒介することであり、あらゆるシステムを、どれにもうまく合わない一つの辞書へと押し込めることではありません。

ポイント・ツー・ポイントのスパゲッティは、古典的で最もコストのかかる失敗です。新たな統合はそのつど二つのシステム間に直接構築されます。それが目の前のプロジェクトにとって最も速い道だからです。十分な数のプロジェクトを経ると、企業システム群は、あらゆるシステムが多くの他のシステムについて知り、誰も全体を見渡せず、いかなる変更も予測不能に波及する密な網目となります。ありうる接続の数はシステム数の二乗で増え、保守の負担も同様に増えます。悲劇は、個々のポイント・ツー・ポイントのリンクがそれぞれ妥当な局所的判断であったことです。スパゲッティは、レイヤーを設計してこなかったことから創発する性質なのです。

分散モノリスは、現代的なアーキテクチャを装う失敗です。システムは分離されていますが、同期呼び出しと共有された前提を通じてあまりにも密に結合しているため、何一つ独立してデプロイできません。一つへの変更は、いくつものシステムにまたがる調整された変更とリリースを必要とします。これはモノリスよりも悪いものです。なぜならモノリスの持つ結合のすべてに加えて、分散システムの運用上の複雑さを併せ持つからです。それはたいてい、システムを論理的に疎結合にすることなく物理的に分割した結果です。

エンタープライズを食い尽くした正規モデルは、過度の中央集権化の失敗です。一つの共有データモデルを定義しようという善意の取り組みがボトルネックになります。あらゆる統合が肥大した普遍的スキーマにマッピングされねばならず、そのスキーマへのあらゆる変更が全員に影響し、モデルはあらゆる特殊ケースに対応しようとして装飾過剰になっていきます。スパゲッティの治療薬が、それ自身の病になるのです。おしゃべりな同期チェーンは関連する罠で、単一のユーザー操作が多数のシステムをまたぐ長いブロッキング呼び出しの連鎖へと広がり、最も遅い、あるいは最も信頼性の低いリンクが全体の振る舞いを決め、チェーンの深部のどこか一つのタイムアウトが、頂点では説明のつかない失敗として現れます。契約のドリフトがこの一群を締めくくります。インターフェースは存在するもののドキュメント化もガバナンスもされておらず、バージョンが非公式に増殖し、誰が何を利用しているのかを誰も確信をもって言えないため、何一つ安全に廃止できないのです。

Nashuaは統合を、納品すべきコネクターのバックログとしてではなく、設計されるべきアーキテクチャとして扱います。出発点は常に、現状の企業システム群の正直な地図です。どのシステムが存在するか、今日それらが実際にどうデータを交換しているか、どこにポイント・ツー・ポイントのリンクが蓄積してきたか、そしてそのうちどれがビジネスに不可欠なフローを担っているか。この地図は、組織が自らの接続性の真の姿を初めて目にする機会となることが多く、本当のリスクと本当の機会が可視化される場所です。私たちは、問題が理解される前に目標技術へ飛びつく誘惑に抗います。

その地図から、私たちは組織と協働して統合リファレンスアーキテクチャを定義します。すなわち、レイヤーとその責務、意味が翻訳される境界、各種のフローに対する同期かイベント駆動かの選択、そして契約、バージョン管理、エラー処理の標準です。これは意図的に技術に通じたものである一方、技術に主導されるものではありません。リファレンスアーキテクチャは、どのゲートウェイ、ブローカー、プラットフォームがそれを提供するかを定める前に、あらゆる統合が持たねばならない性質を定めます。それによってツールが設計に奉仕するのであって、設計を指図することはありません。

デリバリーは漸進的で、証拠に導かれます。何年もかけてポイント・ツー・ポイントに成長した企業システム群を解きほぐすことは、単一のプログラムでは成し得ず、それを試みること自体が一つの失敗形態です。私たちは疎結合が最も多くの自由を買うフローを特定し、まずそれらの周りに統合レイヤーを導入し、拡張する前にそのパターンを実証させます。新たなインターフェースはそれぞれ、オーナーを持つ契約として設計され、機械可読な仕様でドキュメント化され、その利用側が把握されるように登録されます。時とともに企業システム群には、真の資産となるAPIカタログが蓄積されていきます。組織が何に、どのように接続できるかを閲覧でき、ガバナンスされた目録です。私たちはこれを運用面、すなわち可観測性、境界におけるセキュリティ、ライフサイクル管理と組み合わせます。なぜなら、本番環境で監視もバージョン管理もできない統合は、その設計が紙の上でどれほど優雅に見えようとも、負債だからです。

Nashuaがもたらす違いは、アーキテクチャの規律と、本番環境にまで到達するデリバリーの組み合わせです。多くの組織は、こうあってほしいと願う統合レイヤーの図を持ちながら、それとはまるで似ても似つかない現実を抱えています。両者の隔たりは、より強力な図によって埋められるものではありません。それを埋めるのは、接続を構築し運用するチームと肩を並べて働くこと、正しいパターンを容易なパターンにすること、そして契約とバージョンを、安全でいられるだけの厳格さと、動き続けられるだけの実務性をもってガバナンスすることです。私たちはリファレンスアーキテクチャという長期の視点と、今四半期に出荷せねばならないフローという短期の視点の両方を保ち、どちらか一方がもう一方をひそかに損なうことを許しません。

ここには、仕事が前提としてよいことを変える実務的な帰結もあります。あるエンゲージメントがまだ存在しない能力を必要とするとき、それは調達サイクルやベンダーのロードマップを待つ必要はありません。enterprise platformは、エージェンティック・エンジニアリングを通じて、ほぼあらゆる機能を高速に取り込めるよう作られています。必要なものは平易な言葉で記述され、すばやく生成されますが、それは常に確固たるアーキテクチャ原則の内側で、厳格な品質保証のもとで行われ、速度が一貫性、セキュリティ、統制を犠牲にすることは決してありません。その効果は単に便利というにとどまらず、戦略的なものです。それはメイク・オア・バイの線を動かし、選択肢を安価に保ち、アーキテクチャが戦略に従うことを可能にします。戦略が、たまたま棚にあったものに合わせて曲げられるのではなく。

私たちの仕事のあとに残るのは、私たちへの依存ではありません。それは、私的な前提のもつれではなく、意図的でドキュメント化されたインターフェースを通じてシステムが結ばれた企業システム群であり、あらゆる変更が発掘作業になることなく、システムを追加し、置き換え、廃止できる組織です。これが統合アーキテクチャの真の見返りです。技術ではなく、変化する能力の回復です。結合組織が丁寧に設計されるとき、異種混在の企業システム群は互いに衝突するサイロの集まりのように振る舞うことをやめ、一つのビジネスとして振る舞い始めます。そして組織が次に購入するシステムは、脅威ではなく追加となるのです。クライアントがその状態に達し、それを静かに、持続的に保ち続けられるよう支援すること、そこにNashuaの違いがあります。