Architecture technique

L'architecture technique fait référence à la conception de l'application elle-même. L'un des principaux avantages du développement avec Pega Platform™ est la possibilité de concevoir votre application et de réutiliser des composants clés pour plusieurs microjourneys^™ et canaux (channels), voire dans d'autres applications. Avantage de cette flexibilité : lorsque vous souhaitez modifier quelque chose, vous ne le faites qu'une fois. Vous souhaitez exploiter les fonctionnalités de Pega Platform dans la conception technique de votre application.

La conception technique commence durant la phase de préparation et est affinée durant la phase Build. Le lead system architect (LSA) dirige l'activité de conception technique et s'assure que l'application que vous développez exploite au mieux les fonctionnalités prêtes à l'emploi et les possibilités de réutilisation. Le LSA se concentre sur la définition d'une conception technique générale et sur l'implémentation des composants de base de la solution.   

Les composants de base englobent les types de dossiers (case type), les personas et les data objects, créés à partir de leur définition initiale, pour tout Microjourney priorisé dans la version.

Le LSA convient avec le product owner, le Business Architect (BA), le UX designer et les architectes techniques côté client d'une conception générale qui répond aux objectifs métiers (actuels et futurs) et s'aligne sur l'infrastructure technique existante chez le client. 

Au cours de cette phase de conception de l'application, le LSA veille à l'application des bonnes pratiques dans les domaines suivants :      

• Structure de l'application 
• Modèle de données
• Conception de dossier
• Accès utilisateur et sécurité 
• Intégration
• Déploiement et DevOps
• Reporting
• Expérience utilisateur/Interface utilisateur

Le LSA est également chargé de veiller à la qualité technique de l'application. Pega Express^™ préconise l'automatisation des tests unitaires et de scénarios pour garantir la qualité du développement et mettre en place des pipelines de DevOps visant à fluidifier l'intégration des évolutions dans votre application. Le LSA doit s'assurer que la structure de l'application est pensée pour favoriser l'automatisation des tests. Pour plus d'informations sur les tests, veuillez consulter la rubrique Principales approches de test dans Pega Academy.   

Avant de créer l'application (voir notre cours Senior System Architect pour plus d'informations), le LSA détermine le périmètre de l'application au sein de l'organisation, en collaboration avec le product owner et les business architects. Sur la base de cette analyse, le LSA s'assure que l'application est conçue pour soutenir les objectifs métier immédiats et à long terme.

La consultation des intervenants métier est essentielle, car Pega Platform vous permet d'aligner la structure de votre application sur l'organisation de l'activité. Vous pouvez réutiliser des politiques et des procédures communes tout en tenant compte des différences entre les produits, les régions, les canaux (channels) et les segments de clientèle.

Cette flexibilité est obtenue en superposant les applications les unes sur les autres. On obtient alors un Situational Layer Cake, composé de quatre niveaux :

• Organisation
• Framework
• Division
• Implémentation 

Pour des considérations complémentaires sur l'importance du Situational Layer Cake, veuillez consulter cette Partner Spotlight Talk dans Pega Community.  

Dans l’image suivante, cliquez sur les icônes + pour en savoir plus sur chacune des quatre couches du Situational Layer Cake.

Un chaîne de magasins de vêtements se compose de deux marques. L'une des marques est positionnée sur le haut de gamme, tandis que l'autre propose des produits plus abordables. Chacune des deux marques doit gérer les retours d'articles. Ce vendeur peut développer une application globale qui gère les retours de vêtements dans la couche Framework. Chaque marque peut ensuite créer une couche Implémentation pour personnaliser le processus de retour. Chaque application personnalisée comporte des composants spécifiques à la marque, comme le style et les politiques.

Les décisions relatives à la conception technique prises durant la phase de préparation peuvent s'appliquer dans la structure d'application dans les couches suivantes :

Partir d'en haut puis descendre vers les différentes couches :

