BluLogix CIS：ETL で Salesforce と繋がるテレコム請求

ホワイトボードでは簡単に見えて、実際には一年間毎週何かを教えてくれるインテグレーション問題の特定のカテゴリがある。BluLogix での CIS-to-Salesforce インテグレーションがそれだった。

BluLogix は Cloud Innovation Suite (CIS)—テレコムオペレーター向けのクラウド請求プラットフォームを構築する。一般的な SaaS 請求じゃない。テレコム請求に特化したもの：使用量ベースの課金、プラン階層、プロモーション価格設定、バンドル管理、サイクル途中での調整、日割り請求書。この請求の複雑さは、その中にいた人だけが完全に理解できる。2013年から2014年にかけてフロントエンド側のチームリード兼開発者として、そして Salesforce インテグレーション作業をリードした。

テレコム請求が独自のドメインである理由

テレコム請求は一般請求を単純化したバージョンじゃない。独自のデータモデルを持つ独自の規律だ。

テレコムオペレーターの請求システムはイベントレベルで使用量—通話、データ、SMS—を追跡し、それらのイベントをプランの権利に対して集計し、階層化とプロモーション料率を適用し、請求書を生成し、クレジットと調整を処理し、支払いサイクルを管理し、テレコムオペレーターが提出を義務付けられた規制報告を生成する。これがスケールで、継続的に、ネットワーク上のすべての加入者に対して行われる。

データモデルはその複雑さを反映している。加入者はサービスプロファイルを持っている。サービスプロファイルには一つ以上のプランがある。各プランには権利、超過分、プロモーション修飾子がある。使用量イベントは継続的に到着し、発生した期間の正しいプランバージョンに対して料率設定されなければならない—加入者がサイクル途中でプランを変更したかもしれないし、オペレーターがプランの条件を変更したかもしれないので、過去の料率設定が正しくなければならない。

これが CIS のドメインだ。このドメインを深く知っている。問題は CRM システム—特に Salesforce—が全く異なるドメインを知っているということだ。

非互換データモデルの問題

Salesforce は CRM オブジェクトモデルを中心に構築されている：アカウント、コンタクト、商談、リード、ケース。顧客とディールとサポートチケットについて知っている。加入者とサービスプロファイルと使用量イベントと料率設定サイクルについては知らない。

インテグレーション要件は本物だった：CIS を使用しているテレコムオペレーターは販売とサポート業務に Salesforce も使用していた。CIS の加入者には Salesforce の対応するアカウントがあった。サポートチームが Salesforce で開始した CIS プラン変更は、サポートエージェントが CIS に別途ログインすることなく CIS に流れる必要があった。請求履歴は別ログインなしで Salesforce インターフェース内から見える必要があった。

これらは合理的な製品要件だ。実際には、同時に両方向でのデータモデル変換問題でもある。

Talend ETL：実際にリリースされたインテグレーションレイヤー

アプローチは Talend ETL—エンタープライズ ETL プラットフォーム—を CIS と Salesforce の間のインテグレーションレイヤーとして使うことだった。直接 API インテグレーションでも、カスタムミドルウェアサービスでもなく、変換責任を明示的に所有する専用の ETL ジョブオーケストレーションレイヤーだ。

これは振り返ると完全に明確になったいくつかの理由から正しい呼びかけだった。

変換はステートフルだ。 CIS 加入者を Salesforce アカウントにマッピングすることは一度きりの変換じゃない。継続的な同期だ。変更は両方向に流れる。ETL レイヤーは同期状態を追跡し、コンフリクトを処理し、何が同期されたかの履歴を管理する—これは CIS 請求エンジンや Salesforce org がやるべき仕事とは違う。

障害モードが違う。 2つの本番システム間の直接 API インテグレーションはその障害モードを結合する：Salesforce の API が遅ければ CIS も遅くなるか？CIS イベントのプッシュが失敗すると、Salesforce のサポートエージェントは古いデータを見るかエラーを見るか？ETL レイヤーはそれらの障害ドメインを切り離す。CIS が動く、Salesforce が動く、ETL レイヤーがギャップを処理する。

