“Bridging the gap between business and technology for true collaboration” has long been the mantra of Business Rule Management Systems (BRMS) and Business Process Management Systems (BPMS). Although this has too often been a strictly technology-based approach, methodologies and approaches have been forwarded in both the rule and process realm. The problem? It’s almost always been for one or the other and the true power of implementing decisions with modern technology will certainly rely on a powerful combination of both.
Part of the problem lies in the function of most packages available on the market today. BRMS platforms came first and have become quite adept at providing an efficient means for execution and management of business rules. The BPMS platforms that followed did the same for process and often included facilities for monitoring and modeling as well. However, there is typically little to no integration within the packages to encourage a combined approach and externally vendors usually only provide integration with their platform and another product at a very technical level.
More importantly, these platforms are far too often used independently and yet still considered to be the panacea for all the agility ills that an Enterprise may face. While each can provide tremendous benefits, each is meant to only provide certain functionality. Attempts to bury rules within processes (because you have only the means to manage processes) or implement process flow and control from business rules (because you have only the means to manage rules) ultimately limits the agility that a true Business Decision Management (BDM) approach might bring.
We have long argued that an organization can be most successful when looking at business rules from within the context of well-defined business processes. Treating the combined set of all Enterprise rules as a single unit makes no more sense than a corporate data warehouse without any relational structure! The context provided by a process allows a new level of evaluation. Looking at processes first, then the decisions that support those processes, and finally the business rules that comprise those decisions facilitate the articulation of reuse, management and governance over the entire scope of the business and can be done on a decision-by decision basis.
If you aren’t quite yet sold on the power of combining process and rules to achieve greater agility, flexibility and transparency, think about what each of these brings to the table. Process at a very high-level can be explained as a model or description of what the business does. Consider an example from the home mortgage world. A typical high-level process model might include loan sourcing, loan processing, closing, and servicing. We have a workflow and a way to capture where and how people and systems will interact. This is what the business does. Rules (or sets of rules making up decisions) describe how the business does its job. In our mortgage example, each of these processes has a set of decisions inherent to it. Loan sourcing, for example, likely includes decisions involving pre-qualification, product selection, pricing and application submission. It is also important to note that the rules within these decisions are where change will occur – not so much at the process level. We’ll usually always source a loan before we process it. However, the standards for pre-qualification, the set of products available, and the prices of those loans is going to vary dramatically – at least daily, if not hourly in some cases. Consequently, we need to handle them differently than the process itself. And a service-oriented architecture (SOA) is the glue that brings this all together.
A principle tenet of Business Decision Management is the ability to express decisions in a fashion that is understandable to business analysts while maintaining a technical or logical rigor sufficient for implementation. Looking at rules and process in the fashion described here begins to make this a reality. From a technical perspective, a modern BDM application might in its simplest form have 3 layers. First is a business process layer where the process model and workflow are defined. This specifies what the business does and lays out the processes and their interaction. From there the processes will move through a business or web service layer enabled by SOA. This layer of abstraction allows the processes to not be concerned about decision implementation details – only where to call to get the needed result. These results come from the business decision layer. Quite often this will be where our business rules are executed. By isolating them from our processes we may change them, share them, and move them around without altering our main processes. We may provide specific management capabilities so those rules can be changed by the business. This truly defines the agile enterprise.
Modern technology provides us with all the tools we need to build the modern application. Combining these technologies and using them in the manner for which they were created while adhering to the proper methodology (i.e., The Decision Model) will allow the modern enterprise to reap the results.
