Modular reuse architecture

The Pega Situational Layer Cake™ structure is a foundational architectural model that inherently supports modular enterprise reuse. Watch the following video to learn about the Situational Layer Cake structure:

Video transcript:

Hi, I'm Don Sherman, Pega CTO, and if you talk to us enough, you've probably heard about the situational layer cake. Now, no. Pega is not trying to go into the baked goods business, and yes, it's maybe a little bit of a funny name, but it reflects a patented architecture that is absolutely essential to how you think about your digital transformation and legacy modernization. You see, the goal of the layer cake is to allow you to balance what are often two competing forces in your business.

First, it's the desire to have reuse so that you get economies of scale and consistency. But on the other hand, you need to allow for the variation that your business requires. Sometimes you sell different products. You want to be competitive. Sometimes you operate in different regions. You need to adhere to the regulatory compliance needs in those regions. The layer cake allows you to balance those in a way that traditional approaches don't. Too often you're either trying to stick everything in a single application and you end up with a bunch of spaghetti code with all the if-then-else needed to manage the variations, or you end up having each variation deploy its own app, and you end up with 50 to 100 different apps, all of which do mostly the same thing.

The layer cake is an approach to avoiding that. And you start by building your application in layers with an enterprise layer. So think of this as all the pieces that can be reused across your enterprise. Maybe that's your data structures and interfaces. Maybe it's the definition of some key security elements in your application. Maybe you've built some reusable components. You want to have available as a component library for people to use, maybe like how you generate a document or publish certain pieces of information to an event queue. So, above your enterprise application, you might then build a layer with your application. So, say you are building a new business application. That handles how you onboard new customers. Well, as part of that application, you would define your workflow or what we would call your case lifecycle. For the steps that that new business process needs to go through in order to reach its outcome, its fulfillment stage. And so now I have a core application that can work across new business.

Now, of course, I don't just do generic new business, I have different products. So maybe if I'm a bank, I have a lending version of my new business application, and I don't rewrite my whole new business application. I just define the pieces of that application that need to be specific for lending, how maybe I fulfill the loan at the end with specific documents and some of the underwriting decisions I need to make. Maybe I've taken my lending business. Into the UK, and as part of that, I know that at the beginning of the process, I need to collect some information that is distinct in order to manage the loans for the UK. Now, when the application is run or executed, the layer cake looks across all the layers and finds the most specific stuff possible and it dynamically assembles the right process. For a user trying to onboard. A new loan in the UK. And it does that without you having to write a bunch of if-then-else logic embedded into your processing code, without having to have different applications at each layer of the layer cake.

This architecture is incredibly powerful. AIG, the global insurer, used to have 52 different claim systems deployed across the globe. They consolidated those 52 claim systems down to one. They call it One Claim, using this exact architecture in order to do it. If you're thinking about doing digital transformation or modernizing your legacy systems, the layer cake approach is absolutely essential to ensure you don't repeat the siloed structures of the past, but actually build an architecture that's powerful enough to flex for both the variations you need in your business and the reuse that you need in an enterprise level to achieve your economies of scale.

You have reached the end of the video.

Situational Layer Cake organization

The Situational Layer Cake organizes applications into layers to support modular reuse and manage complexity. Each layer serves a distinct purpose:

• Enterprise Layer: Core features of Pega Platform™ and enterprise-wide reusable assets. For example, a company-wide authentication module used across all applications in the organization.
• Division Layer: Reusable components specific to a division. For example, a claims processing flow tailored for the insurance division but reused across its applications.
• Application Layer: Application-specific implementations that leverage lower-layer assets. For example, a customer service app that uses shared authentication and claims components but adds its own workflows.
• Implementation Layer: Customizations for specific deployment scenarios without altering the base application. For example, localizing the customer service app for a specific region by adjusting language and regulatory rules.

This layered structure supports modular reuse by enabling changes at higher layers without affecting lower ones. When you need to customize a component, modify it in the appropriate layer to preserve the integrity of the base and ensure that updates to core components apply across all dependent applications. Pega Platform uses low-code, prescriptive design that provides standardized, interoperable components to accelerate development and promote consistency.

Developers build applications by assembling preconfigured components instead of writing code manually. This approach improves reuse and shortens delivery time. Reusable features are encapsulated in module applications, which you can stack to form built-on applications.

For example, if multiple business processes require meeting setup, you can create a reusable smart shape that handles this functionality. Configure the smart shape in App Studio and then reuse it across applications to eliminate duplication and simplify maintenance.

The following diagram shows a sample business architecture that reuses the Meeting module across multiple applications:

Check your knowledge with the following interaction: