API-led Connectivityとは何か?（後編）

API-led Connectivityは実際のビジネスではどのように機能するか?

API-led ConnectivityはITデリバリギャップを埋めるために重要な要素です。従来のポイントツーポイント統合アプローチで、セールスチームが顧客とのやり取りに使うため、リアルタイムの注文ステータスや注文履歴を提供するウェブアプリを開発したいと考えたとします。この例で、顧客データはSAPとSalesforceにあり、在庫データはSAPに、注文データはeコマースシステムにあるとします。
この時点では通常、ITチームがコードを使って両方のシステムの顧客データをつなぎ合わせてアグリゲートします。そのあと、アグリゲートされた顧客データをさらにeコマースシステム内の注文データと組み合わせて、さらに多くのコードを使って注文ステータスと注文履歴データの両方を作成します。これで、2つのデータのソースはウェブアプリAPIにフックされて、ウェブアプリで活用できるようになります。

プロジェクトは計画どおりにローンチされ、予算内に収まり、正しく機能しているため、このプロジェクトは成功とみなされるでしょう。しかし、そのとき外回りの多いセールスチームがこの機能を携帯電話でも使いたいと言ったとします。ITチームはこの時点でモバイルアプリを構築するという課題を抱えることになります。しかし、アプリを構築する開発者は前のプロジェクトで行った仕事の成果を何一つ使うことができません。そのため、彼らはすべての仕事をやり直さなければならなくなり、あまり良い結果を得ることにはなりません。
開発者はこれが近視眼的なアプローチだとわかっていても、典型的な厳しい時間的制約のために仕方がないと考えるようになります。ここにコンサルタントが関係していれば（これも典型的なパターン）、問題はさらに悪くなります。なぜなら、コンサルタントは長期的に考えることにほとんど何のメリットも見出さないからです。時間が経つにつれて、変更は非常に高くつくものとなるか、ほとんど不可能なものになっていきます。しかし、変更は常にあるため、今度はアジリティが非常に困難になってきます。こうして、下図のようにおなじみの「スパゲティーコード」パターンが形作られ始めます。

しかし、API-led Connectivityアプローチであれば、チームに新しいモバイルアプリを構築するという課題が与えられたときに、システムAPIとプロセスAPIから作成された再利用可能なアセットがすでに存在しており、それらを使って作業を始められるため、一から構築する手間を省くことができます。

そのため、モバイルアプリの構築は、さまざまなシステムをつなぎ合わせるだけの作業となります。また、新しいサービスのイノベーションや追加はこれまでよりもずっと簡単になります。この場合ですと、出荷ステータス情報の追加は、注文ステータスや注文履歴へのアクセスの場合とほぼ同じやり方です。これによって、時間、お金、リソースを節約し、プロジェクトを確実により速く完成させることができます。
このように、API-led Connectivityはサービス指向アーキテクチャの原則を一部利用していますが、このアプローチはサービス指向アーキテクチャを再利用可能なアセットのセルフサービス利用の方向に発展させたものと言えます。API-led Connectivityアプローチでは、従来のサービス指向アーキテクチャのアプローチの場合のようなトップダウンの重量級の指令によるのではなく、ビジネスのいたるところで開発者が必要と考えるプロジェクトがあれば、それを作成するために再利用可能サービスを構成したり再構成したりすることができるのです。API-led Connectivityアプローチでは、組織内でこれらのアセットをどのように使用するかということが、アセット自体と同じぐらいに重要になります。

API-led Connectivityのビジネスにとってのメリットは?

API-led Connectivityについてもっと詳しく知るには?

※この記事に掲載されている内容、および製品仕様、所属情報（会社名・部署名）は公開当時のものです。予告なく変更される場合がありますので、あらかじめご了承ください。