システムの統合

学習の目的

この単元を完了すると、次のことができるようになります。

• Salesforce と MuleSoft がどのように連携するかを説明する。
• Salesforce と MuleSoft の適切なビジネスの使用事例を説明する。
• API 主導の接続手法で設計することがベストプラクティスである理由を説明する。

API 主導の接続の利点を理解したところで、その動作を見ていきましょう。

Cloud Kicks のサクセスストーリー

お疲れさまでした。あなたは、画期的な企業 Cloud Kicks の創業者兼 CEO です。Cloud Kicks は、顧客に合わせてデザインおよびカスタマイズされた、スタイリッシュで履きやすいカスタムスニーカーを作っています。この会社のカスタムスニーカーは、セレブやプロスポーツ選手、サンフランシスコで人気のあるテックカンファレンスの出席者が履きだしたことで注目を浴びています。

Cloud Kicks は消費者だけでなく企業にも販売しており、事業基盤を拡張しています。その拡張に伴い、IT 面での課題がいくつか発生しています。まず、Cloud Kicks が業務を行うために使用しているシステムをいくつか見ていきましょう。

システム	ビジネス価値
Sales Cloud	B2B と B2C の営業管理
SAP Commerce	注文管理
Service Cloud	カスタマーサポート管理
Experience Cloud	カスタマーエクスペリエンス管理
Gmail	メールの自動化

Cloud Kicks が非常に小規模だったときには、本格的なインテグレーションなしでこれらのシステムを使用していても問題ありませんでした。システム間のデータ同期は手動で行うことができました。レポートをまとめるのも、オフィスの向こう側に電話をかけるか、メールでスプレッドシートをやりとりするだけで済みました。

ただし、Cloud Kicks の成長につれ、そのニーズが大きく変化してきています。同社のビジネスプロセスアーキテクト (兼かけだしの Integration Trailblazer) である Mary Evans にとって、現在のプロセスはスケーラブルではなく、対応策が必要なことは明らかです。要件について詳しく説明する前に、Mary と Cloud Kicks に関連する主な登場人物を紹介します。

Mary Evans は、Cloud Kicks のビジネスプロセスアーキテクトです。チームがアジャイル手法に従って、プロジェクトを予定どおりに完了できるようにすることが、Mary の業務です。常に学ぶことに熱心な Mary は、Trailhead を愛用して Sales Cloud、Service Cloud、Experience Cloud のしくみを学習しています。現在は、顧客注文履行を処理するための注文履行と顧客注文履歴を統合することに取り組んでいます。これらは現在、別々のシステムに存在しています。

IT システムアーキテクトの Jamal Cooks は、20 年のキャリアの中で、Siebel、Oracle、Dynamics、SAP、そしてもちろん Salesforce といった多くの主要なシステムやデータベースを使用した業務経験があります。Jamal は、コーディングでも誰にも負けませんが、本当に情熱を持っているのは IT 部門全体のソリューションを設計することです。多くのシステムを調和して連携させるということに Jamal はワクワクします。ゼロから何かを作り上げることにやる気を感じて、Jamal は Cloud Kicks の設立後まもなく入社しました。職場では、テクノロジーに関する第一人者として知られています。現在は、Cloud Kicks の拡大に伴うビジネス要件に対応するために、顧客注文情報を取得元のシステムから解放することに取り組んでいます。

Vijay Lahiri は開発者です。26 才にして Vijay はすでに JavaScript、HTML、Python、Ruby、AWS の高いスキルを持っています。Cloud Kicks のコーディングに関するニーズに何でも対応します。Vijay は、IT システムアーキテクトの Jamal の直後に採用されました。この 2 人は息もぴったりで、協力して意欲的な IT 部門の基礎を築いてきました。現在は、モバイルアプリケーションと Web アプリケーションの開発に取り組んでいて、モバイルアプリケーションと Web アプリケーションの統合ニーズにも対応しています。

プロセスをスケーラブルにするために、Cloud Kicks は、コネクテッド顧客イニシアチブを策定しました。すべての Salesforce ユーザーがリアルタイムで最新の顧客データを使用し、報告できるようにする必要があります。顧客データには、次のものが含まれます。

• 現在の注文
• 過去の注文
• 現在の顧客の問題 (ケース)
• 過去の顧客の問題 (ケース)

また、顧客も Experience Cloud サイトにログインしたときにこの情報にアクセスできる必要があります。

Cloud Kicks が接続済みデータに対するこの要求を満たす方法

Cloud Kicks がこの接続済みデータへの要求を満たすには、いくつかの選択肢があります。チームがカスタムコードを使用した密結合インテグレーションの構築を試みる場合と、アプリケーションネットワークを構築する場合でそれぞれどうなるかを比較しましょう。

密結合インテグレーション

プロジェクトをなるべく早く完了させたいという誘惑にかられ、Cloud Kicks チームは、カスタムコードを使用していくつかの密結合インテグレーションを作成して、すべてを稼働開始することにしました。どのシステムもすべてのデータにアクセスする必要があるため、すべてが他のすべてに接続されている必要があります。

システムの数が少ないため、必要な接続の数は問題になりません。さらに、チームに何人かのコーディングの達人がいるので、作業も迅速です。経営陣は、すばやく稼働を開始できたことに喜びました。Jamal、Mary、Vijay は速やかに作業を完了し、誰もが満足していました。が、それは数週間しか続きませんでした。

