You are on page 1of 141

EXPLORING BUSINESS APPLICATION AGILITY THROUGH RULES-BASED PROCESSING: CENTRALIZING THE BUSINESS RULES OF AN ENTERPRISE

By

William J Leannah, B.A.

A Thesis submitted to the Faculty of the Graduate School, Marquette University, in Partial Fulfillment of the Requirements for the Degree of Master of Science in Computing Milwaukee, Wisconsin December 2006

Preface
Software applications, which were traditionally developed for business processing, have commonly included the business logic within the applications source code. Even though this technique has been used and widely accepted for years it has come at a cost. The need for frequent changes to business rules has become routine for software developers today. Changing application source code takes time. Business can no longer afford to wait months for their systems to respond to changing market conditions. The cost of that time could be critical to an organizations overall business objectives and organizational health. This is especially true for ecommerce systems running on the web. A rule that was good for business today might not be for the same environment tomorrow. This research project will explore the potential agility gains of implementing a rules-based processing approach. The traditional approach, found in most applications today, involves the use of source code based business logic layers. To make a change to the business logic layer requires a software developer. It is believed that a successfully implemented rule-based approach provides business personnel with the ability to manage the business rules in a direct way without the assistance of a software developer. Establishing a centralized repository for an organizations business rules is desired. To demonstrate the rules-based processing approach, a prototype application will be created for the insurance industry. Even though the insurance industry will be used to give the prototype a business context, the same principles could be applied to other industries as well.

ii

Acknowledgments
I would like to give special thanks to Dr. Harris for his guidance not only on this thesis project but for his unique teaching abilities that have played a critical role during my time as a graduate student at Marquette University. From the first time in Dr. Harriss class I have admired his deep understanding of the software development process and the role that process plays in successfully building meaningful business applications. Through Dr. Harriss encouragement I have researched and pursued many new technologies that were almost immediately leveraged by my employer in providing better service to its customers. Dr. Harris has always challenged me to consider alternative solutions to different problems and in the process has made me a better student in the science of computing. I would also like to thank the other members of my committee, Craig Walker and Dr. Praveen Madiraju for their support during the research process. Their assistance and feedback has certainly led me to pursue a successful research project; one that I know I can be proud to share with both fellow students and colleagues at work.

iii

Table of Contents
Preface.................................................................................................................................. i Acknowledgments............................................................................................................... ii Table of Contents............................................................................................................... iii List of Tables or Illustrations............................................................................................. vi Figures............................................................................................................................ vi Tables............................................................................................................................. vi Rules-Based Processing ...................................................................................................... 1 Introduction..................................................................................................................... 1 Expert Systems................................................................................................................ 3 Business Rules ................................................................................................................ 5 Purpose........................................................................................................................ 5 Function ...................................................................................................................... 8 Knowing (Business Knowledge) ................................................................................ 8 Customer Based ........................................................................................................ 10 Forever Changing...................................................................................................... 11 Throwaway Procedures............................................................................................. 12 Business-Driven............................................................................................................ 13 IT Projects................................................................................................................. 13 Models and Strategies ............................................................................................... 15 Traditional Software Development................................................................................... 19 Time and Cost ............................................................................................................... 19 Software .................................................................................................................... 20 Programming......................................................................................................... 20 Development Process............................................................................................ 24 Time-to-market ..................................................................................................... 26 Application Developer Dependence ......................................................................... 27 Business Logic Layers .................................................................................................. 29 Hard-Coded Rules..................................................................................................... 29 Rule Firing and Temporal Redundancy.................................................................... 31 Application Dependant ............................................................................................. 33 Rules-based Processing Approach.................................................................................... 35 Described ...................................................................................................................... 35 Knowledge Information Theory ................................................................................... 37 Domain Experts ........................................................................................................ 37 Knowledgebase or Rulesbase ................................................................................... 38 Metadata.................................................................................................................... 39 Fact Model ................................................................................................................ 40 Artificial Intelligence (AI) ............................................................................................ 41 Historical significance .............................................................................................. 41 Predicate Calculus..................................................................................................... 42 First-Order Logic .................................................................................................. 42 Rule Syntax........................................................................................................... 43 Declarative Programming ............................................................................................. 44 Terms ........................................................................................................................ 44

iv Concepts Catalog ...................................................................................................... 45 Facts .......................................................................................................................... 46 Rules and Rule Classification ................................................................................... 47 Rejectors ............................................................................................................... 47 Projectors .............................................................................................................. 48 Producers............................................................................................................... 48 Centralized Repository.................................................................................................. 49 Business Logic Server............................................................................................... 49 Web Services ........................................................................................................ 49 Service Agents ...................................................................................................... 50 Rule Definition Interface (GUI)................................................................................ 51 Refinement and Training (for Rules)........................................................................ 52 Auditing and Management Reporting....................................................................... 53 Rules Engines.................................................................................................................... 54 Business Rules .............................................................................................................. 54 Atomicity .................................................................................................................. 54 Levels of Abstraction................................................................................................ 56 Independence ............................................................................................................ 57 Priority or Salience ................................................................................................... 58 Processing and Parsing ............................................................................................. 59 Finite State Machine ............................................................................................. 59 Parallel Processing ................................................................................................ 61 Rulesets ................................................................................................................. 62 Business Process ................................................................................................... 63 Maintenance.............................................................................................................. 63 Building......................................................................................................................... 64 Forward Chaining ..................................................................................................... 65 Backward Chaining................................................................................................... 66 Flow-based Processing.............................................................................................. 67 Rules-based Pattern Match Algorithms ........................................................................ 67 RETE......................................................................................................................... 67 TREAT...................................................................................................................... 69 LEAPS ...................................................................................................................... 70 Unification or Two-Way Pattern Matching .............................................................. 72 Source Code .................................................................................................................. 72 Generation................................................................................................................. 72 Rule Engine Languages ............................................................................................ 74 OPS5 (Official Production System).......................................................................... 75 Software Tools .................................................................................................................. 77 Business Rule Solutions (BRS) RuleSpeak ............................................................... 77 Practitioners Toolkit.................................................................................................. 77 Rule Statements ........................................................................................................ 80 Regular Expressions.................................................................................................. 81 Part-of-Speech Tagging ............................................................................................ 84 CLIPS Programming Language.................................................................................... 86 Microsoft Tools............................................................................................................. 92

v nHibernate..................................................................................................................... 93 Prototype ........................................................................................................................... 94 Design ........................................................................................................................... 94 Knowledge Base Database........................................................................................ 94 User Interface............................................................................................................ 97 Generating CLIPS Rules......................................................................................... 100 Native CLIPS Programs.............................................................................................. 103 Validating Drivers................................................................................................... 103 Rating...................................................................................................................... 105 CLIPS and ASP.Net.................................................................................................... 114 ClipsNet .................................................................................................................. 114 Rule Agility............................................................................................................. 117 Reporting and Auditing............................................................................................... 118 Results............................................................................................................................. 119 Rules-based Processing Approach.............................................................................. 119 Success Stories........................................................................................................ 119 Failures and Skepticism .......................................................................................... 122 Future Work ................................................................................................................ 123 Conclusion ...................................................................................................................... 124 Bibliography ................................................................................................................... 126 Appendices...................................................................................................................... 128 Appendix A................................................................................................................. 128 Technical Term Glossary........................................................................................ 128 Appendix B ................................................................................................................. 130

vi

List of Tables or Illustrations


Figures
Figure 1 - Driver Class Example ...................................................................................... 23 Figure 2 - N-Tier Architecture.......................................................................................... 30 Figure 3 - Basic Finite State Machine Diagram................................................................ 60 Figure 4 - LISP Syntax ..................................................................................................... 75 Figure 5 - RuleSpeak Validate Rule Statement ............................................................. 82 Figure 6 - RuleSpeak Regular Expressions ................................................................... 84 Figure 7 - CLIPS IDE ....................................................................................................... 87 Figure 8 - Declaring CLIPS Facts..................................................................................... 89 Figure 9 - List Facts Commands....................................................................................... 89 Figure 10 - Enter CLIPS Rule........................................................................................... 90 Figure 11 - CLIPS Facts Command.................................................................................. 91 Figure 12 - CLIPS Agenda Command.............................................................................. 91 Figure 13 - Run Command, Rules Fired........................................................................... 92 Figure 14 - Knowledge Base Schema............................................................................... 97 Figure 15 - Rule Definition Interface.............................................................................. 100 Figure 16 - CLIPS Generator.......................................................................................... 102 Figure 17 - Valid CLIPS Rule Message ......................................................................... 102 Figure 18 - Invalid CLIPS Rule Message ....................................................................... 102 Figure 19 - CLIPS Program Validate Drivers Result 1 .................................................. 104 Figure 20 - CLIPS Program Validate Drivers Result 2 .................................................. 105 Figure 21 - Rating Rule Result Output ........................................................................... 108 Figure 22 - CLIPS DefTemplate Parser Class ................................................................ 115 Figure 23 - Validate Driver ASP.Net Example .............................................................. 116 Figure 24 - CLIPS Rule Engine Model........................................................................... 118 Figure 25 - Driver Query Results.................................................................................... 119

Tables
Table 1 - Zachman Project Team Members...................................................................... 17 Table 2 - Example Insurance Terms ................................................................................. 44 Table 3 - BRS RuleSpeak Dos and Don'ts..................................................................... 80 Table 4 - RuleSpeak Validation Messages .................................................................... 83

Rules-Based Processing
Introduction
In the fast paced computerized world of today, it is technology that drives competitive advantage in the market place. Companies like General Electric, Allen Bradley, Fidelity Investments, Master Card, Ford Motor Company, Wells Fargo Bank, and West Bend Mutual Insurance all share one common element despite their industry differences. When their employees report to work each morning they will undoubtedly login to their organizations computer network and start conducting business for the day. Conducting business means they will be using specially designed applications that include instructions which govern the organizations daily operations (Giarratano, 2005). These instructions are commonly referred to as organizational rules or more precisely business rules. Business rules are the fabric of todays high-tech enterprise. They dictate when and where business will be conducted and who it will be conducted with. It is for that very reason that they have become an integral part of computer systems (Chisholm, 2004). Systems that keep track of inventory, trade stock, or file tax returns all have rules that will either allow or constrain their users to perform some action. If the rules are changed then so does the behavior of the system. The systems that enforce these rules are unique as the companies they serve. What each rule really represents is a way for the organization to differentiate itself from their competitors. Rules are created for a wide variety of reasons. Some are used to make sure the company is in compliance with local, state, or federal laws. Others represent an industrys best practice for a common process. Yet some provide a way to price products consistently from one customer to the next. Rules represent a way to capture knowledge about the particular business process they

2 were intended to control (Ross, 2003). Whatever their reason, business rules do play a critical role in the everyday lives of employees throughout the United States and across the globe. It is true that business rules existed before the computer was ever invented. However, computer systems do provide a way to automate their enforcement. The emphasis of this research is to explore an implementation approach to designing computer software known as rules-based processing. A rules-based processing system is one that attempts to separate the business rules from the application logic of the system. The reason for this separation is to gain agility for the application. The need for frequent changes to an applications business rules has become routine for software developers today. Business can no longer afford to wait months or even years for their systems to respond to changing market conditions. This is especially true for ecommerce systems running on the web. A rule that was good for business today might not be true for the same environment tomorrow. The primary purpose of this project is to create a prototype system that implements a rules-based architecture to process its data. The prototype will be specifically designed for use by an insurance company but could be applied to any industry. This project will explore meeting the demands of agile business practices through the rules-based approach. The prototype will show how to implement new business agility demands as they relate to the applications work flow when the need for change occurs. In the process of exploring agility it is also hoped that this research can demonstrate that business personnel (business analyst) and not software developers could completely control the business logic layer of the application. In order to do that, the prototype will include a special component; a Rule Definition Interface (RDI). The RDI will allow a business user to change the meaning of a rule and ultimately the

3 behavior of the application (Chisholm, 2004). The previously stated ideas form the primary and secondary emphasis of this thesis. Like most system agility ideas, independence often begins with abstraction. In the case of rules-based processing, abstraction between the applications code and the business rules themselves is achieved through the use of a rules processing engine. The engine is instantiated and then given a list of applicable business rules which define a business process. As facts are then asserted or retracted from the engine, inferences are made which influence the softwares behavior. The architecture just described provides a high-level overview of the implementation approach being analyzed as part of this research. This architecture and all the facets leading up to it are carefully detailed throughout the rest of this paper.

Expert Systems
A computer system is a form of artificial intelligence (AI). AI research began in the late 1960s to early 1970s and focused mostly on general purpose problem resolution (Giarratano, 2005). General purpose problem solving by computer systems without a well defined context proved to be too difficult to achieve even for the most advanced systems of the time. Technology limitations quickly spawned dissatisfaction among the clients of these early AI systems. Public excitement around AI research shifted as negative opinions regarding the technology and its promise for practical use within business systems began to be questioned. Scientists believing they could eventually solve the problem began looking for ways to break it down into smaller more manageable pieces (Brownston, 1985). Most of the research focused on the idea that a computer could be programmed with the knowledge of a human expert for a particular subject matter (Ross, 2003). The subject matter itself would provide the system with exactly

4 what it needed; a specific context or domain in which to operate. To increase its public acceptance, this new AI idea was renamed to Expert System. Expert Systems are designed to emulate how human beings solve problems within a defined domain (Giarratano, 2005). They do this by having business intelligence base logic included within the applications source code. When it comes to an organizations business rules, human employees receive regular training that involves use in daily operations. As employees advance in their careers and move on, they take with them years of valuable training and experience that they learned on the job. These experienced employees represent the experts of the organization, possessing valuable business knowledge (Ross, 2003). The loss of this knowledge can be expensive to recover or maintain. Companies trying to mitigate this from happening began implementing computer systems designed to keep track of their business rules instead of people. Applications finally began evolving to more than just moving data around from one system to another. Now that actual rules and practices were being built inside business applications they began to give people the impression that computers were in fact becoming more intelligent (Brownston, 1985). These next generation applications began storing the business rules that defined the current business process. No longer were companies fully reliant on human experts for maintaining the consistency in conducting business. Programming the business rules inside computer systems also meant that organizations, like insurance companies, could automate more of their processes. When a person buys insurance an important step is the review of the application by an underwriter. That person is verifying the accuracy of the information but more importantly they are assessing the risk factors related to the insured. Those risk factors are weighted against the amount of premium the company will take in

5 for the time period that persons property is insured. They are also used to determine whether or not the underwriter will accept the risk involved when writing or denying the new policy. That determination is based on the business rules of the organization. If those rules are implemented inside a computer application, the process could be done consistently faster and with more accuracy. Efficiency gains, like the one just described, led to an explosion within the Expert System industry. Organizations pumped millions of dollars into these applications providing economic peaks in the late 1990s and beginning of the 21st century (McKellar, 2003). The popularity of these applications has grown tremendously over the past decade. However, just because the business rules of an Expert System are hard coded (Appendix A) into the application source code, doesnt make them rules-based. Implementing new evolutionary aspects of the rules-based processing approach will enable Expert Systems to achieve new artificial intelligence heights (Froscher, 1990).

Business Rules
Purpose
Business rules provide a way for an organization to represent knowledge. This knowledge is captured in such a way as to provide a guideline for completing a valid business transaction (Ross, 2003). To illustrate their purpose lets examine a specific example related to the insurance industry. The following story is complete fiction. It does not represent an account of any real person who has bought or will buy auto insurance. It has been fabricated here to provide a context for this discussion. Robert, a warehouse manager from Chicago, just received a notice from his current auto insurance company that his car insurance premium is about to increase. The

6 reason for the increase is related to the fact that Roberts teenage son Dan is about to turn sixteen and will be driving soon. Robert, unhappy with the new premium amount, decides to shop around for a new insurance provider. Robert contacts Rachel, an insurance agent with Wellington & Associates, and requests a quote. Rachel, a licensed insurance agent, tells Robert that she will try to get him the best price possible. She receives permission from Robert to obtain his credit report, driving abstract (DMV records), and other personal information reports that are needed to provide him with an accurate quote. Robert, knowing that disclosing his son Dan will be a detriment to getting a better price, decides to leave his information off the application that he provided to Rachel. Rachel logs into her insurance quoting application and begins to enter Roberts information into the system. Part of the application process requires Rachel to order industry standard reports on Robert and his household. These reports provide Rachel with Roberts credit score, driving record from the DMV, and information related to Roberts children, in particular Dan who is about to turn sixteen. Being in the business for most of her life Rachel recognizes why Robert is shopping around for new car insurance, its because of Dan. Since Dans information was returned from Roberts household report, the system required Rachel to include Dans information in the quote. Of course Dans information did negatively impact the completed quote that Rachel sent to Robert. When Robert received the new quote he was surprised to see that Dans information was included even though he purposely excluded his information from his application. When Robert called Rachel to inquire how she had found out about Dan she explained to Robert that her computer system required her to verify all of the information on Roberts application. Part of that verification process included ordering a set of

7 industry standard reports that disclosed all of necessary information to receive a quote. Robert then requested that Rachel remove Dans information from his quote which would reduce his newly proposed premium. Rachel explained to Robert that her company had rules about who should and should not be included on a policy and that every driving member of the household must be on the policy. Otherwise the policy could be declared null and void if Dan was to inadvertently get into an accident while driving one of Roberts vehicles. Now, this story provides an excellent example of the role that business rules play in peoples every day lives at work. Robert attempted to circumvent the rules of the business process. He wanted to get a better deal on his car insurance so he decided not to include a high risk driver, his son Dan, on his application. Rachel, a licensed and highly trained insurance agent, understood exactly what Robert was trying to accomplish. Even though Rachel wanted Roberts business she was not willing to get it at any cost. She knew that there were business rules in place which dictated what she needed to do. Even if Rachel was willing to break the rules for Dan she knew that the computer system would not allow her remove Dans information from the quote. The system could easily alert an underwriter that Roberts information was not accurate. Roberts son Dan must be included on the policy; even if it means Robert must pay a higher price. These rules are in place to make sure that car insurance is fairly and consistently priced for every customer that the company services. Insurance is about consuming risk. The higher the risk, the higher the price and the cost of the premium that the individual will need to pay. If these rules did not exist then it would ultimately hurt everyone. Insurance companies with improperly priced policies would be forced to increase everyones premium in order

8 to make up the difference. Even the individuals without teenage sons would end up paying more. Business rules are about governance and consistency. They describe the parameters for which a business activity can be completed (Ross, 2003).

Function
When the U.S. military fights a war, they go into the conflict with something called the Rules of Engagement (ROE). The militarys ROE dictate to each soldier when to and when not to use deadly force (Hall, 1997). If the ROE is violated then those involved could be subject to disciplinary action or even charged with a criminal offense. Since the military knows that they are dealing with real peoples lives, they want to make sure that they are getting it right. They ensure the destruction of the enemy while still protecting the lives of the countrys civilians. So the real function of the Rules of Engagement from the militarys point-of-view is to protect the innocent from unnecessary harm. Certainly the ROE plays a critical role in the business of conducting a war (Hall, 1997). At the core of a business rules function resides the need to solve a business problem or potential problem. When incorporated into a computer system, they allow or constrain the different user steps that make up the business process. Therefore, properly capturing the business rules of the enterprise will allow for the successful implementation of the rules-based approach within the organization (Ross, 2003).

Knowing (Business Knowledge)


To completely understand what business rules are, it is important to note that they are about the knowing and not the doing (Ross, 2003). A business rule always represents knowledge about an entity or process. It is considered to be of an experienced

9 nature. This information is commonly referred to as expert knowledge (Giarratano, 2005). This business expertise is separate from everything else. Business rules are not computer software (Ross, 2003). It is true that they can and are programmed into computer software systems for controlling the behavior of a process. However, in reality that control exists outside of the companys applications. Business rules existed long before computers were even invented. They existed in paper form, but nonetheless they were present in the everyday of lives of company employees. A driver must be licensed is an example of an insurance company rule that pre-dates computers. Business rules are not a process. A process describes a series of steps in order to complete a task. Rules are not a process because they are not concerned with how to get things done (Ross, 2003). They are indeed controlling a process. However, they themselves do not represent a business process. The reason for this conceptual separation between business rules can be explained in this way. When people think of rules, they think of them in an enterprise or company level. That is, no matter what process led to the decision point, applying the same rule should produce the same result; making the rules themselves reusable throughout the organization (Ross, 2003). (Making a business rule reusable has nothing to do the reusability of software components.) This conceptual separation is the distinction between business rules and business processes. If an organization has a valid business rule that they have decided to enforce then all processes, computerized or manual are subject to that rule. If the process breaks a valid business rule, then the process is invalid no matter what the source. There is one other key element of a business rule that is detailed in a later section but is worth mentioning here. A business rule must be atomic. Analysis of a rule should

