統合ルール: データ通信のバックボーン

統合は多くのアプリケーションの縁の下の力持ちであり、プラットフォーム間のデータ通信の静かな門番です。しかし、多くの意思決定者は製品を評価する際に統合の品質を見落としています。

多くの場合、実際に製品を使用する前に、統合がどの程度適切に構築されているかを知るのは困難です。ほとんどのプラットフォームには「チェックボックスをオンにする」統合機能がありますが、品質が異なることがよくあります。適切に構築された統合により、最も単純なプラットフォームでも強力なツールになります。ただし、統合が適切に構築されていないと、フラストレーション、パフォーマンス時間の低下、技術的な困難、誤った情報に基づいた意思決定が発生する可能性があります。

この投稿では、適切に構築された統合の利点、統合によくある落とし穴、および「統合ファースト」の考え方で構築することがどのようなものかを探ります。

統合とは何ですか?

統合は、2 つのアプリケーション間の通信チャネルです。より具体的には、個別のソフトウェア要素を 1 つのシステムに結合するプロセスです。たとえば、連絡先情報やリード情報を CRM システムに保存しているが、ギフト プラットフォームを使用してこれらの連絡先にアイテムや報酬を送信しているとします。

これらを統合すると、ギフト プラットフォーム内からすべての連絡先を表示およびアクセスできるようになります。

組織全体でデータ、アプリケーション、API、デバイスを接続すると、さまざまなシステムの機能を接続し、これらの機能を技術スタック全体で (理想的には) シームレスに使用できるようになります。

適切に構築された統合の利点

統合がうまく機能すると、組織に次のような多くのメリットがもたらされます。

エラーメッセージの改善:

優れた API を使用すると、問題が発生したときにユーザーが明確で明確に定義されたエラー メッセージ (単なる漠然としたエラー コードではなく) を確認できるようになります。統合は常に変化しています。障害コードの意味や、統合のどこで障害が発生したかを知ることは、問題解決にとって非常に重要です。最適に構築された統合により、障害が効果的かつ簡潔に伝達されるため、ユーザーはより迅速に解決策に到達したり、問題を自分で修正したりトラブルシューティングしたりできるようになります。

シームレスな情報転送:

適切に構築された統合により、2 つのアプリケーションが相互にスムーズに通信できるようになります。 「適切に構築されている」とは、情報が期待どおりに提供され、適切に機能するためにマッピングや構成がほとんどまたはまったく必要とされないことを意味します。適切に構築された統合では、ユーザーが 2 つのアプリケーションを接続するだけで作業を継続できるように、面倒な作業がすべて行われます。

唯一の真実の情報源:

このバズフレーズは最近のテクノロジー アプリの間であまりにも一般的ですが、適切に統合すれば、実際に真実になります。非常に多くの異なる製品がビジネスの兵器庫を構成することが多いため、優れた統合 (または一連の統合) により、ユーザーはすべての主要なアプリケーションから情報を取得し、それをより少ない (または 1 つの!) 場所で操作できるようになります。

慎重に構築された統合により、すべてのプラットフォームにわたる情報の同期、正確さ、一貫性が確保されます。古いデータや不正確なデータは、どの企業にとっても深刻な問題を引き起こす可能性があります。

不適切に構築された統合の落とし穴

統合がうまく機能しない場合、複数の部門にわたって深刻な問題が発生する可能性があります。統合に関する一般的な問題点には次のようなものがあります。

統合に関する一般的な問題点には次のようなものがあります。

データロス：

必要なすべての情報が統合を通じて取得されない場合があります。情報転送のプロセス中に、特定のフィールドが欠落していたり、互換性がなかったり、誤変換されたりする可能性があります。

また、ユーザーが経験が浅い、または統合の設定方法に慣れていない場合、1 つのアプリケーションで間違いを犯すと、誤ったデータや問題が統合アプリケーションにエクスポートされる可能性があります。すべての統合が正しくマッピングされていることを確認し、適切なチームメイトが情報の転送の仕組みを理解していることを確認することが重要です。

レイテンシとパフォーマンスの問題:

API 呼び出しの追加 (ほとんどの企業が統合を構築する方法) では、応答パスに余分なステップが追加され、アプリのパフォーマンスが低下する可能性があります。また、正しく構成されていない場合、次のような問題が発生する可能性があります。 単一障害点あなたのシステムで。多くのアプリケーションは、スケーラビリティや適応性を念頭に置いて統合を構築していないため、統合しているアプリケーションが変更されると、システム全体に障害が発生し、再マップまたは再構築が必要になる可能性があります。

考えられる問題のもう 1 つの例は、「無限積分ループ」です。一部のサードパーティ統合ソリューションは自動化上で実行されており、あるプラットフォームでフィールドが更新され、別のプラットフォームで同じフィールドが更新されると、相互に競合し、情報が「行き来」する可能性があります。誰が最終的な真実の情報源であるかについてシステムが互いに争い始め、自動化が互いに何度も何度もトリガーされるため、「無限ループ」が発生し、これはすぐに混乱する可能性があります。

不幸な顧客

シームレスで信頼できる統合を約束されたのに、期待どおりに機能しないことが判明することほど、顧客にとって動揺することはありません。さらに悪いことに、一部の顧客は、デモプロセス中に包括的または有望な統合を売り込まれ、ソフトウェアを購入した後、大規模なマッピングや再プログラミングを行わないと統合がほとんど機能しないか、または自分たちのユースケースに適合しないことがわかります。多くの場合、状況はさらに悪くなり、行き止まりになってしまいます。必要なフィールドが利用できないか、必要な機能が「高度すぎる」ためにサポートされていません。

ワークフローをより効率的かつ正確にするという約束に騙されて、それが不安定だったり設定が難しかったりすると、誰の口にも後味が悪くなる可能性があります。また、信頼の喪失や顧客離れの主な原因となる可能性もあります。

統合第一の考え方で構築する

いくつかのアプリケーション、例えばバイザーは、初日から統合を念頭に置いて構築されました。多くのアプリケーションはユーザーの興味を引くために光沢のある UI に重点を置いていますが、Visor 「ボンネットの下」に行った初め。

たとえば、他のアプリケーションでは、統合を設定するときにフィールド マッピングが必要です。他のアプリがフィールドのマッピングを要求する場合、それは基本的に統合インスタンスの構成情報です。ただし、すべてが正しくマッピングされ、必要に応じてルールと自動化が適用され、可能な場合は再構築されるように、統合を設定するユーザーに重点が置かれます。

Visor は、ユーザーが統合セットアップの負担を軽減して、価値をより早く得られるようにしたいと考えていました。フィールドに関するメタデータを使用し、それをすべてのアプリで統一した方法で保存することで、Visor がバックエンドでフィールド マッピングを処理できるようになりました。そのため、ユーザーは統合アプリと表示したいフィールドを選択するだけで作業を開始できます。 「私たちはサービスが提供するメタ情報を標準化し、それをプラットフォームに依存しない 1 つの形式にしました。 Visor 内のコードは、ユーザーが間違いを少なくする方法でフィールドを表示する方法を知っています」と Visor のプリンシパル エンジニア、パトリック シャンリーは述べています。

バイザー統合アプリケーションによって設定されたルールに従う方法を知ることで、より迅速に価値を提供します。たとえば、Jira でその人が参加していないプロジェクトにその人を割り当てることはできません。また、読み取り専用フィールドに書き込みを試みることもできません。また、連絡先 ID など、データ内に数値 ID として存在する値は、ユーザーフレンドリーで読みやすい形式に変換されます。

うまくやろう、正しくやろう

ほぼすべてのSaaS アプリは、何らかの形で統合を提供することに誇りを持っています。すべての企業が「真実の情報源」または情報の一元化を目指しているため、統合がいつ適切に構築され、いつ後付けで製品に追加されたのかを知るのは困難です。ただし、すべての統合が同じように作成されているわけではありません。十分な統合を操作すると、どの統合が「チェックボックスをオンにする」だけで、どの統合がユーザーを念頭に置いて構築された包括的なソリューションであるかが簡単にわかります。