What rules regulate a business?
Grässle: The rules can vary considerably. Some rules determine a discount, some schedule working hours, and some define account assignments. Essentially, everything that directs or limits a business activity for us is a rule. Some guidelines can be derived from the goals and strategy of an enterprise. Others arise from legal requirements or from the market behavior of customers and competitors.
Please explain the business rules approach – where is it being used internationally?
Schacher: The business rules approach is an enterprise engineering methodology that approaches an enterprise or a specific area of an enterprise comprehensively. It includes the development of a business strategy to systematically derive directives as precise business rules. Special business rules engines can automate the business rules, which can accelerate the execution of business rules and reduce error rates. The precondition is that the subject matter experts who are responsible understand the business rules and tailor them to specific needs as quickly as possible.
In addition to precise formulation, consistency also helps. Consistency mostly means automatically checking the completeness and lack of contradictions within the rules. An additional advantage is that the rules also answer the question “why.” In other words, an operative business rule coherently describes why something is done is a particular way within an enterprise, rather than doing it another way. This factual basis for a business rule can be followed all the way to the enterprise’s vision – a consideration that is becoming more and more important, especially in the context of stronger and stronger calls for compliance or conformity with laws and guidelines.
Internationally, every large enterprise uses business rules technology – a technical infrastructure for defining, managing, and executing business rules. The primary users come from the financial, healthcare, and telecommunications industries. In the real world, unfortunately, the business rules approach is often limited to the use of a business rules engine, and we think that doing so fails to take full advantage of the possibilities of comprehensive enterprise engineering.
Why did you write a book on the business rules approach and to whom is it addressed?
Schacher: We understand the business rules approach as the methodology of a comprehensive mind-set of how to design an enterprise. It’s not just another technology. That’s what we wanted to express in our book. The approach – and the book – begins by developing a business strategy and ends by optimizing program code that automates a significant portion of the strategy.
Grässle: Our book is not just directed to IT specialists. It also addresses subject matter experts and decision makers in an enterprise who deal with the definition and implementation of enterprise policies. This book should help the promising idea behind the business rules approach become more familiar in German-speaking countries.
What areas are particularly appropriate for the use of business rules? Can you give some examples?
Grässle: In principle, every business is characterized by certain rules. First, the business rules approach helps makes these rules explicit and thus fosters a common understanding of the essential specialized terminology and contexts. Second, the business rules automated by business rules technology strengthen the agility of an enterprise. That is particularly important in areas where rules change often and rapidly.
Two typical examples here are the rates in the wireless industry or the regulations that help recognize money laundering in banks. In both cases, it’s important that each can be adjusted rapidly and without delays caused by adjustments in the IT systems. Finally, the business rules approach supports transparency, particularly in areas that demand compliance – think of the Sarbanes-Oxley Act and Basel II.
No business without rules. No profits without a plan. No success without goals. How can business rules be cast in technologies, and what kind of technical infrastructure is required for such applications?
Grässle: Business rules technology can roughly be divided into three categories of software tools. The first category covers technology that discovers rules – tools that extract technically interesting or important contexts from raw data as rules. The raw data itself comes from databases – customer behavior with tools for data analysis, business intelligence solutions, or the source code of legacy applications.
The second category covers technology that manages rules – tools that enable companies to manage business rules as a valuable resource. These tools create, modify, and store the rules in an enterprise repository, where they version, validate, or verify the rules. This category also includes support for a controlled process, such as a workflow with authorizations, to put the rules into effect as of a certain date.
The third category covers technology that executes rules – tools that automatically execute rules or check to make sure that the rules are followed. At runtime, the business rules are interpreted or, as is the case with the model-driven architecture of the Object Management Group (OMG), transformed into conventional code like Java or Cobol.
Do standards already exist for business rules?
Schacher: Various standards are being developed in the area of business rules technology, but commercial products offer hardly any support for the standards. One relevant standard, for example, is the JSR 94 specification for the call interface of business rules engines in Java. Some commercial products already support the specification. The RuleML format is based upon XML and standardizes the representation of various types of rules. This very universal format was created in universities and finds increasing acceptance in the commercial world. Standardized depiction of technical production rules is handled by the Production Rule Representation (PPR) specification that the OMG is currently working on. A final example here is the Web Ontology Language, OWL, developed by W3C. It uses an XML format to represent semantic networks and certain types of rules.
In addition to these technologies, OMG adopted business-oriented specifications at the end of 2005 – such as the Business Motivation Model (BMM), developed by the Business Rules Group. It defines a meta model that can map technical concepts like visions, goals, strategies, tactics, influencing factors, and estimates. The Semantics of Business Vocabulary and Business Rules (SBVR) specification is also available. It shows how a community-specific vocabulary along with structural and operative business rules can be formulated in a syntax based upon natural language. Finally, Business Process Modeling Notation (BPMN) should be noted: a uniform notation for modeling business processes. Employees of KnowGravity were especially involved in the development of both OMG specifications: BMM and SBVR.
How are business rules implemented in an enterprise? In other words, how are errors or violations handled? Who manages or controls the handling?
Grässle: The existence of a rule does not guarantee that it will be observed. When human beings execute business activities, it’s easy to observe or recognize violations in hindsight, but difficult to prevent them ahead of time. Just think of the prohibition against selling alcohol to underage persons. In this case, superiors or coworkers are charged with enforcement. But it looks a lot different with automated business activities. An ATM can enforce a rule that prevents overdrawing an account. In IT systems, checking to see if the rules are being observed often does not occur immediately. But when a rule is violated – which can be determined only in hindsight – IT can intervene to correct the situation.
What technologies and products are available on the market? And what are their strengths and weaknesses?
Schacher: The most important suppliers of business rules technologies include firms like Fair Isaac, ILOG, Computer Associates, Pegasystems, Haley, Versata, Innovations, Corticon, Yasu, Ness, Unisys, Microsoft, and Oracle. In addition, you can also find various open source products and numerous smaller suppliers that offer innovate niche products. Most of these systems are business rules engines based upon a service-oriented architecture. The advantage of this approach is its ability to be integrated into an existing IT environment relatively simply and step-by-step. The disadvantage is that a very large quantity of data must often be transferred during a service call. A danger or significant problems with performance can arise.