No history yet

Pega Infinity Architecture

The Center-Out Approach

Many organizations build their processes from the inside-out, starting with their core data systems and forcing business logic to conform to them. Others work from the outside-in, creating separate applications for each channel like web, mobile, or call center. The problem? Both approaches create silos and inconsistencies. A customer might get a different answer on the website than they do from a service agent.

Pega's architecture flips this model with a Center-Out approach. Instead of tying business logic to a specific channel or database, it places the logic at the very center of the architecture. This central brain contains all the rules, processes, and decisions that define how your business operates. It dictates the steps for a loan approval, the logic for a customer service case, or the next-best-action to offer a client.

Lesson image

With the business logic centralized, channels become simple windows into that logic. Whether a customer interacts via a mobile app, a web portal, or a chatbot, they are all engaging with the same core set of rules. This ensures a consistent experience everywhere and allows the business to update its processes in one place and have it reflect instantly across all channels. It’s a strategy focused on business outcomes, not technology constraints.

The Situational Layer Cake

To organize this central brain, Pega uses a patented design pattern called the Situational Layer Cake (SLC). Think of it as a stack of layers, where each layer contains a set of rules. The layers at the bottom are broad and reusable across the entire enterprise, while the layers at the top are specialized for specific contexts.

This structure works on the principles of inheritance and specialization. Rules are defined at the most general level possible and are inherited by the layers above. Higher layers can then extend the functionality by adding new rules or specialize it by overriding the inherited rules to fit a specific situation. For example, a global 'New Customer' process defined in the Enterprise layer can be specialized in the 'France' layer to include a country-specific regulatory check without duplicating the entire process.

The goal of the SLC is maximum reuse. You build a rule once at the enterprise level, and it's available everywhere. You only create new rules when a specific situation truly demands a variation.

Traditional vs. Modular Design

The implementation of the Situational Layer Cake has evolved. The traditional approach involved building large, monolithic framework layers. An 'Enterprise' layer might contain thousands of rules for everything from HR to finance to customer service. While this promoted reuse, these massive layers could become cumbersome to manage and update.

The modern approach favors a Modular SLC design. Instead of one giant framework, the enterprise layer is composed of many smaller, independent, and reusable modules. You might have a 'Customer Data' module, an 'Address Verification' module, and a 'Credit Check' module. Each is a self-contained unit that can be independently developed, tested, and deployed.

FeatureTraditional Layer CakeModular Layer Cake
StructureLarge, monolithic layersSmall, focused micro-modules
AgilityLow; changes impact the entire layerHigh; modules can be updated independently
DeploymentSlower; requires testing the whole layerFaster; deploy only the changed module
MaintenanceComplex; dependencies are hard to trackSimpler; clear boundaries and ownership

This modularity makes the entire system more agile. A team can update the 'Credit Check' module without any risk of breaking the 'Customer Data' module. It aligns with modern DevOps practices and allows large enterprises to build and adapt applications at speed, while still maintaining governance and reuse across the organization.