技術的なアーキテクチャ

技術的なアーキテクチャとは、アプリケーション自体のデザインのことです。 Pega Platform™で開発する主な利点の1つは、アプリケーションをデザインし、主要なコンポーネントを複数のMicrojourney^™やチャネル、さらには他のアプリケーションでも再利用できることです。 このような柔軟性があるため、必要な変更を一度で行えます。 Pega Platformの機能をアプリケーションの技術的なデザインで活用することをお勧めします。

技術的なデザインは、準備フェーズで始まり、開発フェーズで綿密に仕上げていきます。 リードシステムアーキテクト（LSA）は、構築するアプリケーションで、すぐに使える機能や再利用を最大限に活用できるよう、技術的なデザインのアクティビティを推進します。 LSAは、技術的なデザインを大まかに取りまとめ、ソリューションの基盤となるコンポーネントを実装することに注力します。   

基盤の構成要素には、リリース内で優先されるMicrojourneyのケースタイプ、ペルソナ、データオブジェクトの当初の定義を作成することが含まれます。

LSAは、プロダクトオーナー、ビジネスアーキテクト、ユーザーエクスペリエンスデザイナー、クライアントサイドのテクニカルアーキテクトと協力して、（現在および将来の）ビジネス目標と合致し、顧客の既存の技術インフラに沿った大まかなデザインに合意します。 

アプリケーションデザインアクティビティの一環として、LSAは次の項目についてベストプラクティスを徹底します。      

• アプリケーションの構造 
• データモデル
• ケースデザイン
• ユーザーアクセスとセキュリティー 
• 統合
• デプロイメントとDevOps
• レポート
• ユーザーエクスペリエンス/ユーザーインターフェイス

また、LSAはアプリケーションの技術的な品質にも責任を負います。 Pega Express^™のベストプラクティスは、ユニットとシナリオのテストを自動化してビルドの品質を保証し、DevOpsパイプラインをセットアップしてアプリケーションに加えられる変更の統合を簡素化することです。 LSAは、アプリケーションの構造が自動テストに対応できるように構成されていることを確認します。 テストの詳細については、Pega AcademyのトピックCrucial testing approachesを参照してください。   

アプリケーションを作成する前に（詳しくは、Senior System Architectのミッションをご覧ください）、LSAはプロダクトオーナーやビジネスアーキテクトと協力して、組織内でのアプリケーションの対象範囲を把握します。 これらの情報に基づいて、LSAはアプリケーションが短期および長期の両方のビジネス目標をサポートするようにデザインされていることを確認します。

Pega Platformでは、ビジネスと同じ構成要素を使用してアプリケーションを構成できるため、ビジネスチームからの意見は重要です。 異なる製品、地域、チャネル、顧客セグメントに合わせつつ、共通のポリシーや手続きを再利用できます。

この柔軟性は、アプリケーションを次々に重ねていくことによって実現します。 その結果、次の4つのレベルで構成されるSituational Layer Cakeができあがります。

• Organization
• フレームワーク
• 除法
• Implementation 

Situational Layer Cakeの重要性を示すもう一つの視点については、Pega CommunityのPartner Spotlight Talk in Pega Community（Pega Communityでのパートナースポットライトについての話）を参照してください。  

次の画像で+のアイコンをクリックすると、Situational Layer Cakeの4つのレイヤーのそれぞれについて詳しい説明が表示されます。

衣料品小売店は、2つのブランドの店舗で構成されています。 一つのブランドで高級衣料品を扱い、もう一方のブランドでは価格重視のチェーンストアを運営しています。 返品商品は各ブランドが管理します。 この小売企業は、衣料品の返品を管理する汎用アプリケーションをFrameworkレイヤーで開発できます。 その後、各ブランドはImplementationレイヤーを作成し、返品プロセスをカスタマイズできます。 カスタマイズされたアプリケーションには、スタイリングやポリシーなど、ブランド固有のアセットが含まれています。

技術的なデザインの準備フェーズにおける決定事項は、次のレイヤーのアプリケーション構造に反映されます。

上から順にレイヤーを重ねていきます。

• 最上位のレイヤーは、Frameworkレイヤーの上に並んでいるImplemetationレイヤー（各店舗ごとに1つ）です。 それぞれのImplemetationレイヤーは、各店舗に特化しており、Upscale BrandやReturn Specializationなどが含まれます。
• Implementationレイヤーの下には、返品プロセスの共通技術コンポーネントを含むFrameworkレイヤーがあります。 Frameworkレイヤーは、Organizationレイヤーの上に位置しています。
• Organizationレイヤーは Pega Platformレイヤーの上に位置し、ビジネスのすべての領域に共通する技術アセットを含んでいます。 これはアプリケーションの下位に位置するため、再利用が必要なプロセスや店舗で使用することができます。
• 最後に Pega Platformレイヤーは最下層に位置し、すべての残存機能を上の層で使用することができます。

アプリケーションには、エンタープライズ内またはエンタープライズ外に由来する何らかのデータが必要です。

• 組織内のデータソース：Pega Platformアプリケーションおよび組織内の他のレガシーシステムに保存されているデータを特定します。
• 組織外のデータソース：サードパーティのソフトウェアシステムやアプリケーションに保存されているデータを特定します。

まず最初に既存のシステムにどのようなデータ要素が格納されているかを確認して、データモデルを開始します。 全体として、Pega、会社、外部の3つのソースに由来するデータを検討します。

データに関するデザインを決めるにあたり、次の3点に注意します。

• エンタープライズデータモデル：エンタープライズレベルで適用され、エンタープライズ内で開発または構成されたすべてのアプリケーションで利用可能なデータ
• アプリケーションデータモデル：アプリケーション内で管理されるデータ
• スタンディングデータモデル：ルックアップまたは参照データソースを必要とするデータ

MyDebtという会社は、経済的に困窮している人に融資ソリューションを提供しています。 MyDebt社は、DebtSolというPega Platformアプリケーションを持っています。このアプリケーションには、直接対応にあたる融資ケースワーカーが個人から電話を受け、現在の問題に対処するための融資ソリューションを提示する機能があります。  このソリューションは、個人について、および借り入れ、収入、支出、資産など現在の財務状況についての詳細を記録し、ビジネスルールを使用して、その債務に対処するためのソリューションを提示するようデザインされています。

アプリケーションのデータモデルでは、既存のエンタープライズクラスのデータモデルを再利用して個人情報が記録され、DebtSolアプリケーション専用のデータモデルが特定されました。

次の画像で、+のアイコンをクリックすると、データモデルの例が表示されます。

Pega Platformの認証は、検証されたアイデンティティを持つユーザーとシステムのみが、ウェブページ、API、データなどのリソースにアクセスできるようにするものです。

認証の例には次のものがあります。

• ユーザーログイン
• 外部サービスへのプラットフォームリクエスト
• プラットフォームへの外部サービスリクエスト

組織階層、ワークグループ、ワークキューに対応するオペレーターレコードを適切に認証するメカニズムと構成を検討して選択してください。 Pega Platformの承認またはアクセスコントロール機能を使用して、ユーザーアクションを制限できます。 

3つの基本的な承認モデルをチームで事前に確認し、どのモデルがプロジェクトに適しているかを決定します。

• ロールベースのアクセス制御（RBAC）
• 属性ベースのアクセス制御（ABAC）
• クライアントベースのアクセス制御（CBAC）

セキュリティ

また、セキュリティーチェックリストのどの項目がプロジェクトの状況に該当するかを準備フェーズで確認し、決定することも重要です。

特に次の点に注意してください。 

• 認証スキーム
• アクセスグループ/ロール
• 組織構造
• タイムアウトの構成
• 監査
• ファイルアップロードのセキュリティー   

機密情報や個人を特定できる情報のデータ項目については、暗号化、難読化、アクセス制御など、ユーザーの構成やアクセスを保護するための適切なセキュリティーを適用します。

アプリケーションセキュリティーの詳細については、Pega AcademyのトピックSecurity Checklistを参照してください。

Pega Platformは、さまざまな統合規格と通信プロトコルをサポートしているため、接続の問題に手間を取られることなく、アプリケーションのビジネス要件に集中できます。 各統合コンポーネントについて、構成とデリバリーのための適切な詳細情報があるかどうかを確認し、検証します。  

たとえば、各統合コンポーネントに関連する次の点について、可視性、理解、明瞭性を確認してください。

• 環境ごとのURL
• プロトコル
• 認証
• クラウドまたはオンプレミスのリポジトリまたはサードパーティ（コンテンツ管理）
• SSL/TLS - バージョン
• 証明書
• ポート