10 reveal that it cannot be broken down into smaller parts. Rules need to achieve the smallest level possible. Aggregating multiple rules into one is never recommended (Ross, 2003). Achieving business rule atomicity within the organization is the first step in perpetuating change and becoming a more agile business (Giarratano, 2005).

Customer Based
It is not uncommon for companies to maintain a preferred customer list. A preferred customer usually represents a person or organization that does a high level of business with the company. Preferred customers could also be those entities that do a moderate amount of volume but are extremely easy to do business with. Whatever the case preferred customers will get special treatment which commonly equates to special rules when dealing with them. The practice of crafting business rules around specific entities is called customer based (Ross, 2003). Customer based rules generally focus in on the current status of the customer as it relates to their relationship with the company. The rules are specially designed to provide preferred customers with special treatment. An example business rule for a preferred customer would be: A customer credit limit may not exceed $1,000 unless that customer has a preferred status, preferred customers may carry a credit balance up to $3,000. (Ross, 2003) Creating these types of rules is another way organizations can differentiate themselves from their competitors. Customers who receive preferred treatment often know their client status as it relates to their relationship with the vendor. They can and sometimes do take full advantage of bending business rules in their favor. Interestingly, this concept of making business rules agile enough to be based solely on a specific customer is not a new practice. However, this idea goes way beyond providing special handling for customers who fall within a

11 classified group like preferred. These business rules would be written and maintained when servicing a single customer, Customer X (Ross, 2003). The rule itself would explicitly state that Customer X receives special treatment. Once the system moves off of Customer Xs record the standard business rules would then kick in and the system would return to default ruleset.

Forever Changing
Business rules are not static; sometimes they require refinement or change. As business rules become outdated they need to be changed to keep up with the demands of a changing market and customer expectations. Companies sometimes leverage the known business rules of competitors to gain a competitive advantage with a prospective client (Ross, 2003). Customers often define convenience through business rules. This author has witnessed this practice during sales meetings with a vendor. The sales agent would say to the group, Our best competitor, Company X, has this business rule in place; making them a real bear to do business with as a way to convince the team to buy their product instead. Now, if Company X identifies this rule though their own customer base they may realize that it might be becoming a road block to new sales. They may decide to change the rule to increase its customer friendliness. This chain of events ultimately has a positive impact on everybody. New customers (the market) get what they want and existing customers get a company that is potentially easier to do business with. No matter what business rules an organization puts into place it must be understood that they are all subject to change. Companies should and will change their rules in order to keep up with the demands of a changing market place. The ability to respond to changing market conditions is the primary motivator behind agile business practices (Ross, 2003).

12 This is the main reason that business rules contained within a companys supporting software need to be as flexible as possible. Without this flexibility, organizations could become stagnate; ultimately hurting the long-term financial health of the company. The application used by the organization should never be a road block to changing a rule. This critical aspect needs to be fully understood by the architects of the computer system. The understanding should allow for the design of a system that is highly adaptable and easy to change as it relates to the business rules used by the organization (Rea, 2005).

Throwaway Procedures
Just because a business rule should be changeable does that fact make it automatically subject to retirement or complete abandonment by the organization? The response to this question needs to be answered carefully. The understanding that a business rule is not a procedure should provide us with some useful insight here. Since procedures do not represent rules and visa versa then a throwaway procedure does not imply the complete discarding of the business rule. If, in fact, the company determines that the flaw relates to a current procedure and not the rule then the answer to the question is discard the procedure. The implementation of a new procedure could be the exact thing needed to advance business growth. Consider the following analogy taken from the book The Principles of the Business Rule Approach by Ronald G Ross, 2003. When a football team devises a play they do so with complete disregard to receiving a penalty while executing the play. The goal of every offensive play on a football field is the advancement of the ball to the end zone. What happens if the play doesnt work? The team uses a new play until they find one that does. Since the play represents the doing and not the knowing it represents a business procedure and not a rule. Now, in

13 between all this play switching a team might break a rule and receive a penalty. Penalties happen when the procedure of running a play breaks one of rules established by the football league. (Ross, 2003) Since a rule represents the knowing and potentially important business knowledge, discarding them might be a mistake, especially if that business rule relates to a regulatory or lawful practice (Chisholm, 2004). Organizations should carefully analyze which aspect of the process they are dealing with; the business rule or procedure. Like football plays, business procedures should be designed for executing a process in order to achieve a goal. If the goal cannot be met by running the play then the company needs to devise a new play.

Business-Driven
IT Projects
Today, most organizations employ people who care for and maintain all the computer aspects of the company. This includes both computer hardware and software. These individuals are commonly referred to as the Information Technology Department or IT for short. Within the IT organization of the company there is a group of individuals who specifically manage, maintain and update the companys software. These people are the programmers or are also known as the software developers of the organization. The primary reason that computer software exists is to support a business or organization. Without a business to support computer programs they would not be very useful; having no purpose people would probably ignore them. Since the opposite is true computer software and IT (Information Technology) projects in general need to be business-driven. Business-driven IT projects should always be of the business, for the business, and by

14 the business (Ross, 2003). In the early days of IT Departments, 1960s to 1970s, there were always two kinds of software projects, IT-driven and business-driven. Often these parallel initiatives would seldom compliment one another as they related to scope or direction. The IT Department staff would be off making things easier for them, adding little value in solving business problems or automating business processes. Meanwhile, business personnel frustrated by the lack of resources for their projects would find themselves paralyzed by outdated systems. This practice has slowly faded since that time but still exists in some organizations today. The emphasis of the IT Department and the individual business unit has to be unified (Ross, 2003). Without this unification a true business-driven approach cannot be achieved. IT projects must solve business problems; that is how they add value to the organization. Many companies have recognized this need and have reorganized their IT staff to be business partners. Since partnerships imply working together to achieve common goals the strategy has been adapted by many IT Departments today. Once the partnership has been established the next step is often a refinement of how to accomplish the new business-driven IT project (Ross, 2003). There is an old computer term saying garbage in, garbage out which still holds true today. A business-driven IT solution will always begin with the business knowledge or the knowing the business rules. In other words, business knowledge in, business knowledge out meaning before we can start building the software we must gather all of the business rule requirements. Doing business rule requirements gathering up-front in the beginning of the project is absolutely critical. Without it, IT projects would enter a very dangerous place, scope creep (Ross, 2003). Scope creep happens when the emphasis of the project changes so rapidly that the previous initiatives cannot be

15 completed before new ones are implemented. Suddenly the project is in jeopardy of failing because uncompleted or unused components cannot be deployed or leveraged by the business. The project then gives the leaders or executives of the organization the impression that money is being spent with little to show for it. Sometimes that leads to de-funding and project abandonment. Before a proper system design or coding can begin software developers must be able to understand the entire scope of the project. They cannot do that until the all requirements are gathered. Requirements then form the basis or framework of the partnership between the business unit and the IT staff to achieve the common goals of the project (Ross, 2003).

Models and Strategies


Modeling the new business-driven IT project doesnt end with partnerships or requirements, it is only the beginning. When developing an agile rules-based system it is important to understand the aspects of the strategy that leads to a well finished product. Most organizations have realized that developing their companys software is not unlike any other complex engineering project; like building a bridge or manufacturing goods. It requires precise planning before the actual coding can begin. A computer scientist by the name of John Zachman developed a framework to address this very need in late 1980s (Zachman, 1987). The Zachman Framework is considered to be the highest standard available for implementing software development projects. Many organizations already use some or all of framework when developing applications for use by their employees or for their ecommerce sites running on the web. This author has already worked for two organizations that have used different variations of the Zachman Framework during their regular software release cycles.

16 The Zachman Framework breaks the development process down into a series of defined steps each building on the next until the project is complete. Additionally, he has identified a set of roles for the individual members of the project team. Each role on the team has separate responsibilities. Table 1 contains a comprehensive list of the Zachman Framework Project Team Members (Zachman, 1987).

Team Member Business Unit Sponsor

Project Manager

Business Analyst

Technical Architect, or TA Designer Developer, programmer, software engineer

Quality Assurance, QC, or test engineer

Database Administrator , or DBA

Description The customer for the team providing the financial support for the project. The person for whom the project team is developing the software or rules-based processing solution. The person who manages the deliverables and milestones of the project. The project manager is responsible for assigning the work and setting the priorities for the team. The business analyst primary responsibility is to complete the requirements gathering for the application or new feature by analyzing the needs of the business. Translates business unit requirements into a system design that can be implemented into the final application. Typically designs the user interface for the application focusing on how user tasks flow through the system. Developers write the code that becomes the component or application. They complete this by first documenting the technical specifications and then using the specifications as a map for completing the finished product. Since testing, system stability, and performance are always the measure of success the QC role is probably the most important on the team. Their job is to break the software before it is released to production. Person responsible for the design and implementation of the applications data.

17 DBAs will also monitor and tune the applications database. Concerned mostly with system security the network engineer provides administrative support for application deployment and configuration. If servers are included in the system design then they must be incorporated in the enterprises network. The person or group responsible for releasing new software or versions of software to the end user community. This person is generally a developer; however with proper training a business analyst could easily fill this role.

Network Administrator

Release Coordinator

Table 1 - Zachman Project Team Members

The framework assigns the first phase in the development process to be the requirements gathering or the what phase. The requirements are gathered from the business unit sponsor by the business analyst. The business analyst plays a liaison role between IT and the individual business unit. It is their responsibility to meet with the business sponsor to discuss the different approaches that are available. Requirements represent the foundation from which all other aspects of the process are built. Properly captured requirements usually equates to a great final product. For a rules-based system the requirements gathering phase will capture the terms, facts, and rules that will be used by the enterprise system (Ross, 2003). The purpose of the requirements gathering exercise is to define what the new application or feature needs to do in order to add value to the business process. Completed requirements are then sent to the system architect for design and review. The individual will transform the requirements into a technical design for the application. The technical design describes how the system will meet the specified requirements (Zachman, 1987). Once completed, the designs are then reviewed with the sponsor to make sure that all of their requirements

18 have been met. This process often includes some back and forth negotiations with the sponsor because of the technical feasibility of the requirements (Ross, 2003). After the technical design is approved the project team will provide a cost estimate to the business unit. The cost estimate describes the individual resources needed to complete the project, the projects duration, and any other miscellaneous costs. Estimates are then sometimes negotiated by making adjustments to the requirements or the design (Zachman, 1987). Designs are then handed over to the implementer or software developer who will first translate the design into a technical specification before the actual coding begins. The technical specification documents are then reviewed by the system architect to make sure they meet the specified design. Developers will then begin coding based on their approved technical specifications. At the same time the quality assurance team members will use the technical specifications to begin writing their test cases. Technical challenges discovered during the build phase are then again renegotiated with the business unit. Requirements, design, specification documents, or test cases are adjusted as necessary. Once the build phase is complete the new software is then moved into the test phase. During the testing phase defects are identified and corrected; after testing is complete the software is then deployed to production and given to the user. It is during this phase that user acceptance testing is conducted and changes to the software are evaluated. If changes are identified, then a change request is submitted to the project team and the entire process starts all over again (Zachman, 1987). If the Zachman Framework just described seems overly complex that is because it is. Reliable software is not easy to design and build. It costs time and money to get right.

19 Any software development project not following some sort of organized process is inviting failure. Software filled with bugs and stability issues will cost organizations in the form of low employee productivity or lost sales. The process of developing software must be scientific and repeatable. The Zachman Framework was created for that very reason. So, what if the company needs to change a business rule? Business rules included inside application source code are bound to the software development process. When the code is changed then the process just described must be followed. Otherwise, the organization would risk the introduction of a bug (Appendix A) that could make their software become unstable. Organizations cannot sacrifice time-to-market for system stability. This is the dilemma that the rules-based approach is trying to address.

Traditional Software Development


Time and Cost
Formalizing the software development process is indeed the best approach to delivering high quality applications (Zachman, 1987). It has certainly improved application usability, but it has also increased the total cost of ownership for the enterprise. These costs are consumed by employing large teams of individuals to design, build, and maintain their applications. Upgrades to hardware or pre-built vendor software components produce additional overhead expenditures; adding to the cost the companys technical assets. In the pre-rules-based world, companies had to find ways to control these costs. The answer was iterative development. Iterative software development means; completed pieces of the solution will be released before the final application is finished. Iterative development has become widely accepted in recent years as a way to

20 combat cost. The faster an organization can leverage those delivered pieces of functionality the faster they begin making a return on their investment (Ross, 2003). This of course creates a formidable challenge to the development teams; a resurgence of ensuring high quality applications. Complex systems that provide true business enabling functionality are typically developed over a period of months or even years. The higher the complexity, the more time and money needed to properly test the system. However, the true measure of any business application return on investment (ROI) is user acceptance. ROI measurements are typically represented by frequent use. People will generally use things that add value to their business process by making those tasks easier to complete. To summarize, there are two distinct factors at work here: 1. The business needs to control software development costs by maximizing return on investment (ROI). 2. The IT teams needs to maximize project success and system stability; maintaining a repeatable process (Ross, 2003). These factors frequently do not compliment one another both in agenda and scope. The struggle between the two does add its own additional overhead, usually in the form of re-work by the development teams. The most common area for change and re-work is the behavior related to the business rules, and not how the system processes its data (Froscher, 1990).

Software
Programming

Because this paper is about rules-based processing and not how to write application code, the following sections will spend little time explaining individual programming terms. It is necessary for this author to assume that basic object-orientated programming terms like

21 compile, syntax, programming language, class, function, property, method, etc. are understood by the reader. This author has also chosen Visual Basic .Net (VB.Net), CLIPS, and T-SQL as the programming languages for this research. Going forward, all programming examples will be in the syntax of the language used. No matter what language the application is written in, the described subject matter remains constant. If this seems like unfamiliar territory then this author recommends reading the references provided in Appendix A, which should help the reader increase their understanding. Alternatively, non-technical readers should be able to skim through the technical sections of this paper to understand the individual points being made. The basis of object-orientated programming is representing logic and behavior in the form of a class. A class is a way to provide definition to something within a program (McMillen, 2005). For example: a class of individuals on an insurance policy might include different drivers like insured, spouse, or child. A class provides more than definition it also controls the objects behavior. A child can drive the family car only if they are licensed would be an example of its behavior. Inside a computer program this behavior is controlled through a classs functions or methods. Changing a classs functions or methods will change its behavior and ultimately change the behavior of the entire application. When developing a business solution, classes are used as containers for the business logic (McMillen, 2005). This means that the business logic itself is contained within the programming code. So, in order for a business rule to change, a programmer must change the class that defines it (Chisholm, 2004). Once the programmer has changed the class it will then be recompiled back into the program. The new program will then be deployed to the users who will then experience its new

22 behavior (McMillen, 2005). Figure 1 is an example of a driver class. The driver class contains a property for a type that will be set to either insured, spouse, or child when the object is created in its constructor. The class also contains a Boolean property, which indicates whether or not the individual is licensed. In the rules-based approach these two items are referred to as facts (Giarratano, 2005). It is only in the traditional approach that they remain as physical properties of a class (Chisholm, 2004). The method CanDriveFamilyCar (a business rule) is then executed to check the validity of the driver. The business rule first checks the drivers type in this case it only cares about a child driver. If it is a child driver then it checks to see if the driver is licensed. If they are licensed then the method returns true otherwise it returns false. This business rule will then impact other decisions being made by the rest of the program. The system may not allow an unlicensed driver to be included within the insurance application which of course is another rule represented in another class.

23

Constructor

Business Rule

Figure 1 - Driver Class Example

The practice of including business rules within the programming code is widely used for a number of reasons. For starters, object-orientated programmers typically want to design and implement a constant application. Meaning they will generally keep as much of the logic (including the business logic) within the same programming syntax as possible (McMillen, 2005). This allows them work within a familiar environment which in turn should save the company time and money. Another key element regarding business applications is system performance. Performance is measured by the length of time a user has to wait for the application to complete a requested task. Since the application has to run business rules as a part of its processing, the execution of those rules must perform well (Brownston, 1985). Rule execution performance levels will vary from company to company but the shortest execution time possible is preferred by most users. A long standing notion related to the traditional approach is that since the business

24 rules are included in compiled source code their execution will be faster than their interpreted or declared counterparts (Chisholm, 2004). Although this author does not dispute that fact, what is being questioned by this research is the inability to control the unnecessary redundant execution of the rules which will ultimately slow down the performance of the application (Giarratano, 2005). Additionally, since the business rules are part of the applications source code in the traditional approach they are subject to the formal software development process previously described. Remaining as a part of that process in the traditional approach will slow their delivery to the user.
Development Process

During the development cycle software programmers begin their involvement with the project or iteration after the requirements have been gathered and the system has been designed. To document their work they will produce a technical specification of the component they are about to complete. The specification contains important information such as object dependences, data flow, and the behavior of the individual business rules (Zachman, 1987). Technical specifications are then reviewed by the architect to ensure accuracy. With the architects approval the developer proceeds into the build phase. Most developers will write their code using a tool called IDE or Intergraded Development Environment. IDEs attempt to incorporate as many tools as possible to speed things up. The idea is the more tools the developer has at their disposal, the faster they will be able to produce the finished product. To maintain application source code developers rely on a special database called a source code control system. A source code control system allows the developer the ability to store multiple versions of the same class. Multiple versions are stored to monitor changes and record the history of the

25 application. This feature of source code control systems allows companies to save different revisions of the same application. The process of saving different versions of the same application is sometimes called revision management. This process is similar to a document revision management system; something that should be common to most business users. A developer will work within an IDE to develop, compile, execute, and test their code. Upon completion of the component or business class the developer will check the file into the organizations source code control system as previously mentioned. Even though they have completed coding the developers responsibility of the new functionality is far from over. They have to make sure their changes reach the user. Before the changes can be deployed to the user they must be tested to ensure quality. The testing requirements vary with the company but usually involve installation of the new component in several different environments. The reason for installing it in more than one environment is simple. Computers are extremely complex machines with an unlimited number of configurations and settings. The repeatability of the source code cannot be tested by installing it on a single machine. This gets us back to the fact that the development of computer software should be scientific and repeatable (Zachman, 1987). Once in the test environments, developers are required to vary the behavior of their new code. This verification takes the form of a practice called unit testing. The unit test run by the developer is only testing for the successful completion of the individual piece of source code that they are currently working on. This is opposed to the system test later performed by test engineers who will test the new functionality as it relates to everything else in the system. In other words, the test engineers are trying to find out not only if the new functionality works but they want to make sure that it did not impact or break

26 anything else that is currently running within the system. If bugs are found by either the developer during unit test or the test engineer during the system test then a defect is submitted. Defects are first reviewed by the system architect who provides the checks and balances of the process. Once satisfied with the cause of the defect the architect will then assign the re-work back to the developer (Zachman, 1987). This process is repeated until all the defects are found and eliminated. Deployment of the new software is then planned through the release coordination process. This process might include user training activities if the change to the application is significant. When training is complete the new version of the application is finally delivered to the user community for daily use.
Time-to-market

In order for a developer to change a simple business rule in the traditional approach, they must first negotiate the previously described development process. The process could take weeks or months to complete pending the complexity of the business rule change, and the time needed to coordinate its delivery to the user community (Chisholm, 2004). The coordination of that delivery does include the time required to properly test the feature before releasing it to the end user. Releasing new versions of the updated software is a pivotal step in the development lifecycle of business rules. Since the new software also includes the business rule changes, the end user will not experience any updates until this process has been completed. Before internet based applications, companies would have to coordinate the installation of the new software on client machines. Those client machines most certainly represent a variety of different configurations and operating system environments which further complicate the process.

27 Now that most companies are running web based versions of their software, the deployment process does take less time. However, it still requires the same amount of deployment as it relates to business rules deployment. Since technology has a business enabling or disabling effect, time-to-market is certainly critical. The faster a business can bring new technology to the market the sooner they can gain a competitive advantage. Agility is more than just the adaptability of the softwares implementation; it is also measured by the speed in which the application can respond to change (Ross, 2003). If the application cannot respond to change any faster than the development process will allow (and still remain stable), then the time it takes to deploy that application to the market might be too long. The business rules of an organization are always going to be changing; it is the nature of being in business. As customer expectations change, so will the rules. Therefore, an implementation approach for business rules bound to the development process is doomed to fail when under aggressive time constraints. Either the development team will not make the date, or a rushed process could potentially produce an unstable system. The rules-based approach hopes to change this limitation. It accomplishes this by separating the rules from the source code, making them independent not only of the code but of the development lifecycle itself (Chisholm, 2004). This independence should give businesses the ability to deploy updated rules at nearly on demand speeds; greatly increasing the effectiveness at which the organization can respond to changing market conditions.

