Arquitetura de reutilização modular

A estrutura Pega Situational Layer Cake™ é um modelo arquitetônico fundamental que suporta essencialmente a reutilização modular empresarial. Assista ao vídeo a seguir para aprender sobre a estrutura do Situational Layer Cake:

Transcrição do vídeo

Olá, sou Don Sherman, CTO da Pega, e se você conversa conosco frequentemente, provavelmente já ouviu falar do situacional layer cake. Olha, a Pega não está tentando entrar no ramo de culinária, e sim, talvez seja um nome um pouco engraçado, mas ele reflete uma arquitetura patenteada que é absolutamente essencial para como você pensa sobre sua transformação digital e modernização. O objetivo do layer cake é permitir que você equilibre o que muitas vezes são duas forças concorrentes em seu negócio.

Primeiro, é o desejo de ter reutilização para que você obtenha economias de escala e consistência. Mas, por outro lado, você precisa permitir a variação que seu negócio exige. Às vezes, você vende produtos diferentes. Você quer ser competitivo. Às vezes, você opera em diferentes regiões. Você precisa cumprir as exigências de conformidade regulatória nessas regiões. O modelo em camadas permite que você equilibre isso de uma maneira que as abordagens tradicionais não fazem. Com frequência, você tenta colocar tudo em um único aplicativo e acaba com um monte de código misturado com todas as condições if-then-else necessárias para gerenciar as variações, ou acaba tendo cada variação implantando um aplicativo próprio, e você termina com 50 a 100 aplicativos diferentes, todos fazendo basicamente a mesma coisa.

O modelo em camadas é uma abordagem para evitar isso. Você começa construindo seu aplicativo em camadas com uma camada empresarial. Então, pense nisso como todas as peças que podem ser reutilizadas em sua empresa. Talvez sejam as estruturas de dados e interfaces. Talvez seja a definição de alguns elementos importantes de segurança em seu aplicativo. Talvez você tenha construído alguns componentes reutilizáveis. Você quer tê-los disponíveis como uma biblioteca de componentes para as pessoas usarem, por exemplo, para gerar um documento ou publicar certas informações em uma fila de eventos. Então, acima do seu aplicativo empresarial, você pode construir uma camada com seu aplicativo. Então, digamos que você está construindo um novo aplicativo de negócios. Que lida com a forma como você integra novos clientes. Bem, como parte desse aplicativo, você definiria seu fluxo de trabalho ou o que chamaríamos de ciclo de vida do caso. São as etapas que esse novo processo de negócios precisa passar para alcançar o resultado, a fase de cumprimento. E agora eu tenho um aplicativo central que pode funcionar em novos negócios.

Claro, eu não faço apenas novos negócios genéricos, eu tenho produtos diferentes. Então, talvez se eu for um banco, eu tenha uma versão de empréstimo do meu aplicativo de novos negócios, e não preciso reescrever todo o meu aplicativo de novos negócios. Eu apenas defino as partes desse aplicativo que precisam ser específicas para empréstimos, como talvez a finalização do empréstimo com documentos específicos e algumas das decisões de subscrição que preciso tomar. Talvez eu tenha levado meu negócio de empréstimos para o Reino Unido e, como parte disso, sei que no início do processo preciso coletar algumas informações que são distintas para gerenciar os empréstimos no Reino Unido. Agora, quando o aplicativo é executado, o layer cake olha para todas as camadas e encontra as informações mais específicas possíveis e monta dinamicamente o processo certo para um usuário tentando se integrar. Um novo empréstimo no Reino Unido. E isso acontece sem que você precise escrever uma série de lógicas if-then-else embutidas no seu código de processamento, sem precisar ter aplicativos diferentes em cada camada do layer cake.

Essa arquitetura é incrivelmente poderosa. A AIG, seguradora global, costumava ter 52 sistemas de sinistro implantados em todo o mundo. Eles consolidaram esses 52 sistemas de sinistro em um só. Eles o chamam de One Claim, usando essa arquitetura exata para fazê-lo. Se você pensa em fazer transformação digital ou modernizar seus sistemas legados, a abordagem layer cake é absolutamente essencial para garantir que você não repita as estruturas isoladas do passado, mas sim construa uma arquitetura que seja poderosa o suficiente para se adaptar tanto às variações que você precisa em seu negócio quanto à reutilização que você precisa em um nível empresarial para alcançar suas economias de escala.

Você chegou ao final do vídeo.

Organização do Situational Layer Cake

O Situational Layer Cake organiza aplicativos em camadas para permitir a reutilização modular e gerenciar complexidades. Cada camada serve a um propósito distinto:

• Camada empresarial: Principais recursos da Pega Platform™ e ativos reutilizáveis em toda a empresa. Por exemplo, um módulo de autenticação para toda a empresa, usado em todos os aplicativos da organização.
• Camada da divisão: Componentes reutilizáveis específicos de uma divisão. Por exemplo, um fluxo de processamento de sinistros adaptado para a divisão de seguros, mas reutilizado nos aplicativos.
• Camada do aplicativo: Implementações específicas de aplicativos que aproveitam ativos de camadas inferiores. Por exemplo, um aplicativo de atendimento ao cliente que usa autenticação compartilhada e componentes de sinistros, mas adiciona fluxos de trabalho próprios.
• Camada de implementação: Personalizações para cenários de implantação específicos sem alterar o aplicativo base. Por exemplo, localizar o aplicativo de atendimento ao cliente para uma região específica ajustando a linguagem e as regras regulatórias.

Essa estrutura em camadas suporta reutilização modular, permitindo mudanças em camadas superiores sem afetar as inferiores. Quando você precisa personalizar um componente, modifique-o na camada apropriada para preservar a integridade da base e garantir que as atualizações dos componentes principais se apliquem a todos os aplicativos dependentes. A Pega Platform usa design low-code e prescritivo que fornece componentes padronizados e interoperáveis para acelerar o desenvolvimento e promover a consistência.

Os desenvolvedores constroem aplicativos montando componentes pré-configurados, em vez de escrever código manualmente. Essa abordagem melhora a reutilização e reduz o tempo de entrega. Recursos reutilizáveis são encapsulados em aplicativos de módulo, que você pode empilhar para formar aplicativos build-on.

Por exemplo, se vários processos de negócios exigirem configuração de reuniões, você pode criar uma forma inteligente reutilizável que gerencia essa funcionalidade. Configure a forma inteligente no App Studio e, em seguida, reutilize-a em aplicativos para eliminar duplicação e simplificar a manutenção.

O diagrama a seguir mostra uma arquitetura de negócios de exemplo que reutiliza o módulo Meeting em diferentes aplicativos:

Verifique seu conhecimento com a seguinte interação: