By Kazuyoshi Nakagawa
はじめに
「インテグレーション」という言葉、お聞きになられたことがあるかと思います。特にITの世界で、目にする機会が多いのではないでしょうか。
Boomi Integrationはインテグレーションを行うための製品です。 インテグレーションを可能な限り容易に実現するために2007年にリリースされ、本日まで進化してきました。Boomiのホームページ内では、数々の特長的な機能をご紹介しておりますが、そもそもBoomiが現在に至った経緯のようなものをご説明することも必要ではないかと考え、この記事を作成しました。
ここでは、「インテグレーションとは」から始まり、iPaaS製品であるBoomiに至るまでのインテグレーション製品の流れを見ていきます。
インテグレーションとは？
インテグレーションとは、統合、総合、統一、一体化などと訳されます。少々、大雑把に定義すると、交流がない2つのモノの間に交流を生じさせることをインテグレーションと呼んで良いでしょう。
２つのモノというのを今回のお話の観点で表現すると、２つのシステム、アプリケーション、データなどにあたります。これらの用語の使い分けについては、厳密な境界があいまいな場合も多いようです。用語の違いの説明は他に譲るとして、ここではインテグレーションの誕生からインテグレーション製品の歴史にフォーカスします。
インテグレーションに触れる前に、簡単にシステムの歴史を見ていきます。システムの歴史は計算機によるデータ処理から始まり、データ入出力にバリエーションが生まれ、ハードウェアとソフトウェアは相乗作用で進化してきました。企業や組織が導入するシステムは、メインフレームと呼ばれる大型コンピューターで始まり、最初は限定的なジョブを行わせていましたが、担えることが増えるにつれ重要さは増していきました。絶大な効果が認知され、導入する企業は増えていき、コンピューターはなくてはならないものになりました。
そこから、インテグレーションが生まれるのに時間は掛かりませんでした。外部の別システムと接続するという要件はすぐに発生しました。企業内で見ても、導入数が複数になっていきました。オープンシステムが出現すると、システム数は爆発的に増えていきました。
企業内での何らかの業務が閉じて成立していることはめずらしく、データやプロセスを共有して業務は成り立っています。しかし、導入したシステムはどうでしょうか。特定の業務を行うためのアプリケーションが増えるに従い、アプリケーションＡもアプリケーションＢも、顧客データが必要であり、顧客データを二重に登録しなければならないというやっかいなことが起こり始めました。二重化された顧客データをヒトが時間と労力を掛けて面倒みるのは効率が悪く、なんとしても避けたい。顧客データの保守は一度行えば、自動的に２つの同期が取れるようにしたい。統合要件の発生です。
当初の統合要件は、その統合を実現するために、設計し開発を行いました。使っているシステムも独自であり、統合要件も独自な場合が多く、機能制限も多々ありました。システムＡが他のシステムと交流するための方法がないのであれば、インターフェイスから開発しなければなりません。初期のメインフレームはインターフェイスが限定されていたため、他システムとの統合には多くの労力を要しました。
システムの増大とともに、統合の需要も高まり、標準的なネットワーク仕様や標準インターフェイスが作られました。各アプリケーションは外部と接続するためのインターフェイスをAPIとして提供するようになりました。C言語のAPIがあれば、統合のためのロジックをC言語で開発できるようになりました。このような統合のための様々な技術が増え成熟することにより、汎用的なインテグレーションを実現するための仕様が確立され、統合に特化した製品が生み出されました。インテグレーション製品です。
ETLとは？
ETLとは Extract Transform Load の略です。
あるシステムからデータを抽出し、フォーマットを変換し、別のシステムへ書き出すという一連の処理が名前になっています。データベースなどからデータを抽出、加工して、分析のためのシステム（データウェアハウスなど）へ書き出すというのがETLの用途です。
その日一日の対象データを夜間バッチで収集し、分析のためのシステムへ書き出すと運用が一般的でした。ハードウェアスペックを活かし、指定時間内で終わらせるための構成やチューニングこそが、ETLの能力を競い合うフィールドでした。現在でもバッチで行う大容量データの要件ではETLと言う用語が使われます。大容量データの定義は時代を経るに従い大きく変化してきましたが、依然として需要がある分野です。
EAIとは？
EAIとはEnterprise Application Integrationの略です。
企業に存在するアプリケーションを統合しようというコンセプトの製品です。標準インターフェイスやAPIを提供するアプリケーションが広く普及したことにより、技術的に可能になりました。1990年代後半から、多くのEAI製品が出現しました。日本では海外製品だけではなく、大手SI会社がそれぞれ独自製品を展開し、群雄割拠の様相を呈しておりました。
アプリケーション統合にあたり、EAIを用いるメリットは多々ありました。最大のメリットは、管理運用性の飛躍的向上です。アプリケーションとアプリケーションを需要に応じて個々に接続していくと、その接続はポイントとポイントの接続になり易いです。２つのアプリ間の接続であれば良いのですが、３つ４つとアプリが増えていくと、蜘蛛の巣のように複雑さが増していきます。当然、管理もしづらくなっていきます。きちんと管理して開発していかないと、統合プログラムは何種類にもなり、保守がしづらくなっていきます。機能拡張や使用変更にコストが掛かり、ひいては手の付けられない状態になってしまいます。スパゲッティと呼ばれる状態です。
一方、EAI製品を導入すると、ハブ＆スポークと呼ばれる構成（バス型というのもありました）を取ることができます。EAI製品はミドルウェアとして、アプリケーション統合の基盤を担います。アプリケーション同士は直接交流せず、EAI製品を介して交流します。こうすることにより、EAI製品にすべての接続を集約し、運用を管理できます。セキュリティやガバナンス面でも効果がありました。
開発面においては、アダプターやコネクターと呼ばれる統合のための機能が役立ちます。例えば、SAPと繋ぐために、SAPコネクターが提供されました。SAPコネクターを用いることにより、SAPとの統合をプログラムなしで実現できました。また、多くの製品が統合の流れを作成するGUIツールを提供しました。エディタですべて処理を記述するのではなく、GUIがコーディングをサポートしてくれました。
アプリケーション統合の観点でEAIは最初の製品群です。アプリケーションインテグレーションの黎明期として、最も重要な点は明らかでした。統合要件が実現できるということです。機能要件を満たすことができるということに多くの労力が費やされ、ユーザーフレンドリーの観点はおろそかになりました。製品の基本を学ぶだけでもかなりの時間を必要としました。機能に応じて製品が細かく分かれており、かつ仕様が異なっている製品もありました。その製品のエキスパートでなければ使いこなすのは難しいというのが実際でした。
ESBとは？
ESBとはEnterprise Service Busの略です。
EAI製品を用いてインテグレーションを実現するにあたり、多くの方がぶつかる疑問がありました。ただEAI製品を介して繋ぐのではなく、統合のベストプラクティスはないのだろうか、最適なアーキテクチャーは何か、という疑問です。そこに特化して出現したのがESBです。EAI製品とは別にESB製品をリリースしたベンダーもあれば、EAI製品にESB機能を付加した製品もありました。
ESBは、サービスをインテグレーションします。システム、アプリケーション、データなどのテクニカル面から統合を捉えるのではなく、ビジネス面から考えます。具体的に言うと、注文受付という処理があり、注文受付を細かく見ていくと、製品の在庫確認を行い、在庫があれば在庫割り当てを行うといった一連の処理があります。それらをサービスとして捉えるのです。在庫確認はサービスであり、在庫割り当てもサービスです。在庫確認サービスや在庫割り当てサービスなどが組み合わさって注文受付サービスが構成されます。粒度の小さいサービスは、より粒度の大きいサービスから活用されます。一方、在庫確認サービスの中には、在庫システムに確認問い合わせを行うと言ったより粒度の小さいサービスが存在します。
ESBは、技術的な系譜にあるというよりも、サービスと言う考え方と方法論に価値があります。本来の統合の目的であるビジネス要件の実現に立ち返り、ビジネス観点から統合を捉え、サービス指向は広く支持されました。インテグレーションの方法が大きく前進したと言って良いでしょう。しかしサービスの定義や粒度に関して、ITベンダー、ソフトウェアベンダーなど、ベンダーごとに方法論や見解が異なっており、混乱が生じました。
しかし、インテグレーションにおいて、サービスを繋ぐという方法は依然として重要です。サービスを作る機能、サービスを呼び合って大きなサービスを構成する機能をどのように実現できるかは、チェックすべき点です。
iPaaSとは？
iPaaSはintegration Platform as a Serviceの略です。
クラウドサービスとして提供するインテグレーションのプラットフォームです。
これまでの製品は、製品を購入し（それも永久ライセンスとして購入するものがほとんどでした）、サーバー機や必要なソフトウェア（データベースなど）を準備します。製品をサーバー機にインストールして設定します。そこで初めて使い始められます。多くの場合、導入作業は業者に頼む必要がありました。本番環境以外にテストや開発のための環境を作るのであれば、別途構築する必要がありました。設定後は確認テストも行いますので、トータルで数週間は掛かりました。
iPaaSはクラウドサービスをコアとして作られています。iPaaS製品によっては、すべてをクラウドサービスとして提供するものもあります。サーバー機や必要なソフトウェアの準備は必要ありません。すぐに使い始めることができます。すぐに開発をスタートし稼働に至れます。まさに、クラウドサービスのメリットを享受できます。すなわち、「初期コストが安い」、「運用コストの削減」、「資産管理が不要」、「メンテナンスが不要」、「優れた拡張性」、「どこでも使える」などです。
クラウドサービスの利便性が認識され、多くの企業に導入されていく中で、ETLやEAI製品を提供していた多くのベンダーは、iPaaS へ移行しました。また、iPaaS製品からインテグレーションに参入したベンダーも多数あります。ETLやEAI、ESBの機能はiPaaSに集約されました。iPaaSはインテグレーション製品の最前線と言えるでしょう。
BoomiのiPaaSとは？
Boomi Integrationは、クラウドサービスを用いた製品として開発をスタートしました。クラウドサービスの利点を最大限活かしたクラウドネイティブな製品の第一号として、2007年にリリースされました。
Boomi Integrationはエンタープライズのインテグレーション要件で使っていただけるiPaaS製品です。クラウドサービスの利点と、セキュリティやパフォーマンスの要件を併せ持った製品です。すなわち、クラウドサービスである AtomSphere は統合の流れ（プロセス）を作り、テストし、運用監視までの一貫した機能とGUIを提供します。一方、作成したプロセスを動かす実行環境はAtomと呼ばれており、オンプレミスやプライベートクラウドなどに柔軟に配置できます。
セキュリティ面では、Atomが統合のために処理したビジネスデータはAtomで閉じており、クラウドサービスの AtomSphereには決して保存されません。パフォーマンス面では、Atomにリソースを割り付けることによって処理能力を向上できます。複数のAtomに処理を分散して担当させることもできます。
他にも様々な特長があります。Boomiは使いやすいインテグレーション製品の提供を目指して創業しました。使いやすいツールとは具体的にはどのようなツールかと言うと、第一歩は学習しやすいツールです。学習しやすいためには、ツールに明確で統一されたルールが不可欠です。開発、テスト、運用管理などのすべてのツールにおいて、明確なルールで貫かれています。
使いやすさがもたらすメリットは、迅速さです。学習し、開発し、運用に至るスピードです。それらを加速するために、再利用性を重視しています。自社の過去の資産やグローバルでの既存資産を効率良く活用できるかが鍵です。Boomi Integrationで開発したものは、コンポーネントという部品単位で保存されます。活用可能な部品という単位で保存されているものを、ツールが後押しします。ツールが再利用可能な部品の存在を示してくれます。
部品を組み合わせてプロセスを形成します。プロセスは、さらに粒度の大きいプロセスから利用することができます。部品をサービスと読み替えていただければ、まさにサービス指向の方法論を具現化したものとも言えるでしょう。これにより、再利用性と迅速さに加えて、保守性、拡張性などを実現しています。
また、Boomiは10年以上前から、開発や運用の中でAIによる支援機能を提供してきました。最も活用されている機能はBoomiサジェストです。２つのデータを統合するためには、２つのフォーマットの違いを吸収するためにフィールドのマッピング(統合元のフィールドＡは、統合先のフィールドＢと一致する)を行う必要があるのですが、ここでAIを活用しています。過去１０年間に全世界で実施されたマッピング情報を学習しており、マッピングを支援します。例えば、SalesforceとSAPをマッピングする場合、同じパターンのマッピングが既に何度か存在していたら、それをベースにマッピングの支援をします。
今後、飛躍的な進化が期待できます。Boomiは2023年5月にBoomi AIを発表しました。より迅速な開発、より容易な運用を実現するため、生成AIをBoomi Integrationに搭載します。生成AIが加わることにより、Boomi Integrationの特長はさらに顕著なものになっていくことでしょう。
是非、今後のBoomi Integrationに注目してください。
iPaaS のお客様事例とは？
最後に、 Boomi の iPaaS をご利用いただいたお客様の事例をご紹介します。
ワクチンで有名になった製薬会社のモデルナ社は、新入社員の入社手続きを iPaaS によって自動化しています。具体的には、 Workday 上の人事データと ServiceNowを連携してマスターデータを作成し、必要なシステムなどの権限情報を自動で更新できる体制を構築しています。
その結果、数百時間かかっていた人手による作業を削減することに成功しています。事例は下記からもダウンロードいただけますので、ぜひご覧ください。
▼事例をダウンロード▼
