アーキテクチャ設計の概念と原則はSaaSの核心です

著者: アン・ジンボ

編集者: 千山

この記事は、WOT2023 カンファレンスにおける Tianrun Rongtong CTO An Jingbo 氏の基調講演からまとめたものです。さらにエキサイティングなコンテンツやライブPPTについては、51CTO Technology Stack公式アカウントをフォローし、[WOT2023PPT]にメッセージを送信して直接受け取ってください。

最近、51CTOが主催したWOTグローバルテクノロジーイノベーションカンファレンスで、Tianrun RongtongのCTOであるAn Jingboが「オムニチャネルインテリジェントカスタマーコンタクトプラットフォームの技術アーキテクチャの課題と進化」と題する基調講演を行い、一般の人々に新たな視点を提示しました。

近年、天潤栄通の事業はコールセンター中心の事業からオムニチャネルコンタクトプラットフォームへと進化し、AI技術との統合を徐々に進め、企業が効率的でインテリジェントな管理への移行を加速できるよう支援しています。このプロセスは、製品機能の追加だけでなく、ビジネスモデルの変革や技術アーキテクチャのアップグレードも含まれます。 An Jingbo 氏は、Tianrun Rongtong が開発中にビジネス ニーズに基づいて技術アーキテクチャをどのように繰り返していったかを詳しく説明しました。

この記事では、素晴らしいコンテンツのいくつかを選択し、統一された方法で整理して、皆さんにインスピレーションを与えたいと思います。

1. 17年間の開発プロセスにおける4回の改革

2006 年に設立された Tianrun Rongtong は、常にコンタクト センター事業に重点を置いてきました。初期のコールセンターであれ、現在のオムニチャネルおよびフルサイクルのコンタクトセンター事業であれ、天潤栄通は 17 年間にわたり顧客コンタクト シナリオ向けのサービスを提供することに尽力しており、開発プロセス全体を通じて 4 回のアーキテクチャ再構築を実施してきました。

フェーズ 1: 2006 ～ 2012 年、ソフト スイッチ + コール センター。このフェーズでは、主に大規模かつ柔軟に音声サービスを処理する能力を備えた大規模音声交換プラットフォームの開発と商用化が完了しました。同時に、複雑なコールセンターの製品進化のための強固なプラットフォーム基盤を確立しました。

フェーズ 2: 2013 ～ 2016 年、クラウド ネイティブの再構築。クラウド技術を核として、プラットフォームは徹底的にネイティブに変革され、アーキテクチャの観点から大容量での高可用性を実現し、容量のボトルネックを完全に打破しました。リモートおよびクロスクラウドのアクティブ/アクティブ機能を備えたプラットフォームがリリースされ、急速な進化と安定した運用の矛盾が解決されました。

フェーズ 3: 2017 ～ 2022 年、オムニチャネル + インテリジェンス。音声コールセンターから、完全なオムニチャネルカバレッジ機能を備えたオムニチャネルコンタクトセンターにアップグレードされました。ディープラーニングベースの AI テクノロジーを使用してプラットフォームをインテリジェントなものに変え、完全な AI 製品システムを構築します。

フェーズ4：2023年から現在まで、AIネイティブ再構築。 AI技術を中核とし、企業知識管理を基盤として、「人間と機械の融合」による新世代の顧客コンタクトプラットフォームを構築します。当社は業界で初めて「顧客コンタクト垂直シナリオ」に基づく大規模言語モデル産業ソリューションをリリースし、同時に一連のAI製品をリリースしました。

2018 年以前、Tianrun Rongtong は中国最大のパブリック クラウド顧客コンタクト ソリューション プロバイダーとなっていました。これを実現できる主な理由は、Tianrun Rongtong がコールセンター クラウド サービスが何であるかを正確に定義しているからだと思います。決め手は以下の3点です。

クラウドネイティブのコアソフトウェア。簡単に言えば、ソフトウェア アーキテクチャ + クラウドに基づいています。

クラウドネットワーク統合サービスベアラネットワーク。顧客とのコンタクトのシナリオでは、音声などのサービスはリアルタイムかつ高可用性である必要があります。ネットワーク ノードのいずれかに問題がある場合、ソフトウェアは役に立たなくなります。したがって、クラウドネットワーク統合ビジネスベアラネットワークをどのように構築するかが、製品の中核的なアーキテクチャ上の課題の 1 つです。

