統合は買えない

統合は買えません

システムを接続することを目的とする幅広いツールにもかかわらず、統合は購入できません。

プログラミング言語は購入できます。1974年のCONTUの裁定後、コンパイラにお金を払うことが一般的になりました。ビル・ゲイツの有名なアマチュアへの公開書簡は、コミュニティにMicro-SoftのAltair BASICインタープリター（数年後にダッシュを削除）の支払いを求める呼びかけでした。フリーソフトウェア財団のGCCコンパイラは、プログラミング言語のコモディティ化への扉を開きましたが、開発者ツールの商業市場は残されました。たとえば、Java（現在無料で利用可能）でプログラミングするのは喜んでいますが、viやNotepadでは喜んでプログラミングしません。

統合ソフトウェア製品（ESB、ETLツール、APIプラットフォーム、クラウド統合サービス）は、ビジネス上の問題を直接解決する製品ではありません。たとえば、不正検知製品、分析製品、CRMとは同じカテゴリーではありません。それらは、ツールチェーンとコンパイルプロセスをサポートするランタイムがバンドルされたプログラミング言語です。統合製品を購入すると、商用プログラミング言語で統合自体を構築することに同意したことになります。

統合ツールはほとんどの場合ローコードプラットフォームであり、ドラッグアンドドロップで統合ワークフローを配置できるグラフィカルデザインパレットを提供することにより、開発作業を簡素化することを目的としています。ソースコードは通常、ランタイムで解釈できるマークアップ言語で保存されます。ワークフローをパレットにドラッグアンドドロップするかもしれませんが、その裏側では、プラットフォームはソースコードをJSONまたはXMLとして保存し、マークアップを実際の機械コードに解釈する方法を知っているランタイムを埋め込みます。これは、Micro-Softの初期のコンパイラがAltairプラットフォームでBASICコードを機械コードに変換する方法と変わりません。たとえば、AWSオーケストレーションエンジンのStep Functionsの「Hello、World」ソースコードを以下に示します。

図1：Step Functionsは、JSONとグラフィカルデザインパレットの両方を使用してワークフローを表します。

AWS Step Functionsを含む多くの統合ツールでは、グラフィカルパレットまたはマークアップ言語のいずれかを使用してプログラミングできます。Charles Petzoldの有名なCSAMLに関するエイプリルフールジョークを読んだ人なら誰でもわかる理由で、パレットの方が好まれることが多いですが、パレットで統合ステップを設定する複雑さから、実際には、有能な開発者は基礎となるマークアップ言語自体にもある程度の習熟度を得ます。実際、グラフィカルパレットからマークアップ言語への双方向マッピングがあり、一方を変更するともう一方にすぐに反映されます。数学の専門用語を正しく理解していれば、それは同型と呼ばれるものなので、結果の構造を「ソース図同型」と呼びます。パレットとマークアップ言語の両方ともソースコードを表し、シームレスに相互に変換できます。もちろん、これは世界に対する開発者中心のビューを表しています。ランタイム自体はマークアップ言語だけを気にします。

これは、開発者がグラフィカルパレットなしでソースコードを直接編集するほとんどのソフトウェアプログラミングとは大きく異なります。この方法を「ソースエンドモルフィズム」と呼びますが、「通常」と呼んでも構いません。もちろん、Javaのクラス図を視覚化し、ソースコードに反映される編集を行うことができるツールもありますが、Java開発者の通常の活動はIDEでJavaソースコードを直接編集することです。

グラフィカルデザインパレットを提供することの利点は、思考を整理する方法、統合問題のためのドメイン特化言語（DSL）を提供することであり、不要な複雑さを排除してシステムを接続するという狭い問題に集中できるようにすることです。Javaは汎用的な問題を解決するのに優れているかもしれませんが、デザインパレットと宣言型マークアップ言語の制約は、Excel関数がカスタムJavaコードを書くよりもエレガントに予算の問題を解決するのと同じように、統合とワークフローの問題をよりエレガントに解決すると主張しています。同様に、多くの状況で、私は、Reverse Polish Notationと科学計算をサポートする印象的なHP 50gグラフィック電卓よりも、iPhoneの電卓の方がはるかに優れています。

図2：優れたDSLは、中心的な問題に焦点を当てることで複雑さを排除します。