Application Developer Dependence


In the traditional approach, software developers maintain the business rules when they are written into an applications source code. The business rules are effectively out of the

28 reach of anyone else on the project team including the business analyst (Chisholm, 2004). Business rules implementation questions by the business team are common during future planning sessions. Business planning sessions occur when business teams decide to change their business practices to attract more customers. Changes to business practices will equate to changing the business rules within their applications. Before they can change their applications business rules, they may need information regarding what rules are already in place. The business team then sends their questions to the IT team. Those questions will typically be directed to the business analyst who will most likely contact a developer; who in turn performs an investigation into the source code. The software developer searches through the code to find the answer. In most cases, rule searches through source code require the developer to step through the execution path of the code. This is to ensure that they found the right behavior. Software developers who are unfamiliar with the particular rule in question use this technique to gain a better understanding of the expected behavior of the system (Ross, 2003). Regular occurrences of business rule searches on the part of the developer can slow the progress of the project they are currently working on. Sometimes investigation efforts are so large, they require an estimate before they are even performed. The investigation estimate is then reviewed by the business sponsor and is either approved or retracted. This is because businesses are beginning to realize that programmer resources are limited and should not be wasted on tasks that do not add any value to the business process (Ross, 2003). Software developers must search for these business rules inside source code because the rules are not centrally located. Business rules implemented this way retain a heavy dependency on the software developer. Software developers often do not understand the significance of

29 the business rules and their intended use yet they are ones who implement them (Chisholm, 2004). The person who knows them the best is the business analyst and is not part of their implementation. This traditional approach situation seems to be the opposite of ideal; on the one hand you need some who understands how to read source code so they can find the rule. On the other hand finding the rule is one thing, understanding its purpose is another. Developers confused by unusual business rules behavior then consult with the business analyst to clarify. If needed, the business analyst contact the business team for more information and the circle continues until everyone is clear with what is going on with the business process. For this reason alone, the traditional approach to implementing business rules is less than optimal. Business rule dependency needs to be shifted from the developer to the business analyst. It is the business analyst who is responsible for their creation and maintenance for the project and the overall system.

Business Logic Layers


Hard-Coded Rules
Many business applications developed today use an N-tier model as the basis of their architecture. The N-tier model breaks the implementation of the application into multiple sections or logical layers. Each section of the application serves a specific purpose. (The N-tier architecture model also implies more than two sections.) Applications falling within the N-tier category will always have, at a minimum, three distinct layers (Giarratano, 2005). The maximum amount of layers is not limited. Although experienced development teams know the more layers they create, the more complexities will be to introduce into the system. To keep things as simple as possible, most application teams will strategically keep the amount of layers between three and five. It

30 is commonly accepted that the three main sections of N-tier applications are: User Interface, Data Access, and the Business Rules Layers (Giarratano, 2005). Each of these layers provides a specific set of functionality to the user and when combined, represents the business application. The reason for this kind of separation is to organize the software applications functionality in a structured, logical way. Organizing the software project this way helps reduce redundant code, decreases errors, and speeds up the future development which can leverage the same functionality. The business logic layer of the application is where the business rules of the organization are coded into the system. As the data moves from the user interface, it passes through the business logic layer where the business rules are then checked before it is persisted into the database (Bellinaso, 2006). Figure 2 provides a visual representation of the aritechture.

Figure 2 - N-Tier Architecture

The business logic layer of the application is essentially the same as the rest of the solution. The business rules are written by the developer one at a time, becoming hard

31 coded (Appendix A) into the applications code base (Bellinaso, 2006). The business logic layer maintains its independence, because of the separation model previously described. However there is no separation between the rule and its implementation. In order to understand how a business rule is executed would require an equal understanding of the source code that described it. Hard coding business rules into an application are difficult to view at an enterprise level (Ross, 2003). Application classes are always organized in a technical non-business way as it relates to code dependencies such as object hierarchies. When architecting application changes that involve new or updated rules it often becomes necessary to understand the rule as it pertains to the rest of the rules. If the developer is forced to perform business rule searches each time they need a global understanding that inspection will certainly slow down the project. It can also lead to a misunderstanding, which often causes rule redundancy or the introduction of new errors into the system.

Rule Firing and Temporal Redundancy


A common implementation approach between the user interface and business rule layers of a system is to send a package of data, as opposed to sending in one piece at a time. There are two reasons for this approach. One is system performance, and the other is the logical separation between the different application layers. The transmission of the data from one layer to the next consumes a certain amount of system resources and overhead. It is believed that the performance cost of that overhead can be reduced if the data is packaged up before being sent to the next layer. The process first inspects every field on the screen and then packages the data into a single container. A container could be a variety of different things but for the sake of this discussion lets assume it is an XML

32 (Extensible Mark-Up Language) document. XML (Appendix A) documents are perfect for transmitting data between layers because they are self describing. When a piece of data declares that it is a drivers license number, it is easily identified between the layers. It is the self describing nature of XML that helps to facilitate this process. Once the XML container is filled with the data entered on the screen, it is sent to the business logic layer for the business rule processing. The business logic layer will then iterate through the container verifying the information that was sent. The data will be checked against the business rules. Compliance issues will cause the user to be prompted, and they will not be allowed to continue on to the next step in the process until the problems are corrected. When business logic layers are implemented this way, it means that every time the business rules layer is called all of the rules will be run. This is because there is no way for the business logic layer to know which rules should be run and which ones should not be run. As rules run there is also a possibility that they will change the data and negate previously run (or future) rules. Since updated data could change the outcome of a rule, it may need to be run again or not at all. Temporal redundancy is the primary downfall of business logic layers (Giarratano, 2005). In the traditional approach, rules operate independently of one another. In effect, it is a simple iteration engine. It is not smart enough to know when the rules could work together to save execution time. It simply runs each rule one after the other until it reaches the end of the cycle (Giarratano, 2005). Temporal redundancy can happen one of several ways. The most common occurrence is when two pieces of data fire the same rule. Rules that are redundantly fired slow down the performance of the system. Having the rules drive the process by iterating through all of the available data is inefficient. It requires high levels of computer

33 resources as data moves between the application layers. The problem is further compounded as expensive rules are executed multiple times (Giarratano, 2005). Lets consider our continuing insurance application example. When entering insurance information, a common piece of required data is a vehicles identification number (VIN). The verification process takes 5 seconds to run VIN validation rule. Now consider the possibility, that when each driver is checked on a policy, the system needs to verify the VIN number of the each vehicle. (Assume that is an average household which has two vehicles and four drivers.) The processing begins and driver #1 is being checked, along with checking vehicle #1s VIN. As previously stated, the cost is 5 seconds. Next, driver #2 is checked, which again checks vehicle #1s VIN (now adding an additional 5 seconds). The problem continues to compound itself until all drivers are checked. When the process finally reaches the vehicle data, the VIN number is checked for a fifth time. Vehicle #1s VIN is checked 5 different times throughout the process for a total cost of 25 seconds. If every rule in the business logic layer operated this way, it would have a significant impact on the applications performance and usability. Users do not like to wait one second much less 25 seconds. The more rules that are re-executed, the more time the user will have to wait for a response. This problem exists among many of the business applications in use today, and causes application performance problems without people even realizing it (Giarratano, 2005).

Application Dependant
The final problem with the traditional approach to implementing business rules is that once the rules are coded, they are effectively locked inside their host application (Chisholm, 2004). Decades of using this approach has created large applications that

34 require many developers to maintain. Each business unit within the organization will typically have its own development staff to build and maintain their individualized systems. When new applications need a similar rule they are usually forced to create another version of it within their own code base. Implementing rule redundancy within the organization will eventually lead to increased maintenance costs (Ross, 2003). As the business rules are changed, the applications that support those rules will also need updating. The more applications that contain the same rule, the more the organization will spend on changing those applications. Each competing application quickly becomes a monolithic representation of the individual business units that they were designed to automate. Often these silo (Appendix A) applications have a stranglehold on limited IT budgets, giving the business unit little chance at replacing them with serviced based systems (Ross, 2003). This functionality grows vertically within the narrow aspect of the business unit and not horizontal across the enterprise. In the fast paced changing markets of today, companies can no longer afford to use this type of approach. The business logic layers of tomorrow must be centralized to the enterprise. Business rules are not application or business unit specific, they are enterprise specific (Ross, 2003). The business rules of the organization should be made available to every application within the company. The rules cannot be centralized if they are only implemented within one application. Those implementations are typically inflexible and do not provide a usable programmable interface (API, Appendix A) such as a web service (Ross, 2003). The execution of the business rules themselves should not require complex data structures, if they are to be shared across applications. The client application should be able to execute a rule by providing the smallest amount of required data. Difficulties will

35 arise if analysis of an organizations business rules becomes necessary. The amount of work involved with the analysis exercise varies greatly depending on the size of the organization and the quantity of the applications in place. Even with good documentation this step is almost always unavoidable (Ross, 2003). It is the only way to be sure, of the extent of the systems behavior as it relates to what rules are currently in place. Since the code needs interpretation by a trained programmer, the process quickly bogs down the business analyst who is charged with the task. Implementing business rules this way was originally thought of as a time saving activity. The approach delivered that promise in the days of static applications that were infrequently changed (Giarratano, 2005). However, those paradigms have significantly shifted since the late 1960s through the late 1980s.

Rules-based Processing Approach


Described
To understand how the rules-based processing approach works, its definition must first be examined. Instead of implementing static hard coded rules within the application source code; the rules-based approach uses a collection of rules statements that draw conclusions based on the conditions of different situations. These rule statements can be modified by anyone in the business unit, but the responsibility will likely fall on the business analyst (Ross, 2003). The rule statements are produced with the help of the rule definition interface (Chisholm, 2004). The rules themselves are based on facts, and the facts are based on terms unique to the individual business process. The assertion (or retraction) of facts triggers the firing of one or more of the systems business rules (Giarratano, 2005). The rules do not exist within the application source code; they are interpreted as IF-

36 THEN statements written in a special programming language. Most rules-based systems can trace their roots back to LISP, the second oldest programming language (Brownston, 1985). LISP was designed as an artificial intelligence inference language. To achieve rule centralization, will require the acceptance of this new approach at an enterprise level. Rules-based processing is more than just an applications code implementation style, it is a whole new approach; a new way of thinking about how companies handle and manage their business rules (Ross, 2003). The business rule approach provides a road map for organizations to follow to address the business rule problem within their own company. What is that problem you might ask? Companies know they have business rules, and they also know they have computer systems that enforce them. However, if you were to ask the organization for documentation related to what rules they have, and which systems enforced what, you may find the answer to the question is unknown. Using traditional programming practices the company developed their expert systems over an extended period of time (Ross, 2003). Centralizing the business rules was not a priority. The rules-based approach is the key to solving this problem. It provides a way for companies to distinguish the differences between business rules and business processes. It forces companies, and the IT departments that support their applications to rethink how agile software is built and maintained. The following sections of this paper will explain the important facets of the rulesbased approach and describe their significance in solving the agility problem. More importantly these characteristics should allow the reader to determine what elements make up a well defined business rule and how that rule is classified. Rule classification is critical to the rules-based processing success. It allows business users to understand

37 the core meaning and purpose of the individual rule and how it relates to the applications behavior.

Knowledge Information Theory


Domain Experts
The primary purpose of an expert system (rules-based or not), is to emulate the decision making process of a subject matter expert (SME, also referred to as a domain expert). In order to do that, the system will have to be programmed with the same level of experience as that person (Brownston, 1985). This person plays a critical role in the rules-based approach. These individuals are the ones who help facilitate the centralization of the business rules. Without them, the company would be forced to sift through the source code of their legacy applications to document the companys rules; a time consuming process that is prone to many errors (Ross, 2003). The rules-based approach begins by documenting all of the rules of the organization along with their purpose. The goal of the rule gathering process is to understand what rules are in place and how they are used. Part of the process is to match rules with the different systems that support the organizations daily operations. This step provides the foundation for knowledge management at an enterprise level. To get control of the business rules at an enterprise level requires the company to find a way to manage them. You cannot manage what you dont know or understand; so you must first document what is currently beginning used (Ross, 2003). Expert systems are implemented for a number of reasons, but none is more important than their ability to provide a consistent business practice (Giarratano, 2005). Computer systems do not discriminate the way people sometimes do. The same set of inputs will always produce the same set of outputs. These systems also

38 provide a way to help less experienced staff answer questions about a particular business process (Brownston, 1985).

Knowledgebase or Rulesbase
The knowledgebase or rulesbase is the collection of IF-THEN rules that tell the system what to do under the defined set of circumstances. The rules-based approach includes consolidating all of the rules into a common location. The centralization of enterprise business rules requires the creation of a database (Appendix A). As the rules of the organization are added to the database, the system will quickly evolve into the companys knowledgebase (Ross, 2003). The primary purpose of the knowledgebase or rulebase is to provide a way to achieve knowledge management (KM). KM is the embodiment of what the rules-based processing approach is about. Like any other piece of data within the organization, the business rules need to be treated as an important intellectual asset. Important assets require management. Having all of the rules in one database allows the organization to protect their rule information as valuable data (Merritt, 2004). The knowledgebase quickly presents other advantages as well. First, it is self documenting; that is rules stored in the knowledgebase are stored in plan English. The most important element of all rules is the rule statement. The rule statement is the declarative natural language representation of the rule. It provides the reader with a descriptive understanding of the rules purpose. Next, the relationships between the rules, such as rules that belong to a common business process, can be grouped together (Froscher, 1990). This grouped representation of the rules can provide some helpful insight into how the rules collectively work together when producing some behavior. This analysis advantage makes a strong case for keeping enterprise business rules inside

39 the knowledgebase. Rule redundancy should also be greatly reduced or eliminated. Before adding a new rule to the system the user should search for a similar rule. Reusing the same rules across multiple business processes would be considered a best practice (Chisholm, 2004).

Metadata
Metadata is data that describes other data. The explicit knowledge and skills of an experienced individual represents their expertise about a particular subject. In order to create an expert system based on that expertise, this knowledge must first be captured. The captured version of this knowledge is known as metadata (Ross, 2003). In the rulesbased approach, metadata is data about knowledge. This metadata forms the scope of the problem domain. It provides boundaries and a context in which the system will operate (Merritt, 2004). Expert systems are defined with the smallest amount of metadata possible. This methodology is also true in the rules-based approach. In the rules-based approach the metadata takes the form of how the rule syntax is represented inside the rule engine. A widely accepted rules-based implementation includes rule syntax that is interpreted, rather than compiled (Chisholm, 2004). Interpreted rule syntax allows for the caching of different rulesets as the context of the problem changes. Web based applications will often change their context as the user moves from one page to another (Bellinaso, 2006). In an insurance application, the ruleset used to process a home policy would be different from the one used to process commercial real estate. To increase system performance and efficiency these rulesets would be moved in and out of the systems memory as the situations change (Giarratano, 2005). As the complexities of these

40 processes increase so does the dependency on system metadata. The rules-based metadata acts like an encyclopedia for the current process. Metadata can also be used to map user input fields to the corresponding facts that are either asserted or retracted from the inference engine. Expert systems must have an established metadata context in which to operate (Brownston, 1985). The additional advantage of a rules-based expert system is that this context is separate from the system source code. Different rulesets can be moved into memory scope or dynamically updated as the context changes from one user request to another. The primary purpose of metadata is to bridge the gap between abstracted rules, and the remaining the application code that still resides with the rest of the system (Ross, 2003).

Fact Model
Another key element in the rules-based approach is the fact model (FM). The FM provides organization and structure to the metadata. In the rules-based approach, it is a way of organizing the knowing. The FM represents the knowledge from the business unit perspective, as opposed to the relational database design or technical perspective (Ross, 2003). It provides the business with a logical way to describe and break down the individual entities or customers that interact with the organization. Identifiers like insured, driver, or household all share a relationship with one another in the context of buying insurance. That relationship has a specific hierarchy that reflects the real world. The FM provides a standard vocabulary for dealing with the business process. That business process can then be linked to the individual rules that govern the process. It is generally accepted that there should only be one FM that deals with the entire problem domain (Ross, 2003). However, this does not mean that a large

41 organization should use only one FM for the entire enterprise. Quite the contrary, the rules-based processing approach advocates multiple FM groupings. The groups would be categorized by the individual business process. These groupings would be based on common terms accepted by the organization as relevant to their industry. The FM should be designed in such a way to provide a clear representation of how goals are achieved through the business process. When properly designed, the FM becomes an excellent communication bridge between the business unit and the IT staff (Ross, 2003). The early establishment of the FM can have a significantly positive impact throughout the rest of the project. The FM is the established common business-based vocabulary. The knowledge that is contained within the FM is meant to be shared across the organization.

Artificial Intelligence (AI)


Historical significance
The evolution from Artificial Intelligence (AI) systems to Expert Systems has led to the rules-based processing approach. Early AI systems based on broad unstructured general purpose problem solving were too difficult to implement and maintain. In general the rules-based approach improved the process by narrowing the context in which the AI system was required to operate. It accomplishes this by incorporating the knowledge of experts in the form of IF-THEN rules (Merritt, 2004). The collection of these business rules form the basis of an intelligence which is artificially generated by a computer system. When applying these rules to the problem space, the system provides the user with a conclusion based on the situation. Rules-based systems trace their roots to early AI applications because their inference engines use AI-based algorithms to perform conflict resolution (Brownston, 1985).

42 In the rules-based approach part of the decision making is to decide which rules to fire; that process is called conflict resolution (Giarratano, 2005). A conflict can occur when more than one circumstance fires the same rule or when one rule negates another. Decisions must be made on how to solve these problems; otherwise, the rules engine would produce random results that would not be helpful to the business process. This is significant because without this conflict resolution capability rules-based processing systems would offer little value to business applications (Froscher, 1990). Repeatedly fired rules would eventually cause performance problems as the system grows in size and complexity. Fortunately, this problem was solved in the late 1970s with the invention of the RETE Algorithm (Giarratano, 2005).

Predicate Calculus
First-Order Logic

The syntax of the rules-based approach is that the rules themselves are based on the fundamental constructs of predicate calculus and first-order logic (Giarratano, 2005). The rule formulas outline an expression to produce a truth value. IF x THEN y, where x is the antecedent and y the consequent is the standard form of logical expression. The rules can also contain logical operators such as AND, OR, and NOT. The truth value is contained with a Boolean variable that will either be true or false. This means that, if x is true then y must also be true and visa versa (Goldrei, 2005). This assumes that no additional variables or operators used in the expression, specifically OR or NOT. FirstOrder Logic is used to represent the rules statement in an executable form versus reading it as an English sentence. Having to interpret a natural language sentence for each business rule would cause the system to run slow (Ross, 2003). Eventually, the rules

43 must be in an executable form, not unlike the traditional approach of representing rules within a compiled class. In regards to this topic, the rules generally take the same syntactical form because under both implementation strategies they are trying accomplish the same thing (Chisholm, 2004). This solid foundation provides the rules-based implementation with a way to prove its outcome inside the context of the problem space. This allows for manual auditing of the inferences made by the rule engine (Giarratano, 2005). Rule statements should never contain any ambiguous circumstances. Representing ambiguity within the executable rule would be very difficult, if not impossible (Ross, 2003). The variables inside the rules or facts are the symbolic place holders for rule execution; therefore representing the calculus aspect of it. The following is a rule statement and formula example: A driver must be licensed. (x^y) => r (Goldrei, 2005).
Rule Syntax

Since the rules-based approach is based on simple IF-THEN logic the syntax for declaring a rule is not overly complex. Many of the attributes are similar to the traditional approach. How the rule is syntactically formed depends entirely on the rule engine that parses it (Chisholm, 2004). The rule languages that are available today do share common standards irregardless of their syntactical differences. Following the firstorder logic standard the rule always begins with the Left Hand Side (LHS) or condition of the rule. The LHS describes the facts and how they will be tested to produce a truth value. The truth value will resolve itself to a Boolean returning either true or false. The LHS return value determines whether or not the rules result or Right Hand Side (RHS) will fire. The RHS side of the rule determines what action the rule should take in the

44 event that its conditions have been met. An arrow () character separates the two sides of the rule and represents a logical implication between the two. The expression L R annotates that given the conditions of L; action R will occur (Goldrei, 2005). The RHS of the rule may return an error message, update a fact, or provide a command. The possibilities about which action a rule can carry out is only limited by what the writer of the rule is willing to declare (Giarratano, 2005).

