Just-In-Time Orchestration Of The 'Three Big Bs' For An Event-Driven Enterprise

These ‘three Big Bs mean, of course, Business Process Management (BPM), Business Decision Management (BDM)  (or Business Rules Management, BRM), and Business Intelligence (BI). Historically, all of these ‘B’ frameworks were developed independently and considered as providing benefits to absolutely different and independent sides of an Enterprise Business Model (EBM) execution. The current industry picture shows that most big companies have been implementing standalone BI and BDM Systems (BIS and BDMS, respectively) for some significant length of time, while the relatively recent maturing of BPM Systems (BPMS) and their arrival on the scene has caused some confusion regarding the role and the place of BPMS, BDMS, and BIS in the overall EBM implementation.

This article continues the attempt (started in ¹ and ² ) to consider the Architecture and Processes of an Enterprise (EA) and (EP) from a  unified, objective Enterprise Development Methodology (EDM) point of view. EDM may be thought of as an attempt to catch and identify all EA and EP entities and artifacts in one unambiguous scientific methodology defining the most effective and efficient way for an Enterprise to conduct its business. The concept of EDM was introduced in the aforementioned articles.

Let us start with an elaboration of our view of these frameworks and the Event-Driven Enterprise:

• BPM enables Enterprise to consider all its business-related interactions with external and internal Actors (customers, systems, partners, etc.) as Business Processes (EBP), explicitly formalized first as basic, and then as executable Business Process Flow (BPF) Diagrams. These diagrams are nothing but well known UML Activity and State-Chart ones. These dynamic diagrams usually describe the reaction (response) of an Enterprise to an Actor's business request. During this response one or more Enterprise Business Entities (EBE) (e.g. Customer, Account) related to the Actor may change their values.
  
• BDM enables Enterprise to formalize and concentrate in one place all Enterprise Business Constrains (EBC), the business parameters that may change over time but remain constant during each particular EBP. It is the comparison of EBC to EBE inside EBP that comprises Enterprise Business Decisions (EBD) or Enterprise Business Rules (EBR). For example, if EBC is a customer’s credit score and equals 300, EBE is Customer. CreditScore then EBD might be to provide service if EBE>EBC. This is a very simple EBD example. In practice an EBR may be very complicated and include multiple EBCs. Due to the fact that historically BDMS were created earlier than BPMS, the former often  also have the ability to perform Enterprise Business Actions (EBAs) as a reaction to the result of a specific EBR;
  
• BI enables Enterprise to analyze the effectiveness and efficiency of the EBPs constituting its EBM using certain mathematical algorithms such as six-sigma. As a standalone framework, BI can only analyze business data after they reach data storages. In this case the BI feedback exists mostly in the form of textual or graphical reports meant for human consumption.
  
• And last but not least - Just-in-time (JIT) , Event-driven Enterprise (EDE): It is an Enterprise that produces Business Events as a reaction to external or internal Actor requests (usually immediate, real-time ones) or to predefined internal Tasks (daily, weekly, etc.). These events, in turn, cause corresponding instances of BPF to run, thus producing a desirable timely business response.

The simultaneous but separated and standalone use of BPM, BDM, and BI in a traditional Legacy Enterprise is not a challenge. What is a challenge, though, is the integrated (or, better said, orchestrated) use of these concepts and tools in the framework of a general cohesive process of EDE, amplifying the benefits of each one for achieving a resulting business effect that is greater than the sum of its components.

To describe the EDM-based approach to the creation of such an orchestration we should establish an objective understanding of the relationship between these frameworks. The cornerstone of EDM is neither a Data or Information nor Applications or Services but Business Processes (EBP). A data or service cannot be considered necessary unless an EBP issues a request for it. Hence, BPM becomes the ‘main B’, for it formulates, formalizes and executes all EBPs constituting the company’s EBM. The other two frameworks can and should play a role of very critical and important Business Services (EBS) inside the BPM’s BPFs.

