Bonjour, je suis Don Schuerman, Chief Technology Officer de Pega. Et si vous parlez suffisamment avec nous, vous avez probablement entendu parler du situational layer cake. Non, Pega n'essaie pas de se lancer dans la patisserie. Et oui, c'est peut-être un nom un peu bizarre, mais il reflète une architecture brevetée qui est absolument essentielle à la façon d'envisager votre transformation numérique et la modernisation des systèmes legacy. L'objectif du layer cake est d'équilibrer deux forces souvent concurrentes dans l'entreprise. La première est le désir de réutilisation afin de créer des économies d'échelle et de la cohérence. Mais d'un autre côté, vous devez permettre la variation dont votre entreprise a besoin. Parfois, vous vendez différents produits, vous voulez être compétitif. Parfois, vous opérez dans différentes régions. Vous devez respecter les exigences réglementaires dans ces régions. Ce layer cake permet de les équilibrer différemment des approches traditionnelles. Trop souvent, vous essayez de tout regrouper dans une seule application, et vous vous retrouvez avec un tas de code spaghetti avec tous les if-then-else nécessaires pour gérer les variations, ou alors chaque variation finit par déployer sa propre application et vous vous retrouvez avec 50 à 100 applications différentes, qui font toutes plus ou moins la même chose. Le layer cake permet d'éviter cela. Vous commencez par construire votre application en couches avec une couche d'entreprise. Pensez à tous les éléments qui peuvent être réutilisés dans votre entreprise. Peut-être que ce sont vos structures de données et interfaces. Ou encore la définition d'éléments clés de sécurité dans votre application. Peut-être des composants réutilisables que vous souhaitez rendre disponibles comme bibliothèque de composants prêts à être utilisés, peut-être pour générer un document ou publier certaines informations dans une file d'attente d'événements. Au-dessus de votre application d'entreprise, vous pourriez alors construire une couche avec votre application. Si vous construisez une nouvelle application métier qui gère comment vous intégrez de nouveaux clients. Dans le cadre de cette application, vous définiriez votre workflow, ou ce que nous appelons votre cycle de vie de dossier, avec les étapes que ce nouveau processus métier doit traverser pour atteindre son résultat, sa phase de réalisation. Donc maintenant, j'ai une application centrale qui peut fonctionner pour tout nouveau business. Bien sûr, je n'ai pas que des domaines génériques, j'ai différents produits. Si je suis une banque, j'ai une version prêt de ma nouvelle application métier. Je ne réécris pas toute ma nouvelle application métier, je définis simplement les éléments de cette application qui doivent être spécifiques au prêt, peut-être comment j'approuve le prêt à la fin avec des documents spécifiques et certaines des décisions de souscription que je dois prendre. Et peut-être que j'ai étendu mon activité prêt au Royaume-Uni. Et dans ce cadre, je sais qu'au début du processus, je dois collecter certaines informations distinctes afin de gérer les prêts pour le Royaume-Uni. Maintenant, lorsque l'application est exécutée, le layer cake regarde dans toutes les couches et trouve les éléments les plus spécifiques possibles, et il assemble dynamiquement le bon processus pour un utilisateur essayant de souscrire un nouveau prêt au Royaume-Uni. Et cela se fait sans que vous ayez à écrire une multitude de logiques if-then-else intégrées dans votre code de traitement, ou sans avoir besoin de différentes applications à chaque niveau du layer cake. Cette architecture est incroyablement puissante. L'assureur mondial AIG avait auparavant 52 systèmes de sinistres différents à travers le monde. Ils ont consolidé ces 52 systèmes en un seul, qu'ils appellent One Claim, en utilisant cette architecture exacte pour y parvenir. Si vous envisagez d'entamer votre transformation digitale ou de moderniser vos systèmes existants, l'approche du layer cake est absolument essentielle pour éviter de répéter les silos du passé, mais plutôt construire une architecture qui sera suffisamment puissante pour s'adapter aux variations dont vous avez besoin dans votre business mais aussi permettre la réutilisation au niveau de l'entreprise, afin de réaliser vos économies d'échelle.
