pega 7: architecture and technical brief 7 - architecture and technical brief.pdfpega 7 is an...

Pega 7: Architecture and Technical Brief

CONFIDENTIAL

dfgfg

1

Copyright © 2014 Pegasystems, Inc. All rights reserved. Confidential.

Table of Contents Abstract ..................................................................................................................................................................... 2

Purpose and Structure of Technical Brief.................................................................................................... 2

Section 1: An Introduction to Pega 7 ............................................................................................................. 4

Section 2: Pega 7 Model-Based Application Development ................................................................... 8

2.1 An Example of a Model-Based Strategic Business Application ............................................... 9

2.4 Defining an Application and Grouping Models ........................................................................... 11

2.5 Situation-Based Modeling ................................................................................................................... 14

2.6 Decision Management and Models.................................................................................................. 18

2.7 Declarative Computation Models .................................................................................................... 19

2.8 Design Validation ................................................................................................................................... 20

Section 3: Pega 7 Unified Architecture and Dynamic Runtime ........................................................ 21

3.1 Overview of the Pega 7 Unified Architecture and Dynamic Runtime ................................ 22

3.2 Dynamic Model Selection .................................................................................................................... 24

3.3 Dynamic Working Memory, Caching and Persistence ............................................................. 27

Section 4: Pega 7 Dynamic User Experience, Including Mobile and Social .................................. 29

4.1 Dynamic User Experience ................................................................................................................... 30

4.2 Mobile Applications .............................................................................................................................. 35

4.3 Integrated Social Collaboration ........................................................................................................ 37

Section 5: Pega 7 Enterprise-Class Applications.................................................................................... 39

5.1 Enterprise-Class Security.................................................................................................................... 39

5.2 Enterprise-Class Deployment and Manageability in the Cloud and On Premises ........ 39

5.3 Enterprise-Class Reliability and Scalability ................................................................................. 41

5.4 Enterprise-Class Integration ............................................................................................................. 42

Section 6: Pega 7—The Platform for Strategic Business Applications .......................................... 42

6.1 The Broader Capabilities of Pega 7 ................................................................................................. 43

Conclusion............................................................................................................................................................. 44

2


Abstract Pega 7 is an application development platform intended for large enterprises seeking to build, deploy, and evolve strategic business applications. Strategic business applications are those that embody the key differentiators and innovations for the activities of an enterprise1. They frequently engage users—customers or employees—through a variety of channels, including mobile devices and social channels. Whether deployed on-premises or in the cloud, these are applications which need to evolve and continually improve as the enterprise, its customers, and its competitive environment change. Pega 7 enables the development and deployment of strategic BPM, dynamic case management, and decision management applications broadly and in combination—all through a single, unified model-based platform. Pega 7 employs a 100 percent model-based application development approach and dynamic runtime architecture in order to provide both the agility and productivity of model-based development as well as optimized run-time performance. The Pega 7 platform supports rich, dynamic, and situation-based user experiences across all devices and channels for user-centric applications that lead to successful operations and engaged customers – perhaps the most important strategic goal today. Applications can be specialized by multiple dimensions to meet the varied needs of multiple geographies, customer segments, product lines, and channels. Enterprise-class Quality-of-Service (QoS) features ensure secure, scalable, reliable and manageable production performance for both Pega Cloud and on-premises deployment. By providing these capabilities in a unified, model-based, and cloud-enabled environment, Pega 7 helps enterprises build and change strategic applications much faster than conventional programming. Unique re-usable Pega 7 technology scales from initial projects to enterprise-wide programs and reduces the total cost of ownership of applications that meet the needs of diverse business units, products, and customers.

Purpose and Structure of Technical Brief This technical brief introduces the capabilities and technology of Pega 7. It includes the following:

Section 1: An Introduction to Pega 7—Provides an overview of how the Pega 7 platform delivers rapid time-to-value and enterprise application agility through its unified architecture, model-driven development, and rich functional capability.

1 “What is Strategy”, Michael E. Porter, Harvard Business Review, reprint 96608.

3


Section 2: Pega 7 Model-Based Application Development—Explains Pega 7’s 100 percent model-based application development approach. It discusses the productivity features, breadth of integrated models including predictive analytics, and the unique strengths for specializing applications by geography, customer, product, and channel, for example. Section 3: Pega 7 Unified Architecture and Dynamic Runtime— Explains Pega 7’s unified architecture and dynamic runtime which provides both the agility of model-based development as well as optimized run-time performance. Section 4: Pega 7 Dynamic User Experience Including Mobile and Social— Demonstrates how the Pega 7 platform supports dynamic situation-based user experiences across all devices and channels. Section 5: Pega 7 Enterprise-Class Applications— Describes the enterprise Quality-of-Service (QoS) features for both Pega Cloud and on-premises deployment. Section 6: Pega 7—The Platform for Strategic Business Applications— Explains the broader context of the Pega 7 platform and how it supports multi-customer engagement.

4


Section 1: An Introduction to Pega 7 The Pega 7 platform provides the enterprise unmatched application agility because it is unified, model-based, and rich in development and deployment capabilities. Pega 7 helps enterprises automate, integrate and improve strategic front and back-office business operations. It is a unified platform with industry-leading capabilities in business process management (BPM), dynamic case management (DCM) 2 , analytics-driven decision management (DM), mobility and user experience (UX), and social collaboration.

Figure 1: Pega 7 Unified Platform

Figure 1 shows at a high level the unified Pega 7 platform in the context of the strategic business applications developed and deployed on the platform; the omni-channel interfaces available for user interaction; and the existing enterprise systems of record which are integrated with the strategic applications through the Pega 7 platform. The applications may be full custom applications for an enterprise or customized versions of vertical industry or horizontal applications from Pega. “Unified” means that the Pega 7 platform is not a conglomeration of separate systems with differing development and deployment approaches. Pega 7 has a singular 100 percent model-based approach to application development and deployment in which all models defining the application are uniformly built, managed, deployed, and monitored. Whether an application capability is usually considered to be part of BPM, DCM, DM,

2 Don Schuerman, Ken Schwarz, and Bruce Williams, Dynamic Case Management for Dummies

http://www.pega.com/resources/dynamic-case-management-for-dummies, John Wiley & Sons, 2014

http://www.pega.com/resources/dynamic-case-management-for-dummies

5


