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.

Industry First Open Source Methodology for Business Rules

Yesterday ILOG Inc announced his donation of his Rule Based Methodology to Eclipse Consortium. I need to provide some explanations on what this donation is about. The Agile Business Rules Development methodology (ABRD) is the industry’s first free, vendor-neutral methodology delivered as an Eclipse Process Framework (EPF)OpenUp plug-in. ABRD provides a step-by-step process for developing business applications using technologies such as Business Rule Management System, BPM, BPEL.

ABRD mitigates the risk associated with new business rules initiatives by providing a well documented and structured approach for developing rule-based applications. ABRD allows organizations to avoid using ad-hoc processes or having to expend significant time and effort creating their own best practices.

In case you never have a look at EPF, Eclipse Process Framework provides tools for software process engineering to develop methodology. It comes with content knowledge organized in library, and with a tool, EPF Composer, which enables process engineers and managers to implement, deploy, and maintain processes for organizations or individual projects based on the content of the library.



The goal for EPF is to deliver a platform for producing software development practices, how-to, common definition and vocabulary, and processes with task, role, work product and guidelines definitions. Libraries are physical containers for knowledge content, process configuration and other parameters to publish the content as a set of web pages. Method content describes what is to be produced, the necessary skills required and the step-by-step explanations describing how specific development goals are achieved.
Processes describe the development life cycle. They take the method content elements and relate them into semi-ordered sequences that are customized to specific types of projects. They express who, when, what work will be performed.
EPF Composer provides a knowledge base of intellectual capital which we can browse, manage and deploy. This knowledge base organized in plug-in forms the basis for developing processes. We can define Roles, Tasks, Work Products, and Guidances in a hierarchy of folders named Content Packages. All content can be published to html and deployed to Web servers for distributed usage. Finally process engineers and project managers can select, tailor, and rapidly assemble processes for their concrete development projects. Once content is defined you can define the process building blocks, called capability patterns, which represent best development practices for specific disciplines, technologies, or management styles.

'abrd_openup" is a plug-in which extends openUp. From there you can reuse the content to develop your own plug-in. I recommend to extend ABRD without modifying it, so that you can leverage future release of it. If you want to contribute to abrd_openup you can send me email or comment on this blog. I will integrate most of the contribution in each release of the plug-in.
Have EPF fun!.

Agile Business Rule Development EPF plugin.

Eclipse Process Framework just integrated the Agile Business Rule Development plugin into the OpenUp library. This abrd_openup plugin addresses the development of business application using rule engine technology and Business Rule Management System. This is pre-release 1.0 but it already integrates a lot of content around rule discovery and analysis. I am working on the architecture track and will be able to deliver a new version in March. So any comments or contributions are welcome.
Please download EPF and the OpenUp library and let me know your thoughts.

A Cycle Approach for Business Rule Development

The Agile Business Rule Development methodology details all the different activities to develop a rule set, from rule discovery to rule set deployment and maintenance. We can group the set of activities into five groups. Those groups will be used to build an iterative approach to the development:

• Rule Discovery
• Rule Analysis
• Rule Authoring
• Rule Validation
• Rule Deployment
  

The following diagram represents how the five groups of activities can be executed in a process flow using loops to implement short iterations. The rule set will grow following these cycles to get closer to the outcome expected by the business.

Figure 1 Rule Set Development Life Cycle

In the first loop, between Discovery and Analysis, the team harvests the rules from the business process description, the subject matter expert knowledge, legal documentation, use cases or any other source. This loop represents the first phase of the rule set construction.

1.1.1 Cycle 1: Harvesting

This phase is limited in time. The development team splits the day into two parts, executing discovery workshop in the morning (2 or 3-hour sessions), then performing some analysis and documentation for the remaining of the day. The team iterates on these two steps during 2 to 5 days maximum, depending on the number of rules and their complexity. Meeting execution is based on standard requirement elicitation techniques. To make the better use of the development and business team's time it is important to plan in advance the workshop sessions and to clearly state what is in the agenda.

To organize the session the project team may need to name a moderator responsible of managing the meeting and keeping the team on track. His other roles are:

• Establish professional and objective tone to the meeting.
• Start and stop the meeting on time.
• Establish and enforce the “rules” for the meeting.
• Introduce the goals and agenda for the meeting.
• Facilitate a process of decision and consensus making, but avoid participating in the content.
• Make certain that all stakeholders participate and have their input prepared.
• Control disruptive or unproductive behavior.

