Wednesday, April 2, 2008

Software Development Life Cycle for BR-BPEL application

The purpose of this article is to present an integrated software life cycle for development team who wants to leverage the capabilities offered by technologies such as BPM-BPEL and Business rules management system.

Each new business application development is triggered by a business needs to support or enhance and improve business efficiency. Even with an Agile approach, to trigger the project, architect, business users, project manager and project sponsor have to work together during the Inception phase, to define the business case, the requirements and justifications of the project. Once the project funded, the team may work on specification and requirement documents. I simplify a little here because in reality a lot more documents may be produced, but the goal here is to present how those requirements are supported in an Agile way using the BRMS and BPM products and not discussing about requirements management. So let state the specifications are our main entry point to detail the major work that needs to be done for developing the applications. The format of the specification can be user stories, or a more detailed description. (a good reference to write specifications and user case is Alistair Cockburn work ). Specifications are classically managed by a standard SDLC which includes design, build, test, and deploy of working code to the different staging platforms (development, test, or production).

The Agile approach enforces short iterations to deliver quick value to the business. The blue tasks in the diagram below represent a set of iterations that build the core of the business application.

The horizontal axe of this diagram represents time. The pools are used to contain activities executed in the different development environment. The top pool is the business analyst team which is triggering change to the application. When the development team is using BPEL and BRMS technologies, there are parts of the specifications which go directly to those components: Business processes will be implemented using BPEL and BPM process map, and business rules using BRMS. In the first release (you can see a release as a vertical slice of the above diagram) the agile value of each of these technologies is not clearly articulate. This is true that BPEL and BRMS help to develop in less time, and adopt an agile approach of development. But the main value proposition will come in longer term by the ability to efficiently support the two types of change requests the business user may ask:
• The business rules and policies changes: business want to improve the decision done by the rule engine
• The process tuning or improvements: the process needs to change due to legal constraints, better error and exception path management, or for better execution.

Business Rule changes will be done in the BRMS using a web based interface or IDE like JRules Rule Studio. The hot deployment capability of a rule set authorizes to deploy a newly updated rule set in a question of seconds. This helps a lot to support quick change on the decision logic attached to decision services called by the BPEL process instance. Rule Developer can do a lot of try and catch in a pre-production environment to improve the quality of the rule set, so the quality of the decision. Some IT organization implements the “champion – challenger” pattern to evaluate a new rule set against the production one. The champion rule set is in production and process transaction request with a certain level of metrics: metric can be number of automatic decision, or other business key performance indicator. On the pre-production server, the challenger rule set receives the same data flow, and metrics are compared. If challenger beats the champion it becomes the new champion in production.

Business process improvement requests are managed using the BPMS system, and a new process definition can be released to the different platforms. We can definitively see more change requests coming for business rules change, than on the business process: When we have a working process it is more sensitive to change it. Still business process changes will happen to support for example an improvement of the exception management, or to find some short-cut on the global processing so that the time to complete the process is better.

The core application can still evolve with a new release path. Change to the GUI, or data model will most likely be managed by a new release of the full application.
As a conclusion it is important to consider using an agile development methodology which support quick change when using BPM – BPEL – BRMS technologies, if you do not adapt your way to develop business application, you may lose the opportunity to be agile.


James Taylor said...

Thanks for an interesting post - I blogged about it here as I had a couple of things to add.

James Taylor
Author of Smart (enough) Systems
Blog at

JBoy said...

You are right I try to make the schema simple. The main point was as you quoted :"changes in genuine requirements is slowest, process changes slower and rules changes most frequent"

Then I also agree the analysis team needs to focus on decision step of the business process which at the implementation point of view will call a decision service using business rules. This was not really the purpose of this post. I'm preparing an example of BPM- BR modeling for the future that should describe this.

Anonymous said...

that's a great and usefull sheet - it's quite simple but this is exactly what I'm looking for. to show things simple they're a little bit more complicated but difficult to handle it.
thx for the post. I want to get your overview and drag it to my next customer meeting. - ;)

Anonymous said...

Good post.