統合ツールを購入すると、実際の統合自体を構築することに同意したことになります。購入するのは、汎用言語を使用するよりも効率的かつシンプルに統合を解決できるという約束です。したがって、アーキテクトの仕事は、その約束がどの状況で成り立つ可能性があるかを理解し、そのROIを正当化するために、そのツールをそれらの状況以外で使用するという、理解できる誘惑を避けることにあります。

一部の統合DSLは、私のiPhoneの電卓のように、問題空間のより単純な投影です。実際、チューリング完全であるものもあり、理論的には、汎用言語と同じアルゴリズム能力を持っています。これは真実ですが、計算可能性に関する学術的な議論はソフトウェアエンジニアリングを考慮していません。Googleのエンジニアグループはソフトウェアエンジニアリングを「時間の経過にわたるプログラミング」と定義しました。プログラミングが抽象化を扱うことを必要とする場合、「時間の経過にわたるプログラミング」とは、環境が変化するにつれて複雑なエコシステムでそれらの抽象化を進化させることを意味し、チームの合意、品質管理、デリバリーメカニズムを積極的に考慮する必要があります。まもなく、時間の経過にわたるプログラミングの懸念事項が統合にどのように影響するか、ローコード統合ツールの適切な状況をどのように決定するかを詳細に調べます。しかし、まず、統合の主な目的はシステムを接続することであるという考えに異議を唱えたいと思います。なぜなら、より広範な定義によって、抽象化の簡素化がプログラミングを促進するエコシステムの部分と、時間の経過にわたるプログラミングの追加の複雑さが汎用プログラミング言語を必要とする部分とをより適切に分離できると信じているからです。この主張はまもなく説明します。

クリーンなインターフェースの構築に力を注ぎましょう

ほとんどの人にとって、「統合」という言葉は、システムを接続し、システムを同期状態に保つためにデータを共有することを意味します。統合のその定義は、現代のデジタルビジネスの要求を満たすには不十分であり、うまく実行された統合の真の目標は、機能間のクリーンなインターフェースを作成することであると信じています。

主要な焦点がシステムの接続にある場合、新しいシステムを既存の技術基盤に接続する速度によって、統合アプローチの成功を測定できます。システムはその基盤内の主要な価値ドライバーになり、統合はシステムを適切に動作させるための必要な悪になります。代わりに、デジタル機能に関するクリーンなインターフェースの作成に主要な焦点を移すと、時間の経過にわたるデジタルアジリティの向上によって成功を測定し、それらのデジタル機能が主要な価値ドライバーになります。システム自体よりも重要になる可能性があります。その違いには、実装よりもインターフェースの強調など、多くの要素があります。

インターフェースの簡素化は、成功した製品を作成し、複雑なエコシステム内でスケーリングするための重要な要素の1つです。たとえば、私がタイプしているキーボードの機械電気実装、または私がタイプしているキーが画面に表示されるように魔法のように機能する入力システムドライバーやオペレーティングシステムの割り込みについては、ほとんど理解していません。キーボード、システムドライバー、オペレーティングシステム、モニター、アプリケーションはすべて別々の「製品」であるため、誰かがそれらすべてを理解する必要がありました（おそらく多くの人々が）。しかし、私が心配する必要があるのは、脳内の考えを画面上の言葉に統合するために、適切なキーを適切なタイミングで押すことだけです。

もちろん、興味深い系が導かれます。インターフェースを簡素化する鍵（しゃれではありません）は、より複雑な実装を受け入れることです。

市場と競合するデジタル製品を考えると、この記述に何ら論争の余地はありません。Google検索は内部的には想像を絶するほど複雑ですが、デジタルに不慣れなユーザーでも驚くほど簡単に使用できます。ビジネスユーザーと競合するデジタル製品についても、同様のことが言えます。Salesforceの導入に興奮している営業チームは、ユーザーインターフェースが以前のCRMよりも直感的であっても、製品自体の維持と進化には相当な労力が必要であることを理解しています。そのため、サブスクリプション料金が正当化されると感じています。しかし、私たちは統合を異なるものとして扱います。直感的には、アーキテクチャ図の二次元のボックスは相当な複雑さを隠していることを理解していますが、一次元の線は何か違うものだと期待しています。