UX, or integration, the models can be mixed and customized to the exact needs of the enterprise. “Omni-channel” means that the same experience, capabilities, analytics, and content can be accessed and used across all interaction channels and devices. A user can start an interaction in one channel and switch to another midway through the process. For example, a customer can start a product selection on a mobile device and then complete it on the desktop using web self-service or on the phone with a customer service representative (CSR). No matter how many channels are used, Pega 7 maintains the context of the interactions for all participants. 100 percent model-based application development provides outstanding productivity and collaborative agility between the business and technology teams. A model is a visual and/or form-based definition of an application component at a level higher, less technical, and closer to business semantics than code. Unlike code, the visual models are accessible to both technology and business staff. Like code, models can be shared, versioned, and used in an agile development process.

The Pega 7 model-based approach enables applications to be easily built to support large numbers of specializations according to factors such as customer status, product type, and geography while also providing significant reuse and deployment flexibility. These applications can also evolve in an agile and incremental manner.

Figure 2: Pega 7 “Situational Layer Cake”

Figure 2 shows a Pega 7 “Situational Layer Cake” in which sets of models are organized in versioned layers. Common models are located in the lower layers while new functionality or specializations reside in the higher layers. This structure allows

6


common assets to be easily reused while also enabling each business area to build the specializations they need for strategic differentiation for their market, products and customer segments, for example. Figure 2 shows how an enterprise has built its applications to be specialized across different regions in North America and Europe with a layer of enterprise-wide standards and then standard policies and procedures for each of North American and Europe. Also illustrated are how new or updated models can be layered as a new version while still reusing those models from the previous version that have not changed. Every time the application interacts with a user or advances a case or process, the platform dynamically selects the policy and procedure that is most relevant to the situation at hand. This is especially useful for the rapid creation and deployment of pilots to test new capabilities as is shown for the pilot office in Figure 2. A specific set of pilot users can be designated to experience the pilot, while other users continue with their existing version. To best leverage collaboration between the business and technology teams, Pega 7 supports a “case-first” approach in which application requirements are captured as a case, which models how work is to be done in a way that is intuitive to business people. It is a high-level picture of how work is driven from inception to resolution. A case is a unit of work intended to achieve a business outcome, such as resolving a customer service request. A case can include both structured and ad hoc processes.

Figure 3: Pega 7 Model-Based Development Figure 3 shows the case model for employment application at the top. The case consists of a set of stages across the top which track the case through its lifecycle. Beneath each stage are steps which represent the business activities to be performed within that stage. Once a case is defined at the level of stages and steps, the more

7


detailed application models can then be built in the context of the high-level case model. Because the high-level model is universally understood, its use as the design center facilitates effective communication and business-IT collaboration. Figure 3 shows a user interface model and a process model linked to specific steps. Other models such as data models, decision models, integrations to systems of record, and models defining APIs are created to complete the case or reused from other layers in the application.

The key to high productivity in Pega 7 is that models can be used to build the entire application while still having efficient executable code automatically generated and executed directly from the models. This removes any need to develop at the programming language level. Changes to models can be incrementally deployed without a need to “rebuild” the application for deployment. With the optimized dynamic execution of the Pega 7 platform, all of the advantages of agile, model-based development are realized with optimized performance. Dynamic runtime self-assembly of applications provides implementations unique to the specialized needs of customers and enterprise users. Optimized deployment and runtime strategies support both rapid incremental change and high performance. High run-time performance is achieved by avoiding the performance penalty associated with conventional BPM model interpreters. Pega 7 has no runtime model interpreter; rather, it compiles models as needed into standard Java for superior performance, including the optimization techniques of the Java Virtual Machine (JVM). A new or changed model is deployed and then compiled when needed for execution. This is a major difference between Pega 7 and other model-based platforms. It is the only way to provide the benefits of model-based development with the scalability and efficiency of an application written directly in Java or other conventional programming language. Deployment of Pega 7 applications can be in Pega Cloud or on premises, including private clouds. Quality-of-service (QoS) is provided with scalable and high-availability architectures. Because the execution code is generated, best-practice security is built into the application.

Pega Cloud provides a virtual private cloud for Pega 7 platform applications. It leverages the cost, reach, and availability benefits of a public cloud, but provides a dedicated infrastructure for each enterprise customer to assure security, compliance, and performance. Pega Cloud runs on Amazon’s industry-leading Amazon Web Services infrastructure. Pega Cloud on AWS allows Pega 7 and its applications to scale up and down to meet clients' changing needs. As a unified platform, clients can move their applications between cloud, on-premises and hybrid environments as business needs evolve.

Pega application monitoring is provided by the Predictive Diagnostic Cloud, a Pega Cloud-hosted, turn-key, software-as-a-service (SaaS) application that analyzes Pega business applications for possible issues, predicts likely points of failure and

8


recommends remediation actions. Both cloud and on-premises applications can be monitored. A version for on-premises usage is also available.

The following sections provide greater details about these capabilities and the technologies supporting them. They will help you understand how Pega 7 uniquely enables the rapid creation of mission-critical applications that can simultaneously support many specialized variations and still easily evolve to meet changing business requirements.

Section 2: Pega 7 Model-Based Application Development Pega 7’s model-based application development provides the following key benefits:

Collaboration—Using models for application definition facilitates collaboration between the business and technology teams as they provide a common language and visual representations. The ability to quickly move the models into execution for feedback from the business stakeholders provides great agility to the development process. Additional features available for collaboration include integrated requirements and specifications gathering and management, automatic generation of documentation, and explicit support for agile methodologies including sprint and backlog management.

Reuse—The Pega 7 environment is entirely defined through models. Models range from those that are fine-grained (a single data item) up to fully defined case flows. Models define every process, rule, UI form or element, data, back-end integration, analytics, etc.—literally every capability in the platform is available as a configurable model. Each of these models can be reused in additional applications and contexts, but more importantly, any model can be specialized and extended for other uses. Models are easily customized to support large numbers of variations according to factors such as customer status, product type, and geography. This provides natural support for a layered approach to reuse anywhere within the enterprise as well as incorporating external partners in streamlined processes.

Outstanding productivity—The key to Pega 7 productivity is the automatic generation of low-level code from high-level business-oriented models. This applies to every single component of the application including process, user interface, mobile app, and even integration. Non-procedural declarative computation models provide a unique productivity benefit as the computation result is automatically updated without explicit programming. Reuse also contributes significantly to productivity.

Both automatic code generation and reuse improve quality and reduce testing as well. A significant advantage of building applications as models rather than low-level procedural code is that many errors can be identified at model design-time

9


making application testing much easier. Pega 7 provides a rich set of design “guardrails” to analyze the application models for errors and inconsistencies even before they are tested.

Integrated requirements and specifications—Pega 7 Designer Studio supports

