Enterprise Class Structure
Enterprise Class Structure
An enterprise can have a complex organization structure with many locations. For example, an electronics retailer sells mobile devices and laptops in stores, online, and on social media. The electronics retailer needs a way to manage their channels, products, and customers. The customers of the electronics retailer are in different countries. The electronics retailer must maintain compliance with the regulations of each jurisdiction.
With some application development platforms, you must create separate copies of the application for each product, region, or channel. Or, you must create a single application that treats all business transactions the same, regardless of the business context. The result is hard-to-manage enterprise applications that do not scale.
Pega Platform™ enables you to organize your application by using the same dimensions as your business. Pega Platform makes reusing common policies and procedures easy while allowing for differences between products, regions, channels, and customer segments.
Pega Platform supports this capability by using a class hierarchy structure called Enterprise Class Structure (ECS).
You can share any rule placed in an ECS layer across multiple applications. You can adjust existing ECS layers as business operations change. ECS also enforces best practices around reuse and standardization as the system expands to other lines of business.
Note: Each Pega Platform release generates the class structure that reflects best practices available in that release.
Enterprise Class Structure layers
Pega Platform layer
The Pega Platform layer contains the built-in assets necessary for processing cases and other work in Pega applications. This layer also contains the assets Pega Platform uses.
The Organization layer contains the assets used on an enterprise-wide basis. Such assets are rules for enterprise-wide business logic such as standard properties, decision tables, and service level rules. For example, an online retailer reuses a property that holds a customer account number throughout the retailer's business. The applications used across the enterprise can rely on the same account number property without having to make copies of the property in every application.
The Organization layer also contains enterprise-wide data assets such as classes and rules for data stored in the system, and classes and rules for access to data in external systems, via connectors. For example, access to an external customer database is an integration point that may be added to the Organization layer.
The Division layer contains the assets used on a division-wide basis. The division layer is the middle level of the three-level organization hierarchy (Org-Div-Unit) and is available for use in every application.
Assets in the Division layer may apply to a line of business, region, or brand. For example, a line of business wants to reuse a service level rule that defines the expected response time to a customer complaint in all of its applications. Placing the service level rule in the Division layer provides all applications within the division with access to the service level rule through pattern inheritance. This reuse avoids the need to create and maintain separate copies of the service level.
Note: The Division layer is an optional layer. In larger organizations, the Division layer can help to manage the reuse of rules and other application assets.
Framework and implementation layers
The Framework layer contains assets that can be extended in specific implementations. The framework layer may be comprised of one or more generalized applications, such as a standard Pega application for a specific industry, or an extendable custom application.
The Implementation layer defines an application customized for a specific division or line of business. An implementation layer application may extend one or more framework layer applications.
For example, a clothing retailer consists of two brands of stores. One brand focuses on the upscale clothing market, while the other brand runs a value-oriented chain of stores. Each brand needs to manage item returns. The retailer can develop a generalized application that manages clothing returns in the framework layer. Each brand can then create its own implementation layer to customize the returns process. Each customized application contains brand-specific assets, such as styling and policies.
Another example considering an insurance company can be found in the following image.
Note: The framework and implementation layers are relative separations of application assets. The designation of an asset as belonging to either the framework or implementation layer depends on the design of the application. An implementation application for one line of business may belong to the framework layer for another application. For example, a large financial services company creates an auto loan application for a specific division or brand. A second division then extends the application, customizing assets as necessary. For the second division, the original auto loan application is part of the framework layer. For the first division, the application is part of the implementation layer.