This chapter provides an overview of PeopleSoft Active Analytics Framework and discusses:
Policies and trigger points.
The data library.
The action framework.
PeopleSoft Active Analytics Framework is a suite of tools comprising a closed-loop decision-making system where business-intelligent applications or transactions can respond when conditions are met and specific actions are recommended; for example:
Giving a priority service or a better discount for high-value customers
Send pertinent emails or notifications.
Displaying alerts and warning messages.
PeopleSoft Active Analytics Framework provides components for setting up the analytic framework, which include managing the data library, building policies, and managing trigger points and actions. These components provide a way to define flexible business rules, called policies, that can be altered without modifying application code. Business analysts and other functional users define policies with an intuitive user interface.
Functional users can create policies that use data elements of various forms and shapes residing in different sources such as the transactional environment, data warehouses, legacy systems, and so on forth. The data elements are exposed to the business user as terms defined in the PeopleSoft Active Analytics Framework data library.
The extensible action framework supports the definition and execution of consequential actions. Application developers can create customized action types within product lines to accommodate their functional needs. PeopleSoft also delivers a built-in action type for displaying alerts to the user.
Policies are the result of combining trigger points, conditions, and defined actions to complete a desired business request. The framework includes components for building policies.
Application developers and functional business analysts use a wizard-like interface to build, manage, and associate trigger points to policies. Business analysts can create interactive policies that react to customer behavior of particular interest to them. For example:
If a banking customer deposits more than ten thousand dollars, a banking analyst can create a regulatory I.R.S. notification.
If a high-value customer has logged three or more critical support issues with a call-center within a week, a business executive could send a letter of apology.
Policies supplement, but do not alter, normal transactional processing. Therefore, a policy cannot be used to stop a particular behavior due to some specified restriction. If the condition portion of a policy evaluates to true, the policy causes an action to be performed. If the specified condition evaluates to false, then no consequential actions occur. Policies are evaluated independently from each other. Therefore, if more than one policy is to be evaluated at the same time, the consequential actions of one policy cannot alter or influence the actions of another. Likewise, the sequence of policy execution cannot affect the results of another policy.
You construct a policy by defining one or more conditions, specifying one or more actions, and associating them to a trigger point. A policy cannot be activated without defining at least one condition and action. You can reuse defined policies with multiple trigger points if the elements of the policy agree with the contexts of the trigger points.
Trigger points are events from which the analytic decision engine is invoked by the application. The framework supports the registration of new trigger points, when needed. Examples of trigger points are:
When a customer is identified.
When a product is selected.
After logging in to a self-service application.
Registration of a trigger point involves specifying:
During runtime, policies are triggered by specific trigger points within application components, resulting in defined actions being taken.
Note. Registration of a trigger point also involves introducing necessary code in the application to request the decision engine to evaluate the policies pertaining to a trigger point.
The data library is a repository for information within the PeopleSoft Active Analytics Framework. Each element in the data library is exposed by way of a term, which is a pointer to a unit of data within the PeopleSoft system. This data may reside in a relational database, or it may be derived at runtime.
Terms in the data library are organized hierarchically into functional categories called subject areas. Terms can be assigned to more than one subject area at a time; for example, if a term represents a customer it could be located both in a marketing subject area and in a financial subject area.
The data library enables functional users to:
Access data (terms) residing in different sources such as an operational CRM environment, data warehouses, legacy systems and so on.
Use the data in variety of contexts, such as input in rule applications, tokens in correspondence templates, or placeholders for customized text in questions or for presenting disparate pieces of information in different screen applications.
PeopleSoft Active Analytics Framework includes components to define new terms in the data library and can automatically create terms for data elements in a component.
The action framework is a suite of components that are designed to manage actions and to invoke actions at runtime. The primary purpose of the action framework is to allow functional users to specify and configure the actions to be performed when policy conditions evaluate to true.
Also, PeopleSoft designed the action framework to enable application developers and IT personnel to introduce new action types for use in policies and to invoke them at runtime.
The action framework components:
Register and maintain action types. An action type is metadata pertaining to a class of actions that can be performed at runtime.
Register and maintain action bundles. Action bundles are groups of combinable action types.
Embed and configure consequential actions within policies.
Provide a display alert action type for use with all product lines.