business-IT collaboration as well as rapid and accurate development through its Direct Capture of Objectives (DCO) capabilities. DCO supports the entry of customer objectives (such as requirements), linked directly to the specification and models to implement these objectives. The DCO application profile is a collection of business-related information that describes the cases, specifications, requirements, participants, and collaborators that are associated with the application. This approach encourages business analysts, architects, and other project members to work collaboratively and iteratively, increasing the likelihood of a successful implementation because core business questions are asked and discussed, and then the answers are captured.

Auto-documentation—Pega 7 Designer Studio supports the automatic generation of documentation from the models for review, collaboration, and compliance. The documentation includes inventories of models as well as visual elements such as flows and entity-relationship diagrams for data models. Objectives and specifications entered during the models’ creation and updates are included, providing a versioned history of the supporting information for the models and applications.

Easy application evolution—The model-based approach provides much greater clarity as to what changes are needed for an application to meet a new business need. The specialization and reuse capabilities make it easy to build on existing models without disrupting current capabilities. Pega 7 has a rich versioning and deployment model including no-downtime upgrades for high availability, which provides the infrastructure for application evolution.

2.1 An Example of a Model-Based Strategic Business Application To make the discussion more concrete, this section introduces an example to be used through the rest of this paper. It represents a real use case for Pega 7 customers in the financial industry. The capabilities of Pega 7 demonstrated in the examples all have analogs in other industry verticals such as insurance, healthcare, telecommunications, energy, government, life sciences, and manufacturing.

Consider the needs in a retail bank for selling and providing a new product to a customer, who might be an existing or a new customer. This process is called “customer onboarding” and is critical to both revenue generation and customer satisfaction. The role of this example Pega 7 application is to provide the front-office

10


application for use by both the customer and by bank employees. The focus here will be on the mortgage product case, i.e. the case when the customer desires a new mortgage, and the bank’s objective is to ultimately issue the mortgage.

Figure 4: Onboarding for Retail Banking Application In line with the definition of a case as stages, Figure 4 shows the retail customer with multiple channels to interact with the bank, the bank’s CSRs, and the stages of onboarding for a mortgage.

11


Figure 5: Onboarding for Retail Banking Models Similar to the employment case in Figure 3, Figure 5 shows the retail mortgage onboarding case as a model. At the top of the figure are the stages for the case with the steps below. Figure 5 shows a process model for collecting customer goals for the needs assessment with a user interface model used in this process. A decision model is referenced for prioritizing various mortgage loan options for a recommendation. (Decision models are discussed in more detail in section 2.6.) Given this example case, we will next look at how models are used to build applications with layers of specialization.

2.4 Defining an Application and Grouping Models Pega 7 models are grouped together to define an application, such as customer onboarding. That is, the case, process, user interface, data, decision table, and other models defined for a specific business application can be grouped together for deployment as an application. Figure 6.a shows the models from Figure 5 along with others bundled together into such a group. As models are often called rules in Pega 7, the group of models is called a ruleset.

12


Figure 6: Pega 7 Application Definition

a. An Application as a Group of Models (a Ruleset)

b. An Application as Layered Groups of Models (Rulesets)

13


c. An Application as Layered Groups of Models (Rulesets) with Versions

d. Multiple Applications from Rulesets Multiple models grouped into a ruleset can be updated, versioned, and deployed together. This supports management of an entire application or other combination of models that should be maintained as a unit.

14


Often there are enterprise standards for applications, such as standard portal screens, standard corporate data models, and standard security enforcement. These standards can all be described as Pega 7 models, put in a ruleset, and then be included in the definition of each application to enforce the standards. This provides a key ruleset layering technique as illustrated in Figure 6.b where the onboarding rules are layered in a stack on top of both the retail banking standards and enterprise standards rulesets. Furthermore, the rulesets can be versioned by three levels of major, minor, and revision versions for deployment and application evolution. Rulesets are the unit of deployment to a Pega 7 instance. Figure 6.c shows a major application version with a minor version ruleset “layered” on top. This illustrates that an application can consist of multiple rulesets where the individual rulesets are used to group models by function and by version. Models in a minor version of the same name as the major version take precedence for execution, thus facilitating enhancements or patches by just deploying the additional ruleset. More generally, Pega 7 provides reusability of application components by including the same ruleset in multiple applications. For example Figure 6.d shows two different applications, the commercial banking and the retail banking applications, where the enterprise standards are shared, but the commercial and retail applications have different onboarding models and additional standards. A special “builds on” relationship allows the easy sharing of shared layered rulesets, such as the “Retail Standards” application which builds on the “Enterprise Standards” application. Access control starts at the application level, so a specific user or user group could process onboarding for both commercial and retail customers using the Pega 7 applications, or be restricted to processing of onboarding to just one of the applications according to the access control settings. The grouping of models into versioned and layered rulesets for applications supports reuse, access control, and the deployment process. A user (or client API) is given access to one or several applications. A ruleset, sharable across applications, includes those models which would likely need to be changed together and deployed together for an incremental update to the application. A pilot deployment for new functionality or a fix can be easily created by defining a new application with the updated higher-version ruleset and then giving access to the pilot deployment’s stakeholders.

2.5 Situation-Based Modeling Pega 7 has a rich mechanism for creating applications that support many variations of an enterprise’s business processes. For example, when the customer onboarding process varies by geography (e.g. state or country); when the loan origination process varies according to whether it is for a home loan or car loan; or when the offers available to a customer differ according to whether she is a preferred or non-preferred customer.

15


We have seen how models can be grouped into rulesets for reuse and deployment as an application—and by the choice of rulesets deployed can create specialized applications. However, the most important way of creating situational applications is through the use of model classes. When a model is created, it is placed in a hierarchical name space of classes— similar to classes from object-oriented programming languages in that the hierarchy defines inheritance—but fundamentally different in that the objects of concern are all forms of models, not procedural programming language objects. Inheritance means that if a particular named model is referenced, the reference is resolved by looking first in the current class; if not found it looks in the parent class; and if not found there, then in the grandparent class, and so on. And for any model in a parent class, a more specialized model can be created in a child class. Classes are most often created automatically using the tools in the Pega 7 Designer Studio. For example when a case type such as Retail Onboarding is defined in Designer Studio along with its subcases for specific situations such as car loans or home loans, the classes for case models including associated data properties are automatically generated. Figure 7.a shows such a class structure. Figure 7: Specialization of Models

16


a. Class Hierarchy of the Retail Onboarding Cases

b. Class Definition with Inheritance from Two Parents

17


