Collaboration is Not a Four Letter Word

Comments: 2
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.

Comments

hannah lewis
,
posted 27 weeks 2 days ago
Nothing crystalizes what you bring to the table more than when you're forced to articulate your competencies Collaborating challenges you to articulate and distill what you are great at, and what you do poorly. That help me compose essay for universityhonesty about your strengths and weaknesses can force you to ask for help when necessary and be brazen about how you can help others.
John Tieso
,
posted 34 weeks 3 days ago
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

Your email address will remain private.

Shopping cart

View your shopping cart.

Related training courses

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

BPM 101Decision Management and Business Rules 101OpEx 101Methodologies and Approaches for BPMAgile 101View the Learning Path for more courses »

Editorial Directors

Gregg Rock
Gregg Rock
Editor & Founder
BPMInstitute.org

Andrew Spanyi
Editorial Director
BPMInstitute.org

Jeff Scott
Editorial Director
BAInstitute.org