• Les couches les plus hautes sont les couches Implémentation (une par magasin) qui reposent côte à côte, au-dessus de la couche Framework. Chaque couche Implémentation, propre à chaque magasin, inclut les spécialisations Upscale Brand et Returns.
• En dessous des couches implémentation, la couche Framework contient les composants techniques communs pour le processus Returns. La couche Framework se trouve au-dessus de la couche Organisation.
• La couche Organisation se trouve au-dessus de la couche Pega Platform et contient les actifs techniques communs pour tous les domaines d'activités. Comme elle se trouve tout en bas de l'application en couches, elle peut être utilisée par n'importe quel processus ou magasin qui souhaite la réutiliser.
• Enfin, la couche Pega Platform se trouve tout en bas. Ainsi, toutes les fonctionnalités restantes sont utilisables par les couches supérieures.

Les applications utilisent des données de différentes natures provenant soit de l'entreprise elle-même, soit de l'extérieur.

• Sources de données au sein de l'organisation – Identifier des données stockées dans les applications Pega Platform et autres systèmes existants dans l'organisation.
• Données externes à l'organisation – Identifier des données stockées dans des systèmes ou applications tierces.

La première étape de la définition de votre modèle de données consiste à déterminer quels éléments de données sont stockés dans les systèmes existants. Vous prenez finalement en compte des données provenant de trois sources différentes : Pega, l'entreprise et les données externes.

Dans votre réflexion sur la conception, vous devez garder à l'esprit trois aspects concernant les données :

• Le modèle de données de l'entreprise – Données applicables au niveau de l'entreprise et disponibles pour toutes les applications développées ou configurées dans l'entreprise
• Le modèle de données de l'application – Données maintenues dans l'application
• Le modèle de données permanentes (standing data) – Données s'appuyant sur une recherche (lookup) ou une source de données de référence

La société MyDebt propose des solutions aux personnes en difficulté financière. MyDebt dispose d'une application Pega Platform appelée DebtSol qui permet aux agents de prendre les appels et de proposer des solutions.  La solution est conçue pour enregistrer les informations concernant les personnes et leur situation financière actuelle, par exemple, leurs dettes, leurs revenus, leurs dépenses et leurs actifs, puis proposer des solutions pour gérer leur endettement, à partir de règles métier.

Le modèle de données de l'application réutilise un modèle de données d'entreprise existant pour enregistrer les données personnelles des clients. Un modèle de données spécifique à l'application DebtSol a été identifié.

Dans l’image suivante, cliquez sur les icônes + pour afficher l'exemple de modèle de données.

Le schéma d'authentification de Pega Platform garantit que seuls les utilisateurs et les systèmes dont l'identité est vérifiée peuvent accéder aux ressources telles que les pages web, les API et les données.

L'authentification couvre par exemple :

• Les connexions des utilisateurs
• Les demandes de la plateforme à des services externes
• Les demandes de services externes à la plateforme

Après avoir étudié la question, choisissez un mécanisme d'authentification et une configuration appropriés pour les enregistrements des opérateurs en tenant compte de la hiérarchie organisationnelle, des groupes de travail et des work queues. Vous pouvez utiliser les fonctions d'autorisation ou de contrôle d'accès dans Pega Platform pour restreindre les actions des utilisateurs. 

Passez en revue avec votre équipe les trois modèles d'autorisation de base afin d'identifier lequel convient le mieux à votre projet.

• Contrôle d'accès basé sur les rôles (RBAC)
• Contrôle d'accès basé sur les attributs (ABAC)
• Contrôle d'accès basé sur les clients (CBAC)

Sécurité

Vous devez également passer en revue les éléments de la checklist de sécurité et déterminer lesquels s'appliquent à votre projet durant la phase de préparation.

Attachez-vous en particulier aux points suivants : 

• Schéma d'authentification
• Groupes d'accès/rôles
• Structure de l'organisation
• Configuration du timeout
• Audit
• Sécurité des téléchargements de fichiers   