c. Circumstancing for Fine-Grained Control of Model Applicability

This name space dynamically spans all of the models across all of the rulesets included in an application. The inheritance shown is the primary inheritance structure in Pega 7, but there is a secondary inheritance as well, which refers to an alternate class for model inheritance. It is secondary because during dynamic model selection this alternate class is searched second, after the primary class inheritance. (Primary inheritance is called “pattern-based” in Pega 7 while secondary inheritance is called “”direct”.) Secondary inheritance is commonly used to allow classes to inherit from the Pega 7 core classes such as for work items. Work items are the business-meaningful task types and objects processed in a Pega 7 application, such as the onboarding case, the mortgage subcase, and the flows supporting them. These built-in classes have a name space defined by Pega. Secondary inheritance is also used to inherit from reusable frameworks which have their own separate hierarchical name space.

For example, as shown in Figure 7.b, the FinCo company has a class for company-wide models and, using primary inheritance, defines specialized classes for each of the US and EMEA divisions. Each division has a class for its own specialized onboarding models. Secondary inheritance in Figure 7.b allows the US and EMEA models to inherit from a common financial onboarding framework. The framework onboarding class is itself in the financial framework through primary inheritance, and it inherits from the Pega 7 work item class through secondary inheritance. For finer-grained definition of when a model should be used, a set of circumstances can be defined which must be true for the model to be used. Such circumstancing is most typically used for situations where just a few out of a large number of alternative values require unique handling. For example, if just a few U.S. states have unique handling for a portion of the loan origination process, such as unique compliance regulations as shown in Figure 7.c, circumstancing can be used. Circumstancing can also be used to specify that certain models have specific effective dates either from a given date forwards or for a specified date range. These date-driven circumstances can be used for advanced deployment of new models that should take effect at a specific date and time. At runtime, models are selected for execution according to these structures of classes with primary and secondary inheritance, versioned groups of models (rulesets), and circumstances. The net effect is that very rich applications can be created with significant reuse and modularity for development and deployment. (The mechanism for run-time “self-assembly” of the application is explained in more detail in section 3.2.)

18


2.6 Decision Management and Models

Pega 7 Decision Management (DM) uses business rules and predictive analytics data science to provide automated decision-making and recommendations such as the Next-Best-Action for a CSR or a customer using a self-service application. These are key capabilities for customer acquisition, customer retention, cross-sell/up-sell, risk management, and process optimization. From within a process flow, a decision strategy can be invoked to guide a customer interaction or use predictive analytics to determine the next step at a decision point in the flow. Decision strategies are models which define the data used for decision-making, processing of the data that may be required, the predictive model to be used, how the decision is presented to a user, and in the case of customer offers, a recording of the acceptance or rejection of the offer. All data sources internal and external available to the application can be used in the decision strategy – including big data sources and Hadoop processing. The history is used for analytics and can drive self-learning, real-time adaptive models. Decision strategies are defined as a visual model showing the data flow and processing leading to the resulting decision. For example, Figure 5 shows a decision model with the data flow from source to product recommendation where priority scoring for presenting recommendations to the user is handled by a decision table. Figure 8 shows the resulting mortgage options presented to the user in priority order.

19


Figure 8: User Screen Showing Mortgage Product Recommendations

The types of decision models which can be created in Pega 7 include regression, self-learning adaptive, scorecards, decision trees, and decision tables. For example, Figure 9 shows a portion of the decision table driving the mortgage recommendation. In addition, models from many other commonly used predictive modeling products can be imported through the industry-standard exchange format, PMML. The models can be simulated, compared using historical or real-time data, and monitored with real-time visualizations of KPIs.

Figure 9: Decision Table (partial) for Product Recommendations

2.7 Declarative Computation Models

20


Declarative computation models are a unique aspect of Pega 7’s model-based application development, allowing non-procedural computation driven by changes in data. This provides significant development simplicity and productivity. Figure 10 shows the declarative network for the computation of the monthly mortgage (fixed-rate) payment displayed in the screen shown in Figure 8. The monthly payment output is dependent on the loan principal amount and two other declarative computations, one converting the loan term in years to the term in months and the second converting the yearly interest rate to a monthly interest rate.

Figure 10: Declarative Computation for Fixed Rate Mortgage

By referencing the monthly payment, the screen that is displayed to the user is automatically recomputed if any of the inputs, such as loan principal amount, have changed since the last computation. This greatly simplifies the logic of the application, especially for computed values which are used in multiple models as well as multiple user interface models.

2.8 Design Validation A significant advantage of building applications as models rather than low-level procedural code is that many errors can be identified at design-time, making application testing much easier and reducing errors in deployed production applications. In Pega 7 this design validation capability is called a guardrail. Figure 11 shows the display in Pega 7 Designer Studio with the summary of guardrail warnings in the financial services onboarding application.

21


Figure 11: Design Validation Guardrails

Types of guardrail warnings include data integrity, performance, maintainability, and documentation. They span all types of models in an application and have a severity of caution, moderate, or severe in terms of the potential impact on the application. A weighted compliance score (0-100) based on warnings, severity, and justifications is generated for each application. This provides an overall metric on design validation. Decision management guardrails are particularly important to assure that intended business goals are reached. For example, if a rule in a decision table is unreachable because its conditions for action can never be met, a guardrail warning will be posted. Or, a caution would be issued if the complexity in a case design creates so many stages that it would be hard for an end-user to understand.

Section 3: Pega 7 Unified Architecture and Dynamic Runtime The Pega 7 platform is implemented as a unified architecture. Unified architecture means that all of the components used by both application developers and administrators—including the Pega Designer Studio itself—are Pega 7 applications that share models, operations, and monitoring without custom integrations to tie together dissimilar technologies. The Pega 7 engine is at the core of application execution, and it controls the “self-assembly” of applications. It has a dynamic and efficient approach to selecting, compiling, and executing models to implement an application. This supports the productivity and other benefits of model-based development, allows for many variations of the application according to enterprise and customer needs, and provides for an efficient and scalable implementation. Unlike BPM products in which models are interpreted at runtime, Pega 7 compiles the models into standard Java for superior performance including the optimization techniques of the Java Virtual Machine (JVM), such as just-in-time (JIT) hot-spot compilation from byte code to machine code. This is a major difference between Pega 7 and other model-based platforms. It is the only way to provide the benefits of model-based development with the scalability and efficiency of an application written directly in Java or other conventional programming language.

22


3.1 Overview of the Pega 7 Unified Architecture and Dynamic Runtime Figure 12 shows a high level view of the Pega 7 unified architecture. At its center is the Pega engine, an instance of which is called a node and executes in a JVM.

