For some time users of Business Rule Management Systems (BRMS) have used rule execution sequence as a means of binding together and orchestrating the rules in a set—providing a ‘top level’ view of their content. Nearly all BRMS products have enshrined this idea in the ‘ruleflow’ concept. In many of these products the creation of a ruleflow is seen as a standard step in packaging a rule set and many rule authors find it a natural activity.
We argue, using an example, that not only are flows rarely required, but that they are frequently harmful to the agility of a rule set, can introduce harmful and hard to find errors and can make rule sets difficult to understand by business users. Furthermore, users frequently misunderstand the goal of ruleflows and misuse them.
We show that there is an alternative to ruleflows that orchestrates rules (especially large rule sets) more effectively and is easier to understand—the business decision model. (more…)
Experience has shown that sets of business rules, even those administered using Business Rule Management Systems (BRMS), become very hard to manage and understand once they reach a certain level of size and complexity. Although small, very tightly focused rule sets can be effective for simple business domains, large rule sets are challenging to create and even harder to maintain. Small rule sets that become large over time (scale up) present the most difficulty. They are at risk of collapsing under the weight of their own growing complexity or becoming the sole preserve of a small number of ‘gurus’ and ‘high priests’ who alone understand them—defeating a key objective of business rules.
In a previous article, I described how to overcome the challenges of maintaining a business rules over a long period. But how can you manage the complications of rapidly growing rule sets: keeping them easy to understand, changing them safely without unintended consequences and avoiding ‘stale’ and duplicate rules? Here we show, by example, how Decision Modeling, used from the outset can address all these problems and we discuss in more detail the difference between business decisions and business rules. (more…)
James Taylor, CEO of Decision Management Solutions, and I co-presented a webinar earlier this month to discuss the application of business rules and business decisions in implementing financial compliance solutions.
We agreed that regulatory compliance (e.g., Basel III, FED 5G, FATCA) is a problem well suited to a Business Rules approach. Primarily because:
- it is repeatable and tractable to automation
- it demands transparency and traceability (regulations need to be followed and be seen to be followed) which implies the rules need to be expressed in business English
- regulations change frequently and typically mandate a ‘short time to market’
- it requires a degree of rigor to cope with the complexity of regulation
- it stipulates many regional variations in business logic which need to be coordinated
However, we identified five key issues for financial compliance and discussed why business rules alone do not fully address these challenges. In summary, we feel that Business Rules alone does not resolve:
- how business metrics can be used to monitor the effectiveness of compliance rules
- ‘big picture’ impact analysis to a compliance rule set when regulations or underlying financial conditions change
- the need to consistently apply a compliance policy throughout a complex business process
- the ability to precisely define rule semantics and align them to compliance policies
- the ability to scale a rule set while maintaining coherence
Decision management can address these issues and the webinar illustrates this with a demo of a compliance decision model using DecisionsFirst Modeler. Please see the recording of the webinar at http://decisionmanagementsolutions.com/agile-and-cost-effective-financial-compliance
If anyone is using decision management (or just business rules) for financial compliance I would be most interested in your views.
Are you effectively managing your business decisions (or indeed rules)? Are you fully in control of those operational decisions your company makes, maybe thousands of times a day or more (possibly using some degree of automation), that determine which customers you will accept, what credit terms you will offer them, what risks you’re prepared to take, what products they might like or need, what prices to charge for them, whether you are compliant with regulatory edicts – in short, the bedrock of your business?
The reason I ask is that the vast difference between various companies’ approaches to operational decision management is a constant surprise to us. For some, the management process is a well-oiled machine: not only are all key decisions automated (this represents the bare minimum in this contest!), but so too is the continued measurement of their effectiveness and alignment with (ever changing) business strategies. Decisions are separate from code, tangible to the business, explicit, agile, measured and optimized.
For other companies decision management is a morass of emails, spreadsheets, confusion brought about by lack of visibility and missed opportunities. For many, despite the acknowledged importance of these decisions, their processes are mired in chaos. “We’re not mature enough for that,” or “There is no need to be so highfalutin,” some IT managers claim – it seems to us that, when you examine how well the two corporate styles compare in their effectiveness, this denial is just not credible.
So: how grown-up is your company when it comes to decision management? Why not take our quiz and find out? (more…)
If you model your business decisions and rules using the Decision Model (TDM), it might at first appear that both the information captured in the TDM glossary and the inferential dependencies between rule families in the model itself, together, capture all the same information that might normally be caught in a fact model. All the business terms, their relationships and the fact types than bind them are already in the glossary—why bother to capture them again in a fact model? Would this not cause redundancy and undue maintenance overhead? Our experience of using TDM in the investment banking domain suggests that it is not as simple as that… (more…)
In BPMN, an ad-hoc subprocess is one which has no sequence: the order in which their constituent tasks are performed is unknown or unspecified. The tasks therein not only have no stipulated running order, they don’t have to execute at all. Until recently, when modelling business processes, I’d use ad-hoc processes to denote business activities for which order was irrelevant or ‘unknowable’. But the use of BPM tools has thrown up a new rationale for ad-hoc processes. One which may make their use considerably more common… (more…)