モジュラー型再利用アーキテクチャ

Pega Situational Layer Cake™の構造は、本質的にモジュラー型のエンタープライズ再利用をサポートする基本的なアーキテクチャモデルです。Situational Layer Cakeの構造については、次のビデオをご覧ください。

動画のスクリプト：

こんにちは PegaのCTO ドン・シャーマンです。Situational Layer Cakeについてはご存知の方も多いと思います。Cakeと言っても、ケーキ事業に参入するということではありません。少し変わった名前かもしれませんが、デジタル変革とレガシーシステムの刷新を考えるうえで不可欠な特許取得済みのアーキテクチャを反映しています。Layer Cakeの目標は、ビジネスにおいて競合する2つの目標のバランスを取ることです。

1つ目は、スケールメリットと一貫性を得るために再利用を目指すことです。一方で、ビジネスに必要なバリエーションも許容する必要があります。時には異なる商品を販売することもあります。競争力を高めるためです。異なる地域で事業を展開する場合もあります。これらの地域の規制の要件を遵守する必要があります。Layer Cakeにより、従来のアプローチでは不可能な方法でバランスを取ることができます。すべてを1つのアプリに集約しようとして、バリエーションを管理するために必要なif-then-elseを含む可読性の低いコードが大量に作成されるか、バリエーションごとに独自のアプリをデプロイして 50~100種類の異なるアプリが作成されるという事態が頻繁に起こります。これらはすべてほぼ同じ状況です。

Layer Cakeはそれを回避するためのアプローチです。まずEnterpriseレイヤーを持つレイヤーでアプリケーションを構築することから始めます。企業全体で再利用できるすべての要素と考えてください。それはデータ構造やインターフェイスかもしれません。アプリケーションの主要なセキュリティー要素の定義かもしれません。または再利用可能なコンポーネントの構築かもしれません。ドキュメントを生成したり、特定の情報をイベントキューにパブリッシュしたりするなど、コンポーネントライブラリとして利用することを目指します。そのため エンタープライズアプリケーション上に、アプリケーションを含むレイヤーを構築します。たとえば、新しいビジネスアプリケーションを構築する場合を考えましょう。新規顧客のオンボーディングはこれで対応できます。そのアプリケーションの一部として、ワークフロー、つまりケースライフサイクルを定義します。その成果、つまりフルフィルメントステージに到達するために、新しいビジネスプロセスが通過する必要があるステップが含まれます。現時点で新しいビジネスでも機能するコアアプリケーションができています。

もちろん、新規事業を行うだけでなく様々な商品があります。たとえば、銀行だとしたら、ローン用の新しい業務アプリケーションを持っていれば、新たなビジネスアプリケーションを作り直す必要はありません。ローンについて具体的に定義し、特定の書類や保険引受に関する意思決定を行い、最終的にローンを完済する方法を定義するだけです。次にそのローンビジネスを英国で展開する場合、その一環としてプロセスの開始時に英国でローンを管理するために、明確な情報を収集する必要があります。Layer Cakeがアプリケーションを実行または実行すると、すべてのレイヤーを調べて最も具体的なものを見つけ、適切なプロセスを動的に組み立てます。この場合はオンボーディングしているユーザー、そして英国での新規ローン。処理コードに if-then-else ロジックをいくつも記述する必要はなく、Layer Cakeの各レイヤーで異なるアプリケーションを使用する必要もありません

このアーキテクチャは非常に強力です。世界的な保険会社であるAIGは、以前は52種類の請求システムを世界各地に展開していました。その52個の請求システムを1つに統合したのです。このアーキテクチャを「ワンクレーム」と呼んでいますデジタル変革の実行やレガシーシステムのモダナイゼーションをお考えの場合、Layer Cakeアプローチが不可欠です。過去のサイロ化された構造を繰り返すのではなく、ビジネスに必要なバリエーションとエンタープライズ規模で必要な再利用の両方に柔軟に対応できる強力なアーキテクチャを構築し、スケール拡大を達成しましょう。

ビデオはこれで終了です

Situational Layer Cakeの構成

Situational Layer Cakeは、アプリケーションをレイヤーに整理して、モジュラー型の再利用をサポートし、複雑さを管理します。各レイヤーには明確な目的があります。

• Enterpriseレイヤー：Pega Platform™のコア機能と組織全体で再利用可能なアセット。たとえば、組織内のすべてのアプリケーションで使用される全社的な認証モジュールなどです。
• Divisionレイヤー：部門専用の再利用可能なコンポーネント。たとえば、保険部門向けにカスタマイズされたが、アプリケーション間で再利用される請求プロセスフローなどです。
• Applicationレイヤー：下位レイヤーのアセットを活用するアプリケーション固有の実装。たとえば、共通の認証コンポーネントと請求コンポーネントを使用しながら、独自のワークフローを追加するカスタマーサービスアプリがあります。
• Implementationレイヤー：基礎のアプリケーションを変更することなく、特定のデプロイメントシナリオに合わせたカスタマイズ。たとえば、言語や規制ルールを調整して、特定の地域向けにカスタマーサービスアプリをローカライズします。

このレイヤー構造により、下位レイヤーに影響を与えることなく上位レイヤーでの変更を可能にし、モジュラー型の再利用をサポートします。コンポーネントをカスタマイズする必要がある場合は、適切なレイヤーで変更して、ベースの整合性を維持し、コアコンポーネントの更新がすべての依存アプリケーションに適用されるようにします。Pega Platformは、標準化された相互運用可能なコンポーネントを提供するローコードの処方型設計により、開発を加速し、一貫性を促進します。

開発者は、コードを手動で記述するのではなく、事前に設定されたコンポーネントを組み立てることでアプリケーションを構築します。このアプローチにより、再利用性が向上し、デリバリー機関が短縮されます。再利用可能な機能はモジュールアプリケーションにカプセル化されており、スタックして組み込みアプリケーションを構築することができます。

たとえば、複数のビジネスプロセスで会議の設定が必要な場合、この機能を処理する再利用可能なスマートシェープを作成できます。App Studioでスマートシェープを設定し、アプリケーション間で再利用することで、重複を排除し、メンテナンスを簡素化できます。

次の図は、複数のアプリケーションでMeeting モジュールを再利用するビジネスアーキテクチャのサンプルを示しています。

次の問題に答えて、理解度をチェックしましょう。