Six Myths of Rules and Business Process Management

Several years ago, business rule and business process management technologies were segregated by information architects. If and when a business rule engine was used, it was considered a “black box,” something that generated complex results required for highly variable decisions with multiple contingencies. But, thanks to the ever increasing demands of business owners for smart and more intelligent process workflow and technological advances by select vendors, this segregation is now over. Business rules are important, if not critical for a wide range of business processes, and therefore, it is now commonplace to see rules engines included in business process management systems.



What are business rules? Business rules are business policies, goals, strategies and guidelines that include declarative statements, constraints or predicated actions. The authors of business rules are typically business stakeholders. What most have now come to realize is that the full potential of productivity and the agility of business process management cannot be achieved without digitizing business rules. While much can be gained by modeling and simulating different workflows, without the dynamically executable specificity of business rules and their ability to capture goals and adapt to constantly changing business conditions and situations, the process models remain theoretical.

There are many reasons why business rules, especially declarative rules that can capture management intent, are regarded as essential for BPM . One of these reasons is the tangible ROI achieved by companies who are quickly and effectively deploying rules-driven BPM solutions. Rules-driven BPM solutions are differentiated from embedded or integrated BPM and rules, because they use one cohesive business process management system that can handle declarative rules in conjunction with procedural flow logic, enterprise integration and asynchronous event correlation.

In the rush to embrace business rules, this distinction is frequently overlooked, but it is critical to the future of BPM and to the emergence of a new kind of BPM one might call ‘SmartBPM.’ Adding to the confusion of how rules and process can and should best work together is the proliferation of a number of myths that have evolved around the “Rules and BPM” campfires. By addressing six of these myths, it is hoped that we can remember that what really matters are what the business owner has asked for: compliance, growth and productivity. The shortest path to these goals is through end-to-end automation of business processes that have at their core procedural flows and declarative business rules.

The six myths pertaining to Rules and BPM are as follows:

1. We are focusing on BPM (automating processes) not rules: This myth is instigated by those who have subscribed to the idea of processes but have not understood the importance of business rules. The implicit assumption is that ‘someone else’ will take care of the execution and operational logic. The myth stresses the importance of process automation and lessens or eliminates the requirements for actually translating the plan into action – through the automation which business rules can bring. It typically stems from a lack of understanding or appreciation for the potential of business rules.

  • Reality Check: The key misconception here is to think that one can do effective process automation and digitization without digitizing and automating the business rules. When you come to a decision point in a process or realize you need policies across processes, you are dealing with business rules. These business rules are sometimes in policy rule books¸ or in the heads of process participants¸ or in code (sometimes in legacy applications.) If these rules are not digitized and automated, what you end up with are bottlenecks: the work stops at the in-box of the “experts” who need to figure out what to do next; or the business rules become unmanageable because they are dispersed in spaghetti code which is difficult to maintain and change.

2. We can handle the rules in Java or C#: This myth is propagated by traditional developers in IT shops who have had experience with earlier versions of business rule technology. In this scenario those who are developing the BPM application agree “rules” are important. However, they hold to the myth that these rules can be coded and supported through a procedural language such as Java or C# and developed without any declarative rules or rules management. It is the attitude that says “I can do it in Java – I can do anything in Java.” True. But at what cost to the business? The needs of the business must be weighed against an entirely understandable developer bias. The difference between this myth and the previous one is that here there is some buy-in for rules but without a clear understanding of declarative programming and the need to manage the business rules as assets.

  • Reality Check: Rules are assets that need to be managed separately and independently of your source code. You need to organize and manage the business rules, allowing you to specialize and add new rules incrementally. You should also be able to have the rule engine select the appropriate processes or fire the appropriate rules based on time interval, access control, version or circumstance. To do this type of management and specialization resolution with Java or C# is incredibly complex and unmanageable.

