Collaboration is Not a Four Letter Word

Comments: 1
Rate this:
Total votes: 0

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.


Ankit Tara
posted 6 years 35 weeks ago

Interesting article. The

Interesting article. The solution here, though, at least in my mind, lies somewhere between the poles the author creates. In days past, when I worked with numbers of teams, I always started from the same perspective with them--develop into a real TEAM, if you want to achieve success. That means you understand you have something to offer the larger group, and you are willing to do that, lead when necessary, and assist when that it the appropriate thing to do. Otherwise, you are a GROUP, which has been put together to complete a task, but it will be much harder to do if you persist in the feeling that each of you have something unique to do, and not really a part of a larger group. Whether teams created are large (i.e. single team for project), or in a more agile mode with smaller groups with specific 'chunks' of the action, there still has to be the sense of 'team' to achieve an integrated end game. That does not happen well when the PM or yet another group assumes the integration role. They only know what you tell them about what you have been doing. Instead, put together the 'team' you describe with individuals from the disciplines, and have them work in turn with smaller teams, and report on progress to the larger team.

Join the Discussion

Shopping cart

There are no products in your shopping cart.

0 Items

Related training courses provides training courses online and in person for individuals and groups. View courses related to the material you are reading on this page. 

BPM 101Agile Methodology for BPMOpEx 101Process Modeling, Analysis and Design: As Is, To BeAgile BPM Roles and ResponsibilitiesView the Learning Path for more courses »

Business Process Management Jobs

Remind me later

Free training!

Want to sample our training?
Attend our Open House for immediate access to sample some of our newest courses. 

Schedule an appointment with a training advisor to learn more about our certificate programs.

Act now. The Open House is only available for a limited time.