The Evolution of the Enterprise Class Structure

By David McPhail, Sept 2018

The Enterprise Class Structure (ECS) is the core foundation on which Pega applications are built.  It is one of the most critical components to define as a part of a new Pega implementation, and can have a significant effect on the future state of an organization’s strategy for using Pega.  Get it wrong, and you can cause future problems. Future-proof too much and you end up over-architecting and creating solutions or layers that are costly and difficult to maintain.

The following article speaks to my years of experience as a Principal LSA and pulls from sources from the Pega Community and Academy, including the updated LSA course focusing on Pega 7.3 and beyond.

These are a few of the topics and concepts that you should be familiar with:

• Classes
• Inheritance
• Implementation Layer
• Enterprise & Divisional Layering
• Solution Frameworks
• Application Rules & Rulesets
• Situational Layer Cake & Specialization
• Rule Resolution

The ECS is a well-known Pega Pattern that has matured over the years.  Prior the ECS, applications were often built in silos with little to no reuse value realized (or it was difficult to manage the reuse chaos).  

Centers of Excellence (CoEs) were often set up to add a layer of governance, yet a mature organization was needed—and needed to be a priority—to make them effective. Other common problems: there were often no wizards, or tooling was weak and the basic foundations of an application had to be keyed in manually.  

Enter the Framework layer and the maturity of the Application Profiler and DCO.  As Pega has matured as a platform, so has the tooling and patterns to define applications.  Solution Frameworks began to emerge and the concepts of Built on Applications gained traction.  Today there are almost 100 different Solution Frameworks that a customer can leverage across multiple domains.

But even though the ECS did mature and best practices emerged, a few core problems took hold. The most notable problem: the overuse of the framework layer and the lack of understanding of what should be in the enterprise layer.

Overuse of the Framework Layer (FW)

Overuse of the Framework Layer (FW) occurs when you create a layer that mirrors an implementation layer.  It has been long ingrained in us that we must keep the Implantation Layer light, meaning that there should be minimal rule assets created in this layer and that they must live in the FW layer. While this sounds good in practice, it often creates problems, in that you must create the solution to support the framework to support the implantation.  

Framework layers do make sense if there is a need to create a common layer.  Take, for example, a typical Property & Casualty insurance company that sells Home and Auto insurance. They offer their insurance products individually  (monoline) or as packages, and they may want to up sell an Umbrella product. They also sell Workers Comp and also offer various Commercial Line Products like a Business Owners Policy (BOP). They also may want to sell their Auto Insurance to a fleet of cars but do not have any solution frameworks.  The key point to observe here is that a Product is at the base of what this company does—and that can be defined as a framework with multiple implementations, based on the line of business they are trying to support. A framework layer here makes sense.

Let’s look at another example, this time of a Healthcare Insurer.  Variables such as the size of the company, the state they do business in, and changes in government regulations, may add some complexity.  But let’s say for now that this Insurer sells Retail insurance; has PPO and HSA products; and sells Small Group and Large Group insurance as well. They also have the Pega® Foundation for Healthcare and Pega® Product Composer for Healthcare (PCS) products.  The implementation is built on PCS—but the question is: is a framework layer needed here?

The answer: not really. Creating a FW here only creates a layer that adds complexity to the stack, and that over-complicates a solution that could be avoided by just having the implementation layer.  In a lot of ways, the Pega Solution layer is the true framework layer.

An argument could be made that a Framework layer should still exist at some level—perhaps not the low level classes, and possibly the layer is more generic, like a place to house truly reusable assets.  This is a pattern that I would stand behind, although some customers may not need it. Also, if you are in business to create reusable Pega assets, then yes, a framework layer applies.

Taking Advantage of the Enterprise Layer

It is often difficult to determine what goes in the Enterprise Layer, and companies quite often fail to understand which assets they have that are truly reusable.  In theory, such an asset would be anything common to the enterprise. Most often, this would be in the form of branding.