Declarative Programming
Terms
The declarative programming process begins with the concept of creating a framework or grammar in which to operate. The lowest common denominator in the rules-based processing approach is the term. A term is used by the business to share and communicate ideas about organizational processes or operations (Ross, 2003). Facts are built on these terms, and the rules are then built on top of the facts. Terms are natural language words that describe a single unambiguous concept. Example terms related to the insurance industry can be found in Table 2.

Example Terms customer, insured, spouse, household, gender, status, employee, underwriter, agent, vehicle, home, driver, effective date, motor vehicle report, premium, discount, coverage, umbrella, quote, prior carrier, etc.
Table 2 - Example Insurance Terms

Since a term always represents something, they will always be nouns or qualified nouns. The terms listed in Table 2 begin to form the context in which the rules inference engine will operate. They represent the most basic things about the particular business problem or process. Like other concepts within the rules-based approach terms are meant

45 to be atomic. They should represent an object or idea that is indivisible, not one that is composite. Terms also need to be unique; similar terms should not be repeated or overlapped with other terms. This kind if redundancy creates confusion, not only for the business person, but also for the knowledge engineer that is trying to implement the system. Terms can and often are related together in some way. These relationships are described within the fact model that defines the business process. Maintaining a unique and unified approach with the organizations terms and fact model ultimately leads to consistent rule behavior. Producing reliable rule behavior adds to the validity and acceptance of the business rules related to the individual business process (Ross, 2003).

Concepts Catalog
To ensure that the terms of the organization are clearly understood by everyone in the organization, they must be explicitly defined. These definitions are then gathered together in a common location and should be made assessable to all of the employees in the organization. The collection of all the organizations terms and their corresponding definitions is called the concepts catalog (Ross, 2003). The concepts catalog is used as a glossary for the business terms of the enterprise. In the rules-based approach, understanding the definition of rules is critical. The concepts catalog is one way the company can provide meaning and validity to their business process. When properly documented, the concepts catalog can help facilitate rule changes or updates to the business rules. Users should be able to easily identify which terms belong to which rules and visa versa. The purpose of the concepts catalog is to provide a way for equal understanding of the common business terms throughout the organization. Every term that appears in the fact model or business rule should be represented in the concepts

46 catalog. Coordinating the establishment and maintenance of the companys concept catalog is another step in rule management. It represents the categorization of the know part of the business process (Ross, 2003).

Facts
The real differentiator in the rules-based approach is that rules are based on the assertion (or retraction) of facts from the problem scope (Giarratano, 2005). Rules are based on facts that are built on terms. A fact within the rules-based approach is exactly that a fact. In general, facts represent knowledge about things in the real world. They are pieces of information that are believed to be true and devoid of popular opinion (Ross, 2003). This central idea relates back to predicate calculus aspects of the rules-base approach. In the logical programming sense the fact represents the predicate of the situation. Of course not every fact in the rules-based approach will be a proper predicate. These propositional facts are not excluded from the rules-based approach because sometimes it is necessary to specify rules in a propositional way. Facts are the common or shared verbs found within the rule statement (Ross, 2003). Facts represent what is possible to know about a business process, but they do not provide a way to constrain it. Constraining a business process is left entirely up to the rules (Chisholm, 2004). Facts can also be used during the requirements gathering process of the project. Stating them can form the basis for those requirements. When writing an auto insurance policy, it is necessary to verify that any drivers on the policy are licensed. Whether or not the individual is licensed to operate a car will determine if they can obtain auto insurance for their vehicle. This simple example demonstrates the importance of facts in the rules-based approach. A driver is either

47 properly licensed or not, and that fact can easily be interrogated by the business rule that controls the process. As with anything else, in the rules-based approach it is important that facts are precisely worded. This reduces the chance for confusion and reduces errors; not only in the manual business process but in the finished application. Precisely described facts provide a solid foundation or template for any rules that are based on that fact (Ross, 2003). This correlation between rules and facts grows dramatically as the amount of rules increase within the organization. The facts of the situation must be considered reliable. Inference engines used in the rules-based approach draw their conclusions based solely on the available facts (Chisholm, 2004). Essentially, the facts are the data on which the inferences are built. They form a way for an expert system to solve problems by providing the data for which the system can reason. Facts provide chunks of information to the system, so that a conclusion can be drawn (Giarratano, 2005).

Rules and Rule Classification


Rejectors

In the rules-based approach there are three main categories for the classification of rules. The first and most fundamental of these is the rejector. A rejector rule will always constrain a business process (Giarratano, 2005). By default all business rules can fall into this category. The constraining nature of a rejector rule provides a way to maintain the integrity and validity of a business process. Rejectors will not allow the process to continue if their conditions are true. When a rule is defined as a rejector, the inference engine watches for violations and then provides feedback. Rejector rules are very narrow minded, either you play by the rules or your input is not accepted. They insist on the

48 absolute quality of the data and actively pursue the highest amount of consistency within the business process (Ross, 2003).
Projectors

The opposite of the rejector is the projector rule. A projector rule is used as a constraint, but instead of rejecting it, it makes further inferences about the situation. For example, a projector rule might allow a user of the system to save some information, but will then inform the user that a future step may be halted by a rejector. A projector rule uses logical deduction to maintain the integrity of the business process (Ross, 2003). In effect, a projector rule will produce some other event with in the business process. Projectors infer new knowledge from existing facts in an automated way to produce decisions. This rule classification type bears the closest resemblance to artificial intelligence system. Inside applications, projector rules add value by not causing work stoppages within the application. They will project that the current set of circumstances might not produce the desired outcome (Ross, 2003).
Producers

The final rule type is the producer rule. The name producer implies value calculation and that is exactly what it does. Producer rules are used to calculate a value based on a business rule. Producers neither reject violations nor project events (Ross, 2003). They always provide a calculated value based off the condition of the rule. A common discount in when buying auto insurance is to lower a persons premium when the individual hits certain milestones in their life. The first of such milestones is when the individual reaches their 25th birthday. A producer rule can be

49 used to calculate the appropriate discount based on the fact the person is now 25 years of age or older. This ability to produce information based on the current set of facts allows the rules-based processing approach to handle complex rule patterns or expressions. The computations that producer rules calculate are automatic. As the conditions of the rule become satisfied values remain current and accurate. If re-computation needs to occur, then it is handled by the inference engine (Giarratano, 2005).

Centralized Repository
Business Logic Server
Web Services

Once the business rules of the organization become centralized, it is important that systems begin using them. A common practice for sharing services across an enterprise is to expose those services as a web service. A web service is a system designed to support interoperability across a network from server-to-server. This flexibility allows different applications to leverage the same service as if its logic were part of the native source code. Mainly, web services are faceless applications that are designed to facilitate data exchange (Shodjai, 2006). In the case of the rules-based approach, web services provide the type of aritechture that is ideal for sharing the business rules of the enterprise across multiple applications. This is done by exposing a common API (Application Programmable Interface) that allows for the assertion (or retraction) of facts (Rea, 2005). Based on the provided facts, the web service returns the needed information to the calling system; either proceed to the next step or require the user to fix something. By providing these services, the machine then becomes the Business Logic Server (BLS) for the organization. The BLS is the gateway to the business rules of the enterprise. It is

50 responsible for the execution of the rules found in the rulesbase. The BLS implementation is a critical step in achieving business rule independence for the organization. Establishing a BLS for the sole purpose of the management of the organizations business rules is highly desirable in the rules-based approach (Ross, 2003). The BLS rules-based approach leads to a more agile, easily understood system; one that can adapt itself quickly to change. By including a reference to the BLS, every application within the organization can share the same business logic layer. The shared business rules then become a centralized hub for the companys business logic; ensuring that every system handles all rules the exact same way. The following list provides the primary benefits of implementing a Business Logic Server (Ross, 2003): 1. Lower integration costs. 2. Increased reuse of source code. 3. Increased system agility and time to market. 4. Decreased developer time and reduction of IT dependence. 5. Provides greater transparency between systems. 6. Reduced maintenance and cost of ownership.
Service Agents

The popularity of web services in the market today has led to an increased demand for making their use and implementation as straightforward as possible. This evolution has led to the invention of newer technologies and implementation approaches. As systems become more service orientated, they will require new ways to be managed. Service Orientated Architecture (SOA) and more specifically the service agent are addressing this need (Rea, 2005). A service agent is a way to integrate an existing application with a

51 web service. The service agent acts a common interface into the web service and provides utilities to the client application. These utilities assist the developer in connecting their application to the service. They do this by providing service discovery, data transformations, and security providers to the application (Shodjai, 2006). They can also assist with the definition and management of process flows in regards to interactions with the web service. Some service agents are even developed with monitoring tools designed to provide metric information about their corresponding web service usage (Rea, 2005). The usage information can then be reported to senior management within the organization. The rules-based approach can also make good use of service agents as they relate to Business Logic Server. Rules-based service agents provide the client application with the ability to seamlessly integrate the business rules of the enterprise within their application. One of the ways they do this is by providing state management services between the client application and the web service (Giarratano, 2005). Effective state management reduces overhead and increases application speed. Once the service agent is developed it can be integrated and deployed into many different applications as a shared assembly (Bellinaso, 2006).

Rule Definition Interface (GUI)


In order for a business analyst to create, update, and maintain the rulesbase (database) they will need access to the system. The most common way to provide access to any system rules-based or not is to provide Graphical User Interface or GUI (Appendix A). To implement the business rules of the organization the business analyst will need a special GUI called a Rule Definition Interface (RDI). The RDI provides a way for the user to update and manage the business rules of the organization without having to write

52 program code. The RDI allows the user to declare, validate, and deploy the business rules in real-time. Real-time deployment of the business rules means that organization will not longer have to wait for the development lifecycle to complete in order to change their business rules. This implementation provides a tremendous amount of flexibility and agility not experienced with the traditional approach. It provides business users with the ability to access the business rules directly without the involvement of IT staff. Business users leverage the RDI to manage the business rules at an enterprise. Rule-torule relationships and interconnectivity is a crucial step in reliable rule management. Managing rules at a global level and fully understanding their scope across the organization is a major goal of the rules-based approach. The Rule Definition Interface helps to facilitate its achievement (Chisholm, 2004).

Refinement and Training (for Rules)


Business rules managed through the RDI often require enhancements before being deployed. These refinements can take on many different forms. The user may have to add new terms or facts to the business rule. In the rules-based approach, properly wording the rule statement might require several revisions (Rea, 2005). Rule statements are one of most important aspects of the rule. They provide the understanding necessary to determine the purpose of the business rule and where it should be applied. The rule statement represents the business rule in its natural language form. Unfortunately, business rule writers in the past made many mistakes in this area. In the rules-based approach there are many rules about what makes up a good rule. There is also an entire framework dedicated to the formation of good business rules called RulesSpeak. (The RulesSpeak framework will be covered in greater detail in software tools section of this

53 paper but warrants mentioning here.) The RuleSpeak framework was specifically designed with the proper business rule writing techniques in mind (Ross, 2003). It provides the templates and guideless to the future business rule writers to help them be successful. Rules are not unlike anything else in business, they need regular maintenance in order to remain effective.

Auditing and Management Reporting


Soon after implementing the rules-based approach, the organization may find itself with thousands of rules to keep track of. Managing thousands of business rules that represent every application within the organization can seem overwhelming (Chisholm, 2004). That task is made easier by adding a management reporting feature to the Rule Definition Interface. The management reporting feature allows the business user to query the rulesbase in search of rule improvement opportunities. Performing regular audits of the organizations rulesbase will help increase rule accuracy and reduce errors. The following list taken from the Principles of the Business Rule Approach, and provides some good examples of what the business analyst might consider in an audit (Ross, 2003). This is not a comprehensive list but it does provide a good foundation for getting the company headed in the right direction: 1. To which areas of the business does the rule apply? 2. What work tasks does the rule guide? 3. Where is the rule implemented? 4. In what jurisdictions is the rule enforced? 5. What purpose does the rule serve? 6. What deliverables in a new system design need to address the rule?

54 7. When was the rule created? 8. When did the rule become effective? 9. Are there previous versions of the rule? 10. Is the rule still in effect, and if not, when was it discontinued? 11. Was the rule retired or replaced, and if so, why? 12. What influenced the creation or modification of the rule? 13. Who can answer particular kinds of questions about the rule? 14. Who has been involved with the rule over time, and in what way? 15. Where can more information about the rule be found?

Rules Engines
Business Rules
Atomicity
The rules-based approach is different from traditional implementations. Instead of a business logic layer it uses a rules engine. Rule engine designs are based on the premise that business rules are small pieces of interpreted metadata that form intelligence similar to a human expert (Giarratano, 2005). Business rule engines infer logical responses derived from facts about the particular situation. These responses are called inferences. The effectiveness of these inference engines remains tightly linked to the accurate representation of each individual rule. Writing good rules for engine consumption is not unlike writing good sentences (Ross, 2003). The best strategy is to keep the rule declarations as simple as possible. Simple business rules are easy to understand and implement within the rules-based approach.

55 A business rule must be atomic; meaning it must be represented in its lowest form. A rule containing two meanings is likely to have two separate purposes and should be separated. Business rules should not be composite in nature (Ross, 2003). Feeding the business rule engine composite rules only leads to lesson its flexibility. The inner workings of rule engine include relationships between rules and rule hierarchies (Froscher, 1990). Composite rules do not work well in the rules-based approach because of the difficulty to maintain rule-to-rule hierarchies and dependencies. If rule audits are required it would also be difficult to troubleshoot, debug, or effectively report on the usage of composite rules (Giarratano, 2005). The importance of keeping rules atomic cannot be over exaggerated. It allows for the most agility and flexibility within the business process; allowing for precise changes in the current business practice. Having atomic rules allows the rule engine to make a more accurate inference about the current situation. The engine will then have the ability to relate the rules within logical groupings (Froscher, 1990). Additionally, business rule engines need the narrowest scope possible in order to work. They cannot deal with a general or an over-inflated context. However, they do have the ability to solve complex problems by linking these fine-grained rules together into rulesets. Combining rules together within certain situations forms a unique context or business process in which to operate (Froscher, 1990). The individual rules can then be reused across the different business processes defined by the organization. The idea of business rule atomicity within the organization requires constant management. Everyone involved with the project needs to understand that creating a non-atomic rulebase defeats the goals of the rules-based approach. Good business practices always begin with

56 consistency. Its difficult to remain consistent when two rules with exactly the same purpose produce two different outcomes. This is by far the worst case scenario when violating the atomicity constraint (Ross, 2003).

Levels of Abstraction
Achieving atomicity doesnt automatically guarantee representation inside the rule engine. All rules within an organization exist in a matrix of different logical understandings. Rules that describe company ethics or culture are very different from the rules that govern the completion of a valid business transaction. Every organization has two major types of rules: 1. Business Process rules 2. Decision-Making rules (Ross, 2003). Decision-Making rules are usually always embedded within a specific business process. Both types of rules will fall within specific categories or levels. The levels are based on business rule complexity and the amount of detail the individual rule provides. The placement of the business process rule within this matrix is known as its level of abstraction. Rules with high abstraction levels will yield higher complexities compared to their lower leveled more detailed counterparts (Giarratano, 2005). Often, these atomic but seemly vague rules may have never been intended for implementation inside a business rule engine. For example, an insurance company may have the following business rule: This organization will not accept fraudulent claims. This statement represents a well formed business rule. It describes a specific piece of knowledge not dealing with the how. It also does not appear to be a composite rule strung together from multiple parts. However, this rule is not nearly low enough on the abstraction scale to be implemented inside any of the business rule engines that are available today. The accurate implementation of this rule will require more refinement. Specifically, what

57 constitutes a fraudulent claim will need to be identified. The identified attributes of a fraudulent claim may even create more rules. As fraudulent claim attributes are identified they can be incorporated into the new rule or rules. The rules will then form a hierarchical relationship joining them together. Formations of rule dependencies play a significant role in the rules-based approach (Froscher, 1990). Once dependences are formed between rules, the rule engine will use them to determine the sequence in which the individual rules are fired. Business rules with dependencies must first be compatible. A good way to better understand rule dependencies is to review how a calculation rule works. Calculation rules provide a numerical value. They do this by using the outputs derived from other rules. A perfect example of this relationship can be found in the calculation of a drivers premium for an insurance policy. Premium = (Medical Payments Bodily Injury) / Age. To calculate the premium requires knowledge about the medical payments, and bodily injury limits on the policy along with the drivers age. These values would be calculated as part of subordinate rules within the business rule hierarchy. Having a single business rule calculate all of the values would violate the atomicity constraint placed on all rules. To maintain proper form each of the values would be derived from their own rule. When the rules are brought into the problem scope the rule engine would determine which rule inputs require which outputs. Therefore, the rules that calculate the medical payments and bodily injury would be fired first (Giarratano, 2005).

Independence
At the core of the rules-based approach sits the business rules engine. The rules engine itself represents one of the most fundamental aspects of this design. The invention of this

58 single component has allowed for the business rules to break free from application source code (Brownston, 1985). Without it, business rule independence could not be achieved. The business applications of the future will be designed to communicate with a rules engine instead of a business logic layer (Chisholm, 2004). This technology has already paved the way for the rethinking of the N-tier business application. Keeping the business rules engine component architecturally separated from the rest of the application is extremely important. Not only does this approach reduce the amount of programming overhead, but it also helps to simplify the environment. Business logic servers operate independently from the rest of the organizations systems. This allows all applications within the environment to maximize the reuse of the companys business rules (Ross, 2003).

Priority or Salience
One of the unique features included within a business rules engine is the ability to set rule priority. Rule priority refers to the ability to prioritize the execution of the business rules as they relate to the problem. Setting the rule priority allows the software programmer to decide which rules take precedence over others. If rule priority is established, the rule engine will use the explicit priority as a factor in determining its final execution path. Although, setting a higher rule priority does not always guarantee the rule will fired first. Rule dependencies are always resolved before anything else (Giarratano, 2005). If a priority I rule has a dependency on a priority II rule, the priority II rule will fire first to satisfy the dependency of the priority I rule. Normal priority II rules, without such dependencies will execute after all normal priority I rules are completed. Explicitly setting rule priority within the rule engine can lead to errors. Rule priority must be

59 established with great care. There is always the possibility that setting a specific priority will not create an optimal execution path for the rule engine. In most cases, leaving priority decisions entirely up to the rule engine is the best practice. Rule engines are complex components and selecting the right priority for each individual rule is not a trivial task. Ultimately, the engine will decide which rules will fire and in what sequence (Giarratano, 2005). These decisions are based on the different factors that are included the current problem scope.

Processing and Parsing


Finite State Machine

A business rules engine models behavior based on finite number of transitioning states. The rules engine component is a Finite State Machine (FSM) (Giarratano, 2005). A FSM reflects application changes from the start of the process until its end. Rules engines generally have three distinct action states: match-rules, select-rules, and execute-rules (Brownston, 1985). Inside the rules engine, these transitions occur as facts are asserted (or retracted) from the problem scope. The rules are fired within the engine as the facts are changed. As the client application interacts with the business rule engine it completes the different actions that need to be performed. A Finite State Machine has four major actions: Entry, Input, Transition, and Exit (Jurafsky, 2000). Each of these actions serves a specific purpose during machine execution. The Entry action is when a machine enters a specific state. This state could be when a new fact is created or when an existing fact is updated. Before the individual rules can be executed they must first be initialized. This initialization routine enters the rules into the rule engine for the first time during the specified session. Input actions occur when the present state is dependant on a condition.

60 Calculation rules that have input dependencies from other rules will use input actions to complete their transition. An action can also take place during the transition. Rule engines have the ability to know when the execution of one rule negates another or requires the re-execution of a previously fired rule (Giarratano, 2005). These checks are continuously happening inside the rules engine throughout the rule execution process. The final type is the Exit action. Exit actions occur as the FSM exits a particular state (Jurafsky, 2000). Business rules engines are fed facts which produce responses. Those responses or inferences are returned after the business rules engine has completed a series of states and transitions through a particular path to produce the desired result. A basic FSM diagram is provided in Figure 3. The diagram shows two states S1 and S2 along with several transitions requiring either a 0 or 1 to complete. The beginning state S1 is also the end state as indicated by the double circle. The FSM diagram could be used for anything that has a binary 0 and 1 representation (Jurafsky, 2000).

Figure 3 - Basic Finite State Machine Diagram