(一つの点で確かに違います。ボックスは購入できますが、線は購入できません。なぜなら、統合は購入できないからです。)

これまで、私たちはプロジェクトの計画とコストを、導入するデジタル製品である「ボックス」を中心に立ててきました。しかし、「線」、つまり統合部分は、組織の技術的負債の隠れた、そして多くの場合、主要な推進力です。それが、物事が以前より時間がかかる理由です。

図3：私たちはプロジェクトを導入するアプリケーションという観点から考えていますが、それらのアプリケーション間の「線」が時間とともに重要なコスト要因になります。

その接着コードを簡素化することは確かに素晴らしい努力であり、統合ツールも役立ちますが、機能の上にクリーンなインターフェースを構築することを犠牲にしてはいけません。重要なのは、インターフェースの使いやすさを効果的に判断できるのは、実際にそれを使用するユーザーだけだということです。Googleは、検索の実装を容易にするために、地理的情報、最近の情報、人気情報など、より多くの情報を求めることもできましたが、代わりに単一のテキストボックスを提供し、それらの要素をアルゴリズムに適用する方法を学ぶ必要がありました。同じ懸念事項はAPI設計（同期呼び出しと非同期イベントを含むように広く定義します）にも当てはまります。

クリーンなインターフェースは実装の詳細を隠蔽し、統合コンテキストにおけるそれらの実装の詳細の1つは、プログラミング言語の選択です。関連するシステムのプログラミング言語を主要な焦点とするアーキテクチャ図を私はまだ見たことがありません。

図4：アーキテクチャ図で実装言語を強調することは一般的ではありません。

しかし、統合のためにまさにそれを行う図の多くのバリエーションを見てきました。このような見方は、デジタル機能ではなく、配線ツールチェーンを強調するため、システムを接続する配線作業としての統合の戦術的な理解を強化します。

図5：アーキテクチャ図に商用統合ツールを示すと、インターフェースではなく実装の詳細が強調され、統合が戦術的な懸念事項として扱われます。

API利用者が気にしないことを願うもう一つの実装の詳細として、データの取得元システムがあります。SAPで働くビジネスユーザーとその周辺のITスタッフを除いて、組織の誰もSAPシステムの癖を気にする必要はありません。彼らが気にするのは、顧客データへのアクセス方法や注文の作成方法だけです。この観察は、統合戦略で最も頻繁に違反される原則の1つであり、システムを接続する配線作業としての統合の暗黙的な哲学の最も強力な指標の1つであるため、別に述べる価値があります。デジタル機能の上にクリーンなインターフェースを作成するのではなく。SAP APIは必要ありません。なぜなら、APIユーザーはSAPを気にしないからです。しかし、注文管理APIが必要になるかもしれません。システムではなく、機能を抽象化します。

ユーザーは静止しておらず、多くの場合、優れたAPIは再利用によって価値を追加します。再利用をAPIの主要な目標として過度に重視するのは簡単です（複雑さの抑制がより重要な目標だと信じていますが）、それでもそれは有用な願望です。ユーザーの進化するニーズに対応することは、以前の仮定を破ることを意味し、これは時間とともに発生する典型的なプログラミング上の懸念事項です。以前の比喩を続けると、キーボードの役割は、ユーザーの考えをシームレスに画面上のテキストに統合することです。ネイティブの英語話者として、ネイティブの中国語話者が使用するピンイン表記に苦労したことはありませんが、数年間にわたって、Colemakキーボードレイアウトを使用して不必要に自分を苦しめてきました。物理的なキーボードがソフトウェアレイアウトに魔法のように適応できなかったため、キーボード上の文字と画面に表示されるものとの間にインピーダンスミスマッチがありました。通常、これは問題ではありません。（特に速くない）タッチタイピストとして、キーボードを見なくても慣れています。しかし、そのインピーダンスミスマッチのために、学習プロセスは非常に困難になり、常に画面上のQWERTYへのマッピングを見て、キーを下に見ている間、脳がその結果の混乱を処理していました。バックライト付きで、キーボードレイアウトに合わせて物理キーに文字を投影するキーボードがあることは間違いありません。もちろん、その改善されたインターフェースの代償は、より複雑な実装であり、その進化は時間とともに発生するプログラミング上の懸念事項です。