Pour toute donnée sensible ou à caractère personnel, appliquez des mesures appropriées (chiffrement, obscurcissement, contrôle d'accès, etc.), afin de protéger les accès et les configurations utilisateur.

Pour plus d'informations sur la sécurité des applications, veuillez consulter la rubrique Checklist de sécurité dans Pega Academy.

Pega Platform prend en charge une série de normes d'intégration et de protocoles de communication, ce qui vous permet de vous concentrer sur les besoins métier de votre application plutôt que sur les questions de connectivité. Vérifiez et validez que, pour chaque composant d'intégration, vous disposez des informations appropriées pour la configuration et la livraison.  

Par exemple, assurez-vous d'avoir de la visibilité, une vision claire et une bonne compréhension des points suivants, pour chaque composant d'intégration :

• URL par environnement
• Protocoles
• Authentification
• Référentiel cloud, on-premise ou tiers (gestion de contenu)
• SSL/TLS – versions
• Certificats
• Ports

Le déploiement de l'application se fait tout au long du cycle de vie du projet, l'application migrant d'un environnement à un autre, depuis le développement jusqu'à la mise en production. Le service informatique côté client et votre équipe technique doivent convenir de la meilleure manière de travailler dans l'environnement de développement et de déployer l'application. Incluez le DevOps dès le début du projet.

Le LSA mène les discussions autour du DevOps pendant la phase de préparation afin de garantir le respect des bonnes pratiques de Pega Express et, ce faisant, la qualité technique et la rapidité de livraison.  Lors de ces discussions, le LSA détermine la structure de l'application et les bonnes pratiques de DevOps pour l'équipe technique de l'application Pega.    

Avec l’approche de delivery Pega Express, les développeurs adoptent une approche DevOps du développement d’applications : ils travaillent par branches pour la configuration des mises à jour de l’application et la définition de pipelines de déploiement pour la migrer d’un environnement à un autre. Les déploiements complets doivent être configurés dès le départ. Cela signifie la migration complète de l'application d'un environnement à un autre, plutôt que le recours à des packages incrémentiels. 

L'application de cette bonne pratique permet de s'assurer que le package de déploiement cumule toutes les règles de l'application et des données, mais offre une certaine flexibilité, car elle se limite aux éléments modifiés depuis le dernier déploiement.

Les pipelines de DevOps doivent être configurés en suivant l'ensemble des précautions d'usage, notamment :

• Checklist de sécurité
• Respect des seuils (guardrails)
• Exécution de tests unitaires et de scénarios
• Assurer la qualité de l'application lors de sa migration d'un environnement à un autre   

Définissez dès le départ une stratégie claire en matière de reporting pour vous assurer que l'application Pega Platform réponde aux besoins en matière de rapports opérationnels et de gestion. Les organisations ont souvent besoin d'applications Pega Platform pour fournir des données à leurs solutions de datawarehouse existantes.

Il est recommandé d'extraire les données de votre Pega Platform en utilisant l'outil d'extraction de page, Business Intelligence Exchange (BIX). L'identification de cette exigence en amont détermine la configuration des data objects dans l'application Pega Platform et la solution d'interface utilisée pour l'intégration avec le datawarehouse. 

Voici les thèmes à prendre en compte lors de la conception, dès le départ, en ce qui concerne l'extraction des données :

• Fréquence d'extraction (par exemple, quotidienne/hebdomadaire)
• Conception de l'extraction des transactions (chaque transaction ou cumul journalier des transactions)
• Historique des extractions
• Toutes les propriétés ou des propriétés spécifiques
• Format d'extraction (CSV, XML ou DB)

L'architecture de l'interface utilisateur (UI) fait partie de la conception technique de l'application. 

Les réflexions autour de l'interface utilisateur couvrent les points suivants :

• Bonnes pratiques à adopter pendant le projet
• Pratiques de travail de l'équipe  

Au début du projet, le développeur de solutions UI mène plusieurs sessions de travail en collaboration avec le Product Owner, le Lead Business Architect, le Lead Systems Architect et le testeur pour définir l'architecture de l'interface utilisateur.  Ces décisions prises très tôt garantissent que l'interface utilisateur sera facile à maintenir, cohérente dans toute l'application et conforme aux bonnes pratiques dans ce domaine.  

Le développeur de solutions UI étudie différents aspects :

• Systèmes de conception
• Réutilisation du skin (charte graphique et style notamment)
• Exigences non fonctionnelles
• Architecture web en libre-service
• Processus de gouvernance

Depuis la version 8.3 de Pega Platform, vous disposez avec Cosmos d'un moyen simple d'accélérer le développement de votre interface utilisateur.  Pour plus d'informations sur la manière dont Cosmos contribue à créer une expérience utilisateur de premier ordre, consultez le TechTalk Accelerate your workflow with Cosmos UI sur Pega Community. 

Dans l’image suivante, cliquez sur les icônes + pour en savoir plus sur les interfaces utilisateur.