Randy Cronk asked an interesting question the other day - he asked me to cite some examples of making it easier for business and IT to collaborate (see his comments on this post). This made me think of a recent ADT article - I blogged about it here - in which a couple of related points were made:
- Giving that sort of power to users, even savvy ones, presents challenges. "If you give non-technical users the ability to use declarations to change business logic within an application you have to be [careful] that you're not going to cause performance issues."
- Eventually, users may be able to write and maintain business rules in ways beyond the examples here, but for for the time being, that's still what Forrester's Rymer calls "the new frontier."
It also reminded me of some comments I heard amongst some senior IT staff from healthcare payers - they were not convinced that business rules would allow business users to "do it themselves" or even that this was a good idea.
Now the common thread here is the need for collaboration and the power of business rules to create more opportunities for more effective collaboration. I wrote a longer piece on the different perspectives that the business and IT bring to application development before and it seems to me that the right way to use business rules is as a vehicle for this kind of collaboration.
Remember, the kinds of business rules we are discussing may be complex, with many interrelating considerations. They may also be simple but extremely numerous, covering a wide variety of different situations. They may change frequently based on internal policy decisions and external competitive or regulatory factors. And perhaps most difficult of all for organizations to manage they might require non-technical expertise to understand or edit.
This might lead one to suppose that business users should just be given tools that let them right the rules themselves in some unconstrained way. Like the healthcare folks I was talking with, I don't think so. The reality is that the rules must be deployed in a real system with performance and scalability needs. The rules must execute against data stored and managed in other information systems. Business users are not as used to the discipline of QA and testing that most organizations would want to see before new rules are rolled out.
To empower business users to own the business rules in their systems, you need to create an environment not where IT is replaced by business users but where business users and IT can collaborate. The IT team needs to be able to identify the right data sources, integrate with other systems, identify the structure and metadata for the rules that will be required and develop a structure within which the business users can work. The business users for their part have to work with them to make sure the rule templates and data structures will meet their needs and then they have to step up to owning the rules developed using these templates. In most systems this will not be 100% of the rules but will be the ones that change frequently (promotion or availability rules for instance) or require business expertise to manage (underwriting or fraud rules for instance). As the article said
To address that put the rules engine behind a restrictive graphical user interface that allows the [business users] to observe actions and use various drop-down menus to make decisions, but within limits.
A business rules management technology will allow business people to control and develop their own rules. This means that changing how decisions are made, like creating database reports for example, no longer resides with the IT department. This improves agility and responsiveness. It also removes, to some extent, the element of application design and maintenance that is most prone to errors and inconsistencies. It requires, however, a definite change in mindset from both the business and IT - from a sometimes contentious and finger-pointing blame game to a more collaborative "all in this together" approach. Having a flexible business rules engines can facilitate collaboration between the business and their IT department if you do it right.
This AIG Trade Credit case study is one example and this Egg case study is another. But I will leave the last word to John Rymer as quoted in the ADT article
"Most of the issues with BREs lie not with the tools and technology available, but with the readiness of organizations to adapt to building applications in new ways". Business rules are a way to collaborate but the software capabilities are not enough - you must have a will and a process for it too.