時間とともにユーザーに適応できない、または実装の都合で基盤となるシステムと共に簡単に変化する統合インターフェースは、ポイントインタイムの統合であり、実際には複数のレイヤーを持つポイントツーポイントの統合にすぎません。APIの衣をまとっているかもしれませんが、新しいシステムがシステムに接続され、APIが複製または悪用されて実装上の問題が解決されるたびに、その真の姿を表します。ポイントインタイムの統合は、システム間の技術的負債を増大させます。

もちろん、既存のぎこちないシステムは、それらをボックスに入れる試みに抵抗します。ERPはすべてを行うように特別に設計されているため、ERPと統合する必要がある新しい機能を外部化しようとすると、課題になります。結果として生じる統合の複雑さを制御し、ユーザーから隠すには、高度なアーキテクチャスキルが必要になる可能性がありますが、別の選択肢は、組織の技術的負債を増やし、ポイントツーポイントまたはポイントインタイムの統合のスパゲッティ状の混乱にさらにノードを追加することです。その技術的負債を削減する方法として私が知っている唯一の方法は、ユーザーにとってクリーンなインターフェースを作成することに固執し、必要な変換、キャッシング、およびダウンストリームシステムへのオーケストレーションを作成することです。そうしないと、APIのすべてのユーザーがその複雑さに対処することを強いられ、ユーザーはあなたよりもはるかに少ないコンテキストしか持ちません。

統合問題をツールで解決する方法を考えるという考え方ではなく、俊敏性を最大化するための適切なインターフェースを構築する方法を考えるという考え方に転換する必要があります。

インターフェースの進化を管理するために汎用言語を使用しましょう

多くの商用統合ツールは、統合環境を所有し、必要に応じて汎用言語を呼び出す機能を市場に出しています。このようなメッセージングの背後にあるマーケティング（製品浸透とロックインを促進します）を評価できますが、アーキテクチャのガイダンスとしては、正反対です。代わりに、少なくとも2つの理由から、ほぼ常に汎用言語でインターフェースの進化を管理する必要があります。クリーンなインターフェースの維持の複雑さをより適切に管理するため、および戦略的な統合の意思決定を行う際にツールのメンタルモデルの重力に巻き込まれないようにするためです。

統合ツールは実装という観点で「思考」します

統合ツールは、ITシステムのスペクトル全体でデータと機能を解き放つ複雑さのために作成され、現在も繁栄しています。実際の顧客マスターデータは、たとえばSAP内に存在する可能性がありますが、顧客ライフサイクルの初期段階はSiebel CRMに存在します。IBMメインフレームシステムは、一部の顧客のコア請求処理を依然として処理しており、他の顧客にはOracle ERPが使用されています。今、ビジネスはSiebelをSalesforceに置き換えたいと考えています。新しい製品を導入するビジネスチームは、それを自社の営業受注プロセスに適応させるための設定に時間がかかることを当然理解していますが、システム間の接着剤を整理するだけで長いITタイムラインを告げられることを望む人はいません。結局のところ、SaaSですから！

従来、これらの長いタイムラインはポイントツーポイントの統合の結果であり、学習を許しませんでした。システム間の新しい接続ごとに、チームは接続方法、データの解釈方法、システム間のルーティング方法などを再学習する必要がありました。統合ツールは問題をより小さな部分に分割し、特にシステムへの接続など、一部は再利用できるようになりました。先に見たAWS Step Functionsのパレットで使用可能なアクションの一部を見てみましょう。

図6：AWS Step Functionsワークフローの各ステップは、実装に関する懸念事項を示しています。

Step Functionsは、すべての操作を何らかのAWSサービスに対する何らかの操作という観点から記述しています。ワークフロー内の各ボックスを構成して、たとえばDynamoDBテーブル名を記述することで、パレットの主要部分にある全体的なフローに集中できます。Step Functionsは、クラウドネイティブなAWSサービスに明らかに偏った比較的新しい統合ツールですが、私が知っているすべての統合ツールは、実装に関する懸念事項に焦点を当てて同様の動作をします。アプリケーション統合の初期のオンプレミス対応物はエンタープライズサービスバス（ESB）であり、システム接続をオーケストレーションとルーティングから再利用可能なコンポーネントとして分離していました。統合の「面倒な作業」を取り除くことを目的としていたMulesoftのESBの簡略化されたビューで、その分離を確認できます。

