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.

Organization layer

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.

Division 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.