ビジネスルールが一か所に住む。 CIS サービスプロファイルから Salesforce アカウントフィールドへのマッピングはビジネスルールだ。プランステータスから商談ステージへのマッピングもそうだ。これらのルールが両システムに散らばるのではなく ETL ジョブ設定に住むことで、監査可能で、テスト可能で、どちらの本番システムにも触れずに変更可能になった。

BPMN ワークフロー設計

請求ワークフローとインテグレーションワークフローは BPMN—ビジネスプロセスモデルと表記法—でモデル化された。後付けのドキュメントとしてではなく、ワークフローエンジンが実行する仕様として。

この区別は重要だ。ドキュメントとしての BPMN は描かれた日に正確で、その後現実と乖離していく図だ。実行としての BPMN はシステムが何をするかの権威ある定義だ。テレコムオペレーターのセールスチームがプラン変更がなぜまだ Salesforce に伝播していないのかを理解したいとき、答えはワークフローのどこにジョブがあるか、どの条件を待っているか、次のステップが何かを正確に示す BPMN 図だった。

インテグレーション側の BPMN ワークフロー設計をリードした。課題は、テレコム請求ワークフローが自然なタイミング依存性を持つ—請求サイクルが閉じる前に請求書データで Salesforce を更新できない—ことで、これをスリープタイマーや cron スケジュールではなく、ワークフローモデルの明示的な待機条件として表現しなければならなかった。違いは BPMN ワークフローがなぜ待っているかを知っていて、条件が解決されたときにタイマーが発火するまでポーリングする代わりに正しく応答できることだ。

フロントエンド：2013年の GWT

CIS フロントエンドは GWT—Google Web Toolkit—の上に構築されていた、Java を JavaScript にコンパイルする。2013年にこれは大規模なエンタープライズデータアプリケーションの合理的なアーキテクチャの選択だった。多くの貢献者がいる大きなコードベース全体で Java が提供する型安全性は些細じゃない。コンポーネントモデルは成熟していた。デバッグツールは当時の JavaScript エコシステムの代替手段より優れていた。

また2026年においては、決定的に時代遅れになった技術の選択でもある。ウェブプラットフォームは動いた。JavaScript フレームワークは GWT のトレードオフを不要にするパターンに収束した。正直に述べる—なぜなら作業の誠実な会計の一部だから：GWT で重要な UI を構築し、GWT 開発をするチームをリードした、そして2013年にその選択が意味をなした理由と今はしない理由を正確に言える。

フロントエンド開発チームの監督とリードをした—コードレビュー、アーキテクチャ決断、リリースするチームとマージされないプルリクエストを生成するチームの違いを生むタスクレベルの調整。これが本物のチームリードの役割での最初の経験で、そこからのレッスン（チームレベルでの技術的決断について、何かのやり方を知ることと学んでいる人にそれを説明する方法を知ることのギャップについて）はそれ以降のすべての役割で続いている。

入る前に自分に言いたかったこと

二つのエンタープライズシステム間の非互換データモデル問題は、どちらのシステムをより柔軟にすることでほとんど解決されない。変換レイヤーを明示的に所有し、正しい責任を与え、どちらの側もお互いのモデルが存在しないふりをしないことで解決される。

Talend ETL レイヤーがうまくいったのは、変換の仕事を仕事として真剣に受け止めたからだ—既存の API にボルトで取り付けられた薄いアダプターとしてではなく。独自の状態を持っていた。独自の障害処理を持っていた。CIS の世界と Salesforce の世界の間のギャップに責任があり、その責任を明確に知っていた。

そのモデル—境界を所有し、境界が実際よりも薄いふりをしない—は、それ以来のすべてのインテグレーション問題で手を伸ばしてきたものだ。ツールは違う、洞察は同じ。