Introduction

The Internet takes the concept of information overload to new heights. Search engines now boast in excess of 1.2 billion documents indexed and instantly available. Corporate and business Intranets may even surpass that number. To derive any real value from this avalanche of data, a business must leverage it to make critical decisions. Whether it is the buying habits of males over 25, the latest stock market forecasts, or the demographics of an individual shopper, this information is vital to a company. Integrating this crucial business data, possibly through a central data warehouse, with a business rule engine for decision-making, presents a company with a vast competitive edge.

 

As most businesses start to utilize rule engine technology, companies are searching for something new to maintain a competitive edge. Currently, much of the business decision logic is embedded in collections of proprietary applications (e.g., COBOL applications or stored procedures) – usually maintained by IT professionals. However, it is the business manager and not these computer professionals that understand the business processes and rule logic. These critical decision points must change quickly to remain competitive in a fast pasted business world. This mismatch creates a very costly delay from manager realization until the change is in production. During that time: both parties formally define and agree to the change; the computer professional makes the change; the business manager verifies the change; and the computer professional places the change into production.

 

As the need to react quickly becomes essential, delays caused by inefficient businesses processes become unacceptable. Enabling the business manager, who is inherently non-technical, to automate workflow processes greatly reduces or even eliminates these delays. Early adopters are rewarded with a major competitive advantage. This article looks at one approach to simplifying business rule modification that has been successfully implemented.

Business Automation

To automate time-consuming manual (or batch) data processing (e.g., billing, payroll, planning, etc.) usually requires either customizing or developing programs specifically for that application - usually by the IT department. These programs are both expensive to develop and costly to maintain. Multiplying this effort by the number of business processes that connect, share and use company data, one can see the enormous drain on the corporate bottom line. Workflow automation can take many forms, including Enterprise Resource Planning (ERP) or Enterprise Application Integration (EAI). The potential investment in automation across the more than 11,000,000 American businesses is staggering.

 

The ideal solution would be to harness the existing technical knowledge and programming prowess of the application bridge builders, systems integrators, consultants, engineers, programming analysts, and software developers scattered across the country. These experts already have the ability to create accounting, scheduling, strategic planning, decision support, and other corporate applications that run today’s businesses. A well-designed approach to implementing process automation could eliminate the need for starting automation projects from scratch and could revolutionize how businesses operate.

 

A web-based approach for creating sophisticated Rule Based Applications (RBA), and capturing this expertise, enables business policies and personalization rules to be modified directly from any browser. By being sufficiently generic, these RBAs can support multiple applications and assist in maintaining consistency across enterprise processes and communication channels even from independent and heterogeneous data sources (e.g., marketing, accounting, personnel, sales, and manufacturing).

 

User Friendly AI Technology

In today’s global marketplace, where employee loyalty is literally measured in nanoseconds, a method for capturing business logic and process is crucial. Not only must it accurately represent the business model and function, but the appropriate organizational managers must review and change the logic without IT department assistance. Blaze Software, a FairIsaac Company, has a suite of products for capturing, manipulating and deploying a company’s business rules. The suite’s components include:

• Advisor Builder - the rule development environment

• Advisor Innovator - the rule template authoring tool

• Advisor Rules Server - the deployment engine

At the heart of this suite is a multi-threaded Rete-based rules engine accessible from EJB, COM+, CORBA and other enterprise platforms (see Figure 1). Since most readers are familiar with the functions of rule development, this article focuses on the deployment of a user-friendly application of this AI based technology.

 

Salesmation, an e-Communications Application Service Provider (ASP), implements and maintains rule-based applications using this tool suite. Since applications are provided by the ASP, utilizing its own hardware and software, the client is relieved of the headaches commonly associated with supporting applications. Because the application is Business-to-Business (B2B), businesses use these applications to provide sales, marketing and customer care services to their clients.

Figure 1: Rules are Java objects that can communicate with any of the above languages and development platforms.

 

 

Developing a Web Based System

The e-Communications application includes a real-time display that targets (or personalizes) online advertising based on the Aggregated Market Segment (AMS). An AMS is a combination of two segment data types such as Demographic Market Segment (DMS) and Click stream Market Segment (CMS). For example, a DMS intelligently combines or aggregates any number of demographic data conditions (gender, age, income, etc.) for a customer, while a CMS aggregates any number of online data conditions (browser type, options selected, shopping cart contents, etc.) for someone browsing a web site. The AMS therefore aggregates demographic and online data conditions for a specific customer, enabling the client company to personalize the media campaign based on criteria from either or both data segments. For example, a marketing manager wants to sell umbrellas to anyone visiting a web site from a geographic location where it is raining at the exact time a consumer visits the web site. A banner is served based on a rule that is fed by real-time weather data associated with the visitor's zip code.

 

