DXに不可欠なAPI主導のシステムインテグレーション実現に必要な発想の転換

テクノロジー コンサルティング本部 ITソリューション アソシエイト・ディレクターの山本高裕です。テクニカルアーキテクトとしてMuleSoftを導入するプロジェクトの支援を行っています。

今回はシステム連携基盤として近年注目を集めているMuleSoft Anypoint Platformの紹介と、その特徴であるAPI主導のシステムインテグレーションについてお話させて頂きます。

MuleSoft Anypoint Platformについて

MuleSoft Anypoint PlatformはAPIマネジメントとiPaaS（Integration Platform as a Service）の機能を併せ持つというユニークな特徴を持った世界シェアNo.1のソリューションです。

デジタルトランスフォーメーションの推進に伴いシステムやサービス間でのデータ連携や既に蓄積されているデータの活用が急務である昨今、ビジネス現場からのシステム改善要求の増加とスピードに対して負荷が高まっているIT部門との「デリバリーギャップ」を解消すべく、機動的かつ柔軟なシステム連携が行えるソリューションとして注目されています。

画像出典：MuleSoft Blog「An API-led approach to energy and utilities digital transformation」

MuleSoft Anypoint Platform の最大の特徴はAPIの仕様策定から開発、再利用、およびテスト、デプロイ、実行、運用監視までを単一のプラットフォーム上で実現できる点にあります。

またMuleSoftは製品機能の提供だけでなく設計開発のベストプラクティスや方法論なども提供しており、導入したお客様がAnypoint Platformを最大限に活用できるよう支援する体制も整えられています。

MuleSoftが唱えている最も特徴的な方法論が「API-led Connectivity」（API主導の接続性）です。

API-led Connectivityとは

モバイルやビックデータ、SNS、IoT、SaaSなどはビジネスの強力なツールとなり得ますが、それを達成するにはAPIによってこれらの新しいテクノロジーを統合しなければなりません。従来のようなフロントシステムとバックエンドシステムを直接接続するポイントツーポイント型の連携では、システムが増加・多様化するにつれて連携が複雑化しIT部門の時間とリソースを圧迫し、ビジネスの変化のスピードに対応しきれなくなります。

MuleSoftではこれを防ぐアプローチとして「API-led Connectivity」を提唱しています。「API-led Connectivity」とは、複雑になりがちなシステム間連携において俊敏性と柔軟性を実現する為にAPIを以下の3つのレイヤーに構造化するフレームワークです。

■システムレイヤー
注文管理、請求管理、配送管理など俗に基幹システムと呼ばれるSoR（System of Record）にアクセスし、そのデータを規律的な形式で取り出したり変更したりするレイヤーです。またデータを利用するシステム側にSoRの改修等の影響を受けないようにするクッションの役割もあります。

■プロセスレイヤー
例えば、受注処理や配送モニタリングなど特定のビジネスユーズを達成するために、複数のシステムAPIを統制（オーケストレーション）するレイヤーです。データの取得元のシステムや、そのデータの利用システムとは無関係に汎用性のあるビジネス機能をサービスとして提供します。

■エクスペリエンスレイヤー
CRMやECサイト、SNSなど俗にフロントシステムと呼ばれるSoE（System of Engagement）に、プロセスレイヤーのAPIで提供されるビジネス機能を提供します。様々なSoEに対して利用しやすい最適な形に加工を施す役割があります。

Webアプリケーション開発を行った事がある方は、何かに似ていると感じている事でしょう。そう、この3階層のアーキテクチャはWebアプリケーションのフレームワーク「MVC（Model View Controller）モデル」に少し似ています。

MVCでデータ処理を行う「Model」は「システムレイヤー」に、画面表示を制御する「View」は「エクスペリエンスレイヤー」に、Modelを制御して必要なデータをViewに返す「Controller」は「プロセスレイヤー」に役割が似ています。

MVCも役割を分けて変更に柔軟なアプリケーションを構築する為のフレームワークであり、API-led ConnectivityはMVCの概念をシステム全体に発展させたものという見方も出来るでしょう。

従来型インテグレーションからの発想の転換

例えば、ビジネス部門で「CRMシステムの顧客詳細画面に直近の注文情報とその配送状況を表示して欲しい」という要件が発生した場合、従来のアプローチではIT部門はこれらのデータが注文管理システムや配送管理システムのどのテーブルにデータがあるかを知っているので、注文管理システムや配送管理システムそれぞれにCRMシステムが必要としているデータを返すAPIを作成し、CRMシステムがそれをコールするという直接的な連携方式を構築しがちです。

後にECシステムを構築するので同じようだが少し項目が異なる注文情報と配送状況が必要になったとすると、ECシステム用に同じようなAPIを注文管理システムと配送管理システムに追加しなければならなくなります。

こうしてポイントツーポイント型の接続が増えて複雑化するのです。

このような事態を避けるためにAPI-led Connectivityが適しているのですが、初めはAPI構成を考えるのに苦慮する方も多いかと思います。そこで私が考えるAPI構成検討のアプローチについてご紹介します。

API構成を考える際には、SoEが必要としているデータがどのSoRに保存されているかを一旦忘れます。またSoEが必要としているデータの項目単位の細かい仕様も一旦忘れます。

先ずは「注文情報」や「配送情報」といったデータがどのビジネス領域に属していて、どのような値を持つべきなのかを整理します。そこから「注文情報取得」等の機能を割り出し、それがプロセスAPIの仕様となります。プロセスAPIで扱うデータの形はSoEが欲しい形でもSoRに保存されている形でもなく、整理した論理的なデータモデルとなります。

次にプロセスAPIから注文管理システムや配送管理システムなど実際にデータが保存されているSoRから目的のデータを取り出す為のシステムAPIの仕様を策定します。

最後にプロセスAPIから返される論理的なデータモデルをCRMシステムなどSoEが欲しい形に加工するエクスペリエンスAPIの仕様を策定します。

「基幹システムの〇〇テーブルにある△△項目を連携したい」という従来のポイントツーポイント型の連携方式の発想から、「〇〇に関する処理をしてくれるサービスを構築したい」といった思考に転換する事が、俊敏性と柔軟性を持つAPI主導型システムインテグレーションを実現する為に必要な第一歩であると私は考えます。