Skip to main content

Modules and the Situational Layer Cake

Because you can reuse workflows, data, decisions, case types, and other rules as packaged Modules in Pega applications, this leads to cost and effort savings. 

Pega's Situational Layer Cake approach also helps enterprises to further manage all types of variations, thereby reducing complexity and enabling reuse.

'Layers' can be the differences, or specializations, between:

  • geographies,
  • policies of individual business units,
  • product line variations, 
  • customer segments,
  • other differences.

Thinking of enterprise reuse in terms of modules and layers makes managing the complexity of an application much easier and more effective - making changes in one place means that those changes are reflected wherever that Module is in use within the layers of your application.
 

Layer cake

Traditional Situational Layer Cake

Pega’s Situation Layer Cake approach is perfectly suited for enterprise reuse.

Traditionally, Pega's reusable rules, such as data pages, connectors, and common activities, are saved in a single, large, enterprise reuse layer, or framework layer, so that they can be reused elsewhere. Often, the framework layer is created by a Pega Platform™ or center of excellence (COE) team.  

While many organizations have achieved strong value with a single, large, enterprise reuse layer, this design pattern may result in some of these challenges: 

  • COMPLEX to develop, reuse, and understand because it covers too many functional topics
  • DIFFICULT TO CONTROL without strict governance or change control processes in place 
  • DIFFICULT TO SCALE without additional and expensive resources due to its monolithic nature
  • PREVENTS CONTINUOUS DELIVERY and autonomy of distributed development teams 
     

Modular Situational Layer Cake

A Module-centric design pattern, or 'Modular' Situational Layer Cake, is the optimal way to organize reusable low code assets across the enterprise.

In this design pattern, the enterprise layer is very lightweight, only holding common assets that are applicable across the enterprise, such as UI styling, security, and authentication features.

Instead, Modules contain the majority of the reusable capabilities, which are focused on the needs of a business entity, on system integration, or on utility.

Applications contain the cases and any rules that are specific to that application and that won’t be shared with other applications.

This design pattern offers the following advantages:

  • EASIER TO DEVELOP AND REUSE as a Module covers only one functional topic
  • EASIER TO GOVERN as Modules are 'complete' blocks of functionality
  • EASIER TO SCALE as Modules can be imported and upgraded without regressing the entire application
  • COMPATIBLE WITH CONTINUOUS DELIVERY and autonomy of distributed development teams 
     

Check your knowledge with the following interaction: 


This Topic is available in the following Module:

If you are having problems with your training, please review the Pega Academy Support FAQs.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice