Salesforceプロジェクトの発見と変換フェーズにおいて、統合アーキテクトは、高レベルのビジネス目標にとどまらず、データ交換の技術的な「DNA」を定義する必要があります。組織の準備状況とユーザーエクスペリエンスはプロジェクトの成功に不可欠ですが、システム間でデータを移動するために必要なアーキテクチャパターンを決定づけるものではありません。
統合アーキテクチャを設計する上で最も重要な詳細は、タイミングとボリュームの要件です。
ビジネスプロセスが同期か非同期かを判断することが、最も重要な判断ポイントです。例えば、Salesforceユーザーがレコードを保存する前に外部システムからの即時検証が必要な場合は、Apexコールアウトを使用した同期の「リクエスト・リプライ」パターンが必要です。一方、データ更新がユーザーの操作を妨げずにバックグラウンドで実行できる場合は、システムパフォーマンスとユーザーエクスペリエンスを向上させるために、非同期の「ファイア・アンド・フォーゲット」パターンが推奨されます。
さらに、更新頻度（例：リアルタイム、毎時、夜間）とデータ量（例：100件レコード vs. 100万レコード）を理解することで、アーキテクトは適切なSalesforce APIを選択できます。大量で低頻度の更新は、API制限の消費を最小限に抑えるためにBulk APIが最適ですが、少量で高頻度の更新にはREST APIまたはストリーミングAPIが適しています。これらのタイミングと頻度の側面を具体的に検討することで、アーキテクトは選択したソリューションがスケーラブルであり、プラットフォームガバナ制限内に収まり、ビジネスのサービスレベル契約（SLA）を満たすことを保証します。これらの詳細を把握しないと、ビジネスニーズに対して遅すぎるソリューションや、システムリソースに過度の負担をかけるソリューションを設計してしまうリスクがあります。

https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/using_streaming_api_durability.htm

説明
ミドルウェアはリクエストの配信と支払い処理を調整し、支払いシステムは支払いリクエストを一度だけ処理する必要があります。このソリューションにより、各支払いリクエストが信頼性と一貫性をもって支払いシステムに配信され、同じ支払いリクエストレコードへの重複した更新や競合が回避されます。ミドルウェアは、データエントリポイントと支払いシステム間の仲介役として機能し、エラー、再試行、確認を処理するロジックを実装できます。支払いシステムは、グローバル一意識別子を使用して、支払いリクエストが既に処理されているかどうかを確認し、再処理を回避できます。
参考資料: 認定 - 統合アーキテクト - Trailhead、[統合パターンとプラクティス]

Salesforceを導入して顧客の360度ビューを実現する場合、プラットフォームは従来の
CRMのコア機能を実行する「サイロ化された」アプリケーション。提示されたビジネス目標に基づき、Salesforceはマーケティング、営業、サービスにおけるマスターとなります。
廃止されるシステムは、機能がネイティブに Salesforce に組み込まれているシステムです。
* 電子メール マーケティング: Salesforce Marketing Cloud またはネイティブ マーケティング機能に置き換えられました。
* 営業アクティビティ: リード管理、商談追跡、アクティビティ ログ記録を熟知した Sales Cloud に置き換えられました。
* ケース管理: 顧客サポート エージェントが問い合わせを解決するためのツールを提供する Service Cloud に置き換えられました。
注文管理と見積は、企業が再利用したい「エンタープライズ機能」として明確に記載されています。つまり、これらのシステムは廃止されるのではなく、既存のシステムのままSalesforceと統合されます。したがって、「注文管理」を含む選択肢（AとC）は誤りです。マーケティング、営業活動、サービスシステムを廃止することで、組織は顧客データを単一のプラットフォームに統合し、Salesforceへの移行という主要な目標を達成できます。

接続アプリケーションは、APIやOAuthなどの標準プロトコルを使用して外部アプリケーションをSalesforceと連携させるフレームワークです。Salesforceで接続アプリケーションを設定することで、連携時にミドルウェアを認証し、Salesforceのデータとサービスへのアクセスを許可できます。これは、リモートサイト設定、APIゲートウェイ、ファイアウォール、リバースプロキシの設定を必要としない、安全で柔軟なソリューションです。2 参考文献：1: BatchApexErrorEvent 2: 接続アプリケーション