Figure 12: Pega 7 Unified Architecture The numbers in Figure 12 show a typical sequence of execution and the execution environment. As Pega 7 is unified this applies to all users, whether business application end users or application developers and administrators. It applies to all types of models whether case, process, UI, decision, or integration. It also applies to all channels of interaction including via API.

1. A user interacting with an application UI causes a reference to another model component, which could be any kind of model, such as another UI model, a case model, a process model, a decision model, or a data model. This causes an interaction with the Pega engine.

2. Using the access control and security layer to ascertain that the user has rights to reference the model, the engine uses dynamic model selection to choose the

23


model to execute. This selection is done according to the situation-based model with the layers and specialization created in the manner explained in section 2. (The details of the selection process are explained in section 3.2, while optimizations of the process, such as cache usage, are explained in section 3.3.)

3. The model is retrieved from the model repository. Models created in Pega

Designer and ad hoc cases that are used repeatedly are stored in the repository so that they can be reused.

4. As the models are dynamically assembled into the running application driven by

user and API activity, all required code for efficient execution, including Java, SQL, HTML5/CSS or JavaScript, is automatically generated from the models.3 The generated code is compiled, loaded, and executed. Data is stored for the user in the dynamic working memory— often called the “clipboard”. The dynamic working memory maintains the user session state and all session data (see section 3.3). Declarative model (section 2.7) code is recomputed in the working memory as needed.

5. If the executing model needs to reference previously computed data which is not

already in the dynamic working memory, or if it needs to reference another case or process (a work item) which is not already in the dynamic working memory, it will retrieve the data or work item from the work repository.

6. If the model references data from external systems or from an external database,

the data will be retrieved through an integration model. APIs of all common types (REST, SOAP, JDBC, etc.) are supported for two-way integration with external systems, databases, middleware, and applications. Models can define external data to be auto-refreshed to working memory (see section 3.3).

7. Changes caused by the model execution including data retrieval, change of state

in a case or process, or displaying new UI components are presented back to the user (or API if originally driven through an API).

8. The Pega 7 platform runs on industry-standard Java, relational database, web

and mobile infrastructures. The high-availability and scalability capabilities of these Java, database, and web platforms are leveraged to provide high-availability and both horizontal and vertical scalability to Pega 7 (see section 5.3). All execution in the platform can be monitored by the Pega Predictive Diagnostic Cloud which looks for performance issues, guardrail violations, and other alerts which can impact the health of the application (see section 5.2).

In addition, Pega Cloud on Amazon Web Services provides a virtual private cloud for Pega 7 platform applications. It leverages the cost, reach, and availability

3 As Pega 7 applications execute in standard Java runtimes, and full APIs are provided, conventional Java code can be integrated as part of a Pega 7 application, but such code is not normally required.

24


benefits of a public cloud, but provides a dedicated infrastructure for each enterprise customer to assure security, compliance, and performance. As a unified platform, clients can move their applications between cloud, on-premises and hybrid environments as business needs evolve (see section 5.2).

The Pega 7 unified architecture supports 100 percent model-based application development with a common dynamic runtime for all applications executing either in the Pega Cloud or on premises.

3.2 Dynamic Model Selection Section 2 discussed how modeling can create situational versions of applications by using:

Models organized into classes to support specialization through inheritance

Models organized into rulesets that group related models together for application deployment and versioning

Models with circumstance conditions to handle exceptions and effective dates These three modeling techniques are the keys to determining how models are dynamically selected at runtime for execution. Dynamic model selection takes place as one model references another for execution or retrieval of data. The resolution of these references through dynamic model selection is a search and prioritization process. For example, if the retail onboarding case references the retail auto loan subcase for execution, the search for the proper subcase searches and prioritizes in the following order:

1. According to primary class inheritance 2. According to secondary class inheritance 3. According to ruleset order and version 4. According to circumstance properties 5. According to circumstance effective date and time

Figure 13 shows rulesets defined for the FinCo company with US and EMEA divisions. Ruleset layers are usually visualized from base capabilities going up to the more specialized, so the inheritance—both primary and secondary—points downwards in this diagram to the more general ruleset when crossing layers. Having the class structure cross the rulesets is a best practice when the different layers in the class tree are enhanced, versioned and deployed separately.

25


Figure 13: Dynamic Model Selection with Rulesets

Consider the following three examples of dynamic model selection based on Figure 13 that show the use of classes, rulesets, and circumstances. The numbers in the figures match the example number. The green number shows where the model reference takes place and the red number shows where the model to be used is found.

Example 1: Showing Class Inheritance The user interface for the U.S. division onboarding case references the image “logo” to be displayed. The dynamic model selection looks through the data model instances according to primary inheritance and finds an image with the American flag in the U.S. retail division class. It finds no other “logo” defined in the secondary inheritance Pega

26


7 Work Item or in the rulesets in the US application, so the standard logo for the U.S.

retail division is selected for use by the user interface.

Example 2: Showing Ruleset Versioning In an instance of the EMEA division onboarding case, the new customer makes a choice to apply for a fixed-rate home loan, so dynamic selection looks for the most appropriate fixed-rate home loan subcase in the EMEA application. Dynamic selection finds such a subcase in the EMEA Onboarding Ruleset Version 1.0 as well as another of the same name found in Version 1.1 of the ruleset. As the version priority for the 1.1 ruleset is highest, the subcase from that ruleset will be used. When selected the first time, the model is compiled and saved in a code cache. For the models which compile into Java, this cache is directly accessed by the Java classloader.

27


Example 3: Showing Circumstancing When a New York customer decides to apply for a fixed rate home loan, dynamic model selection finds two subcases in the U.S. Onboarding Ruleset Version 1.0 and no others through inheritance. One case has the circumstance defined for when the “state” property entered by the customer is “NY”, so in this instance the circumstanced subcase is chosen.

3.3 Dynamic Working Memory, Caching and Persistence This section explains details of the data management and related optimizations of the Pega engine execution. Figure 14 shows the Pega 7 engine in more detail.

28


Figure 14: Pega 7 Engine The numbers in Figure 14 are explained below:

1. Dynamic model selection, as explained in the previous section, is optimized through use of a model selection cache. For search efficiency, search results are saved in the cache. If a reference to the same model from the same context occurs again, the result will be found without additional search.

2. The Pega 7 engine shares dynamic working memory, often called the “clipboard”, among multiple applications, including multi-tenant applications. Dynamic working memory is where the state of applications and client interactions is stored for clients, which can be either a user or a system interacting via APIs. The figure shows session storage for four clients: the first is a user of one application, the second is a user of two applications, the third is a user of a multi-tenant application, and the fourth an API client.

