Business Rules

RuleGuide is a tool that accelerates and improves the quality of business decision and rule capture, analysis and management. By providing an enterprise repository for business decisions, rules, and associated metadata, RuleGuide fosters ongoing collaboration and alignment ofthe business and IT teams.

In this article we focus, not so much on the similarities among decision models, but on their differences. More than that, we explore the idea of classifying decision model structures based on differences in their logic. The decision model diagram is the first place to look for visible differences among decision models.
 

Continuous change is a central fact of life for business these days. The techniques you use for business analysis must be based on the assumption that business rules will change, often quite rapidly. The best business solution is one that caters to such change, always doing so in the manner friendliest to business people and Business Analysts.

Like most business analysts, Charles captured business rules as part of requirements gathering. Also like most business analysts, he followed traditional business rules approaches. These included writing individual business rule expressions, storing them outside the confines of process models and use cases, and providing pointers to them. However, he changed his approach after experimenting with The Decision Model.

Transaction Business Logic is the processing required in processing database transactions to enforce business policies. It is sometimes characterized as Enforcement logic, since the transaction should be rejected if the rules are not passed. Consider the insertion of a new Purchase Order...

The Decision Model in practice has delivered many unanticipated, but positive surprises. The most obvious and powerful surprise is how it drastically simplifies process models. In fact, we regularly receive unsolicited messages from people who experience this effect. For example, one practitioner condensed a 45-page process model to one with eight task boxes.
 

Structured business vocabulary is a missing ingredient in most current approaches to developing requirements. This omission should greatly concern every business analyst. Indeed, business vocabulary is key to a whole range of fundamental challenges, including but not limited to capturing business rules. One reason is that business vocabulary, like data and business rules, lives on beyond the point of system implementation and deployment.

The number of successes with The Decision Model is escalating. Organizations are using The Decision Model to solve a range of business challenges and opportunities including some we did not expect. Therefore, this month we summarize three real world projects to illustrate how organizations are using decision models and how quickly project teams are delivering them.

“Requirements are rules. They arise from business models, but they are different from those business models.”  Perhaps you’ve heard the argument. Maybe you’ve even made it yourself. Are they?  No!  Read this article to find out why.

In this article, I explain a project completed in the financial services industry. A client asked me to lead a project to redesign a failed sub-process that had resulted in billions of dollars of backed up financial transactions. This particular financial process had a history of failed and abandoned process improvement projects. The pressure was on and, I must confess, I was not entirely sure that The Decision Model would be a good fit.

You are experiencing success with decision models even without the assistance of decision modeling software. Imagine the possibilities with proper software support!

Can the same business rule be enforced differently in different contexts? The answer – an important one for re-use of business rules – is yes. This article explains. It also outlines what business analysts need to know to specify contexts of enforcement for a business rule effectively.

A software tool for The Decision Model supports the entire life cycle of Decision Management. This includes the authoring, analysis, testing and deployment of entire decision models. Whether managed by the business – as some people consider ideal – or managed by IT or business analysts on behalf of the business – as others consider necessary – business decisions need not only a repository for storing decision models, but a range of functions to manage them effectively.

Many IT professionals currently prefer the if-then form for expressing rules. Why? Put simply, it's closer to what they need for implementation, whether under a rule engine or a programming language. Consequently, they often resist expressions of rules from the business perspective as business people would naturally prefer them. But what effect does that have on the rules?

As business analysts, we know that a business process model is a crucial technique for transforming a business and redesigning automated business systems. Yet, we struggle with the best way to represent the business rules that guide it. This is not a surprise, but disappointing. Ironically, business rules may be the most important dimension of an enterprise. They are the core of business decisions and actions, whether automated or not. How do we treat them today?