Architecture de réutilisation modulaire

La structure Pega Situational Layer Cake™ est un modèle d’architecture fondamental qui prend en charge de manière inhérente la réutilisation modulaire dans l’entreprise. Regardez la vidéo suivante pour en savoir plus sur la structure du Situational Layer Cake :

Transcription de la vidéo :

Bonjour, je m’appelle Don Sherman, Chief Technology Officer chez Pega, et si vous nous connaissez un peu, vous avez sûrement déjà entendu parler du « Situational Layer Cake ». Non, Pega ne cherche pas à se lancer dans la boulangerie-pâtisserie, et oui, ce nom peut sembler un peu étrange, mais il reflète une architecture brevetée qui est absolument essentielle à votre réflexion sur la transformation digitale et la modernisation de vos systèmes existants. En effet, l’objectif du Layer Cake est de vous permettre d’équilibrer deux forces souvent concurrentes dans votre entreprise.

Tout d’abord, c’est le souhait de réutiliser afin de réaliser des économies d’échelle et d’assurer la cohérence. Mais d’un autre côté, vous devez tenir compte des variations nécessaires à votre activité. Parfois, vous vendez différents produits. Vous voulez être compétitif. Parfois, vous intervenez dans différentes régions. Vous devez respecter les exigences de conformité réglementaire en vigueur dans ces régions. Le Layer Cake vous permet d’équilibrer ces éléments d’une manière que les approches traditionnelles ne permettent pas. Trop souvent, soit vous essayez de tout regrouper dans une seule application et vous vous retrouvez avec un code spaghetti contenant tous les if-then-else nécessaires pour gérer les variations, soit vous finissez par déployer une application distincte pour chaque variation, ce qui vous donne entre 50 et 100 applications différentes, qui font toutes à peu près la même chose.

Le Layer Cake est une approche qui permet d’éviter ce chaos. Vous commencez par créer la couche d’entreprise de votre application. Considérez cela comme l’ensemble des éléments qui peuvent être réutilisés dans toute votre entreprise. Peut-être s’agit-il de vos structures de données et interfaces. Ou la définition de certains éléments de sécurité clés dans votre application. Peut-être avez-vous créé des composants réutilisables. Vous souhaitez disposer d’une bibliothèque de composants que les utilisateurs peuvent exploiter, par exemple pour générer un document ou publier certaines informations dans une file d’attente d’événements. Ensuite, au-dessus de votre application d’entreprise, vous pouvez créer une couche avec votre application. Imaginons que vous développiez une nouvelle application métier, dédiée à l’onboarding des nouveaux clients. Dans le cadre de cette application, vous définiriez votre workflow ou ce que nous appelons le cycle de vie de votre dossier. Il s’agit des étapes que ce nouveau processus métier doit suivre afin d’atteindre son résultat, sa phase finale. Je dispose désormais d’une application centrale capable de fonctionner dans les différents domaines d’activité.

Bien sûr, je ne me contente pas de développer de nouvelles activités génériques, je propose différents produits. Donc, si je suis une banque, j’ai peut-être une version de ma nouvelle application métier dédiée aux prêts, et je ne réécris pas entièrement ma nouvelle application métier. Je définis simplement les éléments de cette application qui doivent être spécifiques au prêt, par exemple comment je peux finaliser le prêt à l’aide de documents spécifiques et certaines des décisions de souscription que je dois prendre. Supposons que j’aie étendu mon activité de prêt au Royaume-Uni : dans ce cadre, je sais qu’au début du processus, je dois recueillir certaines informations spécifiques afin de gérer les prêts pour le Royaume-Uni. Désormais, lorsque l’application est lancée ou exécutée, le Layer Cake examine toutes les couches et trouve les éléments les plus spécifiques possibles, puis assemble dynamiquement le processus adapté à un utilisateur qui souhaite souscrire un nouveau prêt au Royaume-Uni. Et cela sans que vous ayez à écrire une multitude de logiques if-then-else intégrées à votre code de traitement, sans avoir à disposer d’applications différentes à chaque couche du Layer Cake.

Cette architecture est incroyablement puissante. AIG, l’assureur mondial, disposait auparavant de 52 systèmes de gestion des sinistres différents à travers le monde. Ils ont regroupé ces 52 systèmes en un seul. Ils appellent cela « One Claim » et utilisent précisément cette architecture pour y parvenir. Si vous envisagez de vous lancer dans la transformation digitale ou de moderniser vos systèmes existants, l’approche « Layer Cake » est absolument essentielle. Elle vous évite de reproduire les structures cloisonnées du passé et vous permet de créer une architecture suffisamment puissante pour s’adapter à la fois aux variations dont vous avez besoin dans votre activité et à la réutilisation dont vous avez besoin au niveau de l’entreprise pour réaliser des économies d’échelle.

La vidéo est terminée.

Organisation du Situational Layer Cake

Le Situational Layer Cake organise les applications en couches afin de faciliter la réutilisation modulaire et de gérer la complexité. Chaque couche a une fonction distincte :

• Couche entreprise (Enterprise Layer) : fonctionnalités principales de Pega Platform™ et ressources réutilisables à l’échelle de l’entreprise. Par exemple, un module d’authentification à l’échelle de l’entreprise utilisé dans toutes les applications de l’organisation.
• Couche division (Division Layer) : composants réutilisables spécifiques à une division. Par exemple, un flux de traitement des sinistres adapté à la division assurance, mais réutilisé dans toutes ses applications.
• Couche application (Application Layer) : implémentations spécifiques à une application qui exploitent les actifs des couches inférieures. Par exemple, une application de service client qui utilise des composants d’authentification et de sinistre partagés, mais ajoute ses propres workflows.
• Couche implémentation (Implementation Layer) : personnalisations pour des scénarios de déploiement spécifiques sans modifier l’application de base. Par exemple, localiser l’application du service client pour une région spécifique en ajustant la langue et les règles réglementaires.

Cette structure en couches favorise la réutilisation modulaire en permettant d’apporter des modifications aux couches supérieures sans affecter les couches inférieures. Lorsque vous devez personnaliser un composant, modifiez-le dans la couche appropriée afin de préserver l’intégrité de la base et de garantir que les composants principaux soient mis à jour dans toutes les applications dépendantes. Pega Platform utilise une conception prescriptive low-code qui fournit des composants standardisés et interopérables afin d’accélérer le développement et de favoriser la cohérence.

Les développeurs créent des applications en assemblant des composants préconfigurés au lieu d’écrire du code manuellement. Cette approche facilite la réutilisation et réduit les délais de livraison. Les fonctionnalités réutilisables sont encapsulées dans des applications modulaires, que vous pouvez empiler pour former des applications « built-on ».

Par exemple, si plusieurs processus métier nécessitent la configuration de réunion, vous pouvez créer une forme intelligente réutilisable qui gère cette fonctionnalité. Configurez la forme intelligente dans App Studio, puis réutilisez-la dans toutes les applications afin d’éliminer les doublons et de simplifier la maintenance.

Le diagramme suivant montre un exemple d’architecture métier qui réutilise le module Meeting dans plusieurs applications :

Vérifiez vos connaissances avec l’interaction suivante :