The working memory is dynamic in the sense that:

Data values resulting from a computation can be defined declaratively so that they are automatically recomputed as source values change.

29


Data from external sources, whether direct from a database, middleware or APIs, can be automatically refreshed according to usage or schedule, when defined as a Data Page data model.

3. When selected the first time, the model is compiled and saved in a code cache (and

also stored in the model repository). For the models which compile into Java, this

cache is directly accessed by the Java classloader. The compiled code is cached so that the compilation need not be done again unless the model changes. The code cache is shared for multiple applications executing the same models.

Data such as external reference data can be shared across applications in accordance with defined access controls.

4. The status of core work items is persisted from working memory to the work repository. The work repository is implemented in a relational database, but with a hybrid storage model where the properties and state of the work item are stored in a binary format with selected object properties exposed in relational columns for retrieval and reporting. Pega’s Business Intelligence Exchange allows for full extraction of the work items into relational format so that they can be imported into a business intelligence system for additional analytics and reporting beyond that provided in Pega 7.

Session-oriented data goes through passivation and is stored in the work repository according to configurable parameters, such as a user session being “idle for 30 minutes”. Unreferenced data can go through passivation separately from the full session, such as data not referenced for 15 minutes. Activation is done on reference to the data or session which causes it to be read from the work repository into working memory.

The optimizations described above allows for a high-performance, scalable implementation of model-based development and execution by the Pega 7 platform.

Section 4: Pega 7 Dynamic User Experience, Including Mobile and Social The Pega 7 platform supports rich, dynamic and situation-based user experiences across all devices. The situation-based user experience is the result of the user interface models used with the core business logic in cases and process flows. Common core logic is used, and the user experience is then customized according to the situation, the device, and the user, such as a CSR in a call center or a customer using a self-service interface. The use of common models allows for an omni-channel user experience supporting all interaction channels including mobile, web, embedding in a web portal or mobile

30


mashups, embedding in and listening to social channels, correspondence (email and print), and telephony. The same experience, capabilities, analytics, and content can be accessed and used across all of the interaction channels. A user can start an interaction in one channel and switch to another midway through the process. For example, a customer can start product selection on a mobile device and then complete it on the desktop or via a phone call to the call center. Pega 7 maintains the context of the interactions across all these channels and devices for both the customer and CSR. Significant help to UX design and consistency is provided by support for standard look and feel, branding, and screen layout using skins in Pega Designer Studio. Skins easily allow a common appearance of all screens of an application on any device with no specific screen-by-screen setup required. Customizations, such as different branding for each business unit in an enterprise, are easily specified. Social collaboration is fully embedded in the Pega 7 platform so that any application can easily integrate contextual activity streams which can impact the current work processes. The social collaboration is available to the application development teams, enterprise users, and customers.

4.1 Dynamic User Experience The Pega 7 platform enables the design of a dynamic customer-centric user experience (UX) across any device—and it does so without requiring the UX designer or developer to write any code. The customer-centric experience is specified through the collaboration features of DCO (see section 2) applied in the UX design context to specify situation-based experiences. This design is then realized, with model-based technology supporting UX specialized according to the device, the task at hand, and the context. This corresponds to the UX being responsive, adaptive, and contextual. Each of these is explained below:

Responsive: Pega 7 models can specify a responsive user interface. A responsive user interface is one which automatically adapts to the screen size, client platform, and orientation. This is done in Pega 7 with no programming. By simply checking off in the user interface model that it should be responsive, and picking from options to set what happens for ranges of screen sizes, the required UI code for the mobile client is generated.

For example, Figure 15 shows the onboarding manager’s user interface for a bank’s customer onboarding application. Figure 15.a shows a responsive layout when using a desktop display. Note the columns with navigation on the left, urgent work table in the center and team members on the right. Figure 15.b shows the layout for a tablet screen with the navigation column changed to a slide out menu and a reduction in columns displayed in the table. Figure 15.c shows how the UI displays on a phone, where the table is converted into a list, and content on the right of the screen has been stacked under the work list.

31


Figure 15: Example of Responsive User Interface

a. Desktop Screen for Onboarding Manager

32


b. Tablet Screen for Onboarding Manager

33


c. Phone Screen for Onboarding Manager

Adaptive: While the responsive UI is based on the client code adapting its content to the screen size, the adaptive UX leverages modeling to customize the content appearing in the UI according to the device being used. For example, a desktop user might have access to all options for creating and advancing a case, while a phone user might have access to only approvals and the most commonly used options for advancing a case. Circumstancing (as described in section 3.2) applied to the user interface models can be used when the user experience needs to account for the differing usage across devices.

Contextual: A contextual UX is specialized according to the attributes of the current situation such as the user role or type of case being processed. For example, in the case of applying for a mortgage, certain documents, including the formal loan application, need to be uploaded to the bank. Figure 16.a shows a customer’s self-service screen for uploading documents, while Figure 16.b shows the view of this step for the bank’s CSR.

Both screens represent the same step in the internal process flow, but different user interface models are used for the customer versus the CSR role. Both are allowed to upload documents, but only the CSR is allowed to change the document status, such as from “Pending in Good Order Review” to “In Good Order”.

34


Figure 16: Example of Contextual User Experience

a. Customer Self-Service Interface

35


b. CSR Interface

All of these approaches to providing a dynamic user experience—responsive, adaptive and contextual—are used to deliver a customer-centric experience according to the usage intent and interaction device of the user.

4.2 Mobile Applications

Pega 7 provides broad and deep capabilities for the development of model-based mobile applications as it supports both mobile web (access through a mobile browser) and native mobile applications. The mobile web capability leverages the responsive user interface described above so that it automatically adapts to the screen sizes of smartphones and tablets. Figure 17 shows the various options for mobile application deployment.

36


Figure 17: Options for Mobile Application Deployment

a) Figure 17.a illustrates the mobile web option where web code, i.e. HTML5, JavaScript, and CSS is downloaded for a mobile browser session. Beyond configuring the dynamic layout model, no changes are required for Pega 7 applications to operate in a mobile web environment.

b) The hybrid native application option shown in Figure 17.b creates a native mobile

