Center-outビジネスアーキテクチャ

ソフトウェアアーキテクチャは、アプリケーションに必要な重要かつハイレベルなコンポーネントの概要を示します。 アーキテクチャは、アプリケーションコンポーネント間の依存関係と相互作用についても説明します。 正しいアーキテクチャを選ぶことで、アプリケーションに必要なスピードとスケーラビリティの実現に役立ちます。

リードシステムアーキテクト（LSA）は、広く焦点を当てたアーキテクチャを定義して、ビジネス上の課題に対するビジネスソリューションを提供する必要があります。 一般的に、ソフトウェアアーキテクチャは、次の図に示すように、3つのレイヤーからなります。

PegaアプリケーションのCenter-out™ビジネスアーキテクチャは、顧客とビジネスに成果をもたらすために、細かく調整されたソフトウェアアーキテクチャです。 トップダウン型とボトムアップ型アプローチの失敗を避けることで、有意義な結果をすばやくもたらし、将来にわたってアーキテクチャを維持できます。

トップダウン型アプローチは、インタラクションのチャネルに特化したアプリケーションをデザインします。 トップダウン型アプローチの最も重大な短所の1つは、チャネル全体で一貫したエクスペリエンスを提供するために、同じプレゼンテーションレイヤーロジックを複数回実行することです。

ボトムアップ型アプローチは、プロダクト中心の実装をデザインします。 ボトムアップ型に潜むリスクは、それぞれのシステムがそのアプリケーションが使用するデータしか把握できないことです。 サイロ化されたレガシーシステムでは、他のシステムに保管されているデータとの重複が起こりがちです。 同じデータが複数のシステムに存在することになります。 また、単一の事業体（顧客）が様々なシステムを使用している場合は、一つのソリューションでは、事業体全体を一目で把握できません。

Center-outアプローチは、ビジネスとITをまとめて、ビジネス成果に焦点を合わせ、ソリューションを迅速に革新します。 チームは、数週間または数日でエンタープライズクラスのソリューションをデプロイでき、基盤となるデザイン思考のベストプラクティスを使用して、共有のローコードプラットフォームでコラボレーションできます。

Center-outアプローチは、

• Microjourney™の目的に焦点をあてます
• チャネルとのエンゲージメントにステップの完了が必要な時を特定
• ステップの完了に必要なデータ、更新されるデータを特定

実装を完了するためには以下ではなく、「チャネルをアクティブ化」して「データソースに接続」するPegaのモデルベースの設定タスクが必要です。

1. 「ウェブソリューションの開発」は、どのようにして同じソリューションがモバイルアプリやチャットボットとして展開されているか、APIを使用して別のアプリケーションのコンポーネントとして使用されているかを考えても、すぐに失敗することが分かります。
2. 「新しいSAPモジュールの実装」は、SAPを使用している事業部門のみに限定され、かつエンタープライズから利用されるデータについて見解が狭まる可能性があります。

Pegaアプリケーションのデザインは、Center-outアプローチから始まります。 このアーキテクチャの5つのステップは、エンタープライズの顧客と成果を中心に構成されています。

1. 「頭脳」から始める – インテリジェンスを中心に管理する：ビジネス成果は、リアルタイムの顧客情報によって導かれるべきです。また、ルールの一貫性が確保され、正確なアクションが推奨されます。
2. 仕事をこなす – 成果にフォーカスし、プロセスを調整する：特定の成果に関係しているカスタマージャーニーの一環として実行するMicrojourneyアプローチを適用することで、仕事を管理、自動化、向上するためのケースマネジメントを使用します。
3. チャネルをつなげる – 一貫したエクスペリエンス： PegaのデジタルエクスペリエンスAPIを使用して、フロントエンドロジックとバックエンドロジックの調和を保ちます。 新たなコーディングなしで、変更が動的に反映されます。
4. データに接続する – ロジックの俊敏性を保つ：バックエンドシステムに接続し、複雑せずに、重要なデータを引き出します。 仮想化レイヤーは、Pegaのライブデータと呼ばれています。 Pegaのライブデータにより、ユーザーは、データの保存場所やアクセス方法を心配することなく、ニーズに合ったアプリケーションを構築するために必要なデータをすばやく簡単に定義でき、実行中のアプリケーションでそのデータにアクセスできるようになります。
5. 拡大に備える – バリエーションを管理する：PegaのSituational Layer Cake™により、顧客タイプ、ビジネスライン、地域などに応じてMicrojourneyを適応させることができます。 まずは、小規模から迅速に始めましょう。 それから大規模かつ広範囲に拡張して、将来性を確保します。