3.“Best of Breed” is best of choice: In this scenario you have buy in for rules and BPM, however, the promoters of the myth ask: why don’t you get a BPMS product from one vendor and a different BRE product from another vendor and put them together. You want two features: procedural flows for BPM and declarative businesses rules; therefore, you need two separate systems.

  • Reality Check: Loose coupling is not a panacea. There are situations where it is appropriate to use loose coupling and others – such as rules and BPM – where a two engine loose coupling approach is disastrous. There are many problems and limitations when the BRE and the BPM system are entirely separate:
    • Difficulties in managing multiple data models: The rules engine and the process engine will have their own data models. A two-engine approach implies that these data models and information sharing between the two products will become yet another enterprise integration problem: they need to constantly be mapped one onto the other, resulting in inefficiencies and complexities that are extremely difficulty to keep aligned with business change.
    • Complexity in sharing information: In a loosely coupled model, the process engine needs to send its decision data, obtain the decisions and then continue its in state transition accordingly. This is inefficient and complex, especially in high-performance applications. This “chatty” conversation approach between the two engines will not scale.
    • Cost of training, supporting, and managing two environments: A two system solution implies training on two different platforms and development environments. It also means you will be getting support and system-level management of two different environments. Two products will have two different release lifecycles. You want to make sure they are certified with respect to the latest releases with all the fixes. Even in situations where the same company is releasing different products, there is difficulty in managing this release complexity, to say nothing of the installation, training and management headaches.

    *There is a false notion underlying the best of breed myth when you assume that rules are separate from processes, therefore, calling for two separate systems or products. Believing that declarative rules such as decision trees/decision maps or expressions/constraints are separate from the process flow leads you to believe you need two separate systems to manage them and then integrate. This is a false assumption and must be treated as such when embracing BPM.

    • Reality Check: In any high-performance software product there are different features or functionalities. For example a DBMS optimizes queries, deals with integrity constrains, and also handles concurrency. It is ridiculous to say one should have actually three products – a ‘best of breed’ query optimizer from one source, a separate engine to handle integrity constraints, and a third to deal with concurrency! It is the same with business process management systems. Business rules are not incidental. They are essential. They should be – and need to be -- within a single cohesive system, with a single engine capable of firing rules and processes concurrently and seamlessly. In the defense of those who propagate this myth, however, they may not know that such a convergence is possible. But it is possible and has proven successful for several years at highly demanding organizations.

    4. Let the BPMS handle ‘simple’ rules and the BRE handle ‘complex’ rules: Here is another myth, that somehow simple “decisioning” is enough for BPM. For complex questions they call a business rule engine. So the idea is to categorize rules: some are “simple,” some are “complex,” some are “in between” some are “inference,” some are “event correlation,” and some are “who knows what.” The idea is to handle some rules here in the BPM and do some there in the BRE. So, the myth goes, you have the BPMS handling the simple rules and the BRE handling the complex rules.

    • Reality Check: No one provides a precise definition of what is complex and what is simple. When you have 3 terms in the rule condition is that complex? How about 2 or 2.5? Or should it be 4? Also what if the rule changes from simple to complex or vice versa? Are you now going to two separate systems and changing them: making sure the “simple” is in the BPMS and the “complex” is in the BRE? This is a strange approach that also suffers from the problems that underlie the previous myth.

    5. Rules should be modeled separately from BPM modeling: Even though there are numerous business process analysis modeling products out there, modeling of business rules, regrettably, is often pushed off to a different platform or approach.

    • Reality Check: Business rules should be modeled while modeling the business processes, not as a separate step in a different tool or paradigm. To separate the modeling is to encourage gaps between planning and execution, and to do this introduces latency and impedes agility. To be effective in building BPMS applications one has to think about, analyze, abstract and model the declarative rules in conjunction with other elements such as the information model, the organization model, the flows and the user interaction. The appropriate use of business rules changes the topology of process flows. It simplifies the flows and facilitates the management of applications involving digitized rules and flows.

    6. Rule-based BPM is a process engine written in a rule language that ‘reduces’ everything including processes to a rule. The myth here is that rules-based BPM builds everything through rules: processes are built in a rule “language” and so are business rules. The promoters of this myth then continue with conclusions based on this misconception that there are ‘deficiencies’ with the rule-based BPM approach since it seems to force or limit process development to rule-centric development for everything.

    • Reality Check: A rule-driven BPMS has all the functions, different types of development models, as well as features that you find in any BPMS. It is a superset of BRE and BPMS. Rule-based BPMSs do not in fact support their processes through a rule language encoding. They instead provide rich development options for all aspects of BPMS development – both for procedural and declarative programming. In fact rules-driven processes provide all different tools and modes of development with all the support for tools that are needed to develop agile enterprise applications. The rules complement and assist the processes in leveraging the power of inferencing to carry out task assignments, support service levels, invoke the appropriate decision rules at decision points, select and dynamically determine what to invoke, and displaying graphical interfaces with intensions. The core problem of this perhaps most serious of the myths is simple: the promoters of the myth have not understood a simple fact – rules-driven BPM is a superset of Rules + BPM. Everything that is true of traditional BPM is also true of rules-driven BPM. And, rules-driven BPM has the added benefit of a cohesive single-engine approach to declarative rule management capabilities.

    It is encouraging to see both customers and analysts are realizing the importance of cohesive models and platforms that appropriately combine and aggregate declarative business rules with procedural flows. It is also encouraging that despite the myths, rules-driven BPM is emerging as the leading BPM technology of choice for customers interested in solving real business problems. Business rules are not an afterthought for successful BPM; rather, they are an essential component of it.

    It is unthinkable to have a relational database management system without the support of various types of integrity constraints or developing word processing software without the spell check functionality. These same principles from database management systems and common desktop tools are also applicable to business process management systems. The full potential of agility through BPM can only be achieved through a cohesive platform that allow you to declaratively digitize your business rules in the context of your automated business processes, supported through a single, intelligent or SmartBPM platform.

    About the Author

    Dr. Setrag Khoshafian - One of BPM’s early pioneers, Dr. Khoshafian is the author of several books on computing and business process management. At Pegasystems, Dr. Khoshafian is responsible for leading product direction and BPM technology strategy, and is also involved in numerous technology, marketing, alliance, and customer initiatives. In the past 15 years he has been involved in the invention, design, and implementation of several advanced products. Previously he was the Senior VP of Technology at Savvion. In addition to BPM, he is a noted expert on SOA, object-orientation, and database technologies.

    More by Dr. Setrag Khoshafian

    About Pegasystems

    Pegasystems Inc. (Nasdaq: PEGA) provides software to automate complex, changing business processes. Pegasystems, the leader in unified process and rules technology, gives business people and IT departments the ability to use best processes across the enterprise and outperform their competition. Our new class of Business Process Management (BPM) technology makes enterprise systems easy to use and easy to change. By automating policy manuals, system specifications and lines of manual coding with dynamically responsive updates, Pegasystems powers the world's most sophisticated organizations to Build for Change(TM). Pegasystems' award-winning, standards-based BPM suite is complemented with best-practice solution frameworks to help leaders in the financial services, insurance, healthcare, manufacturing and government markets drive growth and productivity. Headquartered in Cambridge, Mass., Pegasystems has regional offices in North America, Europe and the Pacific Rim. For more information, visit http://www.pega.com.