application which “wraps” web code, including links to the Pega 7 server, within a native container for Apple iOS and Google Android operating systems. The Pega 7 native container, called the Pega Mobile Client, provides APIs for access to device capabilities as well as security services including user authentication and encryption. Native capabilities supported include geolocation, camera, push notifications, QR/barcode scanning, and local storage. A hybrid native app for a single Pega 7 application can be built by selecting the appropriate option in Pega Designer Studio and then providing the logo and branding to be included in the distributed app. The hybrid application can be deployed through Apple App Store, Google Play, or any private enterprise app store including that provided by Pega AMP Manager.

c) Since an enterprise using Pega 7 may have a number of related applications,

Pega 7 includes dynamic multi-app configuration for a single mobile application. This is a single application with a single logo on the mobile device which supports use of multiple Pega 7 applications as shown in Figure 17.c. Pega 7 applications can then be added to or deleted from this single native application as a user’s needs change. A standard Pega 7 multi-app hybrid native application

37


is available in the Apple App Store and in Google Play. The logo and branding of this app can be customized.

d) Often an enterprise chooses to build or has an existing application built in the

native OS programming languages, Java for Android or Objective-C (or Swift) for iOS. For example, a retail bank might have a widely deployed consumer application built this way. For these situations, Pega 7 provides a mashup SDK for iOS and Android which allows a Pega application to be embedded within a native application as shown in Figure 17.d.

Generally all Pega 7 models are available in the mobile environments. Other key aspects of Pega 7 model-based application development in the mobile context include the following:

Push notifications can be sent to a mobile device by simply including a “push notification” action in process flows.

Disconnected usage is supported when a case has been marked as one that is available when the user is offline. This capability is available when the Pega 7 application uses the Pega Mobile Client. In such a situation, the user can create a new case, or modify a previously created case while there is no connection to the server. When the user regains connectivity, all data that was securely stored on the device is automatically synced back to the server.

The model-based application development and deployment of Pega 7 fully supports mobility. Common models deployed across both desktop and mobile can be enhanced with specializations to take advantage of all uniquely mobile capabilities.

4.3 Integrated Social Collaboration Pega 7 includes an integrated social collaboration capability called Pega Pulse. It can be made available to all users of all Pega 7 applications, whether developers, enterprise users, or customers. It is enabled by simply including the Pega Pulse ruleset in the application definition.

Pega 7 social collaboration enables users to share instant messages, files, and URLs with other users in their work group. It includes:

Contextual activity streams providing public or private posts in the context of a case or user. Its scope depends upon where it is used in the interface. For example, when embedded in a case user form, only posts related to the case appear. Users can choose to post information privately to users working on a case rather than broadcast to the entire work group.

38


User profiles including operator information such as photo, position, contact information, and skills. Users can modify their own photos or biographical information.

Actionable posts where users who have the correct privileges can open cases or create tasks directly from a post. Pega Pulse can be used directly in workflows. For example, messages can be posted when a case reaches a deadline or goal.

Figure 18 shows a social collaboration where a CSR asks for help answering a customer question. Another CSR answers the request with a post and then from the post opens the form to create an ad-hoc task for himself with a deadline to answer the question.

Figure 18: Creating an Ad Hoc Task Based on Social Collaboration The Pega 7 platform capabilities described in this section—dynamic user experience, mobile applications, and integrated social collaboration—combine to make the creation of compelling customer-centric user experiences within easy reach for all enterprises and all developers.

39


Section 5: Pega 7 Enterprise-Class Applications Previous sections have explained how the Pega 7 approach to model-based development facilitates productivity, specialization of applications to a wide variety of users and situations, and a dynamic user experience including broad mobile support. As Pega 7 is intended for mission-critical, strategic applications in an enterprise, they must also have “enterprise class” Quality-of-Service (QoS). Enterprise class means that the applications are secure, easy to deploy and manage whether on premises or in the cloud, are scalable and reliable, and integrate well with the existing enterprise infrastructure and systems of record. The following sections provide details about Pega 7’s enterprise class security, deployment and manageability in the cloud and on premises, reliability and scalability, and integration.

5.1 Enterprise-Class Security Pega 7 model-based application development provides a key advantage for building secure applications. Since the code is generated from the models with embedded security best practices, the code is generated secure, eliminating the kinds of errors introduced in conventional programming. Pega 7 generated code uses best practices to protect against key application security risks4 such as injection, broken authentication and session management, and cross-site scripting. Pega 7 supports fine-grained role-based authorization defined on the objects and functions of the application model. Full capabilities for authentication including use of LDAP, SAML and Active Directory are supported as well as multiple authentication schemes at the same time. This supports differing approaches for internal users, partners, and customers. Models (rulesets) can also be locked and password protected to restrict changes. All of the capabilities necessary for an application to be compliant with various security standards and regulations, such as PCI DSS and HIPAA are provided. Audit trails are provided through the normal history of user activities as well as specific security alerts for situations such as users trying to access restricted activities, data or reports.

5.2 Enterprise-Class Deployment and Manageability in the Cloud and On Premises Pega 7 model-based application development provides key benefits for application deployment. When migrating from development to QA to production, Pega 7 users do not move code—rather the models are moved as versioned rulesets. As shown earlier in Figure 6, an incremental update can be deployed for incremental functions or fixes. Multiple versions can be deployed simultaneously to support pilot testing and then

4 OWASP top ten security vulnerability risks https://www.owasp.org/index.php/Top_10_2013-Top_10

40


migration—all without system downtime. Users are directed to their proper version according to their application access settings. Pega 7 applications can be created and hosted in Pega Cloud, a production-ready platform as a service (PaaS) that provides the flexibility to begin developing solutions immediately and then either to continue to host those solutions in the cloud or bring them on premises by moving just the models as described above. Pega Cloud was built to provide enterprises with faster time to market, cost predictability, security, and full portability so that applications can be moved from the cloud to the data center and vice-versa with no changes to the applications. Pega Cloud provides a global network of data centers, dedicated private cloud and VPN for each customer, 24x7 premium support, 99.95 percent uptime SLA, and compliance with leading industry data security standards. Pega Cloud runs on Amazon’s industry-leading Amazon Web Services infrastructure. Pega Cloud on AWS allows Pega 7 and its applications to scale up and down to meet clients' changing needs. The Pega 7 engine and code generated from business models include embedded instrumentation that can be used to predict and monitor the performance of Pega-based solutions. This instrumentation is used by the Pega Predictive Diagnostic Cloud (PDC). Pega PDC is a SaaS-based application performance management solution that helps Pega customers identify and correct system health issues before they impact the business. Pega PDC complements traditional APM solutions by prioritizing the issues that matter most to the Pega applications’ speed and reliability, as well as recommending specific actions to correct them. Sitting above existing APM tools, and supporting both on-premises and cloud-based systems, Pega PDC monitors the Pega application layer using a unique knowledgebase. Pega gathers alerts, system health pulses and guardrail violations generated by the applications, correlating and analyzing these data streams in real time. The solution proactively produces trending dashboards, aggregates system health scores, emails notifications showing progress or degradation of the application’s health, and recommends the best actions to remediate issues. Figure 19 shows an example set of alerts and performance information.