The business rule engine will always be in a transition state until it reaches an accepting state (final state). The machine will reach an accepting state when it has completed all of its processing and reached a valid end point that is not an error. While parsing the

61 business rules the engine is always in search of the path that will lead to a valid end. Otherwise the rule engine would not be able to provide any output (Chisholm, 2004). FSM have to two major categories of machines: Acceptors or Transducers (Jurafsky, 2000). Acceptors return binary output resulting in a yes/no response from the machine on whether or not the input is accepted. A Transducer machine is one that actually generates some output based on a give state using some action. Transducers are mainly used for controlling applications. Business rule engines are non-deterministic; meaning during every cycle they are not entirely sure exactly where they are going to end up. This is caused by many factors including rule dependencies, priority, or by which facts happen to be asserted (or retracted) into the current problem scope (Giarratano, 2005).
Parallel Processing

Rule engines execute rules based on facts found within the problem domain. The problem domain consists of all the facts that are within the current scope. The corresponding rules equate to the ones whose patterns were matched and moved into an accepting state. Rules in an accepted state are cued for processing. The cueing or preprocessing of the business rules is known as building an agenda (Giarratano, 2005). The business rule agenda is essentially a list of all the rules that are about to executed during the processing cycle. Rule engines do not execute rules until given the run command. Once the command is given the business rules that remain on the agenda will be fired. Rules with higher priorities will be executed first, unless rule dependencies exist. The remaining rules will be fired in order of their dependencies on one another. Since not all rules have dependencies, the engine does gain some additional efficiency by processing rules in parallel. (It should be noted that there is no official sequential order to firing

62 rules inside a rules engine.) The power of rules-based systems is that a certain level intelligence exists for rule processing. Traditional business logic layers will often fire their rules in a predefined order that never changes between process cycles. Business rule engines prepare execution agendas. The rule engine is designed not to run every rule on every process cycle. Running all possible rules on each cycle would consume too much time making the business rule engine run slow. Instead, business rule engines prepare agendas consisting of only the rules that need to be run for the current business process (Giarratano, 2005). Agendas do dynamically change as the facts are asserted or retracted away from the problem domain.
Rulesets

When multiple rules are grouped together inside the rule engine they will form a ruleset. Rulesets provide definition and structure to the business process (Ross, 2003). For example; when purchasing automobile insurance the user of the system will enter information related to the individual drivers on the policy. The information that is entered must be complete. If the user omits a required attribute, say drivers license number, the system should response with an error message that says, The drivers license number is required. This rule, along with the other rules that govern the business process of entering driver information would be logically grouped together into the AddNew-Driver ruleset. These rules would be grouped together because they are all being used in a similar context, adding a new driver to the policy (Froscher, 1990). However, the same rule could be a member of multiple rulesets. Ruleset membership is not limited by the rule engine.

63
Business Process

A business process is a stand-alone unit of work that produces output. Rule engines help to facilitate the completion of business processes. They do this by applying the appropriate ruleset to the problem domain (Ross, 2003). Business processes consist of rules that are grouped together and executed in batch or real-time. Most business organizations prefer applications that allow their users to complete business processes in real-time (Froscher, 1990). This is often referred to as Straight-through Process (STP). STP processing transactions mean that there was enough intelligence built into the expert system that the application was able to complete a valid transaction without human intervention. The business rules fired at the appropriate times and the system was able to govern the transaction. STP transactions save the company time and money. They represent one of the major reasons why an organization would spend the time and resources implementing the rules-based approach. Every rule within the rule engine will always belong to one or more business processes (Chisholm, 2004).

Maintenance
As with any system, ease of maintenance will always remain an issue. In order to be agile business applications must be easy to maintain. The code and fix approach to software development never pays off in the long-run (Zachman, 1987). Companies end up wasting resources fixing bugs and making business rules changes instead of developing more value-add features to their software. In the rules-based approach the business rule engine itself is the easiest component to maintain as far as the developer is concerned. Basically, the Rule Definition Interface (RDI) component allows the business analyst to add, change, delete, and publish new rules into the system (Chisholm, 2004).

64 The only time a developer would even have to get involved is when the new or updated rule did not produce the expected result. This would most likely be the result of an improperly declared rule. It is likely the rule engine component would not be internally developed by the company. It would be purchased from a software vendor or adopted from an open source development project. Most engines have simple implementation styles yet can tackle very complex business problems (Giarratano, 2005). Building a rules engine from scratch would take years of research, planning, and hard work to complete. Most business solution software developers would not have enough ample time to dedicate to such a task. It would also require a deep understanding of how a business rules engine works as compared to the traditional business logic layer. If this was not understood, the business rules engine could suffer serious performance and reliability issues. That would ultimately lead to low user acceptance or quite possibly a complete dismissal of the system (Ross, 2003).

Building
Whether you decide to build the rules engine yourself or adapt one that already exists there are some initial decisions to be made. Specifically, those decisions are centered on how the engine will process its rules. There are three main ways that rules engines process their rules: 1. Forward Chaining 2. Backward Chaining 3. Flow-based Processing (Giarratano, 2005). Each of the processing techniques has their own advantages and disadvantages. It should be mentioned that forward chaining is one most commonly used and accepted by U.S. companies (Brownston, 1985). The details of each of these processing techniques will be described in the following sections.

65

Forward Chaining
Forward chaining rules engines processes their rules by reasoning from the presented facts to the conclusion. In other words, they starts with the data that is available. This method of processing the rules is known as being data-driven. Choosing a rule engine based on the way its processes its rules is absolutely critical. The reason stems from the fact that different rules engines are designed to solve different problems. Implementing business rules that are meant to control or monitor a business process are ideally suited for a forward chaining engine. The primary advantage of a forward changing rules engine is the speed at which it processes the rules. These engines will typically employ a fast pattern matching algorithm to speed up their processing (Giarratano, 2005). Generally, they will also cache (Appendix A) parts of their rules to make the business process run even faster. This is a huge advantage when considering business based solutions that are all about processing data as quickly as possible. Business users often do not like waiting extended periods of time (measured in seconds) for the application to respond. The only notable disadvantage to forward chaining rules engines is there memory consumption. Historically, they have been criticized for consuming too many resources on the machine were they reside. However, this criticism was manly centered on the hardware limitations of machines three decades ago (Brownston, 1985). In todays world powerful distributed servers are equipped with gigabytes of memory (2GB+); memory consumption appears to be less of an issue (McKellar, 2003). The forward chaining rules engine sacrifices memory for speed, making it the rules engine of choice for most business applications. Most forward chaining rules engines are vastly superior to traditionally implemented business logic layers. Instead of processing rules in

66 a sequential order forward chaining engines can shift directions quickly. (Giarratano, 2005).

Backward Chaining
In sharp contrast to a forward chaining engine is one that deploys a backward chaining or truth hypothesis to solve a problem. Backward chaining engines begin with a goal and then search backward through the available facts. They do this to determine if the facts will support the desired conclusion. Alternatively, a backward chaining engine is referred to as being goal-driven (Giarratano, 2005). Since backward chaining engines use less memory they are perfect for systems with hardware limitations. However, rules engines deploying the backward chaining method will generally run slower than their forward chaining counterparts. This limitation doesnt mean that backward chaining engines dont have their place as a viable solution. Again, choosing the right engine to solve the right problem is critical. Backward chaining engines do have an advantage when the problem is diagnostic or research based. This is because a backward chaining engine will investigate all possible paths before returning with a conclusion. If an application was designed to help doctors treat dieses a backward chaining engine would probably produce the best results. These types of engines are built to make connects between things that might not be obvious to the casual observer (Brownston, 1985). For example, the mixing of two types of drugs in treating an illness may have an adverse effect on one type of patient versus another. A backward chaining engine should be deployed when the best decisions need to be made rather than the fastest ones. It is hardly likely that a patient will complain about waiting a few extra minutes for right treatment to be determined. Backward chaining engines are not designed to process

67 transactions, that task is outside of their scope. However, once the data has been collected a backward chaining rules engine could be used to analyze it providing the businesses with additional areas of interest (Giarratano, 2005).

Flow-based Processing
The final rules engine type evaluated by this author is one that uses a flow-based processing method. Flow-based processing engines use a hybrid or combination of the forward and backward chaining models (Merritt, 2004). It is called flow-based because it is mainly procedural in nature. Much like traditional implementations flow-based rules engines are heavily dependent solely upon a business process rather than a list of facts. These engines are commonly implemented to run business rules directly from the knowledgebase or rulesbase rather than leveraging a faster caching approach (Chisholm, 2004). Running rules directly from the rulesbase makes things run slower. The flowbased engine does evaluate the facts as it proceeds through the particular process. It even searches for truths as it trys to control the flow of information (Giarratano, 2005). The biggest problem with the flow-based approach is temporal redundancy. Rules could potentially run multiple times with the final execution of the rule producing the result. This strategy could produce an undesired outcome. This sensitivity to when the rule was run and how many times during the process makes the flow-based processing engine more difficult to work with and harder to understand (Brownston, 1985).

Rules-based Pattern Match Algorithms


RETE

68 One of the reasons that that rules-based approach has become more popular in recent years is because of significant improvements made to rules-based engines. These improvements even include making the engines object-orientated. However, none have had a more significant impact than increasing an engines speed (Brownston, 1985). Application performance is at the forefront of system development. When people talk about the applications that they use everyday often they think of execution speed (Bellinaso, 2006). The rules-based approach bases rules on facts that are based on terms. Terms, facts, and rules have to be linked together somehow. This linking or binding has to happen repeatedly because the scope of the problem is dynamically changing at runtime. So, the rule engine itself is constantly worried about pattern matching before anything else. However, if the rule engine is always bogged down in a pattern matching process then the execution of the business rules would be extremely slow (Brownston, 1985). Therefore the pattern matching process must be fast. The RETE Algorithm invented in 1979 by Charles Forgy addresses this very issue (Giarratano, 2005). The algorithm uses a simple principle. The actions of one rule will only change a small amount of facts available on the fact list. Essentially, the facts will change slower over time. During each rule cycle only a small percentage of the rules will typically be affected. Charles Forgy discovered that having the rules themselves drive the search for facts produced large amounts of unnecessary computing. Realizing that most rules would find the exact same facts no matter how many times the engine cycled he devised a way for his algorithm to remember (cache) peaces of the rule-fact link. This approach significantly reduced the computing power and time needed. The engine could now

69 focus it efforts on only items that have changed or were not found on the previous cycle (Giarratano, 2005). The RETE Algorithm is specifically designed to take advantage of temporal redundancy instead of being victimized by it. Temporal redundancy is present in all expert systems rules-based or not. It leverages the processing of the previous cycle to reduce the work load of the current cycle. RETE also caches the results of network junctures. For example; if a three fact rule had two of its facts discovered during cycle 1 the algorithm responds by caching that information. If fact 3 is discovered during cycle 2 then it will be promptly matched up with its other two facts from the previous cycle. The previously discovered facts would not be reprocessed; they would be used to fire the rule during cycle 2. When all the facts of a rule are discovered the rule is then added to the rule engines agenda. The agenda is only processed when the execution or cycle command is given by the controlling application (Brownston, 1985). Charles Forgy named his algorithm RETE (Latin for net) because it builds a network of patterns. Forward-chaining rules engines make the most use of the RETE algorithm due to the similarities in processing style. The primary disadvantage to using the RETE algorithm is it uses high amounts of system memory (Giarratano, 2005). There is also a possibility that poor rule writing could lead to slower than normal performance. This is something that shouldnt be an issue as long as the rules definition interface validates the rules before they are deployed (Chisholm, 2004).

TREAT
Tens years after the invention of RETE a newer faster pattern matching algorithm was invented called TREAT; by Daniel P. Miranker. Like RETE, TREAT also determines

70 when the rules will fire within the rules engine. However, the similarities between the two algorithms end there. TREAT is primarily based on the principle that fast patterning matching can be achieved without the use of large amounts of system memory. The invention of TREAT was motivated by the perceived deficiencies found RETE (Marshall, 2003). In RETE, the caching of information is inadvertently redundantly done. These redundancies can be found once in the rule-fact link and another in the conflict set or agenda. RETEs heavy dependence on caching also causes it to pay a heavy price when deleting a rule memory. The TREAT algorithm does not create a network or cache information between cycles. The information is instead recalculation only as needed throughout rule execution. This greatly reduces the need for the size of system memory. The only state that TREAT stores in working memory is the conflict set or agenda. The state of the rule engine is not maintained between cycles like it is with RETE. Since TREAT only maintains working memory the cost of deletion is significantly lower than in RETE. TREAT was invented as part of the natural progression of rules-based systems and is the next step to RETE on the evolution scale. This is because TREAT does not sacrifice memory for speed which gives it an advantage in both time and space (Marshall, 2003). The creators of TREAT also claim that extra time needed to recalculate fact additions (compared to RETE) can be offset by the time saved when the data must be removed from working memory.

LEAPS
Forward-chaining based algorithms have continued their evolution on into the present day. At each step in they have advance the speed in which the rules are processed increasing in complexity. This latest algorithm called LEAPS which stands for Lazy

71 Evaluation Algorithm for Production Systems was created by Don Batory from the University of Texas in 1994. Like RETE and TREAT before it, LEAPS uses a matchselection-action system to process rules inside the engine. Like TREAT before LEAPS inventors were looking to create a fast pattern matching algorithm without consuming large amounts of memory, the Achilles Heal of RETE. However, Don Batory looked for way to leverage the best parts of both algorithms to maximize performance. He did this by devising a clever rule grouping routine. What Batory found is that he could double the rule execution speed of TREAT. Like RETE, LEAPS creates fact or data structures to enhance the speed of rule searching. However, LEAPS never updates any match information it only inserted or deletes (Batory, 1994). Like TREAT, LEAPS recalculates it matches only as needed during rule execution not relaying on the system cache. LEAPS then takes the calculation process one step further by assign a timestamp to every fact to indicate when it was inserted or deleted from the stack. As facts are processed a pointer to it is placed on the stack (Appendix A). This creates a stack of timestamp ordered facts with the most recently updated fact at the top of the stack. During the next call for rule execution the LEAPS algorithm selects the fact at the top of the stack. The fact is then checked against the predicates of all rules. Since the rules are arranged in particular order, sorted by the number of positive condition elements, the process of finding a match happens quickly (Batory, 1994). (It is the equivalent of searching an index in a database system rather than performing an entire table scan.) This is because LEAPS takes advantage of similar rules having the same amount of positive conditional elements or fact predicates. As soon as LEAPS determines that a fact can no longer be matched the search is terminated. The fact is then bumped off the stack the rest of the

72 facts are then moved up and the next fact is processed. Rules are fired by LEAPS when all of their predicates or facts are satisfied. If the firing of one rule causes more fact inserts or deletions to occur, LEAPS inserts this new activity back into the stack. When all of the facts have been processed leaving the stack empty LEAPS terminates all search activity (Batory, 1994).

Unification or Two-Way Pattern Matching


As previously stated not all rule engines are forward chaining. The ones that arent, specifically those that deploy the backward chaining method to processing their rules use a completely different type of pattern matching algorithm. Unification or Two-Way pattern matching attempts to find the most general unifier between two objects (Jansson, 1993). In the case of rules-based processing these objects take the form of the facts that are asserted into the system and the individual patterns of the business rules themselves. The algorithm accomplishes this task by searching for the smallest substitution between two terms until they become equal. The substitution process maps variables and terms with a finite number of options. The unifier of the two objects is the final substation for each term that makes the two become equal. The algorithm begins the process with the initial term and traverses the options on both the facts and the rules until a match is made or until all available options have been explored (Jansson, 1993). The use of this algorithm in backward chaining rules engines is becoming more widespread, with it most notable implementation inside PROLOG (Giarratano, 2005).

Source Code
Generation

73 The rules-based processing approach bases itself on the principle that the rules are separated from the applications source code. Rules are then represented as declarative meta-data stored inside the knowledge or rulebase. The actual capturing of the rules seems straight forward enough, but exactly how those declared rules are turned into something a computer system understands needs to be addressed. Turning business rules into an executable format presents rules-based architects with three coding options (Chisholm, 2004). The first option forces the business analyst to construct business rules in an executable format. This is often accomplished by leveraging simple interpreted scripting languages like VBScript or JavaScript. Since the business analyst is actually writing program code that can be interpreted by a compiler the rule can be executed with little or no transformations. This option presents a less than desirable situation for the business analyst because it requires them to understand native programming logic like a programmer. Since a business analyst might not want to add that skill to their background this option might be met with resistance. A second option to converting the business rules into something a computer can execute is to use the stored meta-data to write programming code. This programming code would be similar to the traditional approach to implementing rules by actually constructing a class. The business rules class would then have to be compiled, and then deployed to the server before it can be used. Again, business analysts are generally not exposed to compilers. They will often not understand code promotion procedures especially in environments that support multiple machines like web farms. This option is also very similar to the traditional approach in the sense that the rules are again back in compiled source code. This implementation style blurs the lines between separating the know from the how. It would also be

74 dependent on the software development cycles making business rules deployment slower and less agile (Chisholm, 2004). The final and best option is to use the stored meta-data to create something that can be interpreted at run-time yet remaining declarative. This means that the rules would not be converted into source code. The result then creates a declarative code structure that can then be read by both a human and a machine. The interpreted code can then be independently tested and deployed by the business analyst through the rule definition interface. Since the interpreted code represents more of a predicate calculus equation than a proprietary scripting language it can be easily understood by the business analyst, developer, and the business logic server. As the code is interpreted by the business rules engine it executes the logic of the rules. This is the preferred method in the rules based approach (Chisholm, 2004). It is closely aligns itself with the separation between source code and business rules. It also takes advantage of allowing a business analyst to maintain, implement, test, and publish the rules to the business logic server independent of the software development cycle.

Rule Engine Languages


Not only do rule engines have their own declarative syntax but they also come with their own declarative languages. The languages range in style from simple syntax structures to leveraging complex XML grammars. Most rules-based processing languages can trace their roots to LISP the 2nd oldest high-level language (Brownston, 1985). LISP was originally created by John McCarthy as a declarative mathematical notation language in 1958. The language is based on linked-lists and data structure which also provides LISP with the meaning of its name List Processing. Since its invention, LISP has held close ties to artificial intelligence research. After its creation most AI researchers used LISP as

75 a model for their languages. LISP based languages were then quickly adapted for use inside rules engines. LISP is an expression-orientated language with no distinction between expressions and statements (Brownston, 1985). The code is declarative in nature and always written as expressions. The declarative nature of LIPS made it the perfect base language for rules-based systems. The expressions in LISP are written as prefix and predicate calculus notations. The purpose of these specialized languages is to represent the business rules in their natural form (Giarratano, 2005). LISP commands use white space as delimiters, with each command encapsulated by parenthesis. The parenthesis requirement of LISP has often been criticized as one of languages semantic drawbacks. None-the-less, the LISP language continues to resonate as the cornerstone for the rule engine languages of today. An example of the LISP syntax can be reviewed in Figure 4.

Figure 4 - LISP Syntax

OPS5 (Official Production System)


One of the first successfully implemented rule engine languages specifically designed for rules-based processing was OPS5 (Official Production System). An OPS5 programs begins with a declaration section to describe its object data. This is then followed by a production section which contains the rules. During rule engine cycles the facts are kept in working memory with the rules inside production memory. Once the rules are initialized and have been match to their corresponding facts working memory becomes

76 instantiated. The engine includes two algorithms for matching, selecting, and executing rules. These algorithms are called LEX and MEA (Brownston, 1985). Both of these strategies are used to increase OPS5s rule execution performance. The simpler of the two algorithms LEX uses refraction to delete all previously executed rules from the conflict set. Refraction allows LEX to control rule execution by disallowing the same instantiations of rules from firing more than once. The second step in the LEX process then orders the remaining rules based on timestamps similar to LEAPS. The rules are then processed in descending order. LEX is based on how recent the rule was added to the conflict set (Brownston, 1985). The MEA algorithm differs from LEX because it places an extra emphasis on matches between working memory and the first condition of each rule in the agenda. The name MEA means means-ends analysis. Its designed to accelerate the processing of the rules by keeping the inference focused on fastest possible path until the cycle has finished. Out of the box the OPS5 language only supports forward chaining but is flexible to use some backward chaining problem solving strategies. OPS5 is not a strongly typed language and doesnt provide a way for programmers declare variables of a particular type. This characteristic was directly derived from LISP (Brownston, 1985). As a result type mismatches such as performing mathematical operations on strings can only be detected at runtime. OPS5 does come with complex objects called element classes. Element classes are designed to hold information about a particular fact. For example: A driver on an insurance policy has a first and last name, drivers license, social security number, etc. These elements form the instance containers that are used for rule evaluation and execution. Like any other rules engine OPS5 always includes three main rule states; match, select, and execute. After the

