Periodically I get asked about bringing business rules into the Rational Unified Process or RUP. RUP and the Enterprise Unified Process are designed to apply UML and best practices in a formal way.
They do not formally manage business rules but consider them part of Use Cases or of requirements. To design decision services successfully, you will need to manage business rules more coherently. RUP outlines six best practices that business rules really support:
- Develop Software iteratively
By designing decision services to encapsulate your business rules, and managing those rules as atomic items, you can develop & test business rules separate from other software components. This ability to iterate continues into “change time” once the software is deployed thanks to the rule maintenance capabilities of most business rules management systems.
- Continuously verify software quality
Business rules are easy to verify as they are close to the business. Rules management encourages constant monitoring and this improves software quality. Business users can really give you feedback on rules in a way they could never do with code.
- Control changes to software
Traditional software systems can be “brittle” – small changes can break them. Decision services built with usiness rules are expected to change and can be updated individually even in 24×7 environments.
- Manage Requirements
While business rules should not be managed like requirements, they should be managed in parallel with them. Rule management provides a means of managing “requirements” as explicit business rules, throughout and beyond application development.
- Use Component-based architectures
Decision Services separate business logic into re-usable, manageable components.
- Visually model software
If “a picture is worth a 1000 words” then business rules could be worth many lines of code. Business rules and their interrelationships can be visualized and management more easily than code, resulting in more of the application being managed more visually.
Several changes are typically required:
- Add a Business Rule or Decision Modeling activity alongside Business Modeling that emphasizes the collection and organization of business rules. This replaces a singular focus on use cases with a more balanced view of use cases as a means of rule discovery but not a place to manage them [see above not on rules not requirements]. This activity also has highly compressed interactions between rule modeling and analysis/design/implementation. You need to manage these “source rules” and map these to the use cases and design requirements you are documenting. Source rules are generally in the language your business users would use – both in terms of being in English, for instance, and in terms of using business phrases and terminology. Effective management of terms and vocabulary for these rules will make it easier to check them and easier to map them to additional analysis artifacts. In general, source rules should be kept at a high level. I blogged recently about a great post on the use of Use Cases and Statecharts to find business rules by Scott, who posted some thoughtful comments here. I also reviewed a great book on use cases and rules here.
- Formally identify Decision Services as the components that implement business rules and manage these as a type of component. Decision Services will need to have object-specific rules (that is rules written formally to act against the objects in your system) that drive the decision. As you develop your object or data model, you can start to develop rules that execute against that data. These rules must be managed in a repository, versioned and structured to allow for re-use across Decision Services. These business rules will map back to source rules, though not typically in a simple fashion, and will be collected into rulesets.
- You will need to develop a separate rule maintenance process outside your regular process, especially if business users are maintaining some of the rules in your Decision Service. While you will want to go through many of the usual test and QA steps, realistically you will need a different process as the time frame will be shorter and the changes more frequent than you expectations for a typical IT project.
If you are interested in agile development, by the way, I have posted a virtual conversation with Scott Ambler and an article on this topic for InfoQ.