図7：ESBは接続をオーケストレーションとルーティングから分離します。

業界はバス上にエンタープライズワイドな標準フォーマットを持つことを目指していましたが、ESBの世界にはいくつかの自然な行き違いがありました。しかし、それらはすべて、バスの入力と出力（統合されるシステム）へのアダプターの概念を共有していました。順調な場合は、BPELのような言語で統合を記述できます。これは、XMLでプロセスを記述するように、グラフィカルなデザインパレットとソースダイアグラムの同型を提供できます。

業界はESBから大きく移行していますが、現代のAPIプラットフォームにその遺産を見ることができます。たとえば、Mulesoftの3層APIアーキテクチャを見てみましょう。

図8：Mulesoftの3層アーキテクチャは、エクスペリエンスとシステムAPIとの接続の分離を維持します。

Mulesoftは、API管理プラットフォームと、APIを構築するためのローコードランタイムの両方を販売しています。ミドルウェアインフラストラクチャを購入することは可能であり、多くの場合そうする必要があります。また、汎用プログラミング言語で構築されたAPIにプロキシするAPIゲートウェイをランタイムから完全に分離することも可能です。そうした場合、Mulesoftランタイム以外ですべてのAPIを構築した場合、Mulesoftの3層アーキテクチャを使用しますかという疑問が生じます。

エクスペリエンスAPIのアイデアは非常に気に入っています。その名前は、マイクロサービスコミュニティで普及している名前よりも専門用語が少ないです。バックエンド・フォー・フロントエンドですが、より幅広い懸念事項を明らかにカバーしているため、「チャネルAPI」という用語の方が好きです。たとえば、B2BシナリオでコアAPIへのアクセスを狭めることは、明らかにチャネルに関する懸念事項であり、「エクスペリエンス」や「フロントエンド」に関する懸念事項ではありません。名前が何であれ、最適化されたチャネル固有のAPIを提供することは貴重なパターンであり、チャネルが基盤となる機能とは異なる速度で進化し、攻撃者にとっての表面積を狭めることができます。

実装よりもインターフェースに焦点を当てているため、プロセスAPIとシステムAPIの規定された分離にはあまり興奮していません。システムレイヤーは接続に焦点を当て、プロセスレイヤーはオーケストレーションに焦点を当てています[1]。システムを接続するための実装に関する懸念事項の類似性を無視することは困難であることを示すために、上記の簡略化されたESB図を再描画しました。

図9：3層アーキテクチャは実装の詳細を強調し、そのESBの遺産を示しています。

Mulesoftのようなプラットフォーム（ESBとAPIランタイムの両方）の価値提案の一部は、SAPやSalesforceなどのシステムへのコネクタのビルトインライブラリにあります。これらのコネクタは、システムのエッジ（特にシステムレイヤー）で時間を節約できます。3層アーキテクチャはこれらのコネクタの使用を簡素化し、オーケストレーションと集約を分離して再利用を促進します。

概念的には、3層アーキテクチャは、APIを設計してMulesoftのESBの遺産に適合させるように制約します。理論的には、このアーキテクチャにより、レイヤー間の再利用性が向上します。実際には、複数のコンシューマーへの進化するプロセスAPIのプログラミングに関する時間の経過に伴う懸念事項によって制限されます。実際、APIではなく、むしろAPIの衣をまとったETLである多くのAPIを見てきました。システムレイヤーは抽出を管理し、プロセスレイヤーは変換を管理し、エクスペリエンスレイヤーはロードを管理します。これは驚くべきことではありません。統合ツールは実装という観点から考えているからです。

統合ツールを購入することの魅力は、システムを接続するという戦術的な懸念事項を安価に解決し、カスタムソフトウェアの通常の費用とリスクを回避できることです。残念ながら、問題領域をこのように構成すると、ツールが代わりに考えてしまうことになります。

実装に関する懸念事項を簡素化するために、商用統合ツールを使用しましょう