41


Figure 19: Predictive Diagnostic Cloud

There is also an on-premises version of the predictive diagnostic capability, the Pega Autonomic Event Services application. In addition, Pega provides the System Management Application with views into the current users, requestors, background processes, memory utilization, etc. within Pega 7 applications. The use of a standards-based JMX interface allows integration with existing administration and monitoring tools. For the specific management needs of Pega 7 mobile applications and enterprise-connected mobile devices, Pega Application Mobility Platform (AMP) provides enterprise mobility management (EMM). AMP includes an enterprise app store from which employees can download Pega 7 mobile apps. The enterprise can set and enforce access policies for apps, users, and devices as well as update or wipe devices over-the-air from a central console.

5.3 Enterprise-Class Reliability and Scalability Pega 7 is designed to operate at large scale with a single cluster supporting tens of thousands of simultaneous users and millions of cases per day. Both horizontal and vertical scaling is supported.

Horizontal scaling with linear performance increase is supported by deploying Pega 7 JVM nodes across multiple load-balanced servers. A shared database architecture is used across a horizontal cluster, and all communication between nodes takes place through the database. If needed, database scalability is provided by the database vendor’s clustering capabilities.

Vertical scaling is supported by running multiple Pega 7 JVM nodes on a multi-CPU server.

High availability for Pega 7 builds on the high-availability capabilities of the enterprise Java EE application servers and the load balancers used with the application servers.

42


Pega 7 adds capabilities for failover in the case of node server crashes. Browser crashes are also handled with recovery of the user session. An additional capability for scalability and multi-system configurations is federated case management which allows cases and work assignments to be federated across multiple Pega 7 instances. This allows a single user to access cases and data from multiple applications distributed across multiple nodes.

5.4 Enterprise-Class Integration Enterprise applications do not exist in a vacuum. They must communicate with external and internal systems including core enterprise systems-of-record, both on premises and in the cloud. Pega 7 provides rich API capabilities for accessing external APIs for both services and databases, and for exposing APIs providing secure access to Pega 7 application functions. Like all other aspects of Pega 7, these integration capabilities are defined by models with forms-based configuration that eliminates custom coding. Pega 7 is designed to participate in service-oriented architectures (SOA), integrate seamlessly with enterprise service bus (ESB) technologies, and to communicate directly with external systems. Protocols supported include REST, HTTP(S), SOAP/WSDL, JMS, MQ, SQL, FTP, SMTP (email), EJB, JCA, CMIS (content management), and JSR-286 (portlet) among others. Data retrieved from external sources, using any integration protocol, can be automatically refreshed according to usage or schedule when defined as a Data Page data model. Transformations are supported to map data into or from the APIs. Pega 7 supports transformations targeting JSON, XML, Java objects and Java Beans, delimited and structured file records, and PDF forms.

Section 6: Pega 7—The Platform for Strategic Business Applications Pega 7 is for building, deploying, and evolving strategic business applications which embody the unique differentiated activities of an enterprise. This technical brief has shown how Pega 7 is a unified platform that provides state-of-the-art enterprise application agility via the following key capabilities:

Full model-based application development providing outstanding productivity and agility even for typically difficult-to-implement capabilities such as integration and predictive analytics-based decision management.

43


Dynamic runtime self-assembly of applications enabling implementations unique to the specialized needs of customers, partners and enterprise users according to factors such as customer status, product type, and geography.

Dynamic, omni-channel user experience including social collaboration for all web, mobile web, and native mobile apps based on the same models.

Enterprise-class applications which are secure, easy to deploy and manage on premises or in the cloud, scalable and reliable, and integrate well with the existing enterprise infrastructure and systems.

These key capabilities are all in a unified platform in which applications can be built 100 percent model-based with no conventional programming required while also achieving enterprise-class performance and scalability.

6.1 The Broader Capabilities of Pega 7 Beyond the core Pega 7 capabilities, Pega also provides applications built on the Pega 7 platform that deliver strategic horizontal and vertical business capabilities while providing the flexibility to customize the application to meet an enterprise’s specific business needs. Each application is delivered as a set of models. Horizontal applications, such as Pega Customer Service, Pega Sales Automation and Pega Marketing, provide business solutions across industries. Vertical applications provide business solutions for specific industries including financial services, insurance, healthcare, telecommunications, energy, government, life sciences, and manufacturing.

The example used in previous sections of a financial services onboarding solution is based on the Pega Onboarding for Retail Banking. As shown in Figure 20, this application is based on the Pega Financial Services Foundation, which is based on Pega 7.

Figure 20: Pega 7 Application Stack

44


When these applications are used, an enterprise can quickly develop customizations as modifications and extensions that are simply layered on top of the application.

Conclusion It is crucial that strategic applications can be built and deployed quickly and then evolve according to customer and enterprise needs without disruption to current users of the application. Pega 7 provides the ability to do this through its dynamic approach to high-productivity, model-based application development, incremental deployment, and dynamic execution supporting both cloud and on-premises deployments with no-changes-required migration, full mobile application generation, and integrated social collaboration. Pega’s horizontal and vertical applications provide the additional acceleration needed to quickly attain and exceed strategic goals.

Customer engagement is a strategic goal for every enterprise. As Alan Trefler, CEO and founder of Pegasystems, writes with respect to attaining engagement with the emerging generation of digitally-bred customers:

“There are three core principles for survival: democratize how you do technology; think in layers; and use analytics.5”

The Pega 7 unified platform embodies each of these principles. It democratizes through model-based development that is accessible to both the business team as well as the technology team. It directly builds applications as layers, matching the many variations of customer and enterprise needs. It includes the advanced analytics needed to integrate analytics-based decision making directly into the applications on the front lines of customer engagement. For additional information on how Pega 7 can help your organization deliver engaging customer experiences, simplify and streamline business operations, and achieve outstanding enterprise agility, please contact your Pegasystems’ representative or request a contact at www.pega.com/contact.

5 Trefler, Alan, Build for Change: Revolutionizing Customer Engagement through Continuous Digital

Innovation, Wiley, 2014.

http://www.pega.com/contact

pega 7: architecture and technical brief 7 - architecture and technical brief.pdfpega 7 is an...

Documents