This is the first of an occasional series, “Breaking the Rules”, in which we look at the sacred rules governing business rule design and examine some exceptional circumstances under which they can, and should, be broken. In this article we investigate the prohibition of multiple actions (or, more correctly, conclusions) in definitional rules. Should your rules only have one action as some authorities suggest? Or are there occasions when more than one action is allowed?
Why do business sponsors within an organisation adopt BRMS? What motivates them and what return do they expect on their investment? What drives IT teams to suggest BRMS to their businesses? What ROI do they expect and how does this differ from the business. What adoption pitfalls does this lead to? In this article we look back at our 12 years experience of applying BRMS in the finance industry to see what lessons we can learn from Business versus IT expectations about BRMS and how they differ.
The cost effectiveness of open source business rule management systems (BRMS) are surely self evident – they are free aren’t they? Isn’t that always better than paying a traditional vendor through the nose? Isn’t this decision one of technology’s no brainers? Well no, I don’t think it is…
When it comes to implementing an accounting system, an organisation has three basic choices: buy an ‘off the shelf’ system, build one themselves ‘from scratch’ or compromise and build one themselves using proven infrastructure from an established vendor. Here we argue, from experience, that the latter approach gives an unbeatable combination of flexibility, cost and low development risk. Furthermore a business rule management system (BRMS) is a very potent implementation vehicle for an accounting system.
Recently I encountered two potential clients, in the midst of selecting business rules support software for high volume transaction processing, who were actively considering a continuous event processing (CEP) platform as an alternative to a BRMS. Given that business stewardship of their business rules (as opposed to rules managed exclusively by their IT department) was a goal of both projects – were they right to consider CEP? I do not think so.
Occasionally the event processing requirements will mandate the sophistication of a CEP, but frequently they do not. In the latter cases a BRMS is a better solution. Find our what happened to the project who chose the CEP platform.
In recent years a new set of tools is emerging to allow business users to maintain their business vocabularies, rules and fact models. These differ from business rule management systems (BRMS) in that they are firmly oriented toward business experts and not technologists. What functionality do these tools offer and how do they differ from BRMS?
A job advertisement I saw recently really seems to epitomise some common and serious misunderstandings that many corporations have about the value and role of business rule authors. How many of my concerns do you share?
I was recently heard of a tragic case of a company that lost their business logic in a certain domain. This sounds incredible, but it can happen. How could you avoid the same happening to you?
There are a number of clients (particularly investment banks) that are using business rule management systems BRMS tools to maintain business rules. They all firmly believe that this is a best practice that will bring a great benefit. But IT practitioners are still the stewards and custodians of these rules – so have these august organisations missed the whole point of business rules?
Planning on building business rules or automating your business decisions? Then, as part of your business analysis, you need a fact model. But what is this? How can you build one? Why should you significantly invest in building one as soon as you can and how will you recognise a good one when you have built it?