Here is the value proposition of BPM/Rules from a management viewpoint. Simply put, firms that utilize the Business Process Management with a Business Rules Approach:
- Reduce the cost of application development.
- Accurately and rapidly gather processes and business rules.
Without a formal, BPM/Business Rules Approach gather rules and processes through a loose tale of data models and ‘use-cases’. The core motivation of the BPM/Business Rules approach is to move application requirement from the technical team to the business team. The outcome is that lower-cost individuals get the business rules and the get them right.
I recall a recent conversation with a group of folks, when one individual said that he did not see the value of business rules (or BPM for that matter). This person believed that a solid written specification with some PL/SQL and Data Modeling could address application development. I guess, success strictly depends on the contents of the written application. You can use the BPM/BR approach to develop a very accurate specification; however, you will loose the vast capabilities of this new technology.
One example: As I work with business rules, I am struck with the weakness of data modeling as a requirements gathering tool (Look at this example.). The objective of data modeling is to develop a 'normalized' structure that retain all the instances of an entity. In reality there might be many use-cases within a single entity, even at higly-normalized forms. I do'nt think data modelers are creating tables called: 'orders_from_perferred_customers_with_medium_credit_rating'. In data modeling we might create 'types'; however, the rules that assign these type change and data modeling provides not mechanism (other than brute-force), to track these. You get this information, free of charge, using BPM/Rules technologies.
If business rules technology overcome the weakness of data modeling, then business process management overcomes the weakness of 'CRUD' development in tools such as PL/SQL, and screen generators. For instance, a number of system processes might post records to an order table. One is a screen entry. Another is a program that reads a file. Yet another moves data from a legacy system. Unless the 'CRDU' developers have decided to add the 'source' or the 'origin' of the record to their application, this information will be lost for ever.
What conservative, Waterfall or Information Engineering advocates are clinging to might be explained in terms of the Ross's 'Enterprise Architecture as Strategy'. On page 71, the book describes four stages of Enterprise Architecture Maturity. Adocates of these legacy methodologies are arguing that organization should not advance to stage 4, Business Modularity.
In addition to accurate and timely application development BPM/Business Rules:
- Dynamically Connects Rules, Activities and Events at no cost to the developer
- Positions Processes and Rules for change
- Creates more business-friendly artifacts, connects business requirement with technical artifacts
- Promotes a component-based approach