Enterprise Class Structure
Enterprise Class Structure
企業の組織構造は複雑で、多数の事業所を展開している場合があります。 たとえば、ある家電量販店は店舗、オンライン、ソーシャルメディアでモバイルデバイスとノートパソコンを販売しています。 この家電量販店はチャネル、製品、そして顧客を管理する方法を必要としています。 家電量販店の顧客はさまざまな国に所在しています。 家電量販店としては、常に各地域の法令に準拠している必要があります。
アプリケーション開発プラットフォームによっては、製品、地域、またはチャネルごとに別々のアプリケーションのコピーを作らなければなりません。 または、ビジネスコンテキストに関係なく、すべてのトランザクションを同様に扱う単一のアプリケーションを開発する必要があります。 その結果、拡張のできない、管理が困難なエンタープライズアプリケーションになってしまいます。
Pega Platform™では、ビジネスと同じディメンションを使ってアプリケーションを構成することができます。 Pega Platformを使用すると、異なる製品、地域、チャネル、および顧客セグメントに対応しつつ、共通のポリシーや手順を簡単に再利用できます。
Pega Platformでは、 Enterprise Class Structure (ECS)と呼ばれるクラス階層構造を使用することでこの機能をサポートしています。
ECSレイヤーに配置された任意のルールは、複数のアプリケーション間で共有できます。 ビジネス環境の変化に応じて、既存のECSレイヤーを調整できます。 ECSにより、再利用と標準化に関するベストプラクティスも導入されるため、他の事業部門に展開する際に役立ちます。
補足: Pega Platformの各リリースでは、そのリリースで利用可能なベストプラクティスを反映するクラス構造が生成されます。
Enterprise Class Structureレイヤー
Pega Platformレイヤー
Pega Platformレイヤーには、Pegaアプリケーションでのケースやその他のワークの処理に必要な組み込みアセットが含まれています。 このレイヤーには、Pega Platformで使用されるアセットも含まれています。
Organizationレイヤー
Organizationレイヤーには、企業全体で使用されるアセットが含まれます。 このようなアセットは、標準プロパティ、デシジョンテーブル、サービスレベルのルールなど、企業全体のビジネスロジックのためのルールです。 たとえば、オンライン販売企業では、業務全体で顧客アカウント番号を保持するプロパティを再利用します。 企業全体で利用されるアプリケーションでは、他のアプリケーションでプロパティのコピーを作成する必要はなく、同じアカウント番号プロパティを参照できます。
Organizationレイヤーには、システムで保管されているデータのクラスやルール、コネクター経由で外部システムのデータにアクセスするクラスやルールなど、企業全体のデータアセットも含まれています。 たとえば、外部の顧客データベースに対するアクセスは、Organizationレイヤーに追加される統合ポイントです。
Divisionレイヤー
Divisionレイヤーには、事業部門全体で使用されるアセットが含まれています。 Divisionレイヤーは、3レベルの組織階層(Org-Div-Unit)の中間レベルであり、すべてのアプリケーションで使用できます。
Divisionレイヤーは事業部門、地域、またはブランドのアセットとして適用することができます。 たとえば、事業部門で、すべてのアプリケーションで顧客のクレーム対応に予想される時間を定義する、サービスレベルのルールを再利用する場合を考えてみましょう。 サービスレベルのルールをDivisionレイヤーに配置すると、事業部門内のすべてのアプリケーションが、パターン継承によりサービスレベルのルールにアクセスできるようになります。 このような再利用により、サービスレベルのコピーを個別に作成したり、管理したりする必要がなくなります。
補足: Divisionレイヤーは任意で設定するレイヤーです。 大規模な組織では、Divisionレイヤーがルールやその他のアプリケーションアセットの再利用を管理するのに役立ちます。
FrameworkレイヤーとImplementationレイヤー
Frameworkレイヤー:特定の実装環境に拡張できるアセットが含まれます。 Frameworkレイヤーは、特定の業界向けの標準的なPegaアプリケーションや、拡張可能なカスタムアプリケーションなど、1つまたは複数の汎用アプリケーションで構成される場合があります。
Implementationレイヤーでは、特定の部門や事業部門向けにカスタマイズされたアプリケーションを定義します。 Implementationレイヤーのアプリケーションは、Frameworkレイヤーの1つまたは複数のアプリケーションを拡張することができます。
たとえば、衣料品小売企業が2つのブランドの店舗で構成されているとします。 一つのブランドで高級衣料品を扱い、もう一方のブランドでは価格重視のチェーンストアを運営しています。 ブランドごとに、返品管理が必要です。 この小売企業は、衣料品の返品を管理する汎用アプリケーションをFrameworkレイヤーで開発できます。 その後、ブランドごとにImplementationレイヤーを作成し、返品プロセスをカスタマイズできます。 カスタマイズされたアプリケーションには、スタイリングやポリシーなど、ブランド固有のアセットが含まれています。
次の画像では、保険会社の例について考えます。
補足: FrameworkレイヤーとImplementationレイヤーでは、アプリケーションアセットが相対的に分離されます。 アセットがFrameworkレイヤーとImplementationレイヤーのどちらに属するかは、アプリケーションの設計によって異なります。 特定の事業部門の実装アプリケーションが、別のアプリケーションのFrameworkレイヤーに属している場合もあります。 たとえば、大手金融サービス会社が特定の部門またはブランドで自動車ローンアプリケーションを開発する場合を考えてみます。 2番目の部門が、その後、アプリケーションを拡張し、必要に応じてアセットをカスタマイズします。 その部門では、元の自動車ローンアプリケーションがFrameworkレイヤーの一部となります。 最初の部門では、アプリケーションはImplementationレイヤーの一部となります。