BPM, BRM in SOA

Introduction

It’s a myth propagated by many consultants and vendors that Business Rule Management System (BRM) and Business Process Management System (BPM) are two alternatives for creating flexible and agile enterprise solution. There is no denying the fact that BPM uses rules for decision making. As always truth lies somewhere in the middle, BPM and BRMS are like two sides of a coin which can’t be separated, especially if used in conjunction with principle of service oriented architecture (SOA)

The underline idea behind this is totally separate process logic from decision logic. So what is process logic? Process logic is the specific logic of the business process such as controlling the sequence of activities, adhering of deadline and handling of exception. It is implemented using Process Engines like jBPM etc. Decision logic represents process independent management policies and principles and are implemented using rule engines like JBoss rules etc as part of BRMS

Principles of SOA

1. Explicit boundaries
   SOA is a design approach for special enterprise solution and special information technology software architecture

=> Consistent result responsibility

2. Shared Contract and Schema, not class that is, service share common contract

SOA is strictly independent of the technology.

=> Unambiguous service level

3. Service orientation is an evolution of component based architectures that is service are reusable

=> Proactive event sharing

4. Vendor Independent

SOA is strictly independent of the technology

5. Policy Driven

6. Services are discoverable

7. Business Driven

The granularity of the process modeling determines the granularity of the business service

8. Loosely coupled
9. Wire format not programming languages APIs
10. Document oriented

Consider a message in string format

2007-11-0642055

and compare it to document format:

2007-1-06

420

55

BPM & BRM in SOA

BPM is a closed loop model consisting of three steps: -

Step 1: Analyze, plan, model, test and simulate business process

Step 2: Execute business process via workflow spanning all applications

(process logic) by mean of process engine on a SOA as the

infrastructure.

Step 3: Plan, monitor and control processes, their performance and the

interplay of all business process.

BRP is a closed loop model consisting of three steps: -

Step 1: Based on business vocabulary it describes rules

Step 2: Describes the lifecycle of rules perform analysis, and design

simulation and test, via execution through rule engine.

Step3: Rule monitoring and controlling including responsibilities.

SOA transforms existing business computing assets into well-defined services. It can work effortlessly with BPM because of the reliance on services. SOA exposes services while BPM consumes them. When properly implemented, SOA opens a vast inventory of services for BPM to piece together into an all-inclusive flow of services.

While BPM defines and orchestrates the flow

The drive to use SOA to create a more agile infrastructure also highlights the importance of externalizing highly volatile business logic that is subject to change.

Highly volatile business logic can be defined as business rules. In the traditional application structure these business rules are buried in the application while in a more modern approach they are separated. Just as process flow can be separated from application code into an external BPM engine, the same can be done with business rules. Separating both process flow and business rules empowers a business analyst to make operational changes more quickly, providing maximum flexibility and adaptability.

An important shared characteristic of BPM, BRM and SOA is that they all deliver tactical cost/time benefits while building a base for competitive growth. Each one contributes to the overall agility of a company's IT infrastructure in the long term.

Business application companies such as Oracle/PeopleSoft/Siebel and SAP are contributing to the new opportunity of SOAs by supplying a new class of business applications called service-oriented business applications (SOBAs). SOBAs provide extended functionality for use on Web services standards and should contribute significantly to a company's repository of business services.

So the evolution toward service orientation as an enterprise elevates process thinking, analytics and performance measurement as core competencies to achieve competitive advantage. Accordingly, companies should establish best practices around these disciplines in parallel with implementing the supporting technologies.

Process and Rules in SOA

Many business areas employ rules. Traditional examples include marketing strategies,
pricing policies, customer relationship management practices, human resources activities,
regulatory constraints, product and service offerings. As rules evaluation matured, areas
such as recommendation technology revolve around rules.
Although the definitions of processes and rules differ the differences are not as clear cut.
Typically both rules and orchestration concepts are intertwined within the definition of a
business process.

Feature of rule engines vs orchestration engine (BPM)

Execution time Rules Engines strive to evaluate business rules as quickly as possible. In
contrast, ORCHESTRATION ENGINEs cater to long-running processes, where services
can take minutes, hours or even days to complete.

Synchronicity Rules evaluation is synchronous. In contrast, processes are intrinsically
asynchronous. Typically the ORCHESTRATION ENGINE invokes services in an
asynchronous manner. The mechanisms required to deal with asynchonicity such as
correlation and compensations are readily available in orchestration environments.

Statefulness Rules Engines are stateless; when a rule fires an engine typically pulls its
inputs from the knowledge base, evaluates it, and then updates the knowledge base.
In contrast, ORCHESTRATION ENGINEs are specifically designed to hold the state
(i.e., execution context) of each active orchestration.

Determinism The Rules Engine fires simultaneously all rules whose conditions are satisfied.
The order in which these rules actually execute is non-deterministic. In contrast,
process implementations strive for close alignment with the business. Business
processes are deterministic, and people go to great lengths to ensure determinism.

Rules are orchestrated by the process engine the same way as other services. This is absolutely consistent and show SOA elegance and power. Decision logic is primarily understood as business logic, as its process independent. This underscores the principle of the resusability of services. Rules are modeled and implemented once and are then available for use in different processes.

The right way of using rule engine by mean of BRM for all process-independent rules in SOA and it bring following merits: -

1. reusability of services and hence higher productivity.

2. rule change control mechanism can be controlled.

3. rule changes are versioned and achieved

4. process independent of rules.

Example, showing rule and process are closely coupled

WHEN status=new
THEN DO
creditRating:=call(creditService,customerData)
status:=ranked
END
WHEN status=ranked AND creditRating=threshold
THEN DO
floodCertification:=call(floodService,propertyAddress)
END
WHEN status=ranked AND creditRating>=threshold
THEN DO
appraisedValue:=call(appraisalService,propertyAddress)
END
WHEN status=ranked AND haveCertification and haveAppraisal
THEN DO
decision:=call(decisionService,application,creditRating,floodCertification,
appraisedValue)
status:=decisioned
END

WHEN status=decisioned
THEN DO
documentation:=call(letterService,application,decision)
status:=documented
END
WHEN status=documented
THEN DO
call(mailingService,documentation)
status:=mailed
END

Challenges in BRM

<<todo>>