Business Rules

The goal of DMN is to provide a notation for decisions understandable to all audiences, including business and technical people. This is good news and is the very reason we introduced The Decision Model (TDM) to the public in 2009

This article examines how to use tabulation to write better business rules. If you’re not writing business rules, well, you should be. Fortunately, the very same guidelines apply to writing requirements in general, so there is much to be gained on all fronts.

...As hands-on business ownership of decision automation gains ground it is becoming apparent that fully automating a decision-making process requires an expanded concept of business rules that includes the ability to transform and/or derive data within the rules process itself, in order to align the input data with the policy statements that are driving the decisions; and to produce a wider range of outcomes.

The world of business rules and business rule management has grown up. It has evolved into the world of business decisions – a much more compelling discipline by which companies can master their business logic.

The Decision Model (TDM) is a methodology and framework for modelling the business logic behind business decisions. Its popularity, adoption, and number of ground-breaking success stories are increasing significantly. TDM, as a powerful but simple graphical notation, is easy for both business people to understand and IT professionals to implement. As such, it puts business people in control of their business rules and logic and it accelerates IT’s ability to automate them quickly and without errors.

An operational business decision has structure that you can’t capture using business process models, use cases, or similar techniques. If you fail to delineate that structure, you completely miss a core part of what makes business processes smart. The structure of a decision can be diagrammed in top-down, business-friendly fashion using a Question Chart (Q-Chart™ for short).

Unlike decision rules, behavioral rules do not pertain directly to determining the best or most appropriate answer (outcome) among alternatives... Three simple but typical examples in article illustrate. Avoid force-fitting a decision-oriented approach to every business rule problem. It simply doesn’t work!

As a business analyst you are the all-important glue between the business and technology. Your skills range from various kinds of modeling to gathering of high-level as well as detailed robust requirements. Sometimes you operate in traditional systems development and sometimes within agile approaches. A business analyst’s responsibilities are wide and deep... What Are the New Opportunities for Business Analysts?

Would organizations use such a model? What kinds of organizations? Who in those organizations would introduce it and create them? What would organizations use it for? How successful would these decision models be? After seven years, we have answers.They tell an interesting story about the birth and usage of this new kind of model.

A missing ingredient in most current approaches to IT requirements and business rules is developing a standard business vocabulary, a concept model. Every business analyst should be familiar with the technique – it’s simply about clear thinking and unambiguous communication. What are basic constructs in developing a concept model? This article discusses four prefabricated elements of structure, ones that will enable you to build a complete and robust business vocabulary.

All paths to organizational decision modeling encounter a common question: How do you introduce The Decision Model into an organization? More specifically, how do you gain management attention for delivering decision models as a standard practice? This month’s column addresses that question.
 

Three questions regarding breaches of business rules should be addressed by Business Analysts: enforcement level, guidance message, and breach response. The goal is context-dependent, pinpoint reaction to breaches in real-time. Addressing breaches intelligently is key to creating friendly, agile, secure business solutions, ones that can evolve rapidly in day-to-day operation.

 It is wise to use whatever techniques we can to discover the 'real' requirements and business rules before embarking on development. We all seem to know that it is cheaper to fix problems earlier rather than later in an IT project. So why do so many of our projects exhibit the same mistakes?

What role should business rules play in procedural languages and enterprise architecture? How do they relate to platform independence and compliance? What about knowledge retention? This column, the last in a series of three, explains the deep insights offered by the Business Rules Manifesto on these questions. Already read it? You may be surprised by what you find here!

This means that The Decision Model is at the center of a serious shift in the way we perceive and manage the business rule and logic dimension. So, this month’s column highlights the shift, starting with 2009 and ending with 2012. At its core are the seven observations indicating that a shift is happening. More important, each observation contains corresponding article links to related Modern Analyst articles.