Architects too often place things in this layer that should not go in this layer (e.g., rules with implantation logic are put in the enterprise ruleset).  This may cause problems if another application or process does something differently. Ideally each rule would be very generic, or a stub, and the rule would be placed at the right layer for true value reuse. Still, however, I would argue that such rules don’t belong in the Enterprise layer.

There may be times that you see a pattern that can be reused.  This kind of instance would be a good candidate for the enterprise layer.  Here’s an example: I want to run a collection but I have to create an activity rule each time I do this.  As a best practice, I want to limit creation of activities, so I would create an activity at the enterprise layer that takes in a parameter as the collection rule to run, and run the collection based on the parameters passed in.  I may also want to run a data transform before or after or control the context. Will it run in the primary page or will it run on page I pass in as a parameter?

Services may also be a good candidate to place at the Enterprise Integration layer. However, if the service is not the source of truth, then you’re probably better off putting it in the Divisional Layer or the Implementation Layer, depending on where you will see the best value.

Functions, custom code, common reports are other strong candidates to put at the enterprise layer, along with patterns like Dynamic Class Referencing. Or Global Values could be defined here. Data models may also make sense to put here, but that also depends on the levels of specificity.

Other Considerations

Let’s discuss the Division layer.  By definition, “the division is the middle level of the three-level organization hierarchy and is available for use in every application.” This could lock an application to a specific division of work, which often is the desired outcome. But what if the application you are building is something that’s meant to really cut across the enterprise?  Does it make sense in that case to lock down the ECS to a specific Division? Does this impact the reusability of an application? Does this in the end make for an overly complex solution? I don’t have answers to these questions, but I do know that such questions do get asked time and time again, and I’m seeing customers choose not to use their organizational hierarchies to define their ECS, but rather to use something more generic, or something that aligns to what they are trying to do.  It’s food for thought: these ECS conversations can be tough at times!

Conclusion

The Enterprise Class Structure has evolved tremendously over the past decade.  The technology has gotten better, Solution Frameworks have evolved, and patterns and understanding has really taken shape.  We’ve also learned from what we knew in the past about how to model an ECS, putting those lessons to work moving forward. We are now moving towards the concept of building on applications, and creating FW layers only if absolutely required, thereby helping to more simply building architectures in a world based on change.

I wrote this article to share my experience and lessons learned, knowing that—as we bring on new clients—new people who have never been exposed to this aspect of the design process are now going through this part of an implementation.  Writing this also allows me—someone who has done this over and over again—to unlearn what I have done, and to re-learn how to approach something new. I leave now hoping to spur a conversation and drop a few best practices to consider.

I want to thank my college, Sigang HU, another Principal Consultant at Rulesware who recently was Re-Certified under CLSA 7.3, for informing me of the new design considerations.

Best Practices

1. Ask questions when defining the ECS.  Engage with the customer in understanding the business and the problem you are trying to solve. There is a big difference, for example, in defining an ECS for a small call center of a few hundred front office employees that’s only trying to improve their front office, compared to a large corporation with call centers throughout the world and different lines of business to support, along with the need to support different parts of an operation. Make sure that the client is a part of this journey.
2. Only create a framework if you know you need one. Do not create a framework for the sake of future-proofing. Depending on future requirements may be more appropriate. Maintaining a framework comes at a cost that cannot be justified without evidence for its need in the near future.
3. Only create a framework when it is clear at the start of a project that an application needs to be specialized based on organization or division.
4.  Avoid having to make multiple updates to every specialization of a specific rule, be careful not to over-extend the case types when using pattern-inheritance specialization. Also, do not rely heavily on direct-inheritance, subclass specialization.
5. If numerous subclasses of a specific framework class use polymorphism to override a base class rule, you may need to update each override rule due to some change.  Avoid having to make multiple updates to every specialization of a specific rule, be careful not to over-extend the case types when using pattern-inheritance specialization.
6. Do not rely heavily on direct-inheritance, subclass specialization. If numerous subclasses of a specific framework class use polymorphism to override a base class rule, you may need to update each override rule due to some change.