77 matching state, exiting occurs when there are no more rules to process in the conflict set. In OPS5, users do have the ability set an upper limit as to the maximum number of rules that can be fired between cycles. Rules are always treated individually with no particular ordering relationship used in the ruleset (Brownston, 1985).

Software Tools
Business Rule Solutions (BRS) RuleSpeak
Practitioners Toolkit
Software development projects should begin with the business logic layer (Ross, 2003). A company heavily involved with rules-based research has even created a framework called BRS RuleSpeak. BRS which stands for Business Rules Solutions is an open source organization that assists business with establishing standards for the distribution of the organizations business rules. They provide companies with their Practitioners Toolkit free of charge. (Of course, they also provide consulting services for those companies willing to spend a little money for assistance with their business rules initiatives.) The toolkit is designed to be a guideline to help organizations implement the rules-based approach. Helping to write clear and unambiguous rules is the toolkits top priority. BRS RuleSpeak also helps to bridge the communication gaps that exist between IT and their corresponding business unit. It illuminates the differences between organizational directives, policies, and the actual business rules that control a particular process. RuleSpeak can assist with the analysis and design phases for the particular software project. Expressing business rules properly does not happen by chance. It requires a skilled practitioner or at a minimum someone with the right mind-set and willingness to breakaway from the traditional pitfalls experienced when writing rules (Ross, 2003). The

78 toolkit itself is not a library of source code but rather a collection of documents and materials that describe the fundamentals of the framework. Since this framework is document based it aims itself more at the business expression of rules rather than how the frameworks basic ideas are implemented within an application. The best way to describe what the RuleSpeak framework entails is to describe what the creators call their Dos and Donts (Ross, 2003). Their list is quite extensive, representative of the years of experience the BRS Group has dedicated to their research. Table 3 contains a comprehensive list of the BRS RuleSpeak Dos and Donts. (The ideals listed below where incorporated into the prototype system being developed as part of this authors research.)

Rule Not How, Not Where, Not Who, Not When Not Procedure Not Too Long

Not Impossible

Always Built on Terms and Facts No AWOL Facts or Subjects

Description Removing the how, where, who, and when forces the business rule creator to write a rule in its purest form; which is declarative. Business rules are not business processes or business procedures; they are rules and should remain as such. Rule statements that ramble on and on are not only difficult to understand they are nearly impossible to implement within a rules engine. The best examples of impossible rules are the ones that deal with absolute facts that cannot be changed. Having a rule that requires a person to renew their drivers license even when they are dead is a good example of a bad rule. Youre laughing; the BRS team has documented occurrences of this very rule appearing within client organizations. A fundamental theme of the rules-based approach is that rules are always built on facts which are built on terms. References to relevant facts should never be absent from a rule otherwise ambiguities

79 could occur. A rule cannot be properly enforced if the intended facts are unknown. It also cant control something that is unknown therefore it must have a clearly stated subject. Words used to emphasize a point should never be included in a rule. Rules should always be precisely stated and as short as possible. Multiple subjects will always create problems when exceptions with groups of people or things are identified. Rule exceptions are dealt with better on a oneto-one basis. A rule should never start with the word If. Rules are not asking questions they are declaring something usually a constraint on a business process. Alias words like customer or insured should be used with caution. Sometimes they can imply the inclusion of an unintended group. Rules should always be explicit about their intended targets. Commands are a dead giveaway for a process. Rules are not a How To list for completing a business task. CRUD is a database term which stands for create, retrieve, insert, and delete. These are again commands and should not used within a rule declaration. It is usually not good practice to associate rules with a single event. This practice should be avoided because once the event has passed then rule will essentially expire. Rules must be atomic, meaning they must be in the lowest form available. If two rules are required then declare two rules. Rules should always contain one of the following rule words; must, should, not, no, only if. Using actions verbs usually implies facilitating a process. A good business rule doesnt care how its requirements are achieved. The best example of an ambiguous timeframe is the statement until finished.

No Fluff

No Plural Subjects

Careful about iffy Starts

Careful about Actors as Subjects

No Commands No CRUD

Careful about Events as Subjects

No Embedded Rules Must Contain a Rule Word No Action Verbs

No Ambiguous Timeframes or States

80 What does that mean? If a rule is based on time it needs to be exact, otherwise when should the business process be allowed to proceed? Ors almost always imply multiple rules. Again, if multiple rules exist then they should be represented as two rules. Business rules are meant to be understood by everyone in the organization. If they contain words that are not commonly used then their understanding might be lost. A rule always constrains it does not give permission to do something. Since the word etc. can include just about anything it has no place within a good business rule declaration.

No Or No Legal Jargon

No Permission Statements And no Etc.

Table 3 - BRS RuleSpeak Dos and Don'ts

Rule Statements
At the heart of every business rule is the rule statement. The rule statement is the business representation or natural language form of the business rule. In essence, it is the business rule. The Dos and Donts of the RuleSpeak framework are specifically designed to help with the creation of rule statements (Ross, 2003). The toolkit comes with rule sentence templates. Rule sentence templates further assist with the rule writing process. The templates are not technical in nature like the rest of the RuleSpeak framework. They exist only as a guideline and form the basis of the sentence patterns that are used in the creation of rule statements (Ross, 2003). The templates are used during the requirements gathering and business rule identification phase of the project. The sentence patterns closely emulate the strategies described in Table 3. Within each pattern template rule examples are provided so the reader can make distinctions between a good and bad rule statements. For example the following two Rules Statements were provided during a discussion about permission statements (Ross, 2003).

81 Bad Rule, Permission Statement: Orders on credit $1,000 or under may be accepted without a credit check. (Ross, 2003) Good Rule, Revised Statement: Orders on credit over $1,000 must not be accepted without a credit check. (Ross, 2003) The differences between the two rule statements are a clear demonstration of what the RuleSpeak framework is trying to accomplish. Business rules are not documented without any consideration for how they are constructed. Like anything else in business, rule statements need refinement in order to produce the desired result. Crafting a good rule statement is important in the rules-based approach (Ross, 2003). The closer the rule statements are to the RuleSpeak framework the easier they will be to implement within the rules engine (Chisholm, 2004).

Regular Expressions
Rules statements are natural language sentences that follow a specified set of patterns. Several natural language programming techniques can be used to automate the validation of rule statements. Since rule statements follow organized English sentence patterns their attributes can be easily verified using regular expressions. A regular expression is a special language used to search for patterns in natural language text or strings(Jurafsky, 2000). A string represents any collection of any alpha, numeric, or symbolic characters concatenated together to form an expression. Regular expressions can be used to define a language in a formal way by establishing the search space within the text (Jurafsky, 2000). They form the basis for performing the validation checks that are described in the BRS RuleSpeak framework as defined within Table 3. The rules definition interface,

82 part of this projects prototype application is equipped with a special class that contains regular expression. The regular expressions are used to automate the RuleSpeak of the rule statements.

Figure 5 - RuleSpeak Validate Rule Statement

As shown in Figure 5 the class is instantiated when the user selects the Validate Rule Statement option from the menu. The class then performs the required RuleSpeak validations on the rule statement entered by the user. The user will then be presented with one of the following messages: Message Description

83 When an invalid rule statement is detected, the user will be presented with an error message. It contains a complete list of all the errors that were found. The list will only include the specific errors that it found for that particular rule statement. Therefore the list can grow and shrink as issues are fixed or different rules are checked.

When no errors are detected the user is notified that their rule statement is RuleSpeak compliant.

Table 4 - RuleSpeak Validation Messages

The RuleSpeak class uses a list of regular expression constants as shown in Figure 6 to perform its validation routine. Once the object is created then the validate method is called which accepts a single business rule object as its input. The business rule object represents all of the information that the user typed into Figure 5 including the rule statement. Then RuleSpeak class then performs each of the regular expressions checks that are specified in the validate method.

84

Regular expressions that also use part-of-speech tags as part of their search.

Figure 6 - RuleSpeak Regular Expressions

Part-of-Speech Tagging
Another powerful natural language programming technique that is leveraged for RuleSpeak validation is part-of-speech (POS) tagging. POS tagging is built on the

85 premise that sentences are collections of words that are members of different word classes (Jurafsky, 2000). Classes or categories of words include: nouns, verbs, pronouns, prepositions, adverbs, conjunctions, etc. Each of these words is then matched with a special tag like VB, NP, or NNS. These tags identify a specific word class for how the word is being used within a sentence. The regular expression search can then be expanded to include word categories of words. Without POS tagging enforcing a RuleSpeak rule like A rule must have a subject would be impossible. The tags provide the class with the ability to identify the subject within the rule statement. POS tagging provides a significant amount of information about each word in the provided sentence along with the words around it (Jurafsky, 2000). This provides a context for how the words are being used together. To achieve these results a POS tagger relies on tagsets. Tagsets are preprogrammed meanings for words that are then trained into the tagger using a corpus. A corpus is a collection of tagged words that are used in different sentences. Words often have different meanings when used in different ways within a sentence. The tagger must first analyze each meaning and calculate a statistical probability for the different tags that are found in the training corpus. Larger training corpuses will provide more statistical probabilities (Jurafsky, 2000). Many open source corpuses and taggers exist that are free forpublic use. This author found one on the Internet developed by Mark Watson. The tagger and corpus came together as a set, both libraries where incorporated within the prototype application. The following methods within the RuleSpeak class utilize the tagger before performing the regular expression search: NotHow, NotWhere, NotWho, NotWhen, HasASubject, NoPluralSubjects, and

86 NoActionVerbs. The rest of the RuleSpeak validations could be completed without the help POS tagger relying only regular expressions to complete their processing.

CLIPS Programming Language


In order to facilitate the rules-based approach you need a declarative language. The previous chapter introduced the idea that rule engine languages are based on LISP. The engine selected for this project is no exception and is LISP based. The CLIPS language or C Language Integrated Production System was developed by NASA in the early 1980s (Giarratano, 2005). Since then, CLIPS has undergone many revisions and its development continues today with a current version of 6.2. CLIPS is a multi-paradigm language. It provides native support for three programming models; rules-based, objectoriented, and procedural. The CLIPS engine was designed for use within high volume business based systems. The system uses the forward-chaining method for processing its rules and employs the RETE pattern matching algorithm for fast performance (Giarratano, 2005). CLIPS is provided to the public by NASA as a completely free open source rules-based solution. It comes with a variety of APIs for use within Visual Basic.Net, Java, Perl, Python, and many more. The system was meant to be a low cost, easy to integrate, and high portability solution for organizations interested in implementing the rules-based approach. The system has been tested on a variety of machine types and has even been successfully scaled for use on CRAY supercomputers. The CLIPS system also includes its own IDE for use while testing programs or commands (Giarratano, 2005). The CLIPS IDE as shown in Figure 7 allows for programs to be manually entered via the command line interface. Entire rules-based scripts can also be loaded from a .clp file.

87

Figure 7 - CLIPS IDE

To demonstrate the capability of CLIPS and its IDE interface lets consider the following insurance business rule: A driver must be licensed. This example uses several terms like driver, and licensed which forms the basis for our facts. The CLIPS version of this business rule can then be built on those facts. Before the facts can be sent to the CLIPS engine, it must understand which facts are relevant to the current process. Informing CLIPS of the facts is done by declaring a slot (Giarratano, 2005). A slot is an attribute of a fact. This rule needs to have a person fact and that person has a name (String), is licensed (Boolean), and type (String). These attributes identify one person from another. For this particular example rule the slot declaration would be:

(deftemplate person (slot type) (slot licensed) (slot name)) In CLIPS fact declarations begin with the deftemplate command followed by the template name, in this case person followed by the slots. Slot sequence is not important; they can be in any order. You will notice the use of the parenthesis characters, a characteristic derived directly from LISP (Giarratano, 2005). Now that the fact context

88 has been established the rule itself can now be declared. It begins with the left-hand side (LHS) or the rule condition:

(defrule AllDriversHaveLicense "All drivers on the policy must have a valid drivers license." (person (type driver) (licensed false) (name ?name)) => CLIPS rules always start with the defrule command followed by the name similar to how the facts are declared. The rule command can also include an optional description attribute and in this case is filled in and describes the rules purpose. The rule operates on the person fact. It checks the person type and must be of type driver. When the engine finds a driver it will also check the licensed Slot to determine if the driver is licensed. Finally, the name variable is used to distinguish the results between drivers. If driver number 1 violates the rule but driver 2 does not then CLIPS needs a way tell one driver from another. It does this with a unique identifier and in this case it is using the name variable. Now that the CLIPS rule has been established it must perform some action if the condition is found to be true. That action is represented on the right-hand side (RHS) of the rule or the rule result: (assert (response (action reject-not-licensed) (errormessage "A driver on a policy must have a valid driver's license.") (args ?name)))) The result in this case will assert a response fact. (The response fact must also be declared using the deftemplate command.) That fact has an action which could be a real action command from the calling program. Action commands serve as the link between the CLIPS engine and its host application. In this case an error message is also included to inform the user of the problem. Finally, an array list of names represented by the args

89 ? name declaration is also sent in the response. The name array list provides the user with all of the drivers who have violated the not licensed rule. Arrays in CLIPS are declared using multi-slots. This rule can now be put into action by using the CLIPS IDE.

Figure 8 - Declaring CLIPS Facts

For this rule there are two facts, a person and response. When each is properly declared CLIPS will return command line control back to the user by showing that it is waiting for the next command by displaying CLIPS> keyword. It is now possible to view a list all the current facts by using either the list-deftemplates or facts commands. (Figure 9 demonstrates these commands.)

Figure 9 - List Facts Commands

90 (Please note: at this stage CLIPS doesnt have any facts, only the place holders for the facts the deftemplates.) The image show in Figure 9 also does not have any rules. The valid drivers license rule can now be entered on the command line just like facts:

Figure 10 - Enter CLIPS Rule

If this done correctly CLIPS will return control back to the user and will wait for the next command. (The engine now has two fact place holders person and response and one rule AllDriversHaveLicense.) CLIPS is ready for the assertion or retraction of person facts so that it can process its rule. As facts are either asserted or retracted from the system the RETE algorithm will keep track of which rules need to be run. The matched rules are then added to the agenda. The following facts will now be asserted into the CLIPS rules engine:

(assert (person (type child) (licensed false) (name Myleigh Leannah))) (assert (person (type driver) (licensed false) (name Angela Leannah))) (assert (person (type driver) (licensed true) (name Bill Leannah))) (assert (person (type relative) (licensed true) (name Shelby McPhail))) (assert (person (type child) (licensed false) (name Zoe Leannah))) (assert (person (type driver) (licensed false) (name Linda Miller)))

91

Figure 11 - CLIPS Facts Command

Now that the facts have been asserted, the facts command can be used to provide a list of all the facts that are in the current CLIPS scope. (Remember, as the facts were being asserted into the system the CLIPS rules engine is building an agenda.) The agenda represents the matches between all applicable facts and all applicable rules (Giarratano, 2005). The list of agenda items can be shown by using the agenda command as shown in Figure 12.

Figure 12 - CLIPS Agenda Command

For this particular set of facts the CLIPS engine has identified that two (of all the facts asserted) will cause the valid drivers license rule to fire. Entering the run command will cause all of the fact-rule matches in the agenda to fire.

92

Figure 13 - Run Command, Rules Fired

After the rules fired, two new facts were added to the fact list. They represent the two asserted response facts that expose the two drivers who have violated the licensed rule, Linda Miller and Angela Leannah. The asserted responses are then communicated back to the client application that originally called the CLIPS engine. Those responses could then influence its behavior and prevent the user from moving on to the next step in the business process. CLIPS rule actions could include more functionality than asserting response facts. There could be a whole matrix of things that occur as the rules are fired. For example; the action step of one rule could update or insert new rule facts which in turn could fire more rules. The updating of facts could also negate other rules from firing. There is really no way to predict all of the possible outcomes. Without pattern matching algorithms rules engines could get lost in a sea of possibilities during every cycle (Giarratano, 2005). If that were true then rules engines wont be very useful and the rules-based approach would not be used.

Microsoft Tools
The prototyped application included with this research was developed using Microsoft based tools. Primarily the all code projects are written in Visual Baic.Net which uses a

93 MS SQL Server Database for its backend (Bellinaso, 2006). The reason for this decision; this authors employer uses these products for its own software development purposes. Since this research is of particular interest to them, this author felt it necessary to use Microsoft bases tools where ever possible. The source code for all the modules and components developed as part of this research project can be provided to those who are interested (email: wleannah@wbmi.com). The rules definition interface is a Windows based application while the client application for consuming the CLIPS rules is web based.

nHibernate
One of the source database persistence tools on market today is Hibernate. Hibernate is an ORM or object-relational mapping framework that takes the work out of persisting business objects within applications to a database. In general ORM tools were invented to solve a problem between two programming paradigms; object-orientated and relational databases (Bauer, 2005). Since these two paradigms do not often compliment one another, the task of mapping between them can consume large portions of development time. Originally a Java based tool Hibernate has been recently ported to the Microsoft .Net family of languages making it one of the most widely used in the industry. The Microsoft version called nHibernate works exactly like its Java based predecessor. The framework automates the process of the basic CRUD operations performed by every business application that interacts with a database (Bauer, 2005). (The term CRUD stands for create, retrieve, update, and delete.) By providing nHibernate with a simple XML mapping file a developer can easily move data in and out of a database as the application needs it. Give nHibernate a business object and it figures out the reset. Not

94 only does nHibernate save time but is can significantly reduce the amount of source code that a project team has to maintain. This allows systems to become more understandable by every member of the development team (Bauer, 2005). Spending less time on persistence tasks means developers can spend more time adding business value features to their solutions. These applications then become more business focused. All prototyped applications used for this research project are nHibernate enabled.

Prototype
Design
Knowledge Base Database
This author researched several example database schemas on the topic of knowledge base design. During his review, he found many of the designs exhibited a level of complexity that went beyond what was desired for this research project. Specifically, the designs included dozens of relational entities with many layers. They were also too reliant on store procedure based logic. Rules were even based on the precedence of custom database columns found in the different tables. Database schemas often represent the most inflexible piece of any application system. They usually require an experienced database administrator to design and maintain the system. Making a database change in order to change a rule is not a characteristic of an agile system. Those database design patterns were eliminated as viable solutions for this project. After several weeks of experimentation, a simple design approach was finally decided on. The prototypes schema is equipped with only the essential elements found inside a knowledge base. These elements include storage of the rule statement, any necessary facts, and applicable rule actions. The purpose of any knowledge base design is to provide for the centralized

95 storage of the business rules. Having rules locked away inside an overly complex database schema is no better than having them trapped inside application source code. The prototype stores its rule statements directly adjacent to the CLIPS version of the rule. This feature makes it easy to compare a business rules meaning with its implementation. The schemas primary table called BusinessRules is shown in Figure 14. It is the parent entity to RuleFacts and RuleActions. The RuleFacts table stores the high level fact information that is dependent for each rule. All rules require some action that represents their individual responses when their conditions are found to be true. Those actions are stored in the RuleActions table. The schema supports three separate action types. 1. A text or error message response. 2. A calculation. 3. A custom CLIPS command. Ancestral relationships were kept to a minimum. Only fact slots needed their own one-to-many associations. The design allows a slot to be stored as conditional element or variable. A conditional element slots value is then used for the left-hand side of the individual business rule. Slot values used as variables will only pass their information into a rule. Their values will not be used as a rule condition (Giarratano, 2005). This is commonly done when including a persons name in the rules error response message. Error messages that include real-time information are better understood by end-user of the system. Out of the 10 tables in the schema only 4 are used to keep track of transitional information. For the Rule Definition Interface (RDI) transactions include the business rules, facts, slots, and actions. These transactional tables form the business rule meta-data layer for the prototype application. The actual implementation of the business rules is then extracted from the meta-data for the final implementation in the production system. Three of remaining 6 tables are used for rule, slot, and action types.

96 These tables provide the user with the descriptive values found in the different dropdown boxes within the RDI. Classifying the rules into different types also helps to properly perform rule statement validation. The 3 remaining tables were added during the RuleSpeak implementation. Their purpose is to help facilitate rule statement validation when analyzed by the framework. Each of the RuleSpeak tables represents a different step in the process. Certain complexities existed in the identification of permission, timeframe, and legal jargon words. The issues were minimized by implementing the validation steps through the use of a table in the schema. To further reduce confusion each of the specific words where stored in one of the corresponding PermissionWords, TimeFrameWords, or JargonWords tables. The tables are then referenced by the RuleSpeak class when performing the validation. The schema can be broken down into three parts: 1. Transactional meta-data 2. Type references 3. RuleSpeak support.