Gather “Open Points” and follow up actions between sessions.

The goal is to document just enough rules to be able to start the implementation. In addition, this phase aims at understanding the object model within the scope of the application and to identify and extract some rule patterns.

The starting point of the Rule Discovery is the Decision Point Table: During the Project Inception, the project team is doing business modeling activities (not covered here) which aim at describing the business process and decisions applied to the Business Events corresponding to the scope of the business application. One important work product built during this modeling phase is the Decision Point Table which describes the point in the process (task, activities, transition) where there is a lot of decision points involved (test conditions and actions). These decision points represent potential candidate for rule sets.

1.1.2 Cycle 2: Prototyping

Once a certain level of discovery progress is done, the development team should be able to define the structure of the rule project: the rule set parameters (input-output business objects), the basic sequencing of the rules, also called Rule Flow, and the first major elements of the Domain Logical Model. The team then should be able to already implement some rules.

The idea is to execute the step “Rule Authoring” as soon as possible to uncover possible analysis and design issues. Indeed, most of the rules look good on paper but real issues arise most of the time during implementation and test. The next morning workshop session communicates the issues back to the business team. This leverages the feedback loop approach and provides an efficient mechanism to build a pragmatic, adequate and business-relevant executable rule set.

The second phase still does some discovery and analysis, to complete the rule harvesting.

1.1.3 Cycle 3: Building

Executable rules are more important than the ones defined on paper or in requirement tracking tools in a non-executable form. This is part of the agile-manifesto.

This agile statement is at the core of this cycle. Based on a Test-Driven Development (TDD) approach the goal of this phase is to implement a set of test scenarios with real or close to real data, to test the rules within their corresponding rule sets and their targeted execution context.

The day-to-day authoring activities can be seen as a set of little steps including test case implementation, writing rules, executing them, and doing some validation with the team members.

This cycle is still using short daily loops:

• Loop on Authoring and Validation to develop test cases and rules
• Loop on Analysis, Authoring and Validation to author executable rules, complete the analysis, do some unit testing and address/resolve issues.
• Loop on a bi-daily basis on Discovery, Analysis, Authoring and Validation. The discovery will be used to complete the scope of the rule set and address the issues identified during implementation.

The cycle 3 should finish after 2 to 3 weeks. The goal is to release the rule set within an integrated development build in order to start testing the business application with the decision service. The rule set should only be 40 to 60% complete. Business users or rule writers will then elaborate and complete it in cycle 5 (Enhancement). But at the end of cycle 3, the Object Model used with the rule should be at least 90% complete, and the project structure should be finalized.

It is still possible to execute this cycle multiple times, if the size of the rule set is bigger than what can be done in three weeks (exactly 40% of the size of the rule set cannot be done in three weeks). In this case, it is recommended to still time-box this cycle to three weeks and deliver a concrete build to the QA or validation team for review and execution. Then embark on another build for the next 3 weeks.

1.1.4 Cycle 4: Integrating

The goal of this cycle is to deploy the rule set under construction to the execution server and business application to test it with an end-to-end testing scenario. The integration of the decision service and the domain object model is an important task. Data is sent to the rule engine to fire rules and infer decisions. During the previous phases the development team develops a set of test scenarios with realistic or real data which will trigger rule execution. Those test scenarios will be executed during the integration phase to support end to end testing. In the future they will serve as non-regression test suite.

1.1.5 Cycle 5: Enhancing

It can be seen as a more mature phase where the goal is to complete the rule set, and to maintain it.

It includes authoring, validation and deployment. It is still possible to do some short face-to-face discovery activities with the Subject Matter Expert to address and wrap-up some issues and questions. But with this approach, the team responsible for maturing the rule set to close to 100% coverage can be another team than the initial development one. This team is more business-oriented. As owners of the rule set and the business policies, they can develop at their own pace as they have all of the core infrastructure implemented by the development team.

It is important to note that there will be some needs to enhance the object model or physical data model to add some new facts, attributes, or entities. This can be started in the Rule Business Object Model view by an analyst or can be done in the executable object model by a developer. Those modifications will follow the standard release management process of the core business application.

We will details some of those activities in details later.