Implementing a BPM (Business Process Management) Architecture in Financial Industry

Roy Abraham

1. Introduction:
Business Process Management deals with defining, analyzing, managing and implementing the interaction among internal systems, people and external trading partners. BPM provides a holistic approach to Software development involving technology (objective) and human behavior (subjective). In traditional systems, Business Logic (objective part) and Business Rules (subjective part) in a Business Process are tightly coupled. Hence, any requirement change, in either one, results redesign or re-factoring (depends on the extent of the change) of business process. However, laws, rules and regulations of certain business processes change constantly. This necessitates the decoupling or loose coupling of Business Rules and Business Logic. Business Logic is hard coded (means, business logic change depends only on requirement change). On the other hand, transient changes in rules, laws and regulations are encapsulated in Business Rules. These Business Rules may or may not need human intervention. Business Logic is implemented in Application server (for example, an EJB or IoC container). Business Rules, which need human intervention is implemented in Workflow server. Business Rules, which do not need human intervention is implemented in Rules Engine.

2. Components of BPM:
The major components of BPM are described below.

a) Business Logic: Defines the objective behavior of permanent nature. In software terms, this attribute never changes unless and until requirement changes. This also implies that there is nothing absolutely permanent in software development. The core business model of the enterprise is captured in the business logic.
b) Business Rules: Defines the objective behavior of transient nature. However, this attribute changes within the confines of the requirements. This encapsulates the forces outside the enterprise which influence the core business model such as market forces and government policies. The daily or weekly promotion sale of the company or changing the sales tax structure due to government policies are few such examples.
c) Work flow: Defines the subjective behavior of transient nature. This is where the human aspect interacts with the core business model. For example, a customer agent partially forgives the overdue penalty of a customer and her supervisor completely forgives it due to good payment record of the customer.
d) Trading Partner Interaction(B2B integration): Defines the business relationship with other enterprises. In the current integrated business environment, business to business transaction is inevitable one way or the other.
e) Enterprise Application Integration(EAI): Defines the integration of various software and data assets within the enterprise. It can be legacy assets accrued over the years such as main frame or software written in C language.
f) Life cycle management: Almost every business model has to perform a sequence of tasks from inception to fulfillment, to complete the business process. It can be a claim processing, an order fulfillment of a shopping cart or a loan processing etc. BPM provides the state management of individual steps involved in the Business Process.

Figure 1: Components of BPM

g) Monitoring: The entire software development project is business requirement driven. The business requirement is stake holder driven. Hence, directly or indirectly the business manager is the ultimate stake holder of the software development. However, the business manager may not have the technical acumen to understand the complexities of the software process. She has to believe what she is told by the development team. This poses considerable challenge to the Business Manager on day to day operations of Business Process. The monitoring tools of BPM provide such a visibility to the business process. Monitoring may include but not limited to Business Activity Monitoring (BAM) of Key Performance Indicators(KPI), Six-Sigma, compliance monitoring (like SOX), process analytics etc.

3) Necessity of BPM:
A typical example is the life cycle of a non-performing mortgage loans (assets). Rules and laws continuously change as new legislation come into effect every year. However, it is extremely difficult to change or re-factor the existing applications which process the mortgage loans as per every change in the mortgage law. The best strategy is to separate business logic and business rules from the business process. The subjective and transient tax features are encapsulated in business rules. The objective and permanent mortgage logic is encapsulated in business logic. The Business logic may reside in various disparate systems which needs to be integrated (EAI) using EJB, JMS, JDBC etc. Whenever a mortgage law changes, the business manager create a business rule associated with the new mortgage law and stores it in a rules engine. When the system receives an asset in trouble, the application server applies business logic and rules engine applies business rules on troubled asset data. The asset is sent through a Workflow if it needs to go through human intervention such as evaluating Broker Price Opinion. In most of the cases external trading partners (B2B integration) are to be involved such as Appraisal companies. In many cases, data and software assets reside in legacy systems and other disparate systems which needs to be integrated. For example, ARM loans are processed in C based systems while 30 year loans are processed in COBOL systems. Above all, an oversight by the Business stake holder or upper management (using BAM) is essential for the proper management of the life cycle of the troubled asset. To integrate such a complex and disparate business process, a BPM system is absolutely necessary.

Figure 2: BPM Project life cycle in modified waterfall methodology

4) Architecture of BPM: A BPM system must be able to integrate with Application server environments, Workflow servers, Rules engines, B2B trading partners, Legacy systems and Enterprise application Integration systems. The BPM system must provide a design environment to capture and model the business process and create compile time stubs. The BPM application must have a process engine to monitor the run time processing and KPIs. A high level, logical, design time and run time architectural topologies are shown below.

Figure 3. BPM Logical Architecture

Figure 4. BPM Design Time Architecture

Figure 5. BPM Run Time Architecture

Figure 6. BPM Run Time Architecture in Amazon Cloud


4) Design and Building a BPM application: The following steps describe salient features of a BPM application from design to production release.