今までの説明で明らかになったように、私は企業全体の統合ツール導入には深い懐疑心を抱いています。それは特定のツールそのものを批判するからではなく、その導入が統合の価値に対する根本的な誤解を表していると考えているからです。もちろん、ツールベンダーは反論するでしょうが、ベンダーは浸透率とロックインを高めるという当然で理解できる目標を持っています。アーキテクトの役割は、ベンダーの製品戦略を自社のアーキテクチャ戦略にさせないこと、そして適切なバウンデッドコンテキストをツールに作成することです。

この観点から、商用統合DSLが非常に大きな価値をもたらす可能性のある分野を少なくとも2つ見出しました。

ワークフローと接続性の簡素化

実装は二次的な懸念事項であるからといって、基盤となる機能へのアクセスを簡素化するインターフェースの背後で適切に枠組みを設定する限り、実装を高速化することに真の価値がないわけではありません。当然のことながら、実装の高速化は、商用統合DSLの主要な価値提案です。

多くの統合DSLは、統合環境を「所有」し、必要に応じて汎用言語を呼び出すことを目的として販売されています。時間の経過に伴うプログラミングに関する懸念事項に対処するには、その制御を反転させ、進化の複雑さにさらされる実装部分を、時間の経過とともに多くの変更を必要としない部分から抽象化する必要があります。

図10：時間の経過に伴うプログラミングの複雑さを管理するには、統合DSLを使用して実装を簡素化し、インターフェースを所有するためには使用しないでください。

私が関わったあるチームは、Camundaを使用してマイクロサービスのオーケストレーションを管理しています。一部のオーケストレーションツールとは異なり、CamundaはSpringおよびSpring Boot統合を含むJavaライブラリとして使用できるため、汎用プログラミング言語でインターフェースの進化を管理するために従来のJavaソフトウェアエンジニアリング規律をはるかに簡単に使用でき、ワークフローツール（この場合はオープンソースですが、商用ツールでも同様に機能します）で特定の実装面を簡素化できます。

同様に、それらのシステムコネクタとアダプタは、実装の負担軽減に大きく貢献し、汎用プログラミング言語で記述されたコア機能の抽象化の背後で抽象化することができます。これはMulesoftのシステムAPIガイダンスに似ており、最終的なAPI戦略でシステムを軽視する場合でも、優れた実装アドバイスとなる可能性があります。同様に、グラフィカルなワークフローの視覚化は、上記で示したAWS Step Functionsの例のように、複数ステップのプロセスにおける簡単なステップを一連の呼び出しに接続する作業を高速化できます。

一般的に、統合DSLに多くの変換を追加することには警戒する必要があります。または、時間の経過とともにJavaなどの言語でそれらの変換を再実装することを検討します。それは、時間の経過に伴うプログラミングの複雑さの多くが存在する場所である傾向があるからです。変換は、ソースシステムのデータと、消費システムが期待するそのデータへのインターフェースとの間のバッファを表し、したがって、レコードシステムの変更と、消費者のためのインターフェースの進化という複数の方向からの進化圧力があります。同様に、パフォーマンスの最適化や復元力のあるコード（キャッシングなど）は、時間の経過とともに非常に複雑になることが多いので、汎用言語で維持する必要があります。

B2B統合のロングテールに対応する

B2Bシナリオでは、組織の壁の外での統合が必要になることがよくあります。運が良ければ、そのような統合にはクリーンなAPIに依存できますが、運は特に報われるビジネス戦略ではなく、IT能力の低い小規模企業と統合しなければならない場合があります。B2Bパートナーと同じくらい多様なシステムと統合しなければならないこと、そしてIT能力がほとんどないパートナーもいること、という組み合わせは困難な課題であり、私は個人的な経験から3つの異なる業界で繰り返し見てきました。

• ディストリビュータを通じて取引を行い、自動在庫補充を管理するための共有販売情報の契約を結んでいるエネルギー企業。
• サードパーティディーラーと取引を行っていますが、部品配送をグローバルに最適化しようとしている重機械小売業者。
• 支払者と取引し、（たとえば）不正、無駄、および濫用を検出するための付加価値サービスを提供するヘルスケアサービス会社。

これらのB2Bパートナーが適切なITシステムを持っている場合でも、その多様性は圧倒的になる可能性があり、API契約への統合を作成するように依頼する影響力がない可能性があります。多くのB2Bパートナーはレガシー業界にも存在し、新しいデジタル技術の採用が遅れています。FTPファイル転送、メインフレームシステムからのEBCDIC変換、EDIなどは、依然として解決しなければならない懸念事項です。