Each AMS and corresponding DMS/CMS supports the Create, Read, Update, Delete (CRUD) functions, which are managed by non-technical employees. As we saw earlier, criteria or definition changes have to take effect immediately to keep up with business trends. It was also important to capture as much of the logic as possible in a format that enabled reuse in the future. Since the number of conditions can reach, but are not limited to, seventy-five on the demographic side and fifty on the click stream side, there were concerns that producing this application using traditional programming methods, such as Java or C++, would have taken an intense design period following an even longer development process. Previous conventional program-based projects required resources that ranged from Java/C++ programmers coding custom objects to Relational Database Management System (RDBMS) administrators writing stored procedures (scripts containing business- specific RDBMS operations). There were also the issues of integrating legacy data sources and possibly other segment data types in the future. Unfortunately, the conventional approach embeds the business logic within the application logic, instead of building a base of reusable content to be employed in other applications throughout the enterprise. 

 

Separating Business Logic from Application Logic

In this web-based system, each AMS is really a container for a finite set of nested if/then/else statements relating to one or both of the segment data types described above. It defines an algorithm that combines or aggregates customer segmentation (or characteristic data) at a given point in time. And that is how it is interpreted when inter-acting with the rules engine. The client manipulates the outcomes of these complex algorithms without the aid of a programmer.

 

Three concepts are at the heart of this solution: the template, the value holder and the value provider. Let’s start by defining a rule:

"If the age of the customer is over 40 and the gender of the customer is male, then the name of the demographic segment is males over 40."

 

The template or the reusable fragments of Structured Rule Language (SRL) of interest here are the age of the customer is over 40 and the gender of the customer is male. These fragments of business logic can be reused in other applications and therefore should be stored in a common generic format, such as Extensible Markup Language (XML). They should also be accessible from a standardized location within the enterprise network, such as in a Lightweight Directory Access Protocol (LDAP) repository.

 

A value holder is a container that stores a particular value or list of values of a specific type. The value provider defines the value holder’s range and data type. Thus, the first template has the age of the customer as over 40 with the value holder containing the number forty and the value provider having type integer. Tem-plates contain value holders that contain providers. The providers abstract the condition while the value holder gives form to the abstraction creating a reusable fragment of SRL. So how does this help us?

 

The first template: "if the age of the customer is over 40" can be thought of as "if the age of the customer is over some integer value to be entered by user." The power in this approach is the ability to separate business function (obtain an age) from the format (screen entry of an integer) of the business logic at design-time — bring both together at run-time to represent the model. The age template (along with the other templates: gender, income, etc.) appear in a web page select box ready for any authorized employee to incorporate (along with other condition templates) into an AMS rule.

 

Upon selection of a condition from the select box, the web page reveals the selected template’s value holders as standard HTML controls (text boxes, radio buttons, etc.), ready for value input or modification. To add new values to a value holder, simply add the values to the provider and the new values are ready for use in the condition. The same applies for conditions themselves, which are added to the template provider.

 

Changing Rules, Not Reprogramming

Authorized employees can use a web browser to modify the conditions that make up their AMS definitions (see Figure 2). They are allowed to combine conditions using their own personalized templates as business logic building blocks. Applications can be developed in languages other than Java since the majority of the non-rules-based processing involves loading data into a skeletal class structure.

Not only can the templates be reused, but also the rules themselves can be reused. The fractal aspect of this approach makes it very powerful, since complex business logic structures can be created using just a few concepts. Once an authorized employee creates a new rule, its value holder is available for selection in the web browser.

 

... for Managers		... for Developers
ROI / Competitive edge		Spend time on high value efforts
Business managers empowered		Reduced maintenance costs
Consistency through multiple touchpoints		Leverage development for additional uses
Individually targeted interactively		Ease of use and change
Customer satisfaction		Ease of deployment

Figure 2: Rules-based AI applications benefit both users (i.e., Managers) and builders (i.e., Developers).

 

Integrating Disparate Applications - A Case Study

With the convergence of platforms and messaging between them comes the promise of the ultimate enterprise solution - everything works together. With an abundance of disparate programming languages and data sources, it is important that business logic be available for reuse by other applications. And now with the advent of wireless hand-held or WAP (Wireless Application Protocol) devices, this adds an entirely new dimension.

 