Front Stage Group（FSG）は、大手のサービスプロバイダー企業です。イベントの予約、ホテルの予約、シャトルサービスなどのイベントに関係するサービスを促進しています。 FSGは、様々なコミュニケーションチャネルを使用して、様々な地域の顧客にサービスを提供しています。 FSGのデータベースシステムは、データを保存する新・旧のデータベースが混在しています。 FSGの現行のレガシーアプリケーションは、他のテクノロジーを使用して実装されており、アーキテクチャスタイルは正常に機能しています。 FSGのフロントエンドチャネルには、CSRが使用するコールセンターアプリケーション、エンドユーザーが直接使用するウェブアプリケーション、顧客のFAQに回答するチャットボットアプリケーションなどがあります。 すべてのチャネルが、要求に応じてソースから直接情報を入手し、フロントエンドチャネルすべてのための共通のレイヤーは存在しません。 バックエンドシステムには、オンプレミスのデータベース、クラウド上のデータベース、ERPシステム、メインフレームシステムなどがあります。 データアクセスと永続ロジックは、ベンダーに特化して記述されています。

新たに結成されたセンターオブエクセレンス（COE）チームは、これらのアプリケーションに限界があることを予想しています。 問題点は次の通りです。

問題1：FSGのトップダウン型アプローチは、現在のシナリオでは、チャネル固有のコミュニケーションで正常に機能します。 FSGは、ビジネス競争を勝ち抜くために、新しいチャネルを導入する可能性がありますが、それには新しいコードを記述する必要があります。 チャネル固有のコードを維持することは困難で、手間がかかる作業であり、さらにチャネル全体のコミュニケーションには一貫性がありません。 他のチャネルに実装されている機能を再利用することはできないため、新しいチャネルを追加するには、白紙の状態から始める必要があります。

問題2： FSGのボトムアップ型アプローチは、データへのアクセスや印刷のために、データベースベンダー固有のロジックを使用しています。 データ仮想化レイヤーロジックは存在しません。 データベースと依存アプリケーションの現在のセットアップは、正常に機能しています。 ただし、データベースベンダーがデータアクセスプロトコルを変更した場合、FSGは、データの保存とアクセスのために、コードを書き換える必要があります。 新しいデータベースシステムが追加された場合は、コードも追加する必要があります。

新たに結成されたFSGのCOEチームは、PegaのCenter-outビジネスアーキテクチャを提案しました。

問題1に対する（既存のアーキテクチャにおける）解決策は、Pega 8.xを使用して、アプリケーションを構築することです。 ビジネスルールエンジン、プロセス、ポリシーは、すべてのチャネルおよびインターフェイスで利用可能です。 オムニチャネルでのエクスペリエンスを提供します。 Center-outビジネスアーキテクチャに実装されたMicrojourneyは、追加チャネルに導入されるように設定できます。

たとえば、Alexaを新しいチャネルとして追加する場合は、コンポーネントの追加となり、アプリケーションへのアクセスをAlexaに提供するだけなので、すばやく簡単にできます。

Pegaは、Pega Digital Experience (DX) APIも提供しています。 お客様はユーザーインターフェイスの実装を繰り返すことなく、希望するフロントエンドテクノロジーを使用して、優れたユーザーエクスペリエンスを提供できます。 Pegaコンポーネントは、ネイティブテクノロジーでレンダリングでき、Pegaコンポーネントの使用可能なアクションを理解します。

問題2に対する（既存のアーキテクチャにおける）解決策は、Pegaのライブデータ仮想化レイヤーを使用することです。 Pegaアプリケーションが使用するデータモデルは、システムオブレコードで使用されるデータモデルに依存しません。 条件に基づき、必要なデータベースシステムに移動してデータにアクセスします。 データ保存プランは、データの入手元や方法に依存せずに、更新済みデータや新しいデータを保存するのに役立ちます。

たとえば、Pega 8.xのデータページは、2つの異なるバックエンドシステム（またはSORシステム）に接続される、RESTとSOAPアクセスプロトコルの2つのコネクターを持つことができ、必要なソースを使用するために条件が評価されます。

FSGのケーススタディは、Center-outビジネスアーキテクチャを使用して利点が得られることを明示しています。 Center-out™アプローチに関する詳細については、「Center-out Business Architecture」を参照してください。