統合は多くのアプリケーションの縁の下の力持ちであり、プラットフォーム間のデータ通信の静かな門番です。しかし、多くの意思決定者は製品を評価する際に統合の品質を見落としています。
多くの場合、実際に製品を使用する前に、統合がどの程度適切に構築されているかを知るのは困難です。ほとんどのプラットフォームには「チェックボックスをオンにする」統合機能がありますが、品質が異なることがよくあります。適切に構築された統合により、最も単純なプラットフォームでも強力なツールになります。ただし、統合が適切に構築されていないと、フラストレーション、パフォーマンス時間の低下、技術的な困難、誤った情報に基づいた意思決定が発生する可能性があります。
この投稿では、適切に構築された統合の利点、統合によくある落とし穴、および「統合ファースト」の考え方で構築することがどのようなものかを探ります。
統合は、2 つのアプリケーション間の通信チャネルです。より具体的には、個別のソフトウェア要素を 1 つのシステムに結合するプロセスです。たとえば、連絡先情報やリード情報を CRM システムに保存しているが、ギフト プラットフォームを使用してこれらの連絡先にアイテムや報酬を送信しているとします。
これらを統合すると、ギフト プラットフォーム内からすべての連絡先を表示およびアクセスできるようになります。
組織全体でデータ、アプリケーション、API、デバイスを接続すると、さまざまなシステムの機能を接続し、これらの機能を技術スタック全体で (理想的には) シームレスに使用できるようになります。
統合がうまく機能すると、組織に次のような多くのメリットがもたらされます。
優れた API を使用すると、問題が発生したときにユーザーが明確で明確に定義されたエラー メッセージ (単なる漠然としたエラー コードではなく) を確認できるようになります。統合は常に変化しています。障害コードの意味や、統合のどこで障害が発生したかを知ることは、問題解決にとって非常に重要です。最適に構築された統合により、障害が効果的かつ簡潔に伝達されるため、ユーザーはより迅速に解決策に到達したり、問題を自分で修正したりトラブルシューティングしたりできるようになります。
適切に構築された統合により、2 つのアプリケーションが相互にスムーズに通信できるようになります。 「適切に構築されている」とは、情報が期待どおりに提供され、適切に機能するためにマッピングや構成がほとんどまたはまったく必要とされないことを意味します。適切に構築された統合では、ユーザーが 2 つのアプリケーションを接続するだけで作業を継続できるように、面倒な作業がすべて行われます。
このバズフレーズは最近のテクノロジー アプリの間であまりにも一般的ですが、適切に統合すれば、実際に真実になります。非常に多くの異なる製品がビジネスの兵器庫を構成することが多いため、優れた統合 (または一連の統合) により、ユーザーはすべての主要なアプリケーションから情報を取得し、それをより少ない (または 1 つの!) 場所で操作できるようになります。
慎重に構築された統合により、すべてのプラットフォームにわたる情報の同期、正確さ、一貫性が確保されます。古いデータや不正確なデータは、どの企業にとっても深刻な問題を引き起こす可能性があります。
統合がうまく機能しない場合、複数の部門にわたって深刻な問題が発生する可能性があります。統合に関する一般的な問題点には次のようなものがあります。
統合に関する一般的な問題点には次のようなものがあります。
必要なすべての情報が統合を通じて取得されない場合があります。情報転送のプロセス中に、特定のフィールドが欠落していたり、互換性がなかったり、誤変換されたりする可能性があります。
また、ユーザーが経験が浅い、または統合の設定方法に慣れていない場合、1 つのアプリケーションで間違いを犯すと、誤ったデータや問題が統合アプリケーションにエクスポートされる可能性があります。すべての統合が正しくマッピングされていることを確認し、適切なチームメイトが情報の転送の仕組みを理解していることを確認することが重要です。
API 呼び出しの追加 (ほとんどの企業が統合を構築する方法) では、応答パスに余分なステップが追加され、アプリのパフォーマンスが低下する可能性があります。また、正しく構成されていない場合、次のような問題が発生する可能性があります。
考えられる問題のもう 1 つの例は、「無限積分ループ」です。一部のサードパーティ統合ソリューションは自動化上で実行されており、あるプラットフォームでフィールドが更新され、別のプラットフォームで同じフィールドが更新されると、相互に競合し、情報が「行き来」する可能性があります。誰が最終的な真実の情報源であるかについてシステムが互いに争い始め、自動化が互いに何度も何度もトリガーされるため、「無限ループ」が発生し、これはすぐに混乱する可能性があります。
シームレスで信頼できる統合を約束されたのに、期待どおりに機能しないことが判明することほど、顧客にとって動揺することはありません。さらに悪いことに、一部の顧客は、デモプロセス中に包括的または有望な統合を売り込まれ、ソフトウェアを購入した後、大規模なマッピングや再プログラミングを行わないと統合がほとんど機能しないか、または自分たちのユースケースに適合しないことがわかります。多くの場合、状況はさらに悪くなり、行き止まりになってしまいます。必要なフィールドが利用できないか、必要な機能が「高度すぎる」ためにサポートされていません。
ワークフローをより効率的かつ正確にするという約束に騙されて、それが不安定だったり設定が難しかったりすると、誰の口にも後味が悪くなる可能性があります。また、信頼の喪失や顧客離れの主な原因となる可能性もあります。
いくつかのアプリケーション、例えば
たとえば、他のアプリケーションでは、統合を設定するときにフィールド マッピングが必要です。他のアプリがフィールドのマッピングを要求する場合、それは基本的に統合インスタンスの構成情報です。ただし、すべてが正しくマッピングされ、必要に応じてルールと自動化が適用され、可能な場合は再構築されるように、統合を設定するユーザーに重点が置かれます。
Visor は、ユーザーが統合セットアップの負担を軽減して、価値をより早く得られるようにしたいと考えていました。フィールドに関するメタデータを使用し、それをすべてのアプリで統一した方法で保存することで、Visor がバックエンドでフィールド マッピングを処理できるようになりました。そのため、ユーザーは統合アプリと表示したいフィールドを選択するだけで作業を開始できます。 「私たちはサービスが提供するメタ情報を標準化し、それをプラットフォームに依存しない 1 つの形式にしました。 Visor 内のコードは、ユーザーが間違いを少なくする方法でフィールドを表示する方法を知っています」と Visor のプリンシパル エンジニア、パトリック シャンリーは述べています。
ほぼすべてのSaaS アプリは、何らかの形で統合を提供することに誇りを持っています。すべての企業が「真実の情報源」または情報の一元化を目指しているため、統合がいつ適切に構築され、いつ後付けで製品に追加されたのかを知るのは困難です。ただし、すべての統合が同じように作成されているわけではありません。十分な統合を操作すると、どの統合が「チェックボックスをオンにする」だけで、どの統合がユーザーを念頭に置いて構築された包括的なソリューションであるかが簡単にわかります。