つなぐ仕組み

仕組みの基礎の意図、仕組みの基礎のあとのビジョンが明確でない場合、以下の課題が徐々に浮き彫りになるのではないかと。

さらに、実装したアプリケーションは、いわゆる「野良アプリケーション 」と呼ばれてしまいます。

小さなアプリケーションを実装した後、次は連携したいという話に進みます。
アプリケーション間を直接連携すると、連携数の増加と共にメンテナンスが厳しいという話が発生します。

今までの問題の解決策、つまりゴールはハブの位置に連携の仕組み、ツールを導入することです。しかし、ハブの位置に該当する連携の仕組みにも変化が発生しており、それはアプリケーションのタイプが今までとは変わっているためです。

連携の仕組みを整理した場合、以下の図のとおりになります。
「クラウド・オンプレミス」、「処理するデータ量(レスポンス)」、「リアルタイム」という3つの軸があります。

レシピ型とは定型処理をイベントドリブンで処理を行う事で、エンドユーザーが処理を設定することができることです。
例：Gmailメール本文→Google SpreadSheetに保存する
例：Gmail添付あり→Google Driveに保存する

SaaSサービスが増えており、サービスを連携する場合、ETL等を利用する以外の選択肢がありませんでしたが、Integration Platform as a service (iPaaS)の登場により、SaaS間の連携がスムーズにできるようになります。

iPaaSの普及により、アプリケーションと同様に連携の仕組みにおいてもエンドユーザー自らが対応できるようになり、「レシピ型」という新しいカテゴリーが登場しています。

SaaS利用が前提の今の時代において、当社では以下の基準に基づいて、つなぐ仕組みを提案しております。

パターン1：SaaSサービスのみを考えたつなぐ仕組み　レシピ型
パターン2：SaaSサービスと社内システムを考えたつなぐ仕組み　EAI (Node-Red)

パターン2を実現する際、高価なツールを1つ購入して対応せず、カテゴリー毎にEAIツールを用意し、EAIツール間を連携する分散型のつなぐ仕組みを構築することにより、拡張性が高く仕組みができると考えております。また、Node-Redは OSS(無料)です。

パターン1を実現する際、日本企業のSaaSサービスは非常に少ないため、レシピ型では対応していない事が想定され、レシピ型でのサポートが増加する事により、パターン1での実現性は徐々に高くなると考えております。

Node-Redの特徴は以下の通りで、オープンソースではありますが、IBMが当初は開発しており、ビジュアルプログラミングですので、短期間にて技術を習得することができます。