Consider the case of reworking an existing COBOL Customer Relationship Manager (CRM) application where the business logic resides in two locations:

1. nested within the application itself, and

2. within stored procedures in a DB2 RDBMS format.

To reuse as much of the existing business logic as possible, the client used the web based Graphical User Interface (GUI) discussed above. Connecting to the rules engine from COBOL via the Java Native Interface (JNI) captured approximately 50% of the old business logic. By extracting the remaining rules and entering them in the client’s repository, the system was operational in three days. Essentially, by reusing the existing application, a major part of the development was already completed. They continue to leverage their business logic with the addition of this new rules-enabled application.

 

Business rules provide an enterprise-wide business-logic data source - a great alternative to isolated local applications, or information in stored procedures or, even worse, compiled code. Integrating a child process into a larger parent process is smooth when a large part of the child process’ logic is already in the parent process and business rules are used. The RDBMS is still involved in this solution, but primarily as a data structure and container (storing a Customer, an Account, or a Representative). This is much easier than concealing the actions on the data in stored procedures which are difficult to use and only updateable by Database Administrators (DBAs).  

 

XML - A Common Source of Class and Data Structures

Having a common source of business logic simplifies automation integration by sharing logic among applications and even between companies. XML driven class or data structure that standardizes an object hierarchy (such as a manufacturing process) and a naming convention for properties of those objects within the hierarchy is valuable.

 

RosettaNet (www.rosettanet.org) and BizTalk (www.biztalk.org) are leaders in abstracting business object and process detail into XML Document Type Definitions (DTDs) and schemas. These organizations are valuable resources when designing class and data structures for businesses. Most customers share certain common characteristics (name, address, telephone number, etc.), independent of the business type. These proper-ties should be represented using common naming conventions and data types (where possible), regardless of the programming language. Standardizing not only speeds up any subsequent reengineering, but also decreases the headaches of integrating child processes. 

 

Disparate Object Models and Data Sources

In an ideal company, every application uses the same class hierarchy, programming language and data store. There are two ways to handle non-ideal case, disparate object models and data sources, while utilizing the accumulated business logic in the repository. First, each rules application running within the application server is dependent only on the object model imported (Java, COM, database, et al.) at the start. All disparate object platforms are brought into the system and viewed as Java objects at run-time. It is possible to manipulate properties and calling methods in rules on objects that map to objects in the legacy object model. Secondly, since the ASP platform is a 100% Java multi-threaded rules engine it is capable of communicating with a number of local and remote technologies. Therefore, the platform receives messages from Java-based mainframe applications via MQSeries and returns actionable data just as easily as receiving a request from an automated rules process written in another language.

 

With hundreds of different data stores and messaging technologies available, using them collectively to solve a multi-enterprise automation process is a challenge. Web-Methods (www.webmethods.com) created a series of enterprise adapters (see Figure 3) enabling enterprise solutions with encapsulated business logic accessible from disparate platforms using disparate data stores and messaging. These enterprise adapters act as translators between heterogeneous sources, translating the data into a format acceptable by the automating application, largely via XML. The adapters are available for over fifty of the most popular data store and messaging technologies including Oracle, SAP, CORBA and COM. By plugging into the application server, they significantly reduce the amount of time and expense necessary to develop and implement a complete multi-enterprise automation solution.

 

Figure 3: The Salesmation Application Integration Service Provider model connects to most any data source and integrates AI business logic.

 

Conclusion

AI technology is often misunderstood by the business community, the press and even computer power users. They see this technology as too complex or expensive; unattainable without the assistance of advanced programmers.

 

We have shown one method of simplifying AI - allowing the rules owner to modifying the rules in an AI algorithm from a web interface. In this case, the rules for a client were stored in a common repository, in XML format, with a standard document type definition. They are freely accessible by any rules-enabled application within the enterprise and can easily be declared global to become available outside the organization. Using techniques, such as these, to simplify the application of AI will improve its acceptance within the business community.

 

The use of Rules-Based Artificial Intelligence to capture user logic is becoming simpler. Systems can obtain input from non-technical users and capture it in reusable objects accessible to a rules engine. This type of technology could signal the end of costly and time-consuming application integration and the beginning of reusable business logic - fed by existing adapters connecting to offline and online applications in the market. A web-based ASP can benefit from integrating multiple data sources and applications resulting in an e-business environment that supports growing revenues and higher profit margins than its competitors.

# # #