a) Capturing and Modeling Business Processes. The first step is to capture the logical business process with the help of a business stake holder (or business analyst). Coarse grained processes may be sub-processed to capture underlying fine grained processes. The business analyst may iterate through the processes to refine the business process model. Steps are used to capture the business process and transitions are used to direct the flow among the business process. Such a logical Business process model is shown below.

Figure 7. Logical Business Process Model

Figure 8: Logical Business Process Model using BPMN notation


Using a Modeler or Designer, create a physical business process model out of the logical one. Create stub to develop code to represent the inlaying process. Such a physical model is shown below.

Figure 9. Physical Business Process Model

b) Creating and mapping Logical Data Dictionary (LDD). The LDD is a master reference table containing each and every attribute used in the business process. The meta data pertaining to each attribute is described in the table such as data type, data size, default value, list of values if enumerated, definition of attribute, container hierarchy (xPath) and type of attribute. The relative location of the attribute depends on the structure of the format where the attribute is located as shown in the figure below.

Figure 10. Data transformation and mapping in data formats.

The naming convention and associated meta data information are captured under each domain specific formats. For example, three attributes - order number, social security number and credit card type as it passes through different domain formats are shown below.

Figure 11. Logical Data Dictionary

The LDD is used as a reference document by analysts, architects, designers, developers, managers and testers for their respective needs. If LDD becomes too big to manage, it can be split into domain specific categories. The initial investment in the form of effort and time to build a Logical Data Dictionary is considerable. However, it is worth every penny as it prevents potential problems during the subsequent application development.



c) Creating the Canonical data structure. A canonical document, usually in XML format has to be derived based on the attributes collected in LDD. Thus, the LDD contains every attribute and its structure based on xPath. Different types of strategies can be used to arrive at the canonical XML. The canonical XML can be a subset of industry standard (as MISMO in mortgage industry), a combination of MISMO and trading partner proprietary XML, derived from Business Objects or entirely a new XML structure as shown below.

Figure 12. Derivation of canonical data structure.



d) Identifying and creating Unique Id. Every instance in the Business Process is identified by a unique id, similar to RFID (Radio Frequency IDentification). This id enables to maintain the life cycle of the instance even if it leaves the business process engine. For mortgage assets, it can be MIN (Mortgage Identification Number) which is analogous to social security number in mortgage world.

Figure 13. Canonical document based on MISMO secondary data set (Loan Delivery)


e) Develop necessary code within the created stub. once physical BPM model is created, a stub code can be generated to hold the underlying business process. Generate and test the code within the stub.
f) Monitoring the Business Processes. Once deployed into production, each instance can be monitored using a monitor or BAM enabled portal interface as shown below.

Figure 14. Monitoring of an BPM instance at run time, waiting for first BPO to arrive.

Figure 15. Monitoring of a BPM instance at run time, waiting for Second BPO to arrive.

Figure 16. Monitoring of a BPM instance at run time - the completed life cycle of the foreclosed asset.


5) Big Data analysis in BPM:
As BPM process gather large amount of data, those data can be used for big data analysis. These data can reside in various sources in various format such as Object data in S3, NoSQL data in DynamoDB, Relational data in RDS,  Warehouse data in RedShift, Archived data in Glacier and Streamed data in Kinesis. These data can be used, for example Dodd-Frank Act stress tests. To test the financial variables against the time series (ARIMA - AutoRegressive Integrated Moving Average) model or against random walk (MCMC - Markov Chain Monte Carlo) using Python as shown below.

Figure 17. Big Data analysis using EMR (Elastic Map Reduce) Cluster.

• EC2 instances are created in a VPC(Virtual Private Cloud) in the respective Availability Zone.
• A master node and slaves nodes are created in each EC2 instance.
• Hadoop, Spark and Python code to run ARIMA mode is installed in the Master node. Hadoop and Spark are managed by YARN in the master node. Fail over is managed by AutoScaling group in the cluster.
• Input data is read from any of the data sources and processed by the Python code. The results are written to one of the data storage for further analysis.

5) Conclusion.

Most of the ills associated with the current application development is the inability of the business stake holder to have proper oversight. Most of the software development environment do not provide any such tools. The important benefits of BPM are

a) SAVING MONEY: By completely automating all the business processes, virtually eliminates the unnecessary overheads in the loan processing and saves millions over the years.
b) LESS HUMAN ERROR: By automation, business processes have less human intervention and thus human error is minimized.
c) INCREASED PRODUCTIVITY: Faster loan processing enables better throughput (loans processed per unit time).
d) SUPERIOR OVERSIGHT: Upper management or business stakeholder gets a birds eye view of the entire loan process. In other words, management knows what is exactly going on rather than being told.
e) MONITORING AND OPTIMIZATION: In-depth monitoring of data at every step of the business process.
f) SUPERIOR ERROR HANDLING: Easy resubmission of process at a failed step.
g) ROI: Investing in BPM implementation gives the best return in the long run.
h) USER FRIENDLY: These models are extremely user friendly and provide a visual representation of the business processes which can easily be understood even by non-technical or uninitiated.
i) Fast Development and Implementation: Very fast and easy development life cycle and process refinement.


__________________________________________________
This document is for reference only. For actual implementation, please contact the author. No part of this document is to be used or reproduced without the written consent from the author (roychettan@gmail.com).