世界中で利用可能なクラウド エコシステム。ソフトウェア、ネットワークなどの問題に加えて、通信リソースをどのようにスケジュールするか、エコシステムを使用して高可用性の問題を解決する方法も重要です。

2018年以前は、この3点が仕事の核であることを明確に認識しており、すべての仕事はこの3つの主要なラインを中心に展開されていました。これをもとに、お客様からも高い評価をいただいております。

将来を見据えると、インテリジェンスがコンタクト センターの中核となると考えています。私たちは、AIとビッグモデルを活用してCloud Contactのアーキテクチャを再構築し、リアルタイムSaaS、ビジネスSaaS、人工知能の完璧な統合を実現したいと考えています。

II.事業開発中に遭遇した課題と対応

次に、ビジネス開発プロセス全体で遭遇する課題を包括的に見ていきましょう。 3つの主な問題点をまとめました。

1. 大容量、高可用性、リアルタイムの SaaS システムを実装する方法。
2. リアルタイム SaaS と複雑性の高いビジネス SaaS という 2 つの次元の重なりにどう対処するか。
3. AI 機能をコンタクト センターのシナリオに深く統合する方法。

1. 大容量かつ高可用性のリアルタイムSaaSプラットフォームを実装する方法

それは、エンドツーエンドと完全なクラウドベースのフルリンク高可用性アーキテクチャという 2 つのポイントに要約できます。

いわゆる「エンドツーエンドのフルクラウド」とは、コールセンタークラウドサービスがフルリンクであるということを簡単に説明できます。エンドツーエンドには、システム ソフトウェア、クラウド プラットフォームの展開、ネットワーク アクセス、エージェント側機器、通信リソースの統合の 5 つのレベルが含まれます。いずれかのリンクに問題がある場合、顧客はプラットフォームを使用できなくなります。

写真

ご覧のとおり、チェーン全体は比較的長いため、このような問題を解決するには、エンドツーエンドおよびグローバル構造を考慮する必要があります。

高可用性に関しては、ソフトウェア アーキテクチャの高可用性、クラウド サービスの高可用性、インフラストラクチャの高可用性、通信リソースの高可用性、ネットワーク アーキテクチャの高可用性、持続可能な進化という 6 つの側面を考慮する必要があります。 SaaS サービスの核となる精神は、革新と急速な進化の能力だからです。このイノベーションは、顧客のビジネス イノベーションに貢献できるものでなければなりません。この能力が失われると、プラットフォームは「死んで」しまいます。 SaaS ソフトウェアでは、安定したサービスを提供しながら迅速なアップグレードを実現する方法が重要です。

「高可用性」の中核となる要素について簡単に説明しましょう。

ソフトウェアの高可用性: 分離、クラスタリング、ネイティブ クラウド コンポーネントを最大限に活用し、測定可能な操作を行うことで、ソフトウェアの高可用性を実現します。さらに、アーキテクチャは階層化されており、基盤となる通信をアプリケーションから分離します。

クラウドネットワーク統合型高可用性: 多数のクラウドのサポートに基づいて、クロスクラウドおよびマルチクラウドアーキテクチャを採用しています。北京、上海、深センのコアネットワークには、それぞれ 2 つのコア コンピュータ ルームがあります。 6つのコアコンピュータ室は南リングと北リングを形成し、リング間は光ファイバーで接続され、高い可用性を実現しています。

写真

高可用性通信リソース: 通信リソース機能をクラウド化してプールすることで、障害や輻輳に対処するために、ビジネスの変化に応じてコールディスパッチシステムを柔軟に調整できます。

高可用性の進化型アーキテクチャ: 統合された設計、開発、テスト、運用、保守を実現するための DevOps 組織構造をサポートします。主要アプリケーションのグレースケールリリース（2 つのグレースケール レベル）建設の自動化をサポートします。

2. リアルタイムSaaSと複雑性の高いビジネスSaaSの重なりにどう対処するか

リアルタイム性をしっかり確保しつつ、同時にビジネス拡大に臨むとき、ビジネスSaaSの高度に複雑化した重なりの問題をどう解決するか？これに対処するには 3 つの戦略があります。

1) さまざまなビジネスを効果的に分類して分離し、さまざまな原則を適用します。