Let us take a look at BDM first. As a rule of thumb, Business Entities (EBEs) traveling inside a BPF should change their values as a result of BPF’s Business Actions (EBAs). However, if the BDMS currently used by an Enterprise includes corresponding predefined process providing such actions, then this entity may change its value inside BDMS, which is used in this case as an activity service (see Figure 1 and Figure 2 below that show rudimentary scenarios/patterns for the cases of a simple (comparison) rule request and the complex rule/action request respectively).

Figure 1. The simple rule BPM/BRM request/reply scenario design pattern.

Figure 2. The complex rule/action BPM/BRM request/reply scenario design pattern.

Note, that the main difference between the two scenarios is that the corresponding action that depends on the rule result is being executed either inside BPMS or BRMS respectively.

In this context, it is comparatively easy to make a case for BPM/BRM just-in-time cooperation. The case for including BI in this context is a bit more complicated.

The general goal of BIS is to analyze EBM through specific mathematical algorithms and provide some suggestions about their state to business analysts and the upper management in the human-oriented form of textual, tabular and/or graphic artifacts. The input data of such an analysis is usually taken partially from operational data bases and partially inserted manually by corresponding experts (e.g. six-sigma) after interviewing the company’s employees involved in human-based processes. The usual feedback is also manual, human-based and takes a significant amount of time.

Significant improvements to the ability of an Enterprise to gain feedback have been made with the introduction of BPMS, which include Business Activity Monitoring (BAM) capabilities and enable Enterprises to automate their EBP. As a result this new EDE is capable of receiving plenty of real-time process-related information. Being stored in a specific container, this information becomes an invaluable resource for an automated, just-in-time Business Intelligence. A simplified example of such an approach is shown in Figure 3.

Figure 3 The just-in-time usage of Business Intelligence system in EDE.

It can be seen in this figure that JIT BI analysis can be triggered either by a predefined timer event or by an alarm message coming from an EBP. In both cases it causes a specific kind of BI analysis that either stores its data in an Enterprise BI Data Warehouse or sends an appropriate response to the source BPF.

This innovative approach to BI works in both directions:

• On the one hand, BAM provides a constant flow of real time information regarding the current state of the whole EBM and each and every automated process execution. This information can be analyzed by a BIS as an independent BPF either on a regular basis (daily, weekly) or as a reaction to an alarm sent by a BAM of a particular BPF if it spots some unfavorable combination of business parameter values (e.g. an unacceptably high level of errors and exceptions during some period of time).
• On the other hand, some of the results of BIS analysis might be formalized and used as automatic triggers, initiating human alerts or predefined changes in the original BPFs.

Thus BI changes from a slow-reacting, heavily manual, non-formal process to an automated, just-in-time tool that drastically increases the overall company’s business agility and its customer satisfaction via the increased quality of its processes and services. It could transform the six-sigma level of process quality from the wishful-thinking fantasy that it is right now (most companies would be happy to achieve the three-sigma level) into a reachable reality.

¹ W. Rivkin. Technology Does Not Matter, Methodology Does. SOAInstitute.org. March 10, 2009:
http://www.soainstitute.org/articles/article/article/technology-does-not-matter-methodology-does.html

² W. Rivkin. Architecting Enterprise Business Model. SOAInstitute.org. March 10, 2009:
http://www.soainstitute.org/articles/article/article/architecting-enterprise-business-model.html
 

Wolf Rivkin has a master’s degree in applied mathematics and 20+ years of IT experience, including 15 years as a senior level architect and manage with Alltel, IBM, Bellsouth, etc. He is a practitioner, a methodologist and an author, specializing in Enterprise Business Transformation (EBT) Frameworks / Roadmaps as well as the creator of the Enterprise Service Orchestration Architecture Framework (ESOAF). As a Principal/Chief Architect he led EBT efforts for industry leaders in telecomm, financial, media, utilities and hospitality industry verticals. He is the founder and Chief Architect of B-Wave Software LLC, an analytic and consulting firm in the field of EBT. He can be reached at: wrivkin[at]b-wavesoft.com

Bookmark / Share This

Bookmark or share this with others.