ITの動きが遅いという利点は、時間の経過に伴うプログラミングに関する懸念事項が軽減されることです。商用統合DSLの利点は、その多くが、必要な統合パターンと変換をサポートする機能を備えている可能性が高いことです。変換をツールに直接入れることは上記のアドバイスに反しますが、B2B統合は弁護士や調達部門のスピードで進む傾向があるため、トレードオフはより魅力的です。もちろん、専用のチャネルAPIは必要ですが、統合DSLは安価なアダプタとして機能できます。

図11：統合ツールを統合パートナーと共通のチャネルAPI間のアダプタとして使用します。

汎用プログラミング言語を使用して統合のロングテールに対処することは、非常に高価になる可能性があります。迅速な進化を必要としない限り、問題を迅速に解決するために構築されたツールを使用して対処することは、より良い経済的決定である可能性があります。

統合をビジネス戦略として捉えましょう

統合ツールを購入することを正当化するために使用される理由として、よく耳にするものがあります。それは「当社はソフトウェア会社ではない」というバリエーションで表現されることが多く、市場における組織全体の価値に合わせた投資の優先順位付けに必要な困難な意思決定を整理するための原則として機能することを意図しています。開発者の労力は大きな投資であり、統合DSLに精通した多くの有能な開発者がいますが、一般的に、そのような開発者の労働市場は、汎用言語でのコーディングに慣れている開発者の労働市場よりも安価です。

私は、この原則は「目先の利益に走り、大きな損失を被る」という類型に完全に当てはまると考えています。結局のところ、あなたは数学会社でもないと思いますが、ある規模を超えると、かなり高度な数学スキルに依存します。財務チームや統計担当者にそれほど強力ではない電卓を購入し、全体的な問題をツールの複雑さの限界に適合するアプローチに分割し、すべての問題をツールのハンマーに合う釘に変えるように依頼することによって、この問題を解決するわけではありません。

もちろん、ソフトウェアは異なるものです。ソフトウェアの開発は非常にリスクが高く、費用がかかります。多くの組織はカスタムソフトウェアを非常に恐れており、それを避けるためにあらゆる努力をします。グラフィカルな統合ツールを購入すると、よりシンプルで使いやすいカスタムソフトウェアの形が実現します。確かに、アーキテクチャ図上のボックス間の各線は、作成がより簡単になる可能性があります。しかし、そのようなツールの複雑さの限界のために、線の数は爆発的に増加し、それは時間の経過とともにアーキテクチャの技術的負債を増大させる、ゆっくりと硬化するコンクリートをアーキテクチャに注ぐようなものです。

数年前、私は新しい携帯電話の購入のためにセルフサービスのeコマース機能を提供することを目指していた通信会社と協力しました。この業界で働いたことがある人なら誰でも、その課題を理解しています。通信サービスの購入は、小売製品の購入よりも根本的に複雑です。なぜなら、通信サービスにはライフサイクルがあるからです。携帯電話の場合、そのライフサイクルに対する通常の顧客向け抽象化は、テキスト、データ、音声の制限、および国際電話の請求方法を詳述するプランであり、（法的および通信事業者の契約、海底ケーブル、海底ケーブル修理の全業界、そしてケーブルの切断を防ぐための国防協定など、電話番号というクリーンなインターフェースの背後に隠された、非常に複雑な実装です）。

実際にはすでにAPIが開発されていましたが、eコマースのウェブサイトではなく、コールセンターの担当者向けに開発されていました。電話の利用可能なプランを取得するために、APIと基盤となるシステムは、最初にコールセンター担当者の行動を記録できるトランザクションを作成することを期待していました。これは、ウェブサイトにとっては明らかに誤った抽象化です。システムの詳細が満載されたXMLペイロードを受信するためだけに、偽のトランザクションを作成することで、この制限を回避することができました。

      <x:offerDetails>
        <id>2207891</id>
        <program>2205442</program>
        <filter>
          <typeCode>C</typeCode>
          <subTypeCode>E</subTypeCode>
          <contractTerm>24</contractTerm>
        </filter>
      </x:offerDetails>

