Expert Systems vendors promised that their packaged software would perform tasks just like the companies’ most experienced employees, with intelligence and best practices painstakingly collected from industry experts. By and large, the expert systems promise did not succeed in practical application. The companies who experimented with the systems became leery of computer software promising “intelligent processing.” And other companies who watched the phenomenon from the sidelines congratulated themselves on their caution. With this kind of checkered past, why should companies believe that they can successfully incorporate business rules into their computer systems now?
To answer the question of then versus now, we can use hindsight to examine the problems leading to the downfall of commercial expert systems and see how modern rules management software has addressed them.
- Expert Systems were typically designed as "closed systems".
They were designed to solve an entire problem on their own. They were not designed to support and integrate into larger programming models. In contrasts business rules typically work as a called service with as many intermediate accesses as necessary. While rules can be combined to form an expert system, they can also be defined in small chunks (ruleflows, rulesets) to handle point-specific tasks with results that are handed back to a traditional programming flow. - Specialized hardware/software requirements.
In a time when most corporate computer systems were written in COBOL running on IBM mainframes, many of the expert system packages required exotic workstations using artificial intelligence languages such as LISP or PROLOG. Companies could not easily integrate them into their production environments and had no personnel trained in maintenance or programming techniques for these systems. They had to rely upon special training and support from the software vendors. Today’s rules management systems run on the systems used in daily operations. Languages such as Java and data communications protocols such as XML have created a standardized way of running programs and passing data to them. Companies buying and using modern software have much greater autonomy in integrating the systems. - Generic versus unique rules.
Expert systems came with predefined rules for accomplishing specific tasks. Programmers at the vendor companies, working off interpretations of interviews with industry experts, crafted these rules as compromises between different methodologies employed by their sources. Companies purchasing the software usually needed to go through laborious “tuning sessions” to understand the functioning of the rules and modify them for their own business preferences. Companies wanting to use the systems to automate other tasks usually found it impossible to modify the underlying processing flow and structure of the expert system to perform a different function. Today, companies can build entire rules-driven decision flows from scratch to accomplish the specific tasks of interest to them. Vendors have switched from an attempt to understand and codify work processes themselves, to providing a framework for companies to easily encode their own unique best practices. - Rules management.
Business rules technology found in the best software packages today give companies a degree of control over their rules-driven processes never possible in older expert systems. Companies can trace rule execution; create rules maintenance applications that simplify and organize rule creation and modification; authorize and control access to rule modifications; automatically track version changes and auditing information; produce informational reports with conflict detection; and much more. Rule logic used in business decisions should be expected to change many times over the life of the application as business conditions, external regulations, and internal policy choices change. Modern technology makes these changes practical to implement and deploy with full control by the business.