97

Figure 14 - Knowledge Base Schema

User Interface
The Rule Definition Interface (RDI) component developed by this author is shown in Figure 15. It is the first RDI of its kind to combine a knowledgebase repository, RuleSpeak framework validator, and CLIPS syntax generator all in one easy-to-use interface. The Figure is labeled with discussion points 1 through 12 to provide the reader with additional details related to the available features. The rule list window as show at

98 point 6 provides the user with a list of the current rules being tracked by the system. The user can click any of the rules provided in the list which loads the rule into the current view. Once loaded, changes to the rule can then be made and then saved back to the database. New rules can also be added to the system by selecting main menu option RulesAdd New Rule found at point 1. Likewise, new facts or actions can be added by selecting either the menu option Facts Add New Fact or Actions Add New Action found at points 2 and 3. Rules, facts, and actions can also be deleted from the system. The business rule name, description, type, and rule statement are entered in to the system between points 7 and 8. Newly added rule facts are displayed in the fact list as indicated by point 9. The action list is located at point 10 to the right of the fact list. There is no limit to amount of facts, fact slot attributes, or actions that can be entered into the system. The system will support any amount of information necessary in support of the business rule. However, fact conditions within the rule statement should be RuleSpeak compliant before declaring them within the fact list. The system does not prevent the user from entering facts when the rule statement is not compliant. Doing that would be counter productive. It is highly recommended that all rules be compliant before being implemented, but it is not required. The tool is intended for business rule development. It is understood that the development of good business rules takes a certain amount of time and effort to get right. Rules can be independently promoted when in a finished state or promoted in groups. The idea of the system is assist the business analyst with business rule creation by capturing them in centralized location. Through declaring rule facts and actions the user provides the system with the ability to generate the CLIPS syntax for the user in preparation for business rule deployment to the production system.

99 Points 11 and 12 represent the implemented version of the rule in the CLIPS syntax. The user can even enter the CLIPS syntax manually pending their comfort level with the language or use the CLIPS generation tools provided by the system.

2 1

100

8 10 9

11

12

Figure 15 - Rule Definition Interface

Generating CLIPS Rules


To handle the business rule implementation within a production system the user is provided with the CLIPS generator located at point 5 in Figure 15. An expanded view of

101 the CLIPS generator menu is shown in Figure 16. Since the user has the ability to manually manipulate the generated CLIPS syntax a validation routine was built into the system. The system uses the native CLIPS libraries provided by the rule engine to parse and validate the current syntax. When the rule can be parsed and validated by the CLIPS engine the system responds with the message shown in Figure 17. Invalid CLIPS syntax will invoke an exception response like the one shown in Figure 18. The Generate CLIPS Commands menu option will read the facts and actions declared by the user to generate the CLIPS syntax for the left-hand and right-hand side of each rule. The generated the syntax will appear in the text boxes shown in points 11 and 12 in Figure 15. To export the currently selected business rule to a CLIPS file the user can select the Generate CLIPS File For Selected Rule option from the CLIPS main menu. The interface opens a file save dialog box so the user can provide the system with a directory location for the new CLIPS file. Finally, the system will generate a CLIPS file that represents all of the business rules in the knowledgebase. To export all of the business rules in the database to a single CLIPS file the user should select the Generate CLIPS File For All Rules option. The syntax generator class uses a special class called the CLIPSGenerator. The class was developed by this author for this project. The class is designed to accepted nHibernate rule objects that represent the BusinessRule table relationship as described in the prototype schema section of this chapter. Once passed into the class the CLIPS generator component iterates through the fact and action items to generate the CLIPS syntax. Special consideration was given to when fact names are duplicated between the different rules. When a fact name is duplicated the CLIPS rule engine itself expects only one declaration of the fact and not two. This presented an

102 additional challenge considering a duplicate fact doesnt necessarily mean it will share the same slots. The generator class was given the ability to recognize duplicate facts declaring them only once per CLIPS file. All distinct fact slot declarations are written to the CLIPS file whether they are shared or not. This issue has the potential of manifesting itself when rules are generated in groups or across business process. The issue can still exist if the user creates multiple facts within the same rule but its frequency should be less common.

Figure 16 - CLIPS Generator

Figure 17 - Valid CLIPS Rule Message

Figure 18 - Invalid CLIPS Rule Message

103

Native CLIPS Programs


Validating Drivers
In the insurance industry verifying that the information provided to the company regarding the insured is an important aspect of the business process. Accurate information ensures that the rates provided to the individual and his or her family will be fair and precise. One of the most commonly performed steps in the validation of this information is the verification of the individual drivers listed on the policy. A CLIPS driver validation routine was then built around that idea. The program includes 6 validation business rules. To demonstrate the versatility of the CLIPS engine some of the rules were designed with dependencies with other rules. The program includes the following rules: 1. CalcCountOfInsured = calculates the count of each person listed as an insured. 2. InsuredCountMustBeOne = forces a policy insured count to be equal to one. 3. DriversAreLicensed = requires that every driver on the policy be licensed. 4. HasNoMVRReport = requires that all licensed drivers on the policy have a motor vehicle driving report from the DMV. 5. HasMVRReport = asserts a new fact for each driver that has an MVR. The assertion of this new fact fires auto loss report rule check. 6. HasNoAutoLossReport = requires that all drivers who have an MVR report also have an auto loss report.

The test data used to test these rules can be found in Appendix B. The test data includes a fictionalized family with the head of household being a Mr. Duncan Moonflower. The

104 family has a variety of drivers with a wide range of different information. It provides a good example of a potential real-world situation to be processed by the CLIPS program. After executing the program against the test data, CLIPS has responded that several of the drivers are in violation of the rules listed above as shown in Figure 19. Duncan and Martin do not have an MVR report even though they are a listed as drivers. Susie does have an MVR report but she is missing the auto loss report. Danny and Mary are listed as drivers but they are not licensed. Analysis if this CLIPS program reveals that Martin and Duncan didnt receive any warnings about an auto loss report even though they are licensed like Susie. The reason for this type of response is that the rule that fires the other rule, HasMVRReport did not return true for these two individuals because they did not have an MVR report. Since no MVR report was found, the second rule was not fired by the program. The CLIPS engine recognizes this dependence and understands that the auto loss rule does not need be run. This level of intelligence is achieved using the RETE algorithm (Giarratano, 2005). Not firing the auto loss rule for Duncan or Martin saves the rules engine from unnecessary processing.

Figure 19 - CLIPS Program Validate Drivers Result 1

The program did not produce a response related to amount of insureds on listed on the policy. This is because only Duncan is listed as an insured. Figure 20 demonstrates what

105 would happen to the rule engine response when Martin is also listed as an insured. The modify fact command is given to the engine and Martins relationship type is updated to Insured. The rules are executed and the InsuredCountMustBeOne rule is now fired responding with an error message that indicates the insured count is not correct. This driver validation routine could return an unlimited number of different responses depending on state of the facts are asserted to it. The CLIPS engine does not limit the amount of times that the driver facts are asserted, modified, or retracted away from the problem scope. It keeps its agenda up-to-date in anticipation of the user executing the run command. Only after the run command is fired will the engine perform its final analysis responding with whatever inferences that it determines to be true.

Figure 20 - CLIPS Program Validate Drivers Result 2

Rating
No single business process in an insurance company is more important that rating. Rating an insurance policy is more than just calculating a price its about properly assessing risk. The better a company is at this process the more competitive they will be in the market place. An insurance companys rating algorithm is what sets it apart from its competitors. Companies can win additional business based on the pricing advantages

106 they provide to one driver versus another. An insurance companys rating algorithm is considered to be proprietary information. A proprietary label most certainly means that it is privileged information that should remain confidential by its employees. It should be noted that the following CLIPS program to handle the calculation of insurances rates is fiction. This author modeled his own rating algorithm based on his own ideas about how insurance is rated. (None of his employers algorithms or any other companys algorithms was used in its development.) The program is designed to demonstrate the calculation capabilities of the CLIPS rules engine. All of the rules inside the program are producer rules that calculate a value, which is the policies premium. The Duncan Moonflower policy data found in Appendix B was used to test the program. The algorithm consists of 15 different calculation rules. All of the calculated valuates will eventually be added to the TotalPremium slot found on the policy fact. The rating program includes the following rules:

Rating Rule List: 1. SurchargeDriversUnderTwentyFive = adds a $100 surcharge to any driver who is under the age of 25. 2. SurchargeMaleDriversUnderThirty = adds a $50 surcharge to any male driver who is under the age of 30. 3. DiscountFemaleDrivers = applies a $25 discount to any female driver. 4. SurchargeSingleDrivers = adds a $30 surcharge to any driver who is not married. 5. DiscountMarriedDrivers = applies a $15 discount to any driver who is married. 6. SurchargeCityAddresses = adds a $35 surcharge for every home on the policy that is located inside a city (Territory = City).

107 7. DiscountRuralAddresses = applies a $15 discount to any rural addresses (Territory = Rural). 8. SurchargeRentalUnits = adds a $26 surcharge to any rental unit on the policy (Type = Rental). 9. SurchargeTomahProperty = adds $150 dollar surcharge to any property located in the Tomah (City = Tomah). 10. CalculateDriverPremium = calculates driver premiums with the following formula: (MedicalPayments BodilyInjury) / Age. 11. CalculateLocationPremium = calculates location premiums with the following formula: Value / PropertyDamage. 12. CalculateVehiclePremium = calculates the vehicle premiums with the following formula: (((Value - UnInsuredMotorist) / UnInsuredMotorist) * Symbol) + Capcity 13. CalculatePersonPolicyPremium = adds the calculated person premium to the policy. 14. CalculateAddressPolicyPremium = adds the calculated location premium to the policy. 15. CalculateVehiclePolicyPremium = adds the calculated vehicle premium to the policy. Asserting the test data as is in Appendix B produces the following result:

108

Figure 21 - Rating Rule Result Output

To analyze the rating engine program further lets consider the following test cases found within asserted data: Test Case Susie Moonflower: Susie Moonflower is a 22 year old female driver on the policy. Since she is under 25 she will be penalized with a surcharge for her age, however female drivers do receive a gender discount. Her martial status is single, meaning she will not receive a discount and she will be surcharged again. Considering all of these facts we can expect rule engine to produce the following premium for Susie:

109

Rating Item Under 25 surcharge. Discount female drivers. Single driver surcharge. Total Surcharges and Discounts Driver premium calculation: (MedicalPayments BodilyInjury) / Age or (10000 1000) / 22

Amount $100.00 ($25.00) $30.00 $105.00 $409.00

Total Premium

$514.00

The total cost for having Susie listed on this policy each year is $514.00. This calculation rounded to the nearest dollar and the CLIPS program was told to do the same. Now lets check the rules engines results.

CLIPS Output Results: f-23 (Person (Name Susie MoonFlower) (Type Driver) (Age 22) (UnderTwentyFive True-SurchargeAdded) (MaritalStatus Single-SurchargeAdded) (RelToApplicant Child) (Gender Female-DiscountAdded) (Licensed True) (MVRReport True) (AutoLossReport False) (HasAccidents True) (OperateVehicle True) (Premium 514) (PremCalc True) (PremAggr True)) For this particular execution cycle the Susie Moonflower fact was listed in the CLIPS engine as fact ID 23. The execution of the rules against the Susie Moonflower fact revealed the expected results as shown in the CLIPS output listed about. Susie was surcharged for being under the age of 25. She was also surcharged for being single. The female discount was applied and the driver premium was calculated. Both the CLIPS engine and the manual calculation returned a premium of $514.00.

Test Case Danny Moonflower:

110 Danny Moonflower is listed on the policy but he is not a driver. He is the familys youngest child and is only 12 years old. With his current status we expect Danny to not impact the policys premium because none of the current rules address vehicle passengers under the legal driving age.

CLIPS Output Results: f-8 (Person (Name Danny T. Moonflower) (Type Driver) (Age 12) (UnderTwentyFive True) (MaritalStatus Single) (RelToApplicant Child) (Gender Male) (Licensed False) (MVRReport True) (AutoLossReport False) (HasAccidents nil) (OperateVehicle True) (Premium 0) (PremCalc False) (PremAggr False)) The CLIPS results show that Dannys premium impact is in fact $0.00. Both the PremCalc and PremAggr are showing a false state which means that the rules engine made no attempt to calculate a premium or aggregate it to the policy level. As far as the rating program is concerned Danny didnt match any of the rules and was ignored.

Test Case Martin Moonflower: Martin Moonflower is the younger brother of Duncan who is currently residing at the same residence. Since Martin is living at Duncans house he must be listed on the policy. Martin is a 29 year male driver who is currently single. Given his situation we expect Martins premium calculation to be the following:

Rating Item Male driver under 30 surcharge. Single driver surcharge. Total Surcharges and Discounts Driver premium calculation: (MedicalPayments BodilyInjury) / Age or (10000 1000) / 29

Amount $50.00 $30.00 $80.00 $310.00

111 Total Premium The total cost for having Martin listed on this policy each year is $390.00. CLIPS Output Results: f-28 (Person (Name Martin D. Moonflower) (Type Driver) (Age 29) (UnderTwentyFive False) (MaritalStatus Single-SurchargeAdded) (RelToApplicant Relative) (Gender Male-SurchargeAdded) (Licensed True) (MVRReport False) (AutoLossReport True) (HasAccidents nil) (OperateVehicle True) (Premium 390) (PremCalc True) (PremAggr True)) Again, the CLIPS engine is in complete agreement with our expected results. As shown above Martin was surcharged twice; for being under 30 and single. Since he is on the same policy as Susie the medical payment and bodily injury numbers are constant. The cost for having Martin on Duncans policy is $390.00 per year. $390.00

Test Case 924 Woodland: For this policy Duncan has three locations that he is trying to insure. The first, 924 Woodland is his primary residence located in the rural community of Port Washington, Wisconsin. The homes value is estimated at $155,000. For this property we can expect the CLIPS engine to perform the following calculation:

Rating Item Discount rural address. Total Surcharges and Discounts Location premium calculation: Value / PropertyDamage or 155000 / 3000 Total Premium

Amount ($15.00) ($15.00) $52.00

$37.00

The expected cost of having the 924 Woodland property on Duncans policy is $37.00 per year.

112

CLIPS Output Results: f-32 (Address (Street "924 Woodland") (City "Port Washington") (State WI) (Zip 53074) (Type Home) (Territory Rural-DiscountAdded) (Value 155000) (Premium 37) (PremCalc True) (PremAggr True)) The CLIPS engine added the rural address discount as shown in the results above. The total premium for this location was calculated to be $37.00

Test Case 123 State Street: The Moonflowers have recently purchased a summer home in Tomah, Wisconsin which they have added to their policy. For the past 50 years Tomah has experienced a high amount of tornados in the region. Many homes have experienced extensive damage over the years and the fictional rating engine is designed to handle that fact. For this particular property we expect the premium to be:

Rating Item Discount rural address. Tomah property surcharge. Total Surcharges and Discounts Location premium calculation: Value / PropertyDamage or 85000 / 3000 Total Premium

Amount ($15.00) $150.00 ($135.00) $28.00

$163.00

The expected cost of having the 924 Woodland property on Duncans policy is $163.00 per year. f-37 (Address (Street "123 State Street") (City Tomah-SurchargeAdded) (State WI) (Zip nil) (Type Seasonal) (Territory Rural-DiscountAdded) (Value 85000) (Premium 163) (PremCalc True) (PremAggr True))

113 The special Tomah surcharge was added to the property. However, the rating program also recognized it as a rural location and applied the discount. After the premium calculation was completed the final number was calculated as $163.00 per year.

Test Case Vehicles: For the vehicles on the policy the rating program does not include any surcharges or discounts. Every vehicle on the policy is subject to the same calculation as described in item 12 of the rating list. formula: (((Value - UnInsuredMotorist) / UnInsuredMotorist) * Symbol) + Capcity For each vehicle on the policy we expect the following results: 2006 Vibe: (((16000 5000) / 5000) * 15) + 250 = $283.00 2000 Corvette: (((45000 5000) / 5000) * 27) + 1500 = $1,716.00 2005 Venture: (((25000 5000) / 5000) * 19) + 325 = $401.00 CLIPS Output Results: f-45 (Vehicle (Make "Pontiac-PremiumCalculated") (Model Vibe) (Year 2006) (BodyType Hatchback) (Symbol 15) (Vin -382677282) (Value 16000) (Capacity 250) (Premium 283) (PremCalc True) (PremAggr True)) f-48 (Vehicle (Make "Chevy-PremiumCalculated") (Model Corvette) (Year 2000) (BodyType SportsCar) (Symbol 27) (Vin T39i39393939r9349340303) (Value 45000) (Capacity 1500) (Premium 1716) (PremCalc True) (PremAggr True)) f-51 (Vehicle (Make "Chevy-PremiumCalculated") (Model Venture) (Year 2005) (BodyType Minivan) (Symbol 19) (Vin U93940340307374734934) (Value 25000) (Capacity 325) (Premium 401) (PremCalc True) (PremAggr True)) Again, both the manual calculation and the CLIPS rules engine rounded the final numbers to nearest dollar. As described in the returned results shown above the CLIPS engine produced the expected results. The rating engine program described in this section always produced the expected results. Drivers, locations, and vehicles are the

114 typical elements used when rating a policy for insurance purposes. These facts can either be added or taken away which will produce varying outcomes to the final policy premium. Based on the results from these simple experiments the CLIPS rules engine could be used to successfully handle an insurances companys rules as they relate to the rating process.

CLIPS and ASP.Net


ClipsNet
The CLIPS rules engine supports a variety of APIs within a wide range of programming languages. These APIs include both Java and .Net but the libraries are also available in other languages like Python, Perl, and Lua. More information related to those APIs can be found at http://www.ghg.net/clips/OtherWeb.html. The final piece in this authors prototype is an example of using the CLIPS engine within an ASP.Net application. (It should be noted that there are currently two CLIPS APIs for .Net; ClipsNet and Clips .Net Lib.) ClipsNet was developed first and was the only API available when this project began. It wraps of the original CLIPS engine with a .Net assembly. The later .Net version is actually a CLIPS assembly port from C to C++.Net making it 100% managed code. Even though the later implementation would be preferred in a real CLIPS deployment, its late availability did not fit within the research deadlines for this project. Therefore the .Net examples described here are using the ClipsNet implementation. The example is designed to validate a single driver from an ASP page. The program uses a subset of the rules described in the validate driver section of this document. The ASP page does not persist any of its data to a database, it is only concerned about the businesses rules. To emphasis agility, the application is completely dependant on CLIPS

115 files. It translates the defined CLIPS fact driver slots into input fields on the ASP page. To read the CLIPS fact template file a special class was developed for this project called ClipsDefTemplateParser. It is designed to use regular expressions to determine which facts and slots are present in the current CLIPS file as show in Figure 22. When the user enters data into the page and clicks on the Validate Driver button the fields are then mapped to their corresponding facts within the rules engine.

Figure 22 - CLIPS DefTemplate Parser Class

116 Facts that violate a rule write messages to the CLIPS Errors section of the page as shown in Figure 23. Below the error section, is the trace or debug part of the page. It displays the current facts and their current state. Often during rule execution the CLIPS engine will manipulate the facts. Any mistakes made by the engine can be exposed by monitoring the CLIPS fact list or factset. Similar to the previously described CLIPS programs changing the input values will change the responses from the CLIPS engine.

Input fields read from CLIPS fact template file. Add or remove a slots from the template will dynamically be represented here.

Returned results from rules.

Current CLIPS fact list or factset.

Figure 23 - Validate Driver ASP.Net Example

117

Rule Agility
In the presented prototype, CLIPS rules can be automatically generated by the Rules Definition Interface (RDI) or they can be maintained by a skilled professional. Business rule agility can be achieved by applications that leverage this technology. CLIPS separates the knowing from the doing by relying on declarative programming techniques. These techniques declare rules based on facts and their current state instead of explicitly writing the programming logic necessary to enforce a rule. Explicitly writing the rules into a compiled class is a completely different approach. The CLIPS engine loads its declared rules from a text file. This file is not compiled into an assembly rather it is interpreted by the rules engine at runtime as shown in Figure 24. CLIPS text files have special extension; .clp. They can be independently deployed between software releases. Deploy an updated CLIPS file and the systems behavior is going to change. This design effectively removes business rule changes from the software development process. Removing business rule changes from the software development process is the key to business agility. In a CLIPS enabled system, company business units will be able to react to changing market conditions more quickly than ever before. The business rules of the system can be changed in an independent way without sacrificing the stability of the rest of the environment.