アプリケーションのデプロイメントはプロジェクトのライフサイクルを通じて行われ、アプリケーションは、開発から本番に向かうステージングまで、異なる環境に移行していきます。クライアントサイドのIT部門と自社の技術チームは、開発環境内で作業を管理するためのアプローチと、アプリケーションをデプロイする最適な方法について合意する必要があります。 プロジェクトの最初からDevOpsを含めます。

LSAは準備フェーズでDevOpsのディスカッションをリードしてPega Expressのベストプラクティスが遵守されるように徹底、技術的な品質とスピーディなデリバリーを保証します。  LSAは、こうしたディスカッションの中で、Pegaアプリケーションの技術チームに必要なアプリケーションの構造とDevOpsのベストプラクティスを確立します。    

Pega Expressデリバリーアプローチを用いてアプリケーション開発にDevOpsアプローチを採用する場合、開発者はブランチで作業するというベストプラクティスに沿ってアプリケーションへの更新を構成し、アプリケーションをある環境から別の環境に移行するためのデプロイメントパイプラインを定義することになります。 始めから完全なデプロイメントを構成する必要があります。 つまり、アプリケーションの追加のパッケージとしてではなく、アプリケーション全体を、元の環境から別の環境に移行することになります。

このベストプラクティスを適用することで、デプロイメントパッケージにアプリケーション内のすべてのルールとデータの累積的なコレクションが含められるようになります。一方で、前回のデプロイメント以降に変更された部分だけがデプロイされるため、柔軟性もあります。

DevOpsパイプラインは、次のような推奨されるすべてのチェックとバランスで構成する必要があります。

• セキュリティーチェックリスト
• ガードレールコンプライアンス
•  
• ある環境から別の環境にアプリケーションを移行する際の品質の保証   

最初から明確なレポート戦略を定義することで、Pega Platformアプリケーションのデザインがビジネス上のビジネス運用と管理の両方のレポートのニーズを満たすようにします。 組織では、Pega Platformアプリケーションから既存のエンタープライズデータウェアハウスソリューションにデータを供給することが要求される場合がよくあります。

Pega Platformからデータを抽出する際には、Business Intelligence Exchange（BIX）ページ抽出ツールを使用するのがベストプラクティスです。 この要件を前もって特定するかどうかは、Pega Platformアプリケーションのデータオブジェクトの構成や、データウェアハウスとの統合に使用するインターフェイスソリューションに影響します。 

以下は、データ抽出を扱う際に、事前に決めておく必要のあるデザイン上の重要事項です。

• 抽出の頻度（日次/週次など）
• トランザクション抽出デザイン（各トランザクションまたは累積EODトランザクション）
• 抽出履歴
• すべてのプロパティまたは固有のプロパティ
• 抽出形式（CSV、XML、DB）

ユーザーインターフェイス（UI）アーキテクチャは、アプリケーションの技術的なデザインの一部を構成します。 

UIは次をカバーしています。

• プロジェクトで採用すべきベストプラクティス
• チームのワークプラクティス  

プロジェクト開始時、UIソリューションの開発者は、プロダクトオーナー、リードビジネスアーキテクト、リードシステムアーキテクト、テスターと協力して、UIアーキテクチャを定義するための複数のセッションをリードします。  このような初期段階での決定により、UIは、保守が簡単で、アプリケーション全体で一貫性を持ち、UIのベストプラクティスに沿ったものになります。  

UIソリューションの開発者は次の点について考慮します。

• デザインシステム
• スキンの再利用（ブランディングやスタイリングなど）
• 機能に関係しない要件
• ウェブセルフサービスアーキテクチャ
• ガバナンスプロセス

Pega Platformバージョン8.3以降には、Cosmosを使用してUIを高速化するシームレスな方法が用意されています。  Cosmosが最高のユーザーエクスペリエンスの実現にどのように役立つかの詳細については、Pega CommunityのTechTalk、Accelerate your workflow with Cosmos UIを参照してください。 

Pega Platform バージョン8.7以降では、Constellationデザインシステムにより、規定された設計とビューベースのアーキテクチャを利用してアプリケーションを構築できます。 Constellationでのアプリケーション構築の詳細については、Configuring Constellation applicationsを参照してください。

次の画像で「+」アイコンをクリックすると、UIについて詳細を表示できます。