Subscribe to the FREE Business Rules Journal Newletter


 

 

 

     INSIGHT ARCHIVES ...
untitled

Applying Agile to Business Rules Elicitation

by Carole-Ann Matignon

Here is an interesting enigma.  On one hand, Business Rules are gaining momentum due to the need for Agility in automated systems.  On the other hand, despite wide appeal and adoption, the Agile methodology has hardly been applied to BRMS.  As I became more immersed in both, I started considering various ways to combine both aspects of modern agile systems.  Let me share my thoughts in this article.

In the many projects I have seen over the last decade, I have witnessed a traditional waterfall — from Business Users to Business Analysts, eventually to IT — to get changes done to the business logic layer of the systems.  The whole purpose of Business Rules is to enable more agility.  How come the Agile methodology has not altered this traditional approach?

My take on Agile

The Agile methodology shines by its incremental approach, providing many opportunities to review the status of the effort and steer it into different directions whenever roadblocks occur.  A naïve comparison between Waterfall and Agile could be an analogy to end-to-end direction versus GPS.  The former will get to your destination quickly and efficiently, with the opportunity to use shortcuts that you learned with experience.  Unfortunately, if any of the roads are blocked on the way — due to an accident or a special event — finding the right detour could take you a long time, much longer than you had budgeted for, while the latter will reassess and update your list of maneuvers as you go, to constantly get you back to an optimized path to your destination.

A Product Manager at heart, I see tremendous value in the transparency of the Agile approach.  When I have used that approach in the uncharted territory of new technologies or products, I find I saved time by co-designing in a way; although I knew what I was looking for, I found that the try-and-adapt cycles reduced the need for pages and pages of what I would have called 'obvious requirements'.  The problem is that a business person and a developer have different perspectives on what is 'obvious'.  Unless you have only one person representing both, you can be certain that non-said requirements will often be overlooked.  It happened to me; I am sure it has happened to others.  Communication is critical, and exhaustive written requirements could take years to be perfected.

Agile methodology has been documented over and over as a great path to reduce risk and accelerate time-to-market.  That being said, a software development effort and Business Rules implementation may or may not expose the same characteristics.  How else could you explain that Agile has not been widely applied to BRMS technology?

Some history on Agile and BRMS

The only attempt I am aware of, that made it to a larger audience, was proposed by Jerome Boyer and team at IBM.  They contributed it to the Open-Source community a few years ago under the "ABDR" add-on, which stands for "Agile Business Rule Development" methodology. 

ABDR focuses mostly on the process aspects of rules development in an Agile environment.  It puts attention on the following key aspects:

  • Prepare the logical object model for rules;
  • Develop the business terms and corresponding artifacts;
  • Organize rules in terms of decision services (mostly for deployment services);
  • Establish a rule governance process.

This is a great starting point for including Business Rules into a software project.  The use of Business Rules does raise the opportunity to discuss and refine the language for a solid object modeling foundation.

What the methodology does not cover, though — which is my main focus — is the harvesting of those business rules.  How do you go from ideation to specification to implementation at full speed in an iterative manner?

A practical approach to Agile Business Rules Harvesting

Rather than re-inventing the wheel, I recommend we borrow from the Agile methodology in the first place.  All concepts are probably not applicable, but others fit both software development and business rules paradigms quite nicely.

I always liked the 'test-early' concept of Agile as it gave me the opportunity to get my hands dirty early in the process and to test the interactions live.  How does that apply to business rules?

  • Understanding the business impact of your business rule changes is something you want to do early rather than late.  Amazingly enough, in many projects I have seen, the business impact cannot be measured until 2 weeks or more AFTER deployment.  As a Subject Matter Expert, I wish I could get this insight much earlier in the process.  Ideally, I would like to get some directional computations as I am formulating my changes.

  • Testing and measuring can only be done within the context of formal use cases.  Agile recommends that user stories be documented for communicating the requirements to the development partners.  Similarly, use cases could be leveraged for communicating business rules.  I would even argue that use cases could be exposed to business users to formulate their requirements and to experiment with alternatives when appropriate.  Well-selected use cases can be used to challenge business users in the context of real situations.  The beauty of business rules technologies is that you can execute those statements without having to wait for their implementation, assuming that enough of the infrastructure is readily available — although you do not need much to get started.

I envision an Agile approach for Business Rules that will enable business users to get acquainted with those technologies without such a heavy learning curve.  After all, what they know is their business and their interest in technology is only driven by necessity, not affinity.

I presented this approach to Agile Business Rules Elicitation in more detail at Rules Fest in October 2011.  Feel free to reach out to me directly with your questions and/or comments.

Key takeaways:

  • Agile lessons learned are applicable to Business Rules elicitation;
  • Current Agile efforts have been focused on object modeling;
  • Challenge business users with use cases;
  • Factor business objective measurements early.


standard citation for this article:
Carole-Ann Matignon, "Applying Agile to Business Rules Elicitation," Business Rules Journal, Vol. 12, No. 11 (Nov. 2011), URL:  http://www.BRCommunity.com/a2011/b626.html  

November 2011
Applying Agile to Business Rules Elicitation
By Carole-Ann Matignon
April 2011
Capturing Business Rules You Don't Know
By Carole-Ann Matignon


October 2010
#1 Reason You Should Pay Attention to Gartner's Pattern-Based Strategies
By Carole-Ann Matignon


July 2010
Don't Hate Business Rules
By Carole-Ann Matignon

 

 

 about . . .

  CAROLE-ANN MATIGNON


Carole-Ann Matignon is President & CEO of Sparkling Logic, a company pioneering new approaches to make Decision Management more widely accessible. Her passion for Decisioning techniques, combined with her technical background, made her a credible strategist and advocate for "Everything Decision Management."

Prior to Sparkling Logic, Carole-Ann served FICO as Vice President for Decision Management Tools. She was in charge of the direction and strategy of the industry-leading BRMS product Blaze Advisor. as well as the Predictive Analytics and Optimization products. She crafted the vision for Decision Management and fostered technological progress. She personally holds a few patents on adaptive analytics and other decision management capabilities.

Her past experience at ILOG (now acquired by IBM) and Cleversys (now acquired by Kurt Salmon & Associates) focused on customer interactions as the head of Field Sales organization in the Americas and Consultant in Advanced Technology group. In particular, she implemented applications early on using Expert Systems and Business Intelligence tools.

Carole-Ann is now a recognized thought-leader in the industry, sharing her thoughts and expertise on her blog and regularly speaking at Decision Management events like Business Rules Forum and Rules Fest.

 

 

[ Home ] [ Staff ] [ About BRC Publications ] [ Editorial Feedback ] [ About BRCommunity ]
[ Contributor's Guidelines ] [ Privacy Policy ]