具体的には、業務分類の観点から、リアルタイム系と業務系に分類されます。リアルタイム システムには、通信プラットフォーム、コール センター、RTC オーディオとビデオ、ロボットなどが含まれますが、これらはすべて数秒または数ミリ秒単位での応答を必要とします。比較すると、CRM/SCRM、作業指示書、ナレッジ ベースなどのビジネス システムは、ビジネスの複雑さと理解をテストします。これら 2 つには異なるアーキテクチャ原則を適用する必要があり、最終的な組織構造もアーキテクチャ原則と一致する必要があります。

2) SaaSビジネスの基本フレームワークを構築し、再利用効率を向上する。

すべての新規ビジネスは試行錯誤から始まりますが、いくつかの基本モジュールのサポートがなければ、試行錯誤のコストは非常に高くなります。そのため、企業レベルでインフラとして基本的かつ再利用可能なものを構築する必要があります。

SaaS ビジネスを構築するための基本的なフレームワークは、大まかに 7 つのカテゴリに分類できます。RAM (統一されたユーザー権限システム)、ビジネス支援システム「BOSS」ワークスペース ワークベンチ フレームワークとマイクロ フロントエンド コンテナー。レポートを最初から作成する必要がないようにする基本的なレポート エンジン。ローコードエンジン、統一されたUI仕様などのフロントエンドの再利用可能な構造。運用監視システム;セキュリティ管理システム。一般的に、十分な数のビジネスがある場合、この種の基本的なフレームワークにより、新しいアプリケーションを迅速かつ効率的に統合できます。

3) 競争障壁を構築するためのSaaSビジネスのPaaSアーキテクチャ。

一部の SaaS ビジネスを PaaS に変換することの中心的な価値は、企業が配信効率を向上できることです。これに関するいくつかの洞察は次のとおりです。

• 2Cと比較して、2B製品はPaaSに適しています
• 「PaaS は大企業しかできない」というのは、実は本末転倒です。つまり、抽象化・要約する力があるからこそ、PaaS をやることで大企業になれるのです。
• 顧客ビジネスの多様性にあまり関係のないものを選択し、PaaSにする
• PaaS の洞察は、現場のニーズを蓄積し抽象化した産物である SaaS から生まれます。そのためには、顧客と長期にわたってコンタクトを取り、顧客の根本的なニーズを理解し、変化する部分と変わらない部分に対する洞察力を獲得することが必要です。
• PaaS の価値は最終的なサービスである SaaS に反映されます。最終的には、PaaS の有効性は SaaS ビジネスのパフォーマンスによって評価される必要があります。
• PaaSは主要顧客を支援するためにエクスポートすることもできる

3. AI機能をコンタクトセンターのシナリオに深く統合する方法

深い統合を理解するにはどうすればよいでしょうか?コンタクトセンターにおける AI の応用は、単に音声ロボットやテキストロボットを作成することではなく、業務フローとビジネスプロセス全体のすべてのステップを AI 化するものと理解する必要があります。コールセンターを例に挙げてみましょう。着信、キューイングの方法、待ち時間の予測、通話接続後の感情認識と顧客ラベルプロファイリングの方法、通話終了後の満足度調査の実施方法、そして最終的な分析に至るまで、プロセスのすべてのステップをインテリジェントにする必要があります。これは、クラウド コンタクト センターにインテリジェンスを統合して、人間と機械の真の統合を実現するという当社の考えです。

写真

3. ビジネス組織と技術アーキテクチャの原則

以下では、実践中にまとめたビジネス アーキテクチャと技術アーキテクチャの原則をいくつか紹介します。

1. マッチングの原則。

• 技術アーキテクチャはビジネスに役立つものでなければなりません。
• さまざまなビジネス フォームは、さまざまな技術アーキテクチャに適しています。たとえば、リアルタイム サービスと非リアルタイム サービスは明らかに異なります。
• 段階に応じて異なるアーキテクチャを適用する必要があります。スタートアップ段階に適しているものは何ですか?急速な発展段階に適しているものは何ですか?私たちは状況に適応しなければなりません。

2. 安定性と革新性を組み合わせる。

• 事業継続性の分類と分離

プラットフォームは、安定したプラットフォームと革新的なプラットフォームに分ける必要があります。安定したプラットフォームは主要な顧客を運び、革新的なプラットフォームは頻繁にニーズを持つ顧客を運びます。顧客が変わったときにすぐに調整できる、CICD コンセプトに似た継続的な分類の標準とツールを確立する必要があります。

• アーキテクチャの分離には明確な目標がある