顧客データに簡単にアクセスできるようになったことで、マーケティングチームはセールスパイプライン内のリードを増加させました。Cloud Kicks は、いくつかの実店舗を開店し、デモを行うためのストリートチームを新設しました。経営陣は、その増加した収益の一部を新しいマーケティングテクノロジーにも再投資したいと考えました。その結果、店舗の POS アセットをセルフサービスストリートチームのイベント管理アプリケーション、新しいマーケティングソフトウェアを既存のアプリケーションネットワークに統合する必要が出てきました。

変更要求が積み上がっていくにつれて、システムアーキテクトの Jamal と開発者の Vijay の作業に遅れが出始めました。以前は、Jamal がいくつかの新しい項目を作成し、Vijay が Web フォームやモバイルアプリケーションをすばやく変更して新しい情報を取得すれば済みましたが、今はそれほど単純ではありません。新しいデータベースエンティティそれぞれについて、カスタムインテグレーションコードを記述し直し、テストし、リリースする必要があります。軽微な変更でも、数時間では終わらず、数日または場合によっては数週間もかかります。

技術的な遅れが大きくなりすぎ、実際のソリューションが形にならないため、Vijay と Mary はビジネスについて心配しています。

困ったことです。あまりうまくいきませんでしたね。タイムマシンに乗って時間をさかのぼり、別の選択をしましょう。

API 主導の接続

システムの稼働を開始する前に、Cloud Kicks チームは、分担して、最新の優れたインテグレーションベストプラクティスについて調査しました。再度集まったときに、社内の Integration Trailblazer である Mary は全員に MuleSoft と API 主導の接続と呼ばれるものについて報告しました。始めに入念な設計を必要とするものの、この手法はビジネスに合わせて拡張できるということを Mary は説明しました。API 主導の接続手法では、各システムを個別に接続する代わりに、インテグレーションを 3 つの API 階層に整理して構築し、アプリケーションネットワークを作成します。

API の 3 つの階層は、Jamal、Mary、Vijay のそれぞれの責務と一致しています。 

• Salesforce、SAP、Gmail アプリケーションのセールスデータとサービスデータにはそれぞれ独自のシステム API があり、Jamal がそれを作成、管理しています。
• それらのシステム API は、顧客注文 API と注文履行 API という 2 つのプロセス API に集約され、Mary がそれを担当しています。
• モバイル、Web、カスタマーサービスの 3 つのエクスペリエンス API は、顧客注文データと注文履歴データを適切なエンドシステムに配信します。これらは Vijay が所有しています。

チームはアプリケーションネットワークを設計し、API を構築し、誰もが満足しました。

顧客データに簡単にアクセスできるようになったことで、マーケティングチームはセールスパイプライン内のリードを増加させました。Cloud Kicks は、いくつかの実店舗を開店し、デモを行うためのストリートチームを新設しました。経営陣は、その増加した収益の一部を新しいマーケティングテクノロジーにも再投資したいと考えました。その結果、店舗の POS システム、ストリートチームのイベント管理アプリケーション、新しいマーケティングソフトウェアを既存のシステムに統合する必要が出てきました。

変更要求を受けると、Jamal、Mary、Vijay は、簡単に作業をアプリケーションネットワークの小さな部分に分離し、責務を分割できます。すべてのインフラストラクチャはすでに配置されているので、Jamal はプロセス API に直接影響を与えずに新しいデータベースエンティティを構築できます。Vijay もプロセス API に触れずに新しいユーザーインターフェースを変更または作成できます。また、チームが多忙なときには、Trailblazer の Mary がシチズンインテグレーターとして MuleSoft Composer を使用して、クリックで新しいインテグレーションを構築することもできます。

POS システムは Web API に関連付けます。新しいストリートチームアプリケーションはモバイル API に関連付けます。また、Mary の革新的な思考と MuleSoft Composer を使用したシチズンインテグレーション作業のおかげで、独自の API が付属する新しいマーケティングソフトウェアは顧客注文 API と接続します。毎回ネットワーク全体を作り直すのではなく、以前の成果を系統的に再利用する方法があるため、生産性が向上します。それだけでなく、Cloud Kicks は、テクノロジーチェーン全体を所有していなくても、ビジネスプロセスとカスタマーエクスペリエンスの改善を続行できます。代わりに、API を介して最終的なソリューションの主要な部分をマーケティング機能が専門のサードパーティにアウトソーシングできます。こうした機能を Cloud Kicks が (特に妥当な時間で) 独自開発できるとは思えません。

Jamal、Mary、Vijay は、時間をかけて入念に計画を策定してよかったと思っています。ビジネスと共に成長するシステムが完成し、Cloud Kicks は飛躍的な成長の基盤となるテクノロジーを手に入れました。

比較してみましょう

API 主導の接続手法を使用して MuleSoft によるアプリケーションネットワークを構築することは、Cloud Kicks にとってはるかに良い選択肢でした。これらの 2 つのシナリオを並べて比較してみましょう。

シナリオ 1: 密結合インテグレーション	シナリオ 2: API 主導の接続
短期的なニーズのための設定	将来の柔軟性のための設計
ポイントツーポイントのインテグレーション	3 層の API アーキテクチャ
作業の反復による拡張	再利用による拡張
複雑なコード	アプリケーションネットワーク

MuleSoft Anypoint Platform の詳細へ

俊敏性を維持しつつシステムを拡張するために API 主導の接続にできることを理解できたところで、「API ビルドの最初から最後まで」チュートリアルに従って Anypoint Platform を試してみてください。