Exciting Differences in Business Rules Design
This is the final installment of this series on business rules systems development. However, the truth is that the most exciting part of the series has only just begun. By following a business rules design approach, you will unleash your business community's decision-making capabilities. You will enable it to change its mind as it sees fit.
What is a Business Rules Design Approach?
A business rules approach, when compared to other systems development approaches, places deliberate emphasis, importance and formalism on the rules of the business and, hence, the delivery of rules within corresponding system logic.
This means designing at least three parts of the system (process or control flow, database and rules). It means integrating these three distinct designs into a system that works. So, what is new about designing for a business rules approach?
For starters, you don't want to bury rules within application-specific, nonshareable code, where you cannot leverage them (and change them) as separately managed software.
Thus, the first difference in design philosophy is that you aim to implement the rules in a manner that separates them from "traditional" application logic. This means you house the rules in rule-specific commercial technology or build your own rules capability. In this way, the rules are shareable across applications and components.
The second difference is that you favor changeable rule implementations over rigid ones. You can achieve this by implementing rules in declarative language where possible. You also enable future rule changes by delivering flexible data structures. That is, you want to deliver databases capable of easily accommodating new kinds of services, products, people and other aspects important to business change.
Is a Generic Approach Possible?
In 1989, Candace Fleming and I published a book entitled, Handbook of Relational Database Design (Addison-Wesley Longman). It documents a methodology for designing effective, practical databases using imperfect relational DBMS products. At that time, the relational model was 19 years old. Some relational products were quite mature while others were new and less mature. There were products that claimed to be relational even if they weren't. However, with the relational model as an ideal implementation target, there was a solid direction. The generic relational database design methodology, by holding sacred the qualities of the relational model, assists in delivering useful databases, regardless of relational product. When database designers apply the generic relational database design methodology, they enhance it with product-specific considerations at each step.
A new question surfaces. Is it possible (or even desirable) to devise a generic business rules design approach? After all, some rules products are quite mature. Others are new and less mature. Some claim to be business- rules-oriented when they're not. New rules products are emerging. There are many valuable ideas about rules from the field of knowledge engineering, active database research, business rules groups, the relational model and even object- oriented communities. However, there is no universal "rule standard" against which software vendors design new releases and against which you can confidently measure the merits of your rules design solution.
As a result, rules products today (and in the future) will vary significantly in how they deliver a rules capability. While this makes the market-place confusing, there is good news. Fortunately, many common principles of a business rules approach emerge across vendors and products, even without a standard. Four of these principles are summarized in Figure 1 and serve as the foundation for the generic design approach.
Figure 1: Four Basic Principles as the Basis for Business Rules System Design
From Generic to Specific
It helps to review the generic relational database design methodology as a framework by which to craft a corollary in the rules world. The generic relational database design methodology starts by translating a logical data model into a product-independent design targeted for relational database technology. This is called a preliminary database design. This design is faithful to the structure and integrity of the logical data model; however, it builds on the simplicity, productivity and flexibility advantages of relational database technology while remaining independent of your choice of RDBMS. You adopt the preliminary design to your product environment. Finally, you tune it to accommodate functionality and performance requirements.
As a parallel, the generic rules design methodology translates a logical rules model into a product-independent rules design targeted for delivering a rules capability into your system. This is called preliminary rules design. It remains faithful to the rule dependencies and integrity of the logical rules model. However, it builds on the simplicity, productivity and flexibility advantages of a business rules approach.
You next adopt the preliminary rules design to your product environment. Your target technology may be not rules-oriented technology at all. You may design shared program code to enforce rules (outside or within the DBMS). The database design team may be a key player here. You are aiming for well-managed rule automation. This ensures that rules are no longer redundantly (and possibly inconsistently) implemented in application code. Ultimately, you tune your rules design to accommodate functionality and performance requirements.
Always keep in mind, however, that you are likely to measure the success of your design not by performance alone and not by how correctly it reflects current business requirements. Rather, the business will measure your system's success by how easily it accommodates business changes and future needs. The ability to accommodate database changes was one advantage of relational database technology. The ability to accommodate changes in rules (business policy logic) is now an advantage with the business rules approach.
The Rules Design Process
Because a design goal is to introduce a rules capability into your system architecture, the rules design process consists of at least four considerations: specifications of how the rules capability functions, the assignment of rules to a system tier, detailed specifications on how each rule is implemented in its target tier and insights into how all layers communicate with the rules capability.
A Basic Design Approach for Rules
- Step 1: Confirm your architecture but sharpen it with a rules capability. No one doubts that for many reasons a three-tiered architecture (i.e., presentation layer, business logic layer and data layer) is preferable over a traditional two-tiered approach. However, to leverage a rules approach, you need to look deeper than this. Specifically, you need to recognize that the business logic layer may, in fact, contain two kinds of functionality. The traditional functionality is that which controls the specific process flow for the target application. The new functionality is a capability or layer that manages execution of shared rules on behalf of applications. This is analogous to a layer that manages access and manipulation of shared data.
- Step 2: Determine the basic requirements for your rules layer. Once you accept the need for a rules capability, you decide on the functional and technical requirements that will best service your application. Do this regardless of whether you will buy a product or build a simple rules capability yourself.
As a very general view, consider that there are two very different kinds of rules capabilities.
One is a data-oriented rules capability through which a rules component executes rules in response to a running application touching data for which rules have been declared. With this approach, as an application attempts to update data, the rules capability watches for conditions that must be true about the data as well as conditions that should cause a reaction, such as the creation of new data. The data- oriented rules capability watches out for the complex conditions specified in rules.
Another kind of rules capability is a service-oriented rules capability through which a rules component executes rules upon request by a running application, not because the application directly attempted to touch data. In this case, the rules service waits until an application calls on it to apply rules to data. Usually, the application passes the data to the rules service. The rules service may also retrieve and update data from a database. The rules service executes the rules and sends the results of the rules execution back to the calling application. The application can then decide to abort the transaction, update the database or carry out other actions.
It is entirely possible that your system may benefit from more than one kind of rules capability.
- Step 3: Determine if you will acquire a commercial rules product. Once you determine the requirements for your rules layer, you need to determine if you will buy it or build it.
Consider past history. How many of us followed good database design principles (principles based on the merits of the relational model), and then implemented our design in nonrelational database products? It is not impossible to do, but it certainly is not easy. You cannot easily gain all the benefits of relational technology.
The same is true when you take a business rules approach. You can follow good rules design principles where those principles are based on the merits of the business rules approach. To implement them without rules technology is not impossible, but it is not easy either. And, full benefits may not be easily attainable.
Refer to Figure 2 for a summary of the benefits of a business rules approach. Notice how many of the benefits are enabled by commercial rules technology.
Figure 2: Summary of Benefits of the Business Rules Approach
- Step 4: If you will not buy a rules product, determine your approach for incorporating a rules capability into your system design. There may be many reasons why you cannot incorporate rules technology right now. You can still design your system with rules in mind, but you have to be diligent about separating the rules or you will lose them again.
One way to achieve rules separation is to simulate a simple rules capability. Introduce into your application architecture a new kind of service or component targeted specifically for managing rules execution and nothing else. That is, design for and implement object classes that exist primarily to execute rules. The more you separate these rules-oriented object classes from application-specific object classes, the more shareable the executable versions of the rules will be. You can design these rules-oriented object classes to simulate a (simple) data-centric rules capability or a (simple) service-oriented rules capability.
If you choose not to create rules-specific object classes, you will build your application with application-specific object classes that contain executable rules as parts of the methods. This does not deliver a rules capability that is separate from the application.
- Step 5: Determine the system tier in which to enforce rules. Assuming that you included a rules capability (commercial or homegrown), you now need to assign rules to appropriate system tiers for enforcement. Thus, in your preliminary rules design, consider delegating to your rules layer the rules you want to manage as a separate, shareable, changeable asset to the rules layer.
- Step 6: Design for rules in the rules capability. The steps you follow to design for rules in the rules capability vary depending on the characteristics of your rules capability (data- or service-oriented), functionality and rules limitations of your rules capability, and performance considerations, for example.
When working with a data-oriented rules capability, rules design and implementation should be data-centric. This involves first specifying the tables and columns to the rules product, usually in data or object model form. Then, you express rules about the data for which the rules capability will watch. The rules are usually expressed in declarative form, although this may require language translation if the product's language is not intuitive to you. For example, if you have captured your rules as IF/THEN statements and your product does not support this syntax, you will need to rethink the expression of the rules.
Rules design for a data-centric environment may also involve altering the table specifications to accommodate rule-processing restrictions. The design effort may also involve denormalizing data in the database for functionality and performance reasons.
In comparison, when using a service-oriented rules capability, the rules design effort tends to be process-oriented. It usually involves creating an object model with which to communicate or share data with the rules service. Usually, the objects for rule execution contain data only, no rules. The rules are in the rules service. Sometimes you express the rules in procedural code, and sometimes you do not. If declarative, you may be able to use IF/THEN syntax. You are not likely to need to change database specifications because a service- oriented rules capability is not so closely tied to the data. The rules design effort usually involves grouping rules into executable sets or hierarchies, sequencing the execution of rule sets and possibly sequencing the execution of rules within rules sets. You do this so that when your application calls the rules capability for rules execution, the rules capability has been set up to perform that service in a particular manner.
There are various ways you can build your own simple data-aware rules capability. In the simplest form, if acceptable, you can implement each rule in the DBMS. When your application attempts to update the database, these rules will execute automatically. If this architecture is unacceptable, you may consider building a simple rules service that correlates database touches with the execution of corresponding rules.
There are also various ways you can build a simple service- oriented rules capability. You would need to create a rules capability that accepts rule requests from applications and has a process by which to execute them. Details on building your own rules capability are beyond the scope of this article.
- Step 7: Tune the database. Every systems design effort requires database tuning. As always, tuning the database is specifying design options that improve performance or functionality of an initial database design. The rules designer and database designer should collaborate on database tuning. If useful, you can classify each rule pattern (see part 4 of this series) according to its data access characteristics: single versus multiple tables, single row versus multiple rows and those requiring aggregate functions and sorts. Traditional database tuning options then apply. To preserve the most stable data structure, tune first those tuning options that are transparent and do not compromise the stable data structure. These include, as examples, specifying file allocations, primary and secondary space, free space, locking considerations and indexes.
- Step 8: Tune the rules. As with database tuning, proper rules tuning can be the difference between a successful and unsuccessful implementation. As with all approaches, tuning in a business rules approach should be collaborative and iterative. Data, process and rules specialists should jointly perform rules tuning.
The best kind of tuning for rules, as for databases, involves tuning options that are transparent to human actors, programmers and application components requiring rules execution. Examples of these tuning options include caching mechanisms for rules or data referenced by rules. Because each rules product is very different, refer to your product-specific manuals for insights regarding these kinds of tuning options.
There are, however, tuning options that are not as transparent. For example, you can move rules enforcement from the ideal (rules) tier to a different tier. You may do this to accommodate performance or functionality limitations. Sample options for rules enforcement are:
Application-specific layer: This refers to application code that is not shared with other applications. This code is usually procedural code (such as C++, Java, Visual Basic, etc).
Rules layer: This refers to rule-specific definition intended to be shared among applications. In commercial rules products, this code tends to be declarative (SQL-based or IF/THEN syntax). If a particular rules product accepts a rule definition, but implements the definition in the DBMS (as may be the case for a some rules in a data-aware rules product), this is still considered to be a rules-layer implementation. The critical point is that the rules are defined to the rules layer and the rules layer manages them, regardless of where the executable code actually resides.
DBMS domain definition: This is database code intended to be shared among applications that share the database. It defines data types, lengths and sometimes value restrictions on domains.
DBMS table definition: This, too, is database code intended to be shared among applications that share the database. It defines column types and lengths, sometimes value restrictions on columns (uniqueness, not null, values) and sometimes relationship restrictions (referential integrity rules).
DBMS view definition: This is database code defining a virtual table to be shared among applications if they specify use of the same view. For example, view definitions can be used to materialize computed values.
DBMS trigger: This is database code intended to be shared among applications which defines code to be executable automatically when a table or column is operated on. It is typically written in declarative code.
Method in shared-object class: This is code intended to be shared among other applications because it is in an object class that is shared across applications. You can use this as a mechanism for creating shared, standard rules logic.
You can also duplicate rules enforcement. For example, you can start out with rules in the rules layer, but duplicate traditional data integrity enforcement in the DBMS. You may, for performance reasons, duplicate some rules enforcements in the presentation layer.
- Step 9: Determine interfaces to the rules layer. Whether you purchase a commercial rules product or build your own rules capability, you need to design the interfaces from your application and data layers to your rules layer.
The Total Design
In many ways, designing a business rules system is very much like designing any system. A business rules approach is truly the integration of data orientation, process or object orientation, and rule orientation. You need data models and corresponding database designs. You also need process models (which today are often object- oriented) and process (object-oriented) design.
However, a business rules approach offers new opportunities for building better systems. For example, you can enhance your data models by adding rule-materialized data elements and normalizing rules to entities. You can approach object-oriented analysis and design differently by separating rules dynamics from other application dynamics.
Therefore, during the design phase, you define a rules capacity, assign rules to a target tier, confirm technology for all tiers, design the database, design rules support wherever it resides and finally pull it all together by designing the application process around shared rules executions.
If you want to prototype a business rules approach with a business rules product, a common design approach is summarized in Figure 3.
Figure 3: A Common Approach to Prototyping a Business Rules Approach
Ideally, this series gave you something to think about. Hopefully, it placed you on the same frontier with respect to a business rules approach as you once were regarding a relational database approach.
With a relational database approach, you deployed technology that externalized and managed the informational assets of the organization. With a business rules approach, you deploy technology so that it externalizes and manages the "thinking" or "decision-making capacity" of an organization. A business rules approach is merely a shift in emphasis. It adds no complexity. In fact, it simplifies much of the development process. A business rules approach aims to deliver systems that are the very instrument of business change. Imagine the possibilities.
Acknowledgements: The material in this article is adapted from an upcoming book to be published by Wiley & Sons in 2001. Significant contributions to the content came from Janet Wall, Art Moore, Linda (Jeney) Nieporent and Neville Haggerty. More details on design steps and vendor solutions to a case study will be found in the upcoming book and on a companion Web site.
The author would also like to extend a special thank you to the rules vendor personnel who assisted in developing a solution to the book's case study and to some of the ideas in this article.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access