Collaboration and agility have always been noted as key benefits of business rule systems – collaborate and be agile! This has typically been discussed in terms of rule management – enabling business user control over an established rule base. But this often overlooks how we first get to a baseline rule base.
Decision Management is as much a methodology as it is a technology. It provides a detailed, methodical approach to defining the decisions, and where appropriate, the rules to support those decisions. We now have a plethora of rule and process management platforms to enable testing, execution, monitoring, and change management. Most of the tools available now support the methodology (many even handle the emerging Decision Model and Notation (DMN) standard). Business analysts can find, define, analyze, document and write rules. But we’ve seen some cases where we’ve inadvertently created yet another corporate silo and dichotomy between Business and IT. Business creates and throws a set of rules (perhaps in requirements, perhaps not) over the fence to IT and hopes everything works out. It is a matter of fact that developing rules requires a very precise and unambiguous set of specifications. But when happens when that isn’t produced?
A strictly linear waterfall process of this type – business analyst to designer/architect to developer – is problematic. Implementation can and will find many issues that either were not considered by business analysts or were out of scope of their expertise. Some of the common problems we have seen IT encounter in this scenario:
- Referencing attributes incorrectly – they are mis-typed, unavailable, or just not representing what business thinks they are.
- Inconsistently applying data validation – sometimes putting it in the rules or often assuming everything is good to go by the time the rules execute.
- Distinguishing between workflow, process, rules and decisions – determining what should go where on a consistent basis.
- Poor or inefficient rule structure – either in terms of execution speed or management complexity.
- Concepts of rule execution – e.g., if no rules in a ruleset execute does it signify a system error or a business error?
- Identifying potential areas for re-use of rules across business events.
On smaller projects it may not be too onerous for developers to go back to business for quick resolution. Larger efforts with tight deadlines may have to rely on a defect process. This will further impede efficiency and resolution.
Experienced decision management developers are going to be very cognizant of all these areas. However, they typically lack deep business knowledge of the domain and cannot (should not!) make assumptions about the business intent. That’s why they don’t write the rules in the first place. And at this point there is no trainable methodology or software platform that will completely enable business empowerment from the start without intervention. What does this mean? We collaborate sooner.
We have seen this process work at Enterprises in the past. Typically it has come around after the realization that progress was slowed by IT going back to business to resolve issues on a constant basis. By involving all facets of development – business, design, development – earlier we gain many advantages:
- IT gets to learn and understand the business by working with Business
- Decisions, rules and process are developed that truly meet the Business need
- The implementation process is more efficient
- Testing and Management ultimately become more efficient as well
This does not have to be a complicated process. We’re not advocating throwing the entire Business side in an auditorium with all of IT, locking the door, and telling them not to come out until it’s resolved! Rather, we can create a well defined, scheduled, and documented process with measurable metrics to facilitate the implementation.
We propose a very agile approach with small teams represented by all relevant aspects of the project – business, design, development, etc. – that each takes a representative chunk of the problem (perhaps defined by a business event). Frequent, short meetings will be scheduled to methodically work through the event. Assignment, resolution and tracking of issues that arise are maintained on a daily bases. Specific areas of concern are assigned to each group member. For example:
- Business deals with requirements, a data dictionary and perhaps some examples of complex elements of the business event.
- Design has the bounded business event and may additionally be represented by the data architects.
- Development has a physical data model, a high level workflow/process and perhaps some prototyped rules.
- Most importantly, everybody brings their particular expertise to the group.
We hope (and indeed we have often found) large portions of the material to be straightforward and in relatively good shape. By devoting the time early on to correcting those areas with discrepancies the implementation can be made more efficient with a better quality product. More importantly, the TEAM is fully on board with the approach.
Collaboration is a word that has been thrown around quite a bit over the years in this field. By truly embracing it at all points in the project we significantly increase the chance of fully realizing its benefits.