118 Facts are asserted or retracted away from the problem scope. This process changes the outcome of the inferences. Compiled CLIPS rules Engine. CLIPS rules files, not compiled loaded at runtime.

Figure 24 - CLIPS Rule Engine Model

Matched rules are then executed from the agenda.

Reporting and Auditing


Centralizing the business rules of the entire organization makes sense for multiple reasons. Doing so allows organizations to gain a better understanding of what rules they have and how those rules are used across the organization. The strongest argument that can be made for gaining a better understanding is through the reporting and auditing process. Decentralized rules only available in application source code would be very difficult to search through and decipher their true meaning and purpose. The prototype application stores its business rules inside a database. Rules are stored two ways: 1. English natural representation of the rule. 2. Implemented version of the rule in CLIPS syntax. Those rules have standard database relationships between child and parent records. These relationships can be analyzed by performing some simple SQL joins

119 while querying the tables for different pieces of information. For example if someone was interested in how many of the organizations business rules had anything to do with driver facts then they could execute the following query against the database:

Select bp.Name, bp.RuleStatement, ft.Subject From BusinessRules bp, RuleFacts ft Where bp.RuleId = ft.RuleId and ft.Subject like '%driver%' Executing the above query against the current prototype database will reveal the following records:

Figure 25 - Driver Query Results

Database queries run against the organizations knowledgebase could be converted into company business rule reports. These business rule reports would then be used to perform further analysis and design as the system evolves in support of the changing business needs.

Results
Rules-based Processing Approach
Success Stories
In order to determine whether or not the rules-based approach produces time saving results it must be tested under real world conditions. Performing these tests directly

120 would require resources that are beyond the scope of this research paper. However, there have been several case studies on the subject along with some real-world implementations. The most notable of these comes from one of the worlds largest mortgage companys Freddie Mac. In an effort to capture more business and better serve its core customer base Freddie Mac has recently overhauled its underwriting system (Havenstein, 2006). The old system implemented its business rules utilizing the traditional approach; by including the business rules within a class. According to company management their legacy application was very difficult to maintain. Even the smallest of business rule changes required many man hours complete, test, and move into their production system where it could be utilized (Minsky, 2005). In addition to that, Freddie Mac is a third party provider in the mortgage business buying and servicing loans from banks like Wells Fargo, Bank of American, and Citibank. Contracts between them and the frontline banking organizations contain strong language that requires strict compliance to their agreements. Changes to their computer systems were further complicated by these agreements and other regulatory issues. With these known issues and the traditional approach to implementing the organizations business rules not meeting their needs Freddie Mac management decided to make a change. They decided to try the rules-based approach (Kersnar, 2006). What is even more interesting about this decision was that not only were they willing to try some new but they also wanted to put the technique to the test. The organization established two development teams with similar task during the application re-write process. One team was required to use the rules based approach and the other the traditional approach. They began the project and recorded the results. The

121 outcome revealed that not only was the rules-based approach faster in terms of maintaining an application long-term but it proved to be faster during its development as well. According to Brian Stucky, a Freddie Mac business sponsor their findings exceeded expectations (Minsky, 2005). The rules-based team was able to complete their tasks up to 5 times faster than the traditional team in terms of individual man hours. In terms of actual time to complete their portion of the finished project, they were able to accomplish that 3 times faster than their traditional developer counter parts. These truly amazing results can be related to several factors. For starters the rules-based team did not require developers to write, manage, or implement any of the new systems business rules. That was the task of the business analyst. Since the knowledge was now separated from the processing developers could concentrate their time on more value add systems items. Likewise, the traditional team development staff had to invest large amounts of their time fully understanding each business rule so that they could successfully implement it within the code. Instead of relying on a few system experts the rules-based team was able to easily spread responsibilities across a greater number of individuals (Minsky, 2005). Now, you might be asking yourself, how is this test fair they had more people, right? Wrong, there were not any limitations imposed on either team as to how many business analysts or business personal they were allowed to engage in the project. They were only limited on the amount of software developers on each team with both teams having an equal amount. The traditional approach requires a developer to write and maintain the rules because they are included in the applications source code. Not only that, without the help of a rules engine the traditional team was also on their own with solving rule execution and temporal redundancy issues. Rule matching and rule execution issues are

122 already solved by the rules-based approach. The rules-based team had less to do, which resulted in less time and lower costs. This is the power of the rules-based approach. More companies will continue to adopt it not because it is an interesting idea but because they will have to in order to remain competitive. One of the most compelling stories related to fast and changing market conditions is the story of hurricane Katrina which destroyed New Orleans in September 2005. Months after its aftermath when individuals started to rebuild their homes and their lives, they began applying for financial assistance from banks and the federal government (Kersnar, 2006). What these organizations quickly realized was that individuals who were affected by the disaster didnt necessarily meet the minimum requirements to obtain a home loan. Worse yet, the computer systems that enforced those rules were never designed to make the volume of exceptions that were needed to provide adequate assistance to the victims. The companies where faced with a daunting task; they might have to change their rules and manually service hurricane Katrina victims without the assistance of their computer systems (Kersnar, 2006).

Failures and Skepticism


As with all new ideas the rules-based approach is not immune to its share of ridicule and skepticism. In general, most negative comments are related to the recent hype that have stemmed from success stories like the one involving Freddie Mac. Critics warn that without strict scientific proof, the rules-based approach will amount to nothing more than an overvalued technique based on popular bias. Scientifically proving new software technologies remains difficult due mostly to the inability to conduct experiments in a controlled and repeatable way (Glass, 2004). Therefore, critics charge new revolutionary

123 methods like the rules-based approach will be used based solely on the belief that they are better. They contend that enthusiastic software developers will always be able to move the masses by peddling anecdotal evidence that their theories are correct. Richard Glass is quick to point out that anyone can always spin the results of using different technologies in their favor (Glass, 2006). Another author on the subject by the name of Frank Carver even suggests that business rules engines will still require a software developer to implement and write the rules. This is because they are the only ones that can understand the true intricacies of the systems they create. Frank further writes that implementing common standards or frameworks can be dangerous because even systems with standards can be difficult to maintain. (Frank Carver is senior consultant with Efficacy Solutions Limited and has many Internet blogs related to this topic.) This author does agree that more research studies are needed. However, the idea that successful implementations add zero value in determining the effectiveness of the technology is strongly dismissed. When developing business solutions any technology that helps increase the time-to-market can and do help organizations increase their competitive advantage. The rules-based approach is designed to help with the agility issue. In the end, whether or not it will ultimately solve the problem will be left up to the organizations who decide to try it.

Future Work
The next step in the proving the rules-based approach would be to conduct a scientifically controlled head-to-head study comparing it to a traditional implementation. Under ideal circumstances this study would involve two or more development teams each given identical programming tasks. Successfully measuring the results of the study would

124 require establishing standards before any data is collected. Those standards would include the processes that each team would be expected to follow along with enforcing strict boundaries for implementation styles. Additionally, the study could also include rule engine performance measurements. For example, stress testing of the CLIPS rule engine. How many rules can it really handle before its performance becomes an issue? This author suspects that the answers too many of these questions will depend heavily on how the technology is architected and deployed as compared to its intended use. Often when there are issues with maintaining business applications they can be related to its original architecture or design. Sometimes businesses evolve faster than applications that support them, and applications get used in ways they were never intended or designed. Since this evolutionary business process would be impossible to predict keeping things as agile as possible is always desired.

Conclusion
This paper explored a technique to designing software known as rules-based processing. It attempted to show that business logic and programming source code should not be mixed together when designing flexible software. The theories behind this technology suggest that the approach will help organizations to better develop, maintain, and manage their business rules. Companies will always be in search of new technologies that can give them a competitive advantage in the market place. The same is true for business rules. Business rules help companies conduct operations in a precise and consistent way. Service related industries like insurance will even use the business rules themselves as way to reach and maintain more customers. If business rules truly are the fabric of todays high-tech enterprise then organizations must find better ways to manage them.

125 Centralizing the business rules of an organization into a single database is one way to accomplish it. Doing so will save the company time and money in the long-run. Unfortunately, centralizing the rules of the enterprise does not solve the entire problem. As the business rules change, then so must the computer systems that enforce them. This need for frequent change really defines the problem the rules-based processing approach is trying to address. Extracting the business logic from the application source code makes perfect sense to the agility minded developer. Rules can then be independently updated and tested outside the applications source code. Successfully tested business rules are then quickly deployed to the production system in response to changing market demands. Since the deployment of the updated business rule does not include application source code the associated risks are mitigated by the process. The prototype application developed during this research demonstrated how this is accomplished. Business analysts used the Rule Definition Interface (RDI) to define the rules of the organization. The RDI was equipped with RuleSpeak intelligence that allowed the user to validate their rule statements. After being satisfied with the validation results the Business Analyst could define the different facts and actions that the rule involved. Defined facts and actions are used by the RDI to automatically generate the CLIPS rule engine syntax. CLIPS syntax is extracted into a special file with .clp extension. The implementation of the rule and its original meaning could then be audited together within a single report. Separating the rules this way gives them the ability to be shared across multiple systems within the organization. This allows organizations to change the behavior of multiple systems simultaneously giving them a level of agility not previously experienced. The rulesbased approach has already found its way into real applications that are being utilized by

126 some of todays leading companies. As more organizations realize rules-based processing potential, it is anticipated that its popularity within the business community will grow. Drawing from its AI roots has made the rules-based processing approach the success that it is today.

Bibliography
Batory, Don. The LEAPS Algorithms. Department of Computer Sciences: The University of Texas (1994). 1-15 Bauer, Christian and Gavin King. Hibernate in Action. The Ultimate Hibernate Reference. Greenwich: Manning Publications Co., 2005 Bellinaso, Marco. ASP.NET 2.0 Website Programming: Problem - Design Solution. Indanapolis: Wiley Publishing, Inc., 2006. Brownston, Lee, Robert Farrell, Elaine Kant, and Nancy Martin. Programming Expert Systems in OPS5. An Introduction to Rule-Based Programming. New York: AddisonWesley Publishing Company, Inc., 1985 Consumer Guide to Auto Insurance. State of Wisconsin: Office of the Commissioner of Insurance (2006): 1-26. Chisholm, Malcolm. How to Build a Business Rules Engine. Extending Application Functionality through Metadata Engineering. San Francisco: Morgan Kaufmann Publishers, 2004 Froscher, Judith and Robert J.K. Jacob. A Software Engineering Methodology for RuleBased Systems. Washington D.C.: Naval Research Laboratory (1990): 1-53. Giarratano, Joseph C. and Gary D. Riley. Expert Systems: Principles and Programming, Fourth Edition: Principles and Programming. Canada: Course Technology, 2005. Glass, Richard. All Aboard The Gravy Train: Hype is the plague upon the house of software. Hacknot. 27 August 2006. http://www.hacknot.info/hacknot/action/home;jsessionid=1E8F98CD7D9F86081EA2C1 7023AEB088 Glass, Richard. Anecdotal Evidence And Other Fairy Tales. Hacknot. 22 March 2004. http://www.hacknot.info/hacknot/action/showEntry?eid=49

127 Gnanavel, Saradha. Design Issues & Architectures in .NET Application Development. C# Corner. 03 September 2005. http://www.csharpcorner.com/Code/2005/March/DesignTechniques.asp Goldrei, Derek. Propositional and Predicate Calculus: A Model of Argument. Mathematics abounds with theoretical results. London: Springer-Verlag, 2005. Hall, Major D. B. Rules of Engagement and Non-Lethal Weapons: A Deadly Combination?. GlobalSecurity.org. 1997. http://www.globalsecurity.org/military/library/report/1997/Hall.htm Havenstein, Heather. Freddie Mac Overhauls Underwriting System. ComputerWorld Business Intelligence. 21 August 2006. http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId =9002609 Jansson, Patrik and Johan Jeuring. Functional Pearls: Polytypic Unification. Cambridge University Press (1993). 1-10. Jurafsky, Daniel and James H. Martin. Speech and Language Processing. An Introduction to Natural Language Processing, Computational Linguistics, and Speech Recognition. New Jersey: Prentice-Hall, Inc, 2000 Loucopoulos, P. and A. Tsalgatidou. An Object-oriented Rule-Based Approach to the Dynamic Modeling of Information Systems. 1-16. Kersnar, Scott. Rules-Based Systems Call the Plays. Mortgage Technology. February 2006. http://www.mortgagetechnology.com/plus/print_archive/?pub=MortgageTechnology&year=2006&issue=T101 &item=9 Marshall, James and Ian Wright. The Execution Kernel of RC++: RETE*, A faster RETE with TREAT as a Special Case. London: Imperial College (2003): 1-13. McKellar, Hugh. Artificial Intelligence: past and future. KM World Magazine. 01 April 2003. http://www.kmworld.com/Articles/ReadArticle.aspx?ArticleID=9693 McMillen, Michael. Object-Oriented Programming with Visual Basic.NET. New York: Cambridge University Press, 2005. Merritt, Dennis. Best Practices for Rule-Based Application Development. MSDN: Microsoft Corporation. January 2004. http://msdn.microsoft.com/library/enus/dnmaj/html/aj1rules.asp?frame=true Minsky, Steven. The Role of Technology in Business - Assessing Operational Risk. 05 August 2005. http://www.ebizq.net/topics/tech_in_biz/features/5902.html?&pp=1

128

Rea, Sara Morgan. Building Intelligent .Net Applications. Agents, Data Mining, RuleBased Systems, and Speech Processing. New York: Addison-Wesley Information Technology, 2005 Ross, Ronald G. Principles of the Business Rule Approach. New York: Addison-Wesley Information Technology, 2003 Shodjai, Payam. Web Services and the Microsoft Platform MSDN: Microsoft Corporation. June 2006. http://msdn.microsoft.com/webservices/default.aspx?pull=/library/enus/dnwebsrv/html/wsmsplatform.asp Voelker, Michael P. Business Makes the Rules. IntelligentEnterprise. November 2005. http://www.intelligententerprise.com/showArticle.jhtml?articleID=172302190 Zachman, J.A. A framework for information system architecture. IBM Systems Journal (1987): 1-17

Appendices
Appendix A
Technical Term Glossary
Application Programmable Interface (API) = A way to access a computer system, application, or library to facilitate data exchange. http://en.wikipedia.org/wiki/API Bug = Errors found in an applications source code are commonly referred to as bugs. http://en.wikipedia.org/wiki/Computer_bug Cache = The collection of data storing an original value used by computers to compare derived results. http://en.wikipedia.org/wiki/Cache Class = A programming construct used as a container that groups common functions and methods together within a program. http://en.wikipedia.org/wiki/Class_%28computer_science%29 Compile = The transformation of written syntax into binary or machine language for use by a computer system or application. http://en.wikipedia.org/wiki/Just-in-time_compiler Database = A collection of data intended to meet the persistence needs of an application. http://en.wikipedia.org/wiki/Database

129 Extensible Markup Language (XML) = A language that defines data along with its meaning. http://en.wikipedia.org/wiki/XML Gigabytes = A measurement of computer memory that represents its capacity in the billions. http://en.wikipedia.org/wiki/Gigabyte Graphical User Interface or GUI = Allows interactions between a computer program and a user through user controls displayed on a screen. http://en.wikipedia.org/wiki/Graphical_user_interface Hard Coded = Programming code that does solve a business problem but is inflexible to reuse or change. http://en.wikipedia.org/wiki/Hardcoded Programming Language = The collection of variables described in a semantic way to provide structure and meaning to a computer program. http://en.wikipedia.org/wiki/Programming_language Property = An attribute of a class. Method, Function, or Sub = A piece of code used to perform a task. http://en.wikipedia.org/wiki/Method_%28computer_science%29 Object-Orientated Programming = A programming paradigm for writing applications made from modularized pieces. http://en.wikipedia.org/wiki/Objectoriented_programming Object = An instance of a particular class. http://en.wikipedia.org/wiki/Object_%28computer_science%29 Silo = A system or application that is incapable of communication with other business systems. http://en.wikipedia.org/wiki/Information_silo Stack = A temporary list of structure data used by a computer system to process a result. http://en.wikipedia.org/wiki/Stack_(data_structure) Syntax = The pattern or symbols used to control the behavior of a machine. http://en.wikipedia.org/wiki/Syntax Transact Structured Query Language (T-SQL) = A language for performing transactions within a database. http://en.wikipedia.org/wiki/Transact-SQL Visual Basic .Net (VB.Net) = A language created by Microsoft used for building custom applications. http://en.wikipedia.org/wiki/Visual_basic

130

Appendix B
The fictionalized test family for the native CLIPS program; Duncan Moonflower. (deffacts PolicyInfo (Policy (PriorInsStatus Good) (CountOfInsured 0) (CountOfSpouse 0) (TotalPremium 0) ) ) (deffacts Locations (Address (Street "924 Woodland") (City "Port Washington") (State WI) (Zip 53074) (Type Home) (Territory Rural) (Value 155000) (Premium 0) (PremCalc False) (PremAggr False) ) (Address (Street "123 State Street") (City Tomah) (State WI) (Type Seasonal) (Territory Rural) (Value 85000) (Premium 0) (PremCalc False) (PremAggr False) ) (Address (Street "487 Wells Street") (City Milwaukee) (State WI) (Type Rental) (Territory City) (Value 500000) (Premium 0) (PremCalc False)

131 (PremAggr False) ) ) (deffacts Drivers (Person (Name Duncan C. Moonflower) (Type Driver) (Age 40) (UnderTwentyFive False) (MaritalStatus Married) (RelToApplicant Insured) (Gender Male) (Licensed True) (MVRReport False) (AutoLossReport False) (HasAccidents True) (OperateVehicle True) (Premium 0) (PremCalc False) (PremAggr False) ) (Person (Name Mary L. MoonFlower) (Type Driver) (Age 35) (UnderTwentyFive False) (MaritalStatus Married) (RelToApplicant Spouse) (Gender Female) (Licensed False) (MVRReport False) (AutoLossReport True) (HasAccidents False) (OperateVehicle True) (Premium 0) (PremCalc False) (PremAggr False) ) (Person (Name Susie MoonFlower) (Type Driver) (Age 22) (UnderTwentyFive True) (MaritalStatus Single) (RelToApplicant Child) (Gender Female) (Licensed True)

132 (MVRReport True) (AutoLossReport False) (HasAccidents True) (OperateVehicle True) (Premium 0) (PremCalc False) (PremAggr False) ) (Person (Name Danny T. Moonflower) (Type Driver) (Age 12) (UnderTwentyFive True) (MaritalStatus Single) (RelToApplicant Child) (Gender Male) (Licensed False) (MVRReport True) (AutoLossReport False) (OperateVehicle True) (Premium 0) (PremCalc False) (PremAggr False) ) (Person (Name Martin D. Moonflower) (Type Driver) (Age 29) (UnderTwentyFive False) (MaritalStatus Single) (RelToApplicant Relative) (Gender Male) (Licensed True) (MVRReport False) (AutoLossReport True) (OperateVehicle True) (Premium 0) (PremCalc False) (PremAggr False) ) ) (deffacts Vehicles (Vehicle (Make Pontiac) (Model Vibe) (Year 2006) (BodyType Hatchback)

133 (Symbol 15) (Vin 838383838383838383838) (Value 16000) (Capacity 250) (Premium 0) (PremCalc False) (PremAggr False) ) (Vehicle (Make Chevy) (Model Corvette) (Year 2000) (BodyType SportsCar) (Symbol 27) (Vin T39i39393939r9349340303) (Value 45000) (Capacity 1500) (Premium 0) (PremCalc False) (PremAggr False) ) (Vehicle (Make Chevy) (Model Venture) (Year 2005) (BodyType Minivan) (Symbol 19) (Vin U93940340307374734934) (Value 25000) (Capacity 325) (Premium 0) (PremCalc False) (PremAggr False) ) ) (deffacts LiabilityLimits (Liability (BodilyInjury 1000) (MedicalPayments 10000) (UnInsuredMotorist 5000) (PropertyDamage 3000) ) )

Marquette University This is to certify that we have examined this copy of the masters thesis by William J Leannah, B.A. and have found that it is complete and satisfactory in all respects.

The thesis has been approved by: Thesis Director, Department of Mathematics, Statistics and Computer Science Dr. Doug Harris

______________________________________________ Dr. Doug Harris

______________________________________________ Dr. Praveen Madiraju

______________________________________________ Craig Walker

Approved On: ______________________________________________