明確な目標は次のとおりです。各アプリケーションは独立してリリースおよびアップグレードされます。リソースは独立して展開され、アプリケーションは互いの安定性に影響を与えないように互いに分離されます。各アプリケーション チームは独立して作業し、API を通じて効率的に連携します。

• コンポーネントは疎結合、密結合、不整合がある

複数のアプリケーション間で低結合相互作用の原理が採用されています。アプリケーションは API インターフェースを通じてのみ対話し、独立してリリースされます。製品の固有の機能コンポーネントは低結合であり、顧客への最終プレゼンテーションでは製品設計を密結合する必要があります。内部と外部の一貫性を保つために、優れた建築家は、外部の統合されたプレゼンテーションを明確な境界を持つモジュールに分解して抽象化する必要があります。

3. 顧客中心主義。

• グレースケール原理

プラットフォームグレースケール原則に従って、すべての新しいバージョンは最初にイノベーションプラットフォームでリリースされ、その後、軽微な問題が修正された後に安定したプラットフォームがアップグレードされます。顧客グレースケール原則に従い、単一の顧客によって提起されたニーズについては、他の顧客に影響を与える変更を回避するために、単一の顧客に対してグレースケールで開発およびリリースされます。複数のプラットフォームにおける顧客モビリティの原則によれば、顧客の安定的かつ革新的なニーズは変化しやすく、プラットフォーム上の顧客を定期的かつ動的に調整してバランスをとるために、顧客に依存しない移行ソリューションが必要です。

• クイックフォールバック原則

問題が発生した場合は、それが単一の顧客の問題であるかどうかを判断します。問題がグローバルなものであり、ある種類の顧客の 10% 以上に影響している場合、または複数の主要顧客に影響している場合は、すぐにロールバックして問題を分析して解決します。要求の緊急度は常に障害の緊急度よりも低く、問題が修復され、正午またはその日の夕方にシステムがオンラインに戻るようにします。

• APIインターフェースの原則

API インターフェースがリリースされると、インターフェース定義と戻り値は削除または変更できなくなります。パラメータと戻り値は互換性のある方法でのみ追加できます。 API インターフェースの実装ワークロードは、ビジネス統合に必要なワークロードよりもはるかに小さくなるはずです。インターフェース設計は建築家の主な仕事であり、建築的思考の具体化でなければなりません。

4. SaaS技術アーキテクチャのビッグモデル再構築の展望

これまで、天潤栄通はAIを中核として、アクセスチャネルやマーケティングサービスのビジネスシナリオなど、いくつかのアプリケーションを統合してきました。当社は今年初めから、2023年をビッグモデルを用いてコンタクトセンターのアーキテクチャを再構築する最初の年と位置付けています。ここで少し紹介と展望を述べたいと思います。

写真

現在、ChatGPT、Wenxin Yiyan、Tongyi QianwenなどのLLMの機能を統合し、コーパス拡張、知識抽出、ドキュメント質疑応答エンジンなどの機能をリリースしています。さらに、音声最適化や雑談などの機能もテスト中です。

一般的に、ビッグモデルはクラウドコンタクト SaaS シナリオに大きな影響を与えます。お客様は大型モデルに対して非常に高い期待を抱いており、当社に対しても多くの期待を寄せています。もちろん、機械が大規模に人間の労働に取って代わると、予測できない破壊的な変化がもたらされるのではないかと不安に思う人もいるかもしれません。しかし、私たちは、その逆ではなく、顧客のニーズに焦点を当て、顧客の行動に近い組織が変革を成功させることができると信じています。

V. 結論

今日のスピーチの重要な点を要約します。

1. アーキテクチャ設計の概念と原則は、SaaS の核となるものです。
2. プラットフォームの安定性とイノベーションの矛盾をバランスさせるには、ビジネスを分類して分離する必要があります。
3. SaaSビジネスの基本フレームワークを構築し、再利用効率を向上します。
4. PaaS アーキテクチャを通じて競争上の障壁を構築します。

優れた技術アーキテクチャは進化すると信じています。これは、すべての落とし穴に再び落ちなければならないという意味ではありません。私は長年にわたり、あらゆる落とし穴に落ち込み、絶えずそこから這い上がってきました。今日の共有は、いくつかの落とし穴を避けるのに役立ちます。あるいは、次のステップに進む準備ができ、これが落とし穴だと感じた場合は、心を開いて他の人ともっとコミュニケーションを取り、そのコミュニケーションを利用してアーキテクチャの特定の側面に対する理解を加速することができます。