Where does the transformation from frozen code to real automation take us? As illustrated in the accompanying diagram, it builds on the promise of service-oriented architecture (SOA) to deliver a truly agile enterprise.
At the top you have a current process composed of activities and decision points. Activities create and use data through SOA-based data services, which sit between the activities and the databases. Between activities, a decision point needs to test a condition to determine which path in the process should be followed. It would call a standard decision service, which defines which business rules need to be invoked for the decision, and connect with the business rules engine. The engine then queries the database for the data it needs to determine the results of invoking the rules and returns the answer back “up” until it reaches the decision point that requested it, at which time the process can proceed along the appropriate path.
This is my overall conceptual view of how it all fits together; its implementation will vary according to the underlying technologies that are used, as the market offers many options to select from. You can expect, for example, that many BRMS vendors will offer both decision services and a business rules engine in one product suite.
Still, an organization could accept the value of this Operational Model, yet implement it in a code-based architecture that will freeze up on its completion. The Model must be supported by use of BPMS and BRMS in concert with the well-accepted DBMS, so that the most volatile parts of this Model can be changed without the need for IT resources committed to an IT project.
For processes, the BPMS has to support the original definition of a process’ activities, decision points and paths, and then it has to be able to change all these aspects as needed in close to business real-time: add new activities and decisions, retire those that are no longer needed, and changing paths through the process.
For Business Rules, the BRMS must provide similar functionality: definition of the original rule statements, followed by changes in statements, adding new rules and retirement of rules when they are no longer applicable to the business.
Both the BPMS and BRMS must also support change management; while change is no longer bound to code, the need to test and validate changes prior to implementation remains. The capability of these systems is increased by the addition of impact analysis and analytics.
For example, given a set of rules for underwriting loan applications, changes to ease those rules can be analyzed by a BRMS against prior application history to determine the number of increased approvals that would have resulted, balanced against the additional level of risk of funding those approvals. BPMS products are already well known for providing simulations of process executions based on trigger volumes and activity execution times to show what the impact of process changes would be. Overall, these capabilities provide an organization with the capability to understand and improve its operations on a near real-time basis.
Next Time: Looking Forward
