API-led Connectivityとは何か?(前編)

API-led Connectivityは、再利用可能で3つのカテゴリ(後述)のいずれかに属するAPIを使ってデータとアプリケーションを接続する方法です。これらのAPIは、システムからデータをアンロックしたり、データをプロセスに組み入れたり、ユーザーエクスペリエンスを提供するなど、特定の役割を果たすために開発されます。


組織全体がAPI-led Connectivityと呼ばれる方式を採用すると、そのビジネスに関わる全員が、発見、セルフサービス、再利用を通じてアプリケーションやプロジェクトをデリバリする際の最高のケイパビリティにアクセスできるようになります。 API-led Connectivityは再利用可能な3つのカテゴリのAPIを使って新しいサービスやケイパビリティを構成するだけではなく、企業内のデータへのアクセスを分散化および民主化します。IT部門は再利用可能なアセットを作成し、その過程でレガシーアプリケーションやデータソース、SaaSアプリを含む主要システムをアンロックします。すると、IT部門およびその他のチームはこのAPIアセットを再利用してプロセスレベルの情報を組み立てることができるようになります。次に、アプリ開発者はこれら再利用可能なアセットを発見、セルフサービスでの利用ができ、エクスペリエンス層のAPI作成と最終的なエンドアプリケーションの構築ができます。このようなAPI主導のアプローチを使った統合は、アジリティ、スピード、および生産性を向上します。


なぜAPI-led Connectivityが必要なのか?

API-led Connectivityが重要な統合戦略になりつつある背景には、企業が顧客、従業員、およびパートナと関わるために使用するテクノロジーが劇的に変化したことがあります。loT、SaaS、ビッグデータ、ソーシャル、モバイル、そしてAPIといったエンタープライズテクノロジーはビジネスに新しい強力なツールをもたらしつつあります。これによってビジネスはこれまでより多くのことを行い、新たな収入の流れをアンロックし、顧客をよりよく理解し、これまでよりも速くイノベーションを起こすことが可能になります。しかし、そのためには、APIによってこれらの新しいテクノロジーを統合しなければなりません。従来、このような統合はポイントツーポイント接続で、プロジェクトで必要な場合にその場限りのものとして行われていました。このため、システムは複雑で扱いにくく、故障しやすく、維持するために膨大なIT部門の時間とリソースを必要としていました。

それに加えて、新しいシステムの変更頻度も増加しました。たとえば、コアバンキングシステムのデータベーススキーマは年一回しか変更されないとしても、これらのシステムに接続するオンラインやモバイルのバンキングアプリケーションの要件は毎週、毎日、あるいは毎時変わる可能性があります。もはや従来のポイントツーポイント統合方法ではこのような変化のスピードに対応しきれません。もっと別のアプローチが求められています。それがAPI-led Connectivityです。


API-led ConnectivityはどのようにIT部門の仕事量を減らすのか?

API-led Connectivityには重要な役割があります。というのは、IT部門にはこのような新しいテクノロジーを実装し、必要な変更を行う一方で、レガシーシステム(およびその他のシステムへの接続)のメンテナンスを行うことが求められているからです。IT部門のリソースは一定であるにも関わらず、対応しなければならない要求は増える一方です。そして、その結果生じるのがITデリバリギャップです。

今日のテクノロジーのニーズを満たすのに必要な新しいプロジェクトの数は、それらを実際に実行するIT部門の処理能力をはるかに超えて限りなく増え続けています。また、ビジネスにおける技術要件は倍数的に増加する一方で、ビジネスがどれだけ多くのリソースをつぎ込めたとしても、IT部門のリソースは直線状にしか増えません。MuleSoftの「Connectivity Benchmark Report」によると、ITに関わる意志決定者の大半は予算が今後も変わらないか、増えたとしてもごくわずかであるとし、そのため無制限なリソースというのは選択肢にないと考えています。だからこそ、API-led Connectivityがよりよい統合戦略となるのです。


API-led Connectivityを可能にするAPIとは何か?

API-led Connectivityはアセットの接続と公開のためのアプローチを提供します。このアプローチでは、ポイントツーポイントで接続するのではなく、すべてのアセットがマネージドAPI、つまりモダンなAPIとなり、統制を失うことなくセルフサービスで発見可能になります。 API主導のアプローチで使用されるAPIは以下の3つのカテゴリに分類されます。

  • システムAPI- 通常、レコードのコアシステムにアクセスして、ユーザーを複雑さや基本システムの変更などから隔離する手段を提供します。一度構築すると、多くのユーザーは基本システムについて学ばなくてもデータにアクセスできるようになり、また複数のプロジェクトでこれらのAPIを再利用できるようになります。
  • プロセスAPI - これらのAPIは単一システムまたは複数のシステム間のデータと相互作用してデータを形成し(データのサイロ化を打ち破る)、データの元となるソースシステムやデータの配信される対象チャネルに依存することなく、作成されます。
  • エクスペリエンスAPI - エクスペリエンスAPIは、チャネルごとに別々のポイントツーポイント統合を設定するのではなく、すべてのデータを共通のデータソースから取得し、意図したオーディエンスによって最も簡単に利用できるようにデータを再構成できる手段です。エクスペリエンスAPIは、特定のユーザーエクスペリエンスを念頭に置いてAPIをデザインするAPIファーストの原則によって作成されます。

このようにAPIを構築、組織し、セルフサービスで発見可能および利用可能にすることで、API-led Connectivityはビジネスを構成可能なものに変えます。これにより、ビジネス内のどのチームもこれらのAPIを構成および再構成し、適合させて、ビジネスの絶えず変化するニーズに対応することが可能になります。


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

API-led Connectivityがビジネスにもたらすメリットや、それを実現するためのAnypoint Platformの詳細情報についてはオージス総研にお問い合わせください。

本記事はMuleSoftのblogをオージス総研が抄訳したもの(前編)です