さまざまな専門家と調整して、魔法の数字と文字の意味を理解した後（基盤となる請求システムからのリーキーな抽象化）、価格の詳細を取得するためのさらなる呼び出しが必要でした。その最終的な呼び出しは、1,000行を超えるXMLを返し、そのうち約100行がeコマースのニーズに関連していました。

決して簡単ではありませんでしたが、基盤となるIT組織と協力して、追加のレガシーの複雑さのない、eコマースの懸念事項をより明確に表す新しいAPIセットを作成しました。リーキーな抽象化を意味のある機能に翻訳するクリーンなインターフェースは、eコマース開発者が請求システムのメカニズムを理解する必要がないようにしました。将来のセルフサービスを作成するために、レガシーの複雑さを抽象化する必要がありました。アーキテクチャ図は、問題に対する新しい考え方、つまり基盤となるシステムではなく、デジタル機能という観点から考えることを反映していました。eコマースチームの図表に、下流の複雑さと実装プログラミング言語のどちらも配置することを許しませんでした。

図12：下流の複雑さが大きいため、コア機能へのクリーンなインターフェースを確保してeコマースの俊敏性を向上させました。

すべてが完了すると、その通信会社は、新しいiPhoneが発売された際に、国内で完全自動化されたセルフサービスエクスペリエンスを初めて提供し、直接の競合他社だけでなく、強力なAppleさえも上回りました。

真偽はともかく、有名なジェフ・ベゾスの「外部化可能なAPIのみを通してコミュニケーションを行う」という指令は、アマゾンの現在の世界支配の鍵だったのかもしれません。この指令は、システム中心の考え方から能力中心の考え方へと統合に関する議論の軸を転換させるなど、広範な影響を与え、テクノロジー内部に計り知れない組織の俊敏性をもたらしました。さらに、より大きな変化をもたらした影響は、インフラプロビジョニング、コールセンター、フルフィルメントといった内部運用から収益源を生み出したことです。これは、それらの能力を利用する顧客向けのインターフェースを簡素化する困難な作業を行うことで実現しました。これによって、複雑なプロセスをユーザーフレンドリーなプログラム可能なインターフェースの背後に具体化し、アーキテクチャ図上に線が引かれていた場所に新たなボックスが作成されました。

統合戦略は、組織の俊敏性における重要なアーキテクチャコンポーネントです。他の「購入か開発か」のトレードオフと同様に、リスク管理のために製品にアウトソーシングしたいと思うのは理解できますが、このようなアプローチでは、統合は常に戦術的な問題として扱われることになります。アマゾンが示したように、システムを連携させることから、ビジネス能力間のセルフサービスインターフェースを公開することに統合に関する議論の枠組みを変えることで、大きなビジネス価値を生み出すことができます。そのためには、この記事で説明する統合原則の種類について考える必要があります。

Gregor Hohpeは『The Software Architect Elevator』において、デジタル組織が「一次導関数」で動作する方法について説明しています。これは数学オタクの言い方で、現在のデジタルフットプリントから変化率に焦点を移すことを意味します。私はグレガーの一歩先を行き、優れた統合戦略は「二次導関数」に存在すると述べたいと思います。つまり、組織の能力に対するインターフェースを簡素化するために時間と費用を投資する能力は、組織の加速化の重要な推進力となります。最初はわずかに速度が低下するかもしれませんが、時間の経過とともに、これらのインターフェースはデジタル変革のアクセルペダルになります。

図13：デジタル加速の構築には、特にシステム間のクリーンなインターフェースの必要性など、時間の経過に伴うプログラミングに関する問題に注意を払う必要があります。

ですから、CRMや収益管理システム、コールセンターへのML駆動型感情分析アドオンを購入するのは構いません。APIゲートウェイ、分析データベース、コンテナオーケストレーションシステムも購入してください。デジタルネイティブから製品運用モデル、インソーシングアプローチ、自律型チーム構造について学びましょう。しかし、これらの新しいシステムを活用するために統合を克服すべき戦術的な問題として扱い続ける限り、デジタル世界で競争力を維持することはできません。

統合は購入できませんが、大丈夫でしょう。自分で構築するだけの価値はあります。結局のところ、それはあなたのポートフォリオの中で最も戦略的なソフトウェアかもしれません。