The Living Transaction

Transaction automation can help your business keep pace with quickly changing markets

By Presley Becerra

Continued from Page 1

Intellectual Inventory

Customizing business practices for intellectual property exchange Yet2.com, a privately held company based in Cambridge, Mass., is an international forum where technology officers, scientists, and researchers meet to exchange, license, or sell technologies, patents, and other intellectual properties online. Corporations worldwide have massive inventories of patents that typically go unused, blocked by unwieldy and time-consuming technology transfer processes. Yet2.com's exchange covers all industries and areas of research and development. The founders met in March 1999 to plan an Internet strategy and publishing solution with a launch deadline of December 1999. The founders completed hiring staff by July and started looking for a solution that could customize business practices specifically for the intellectual property exchange. Workflow processes related to approval, for example, needed to be customized so that when an engineer created a technology listing, corporate representatives (including legal) would review it to ensure that the submission met protocols before Yet2.com readied it for publishing on the site. Based on Yet2.com's review of project proposals from a consulting firm, the company began to conclude that the publication, administration, and e-business challenges it faced would get only 50 percent coverage at best. The consultant also estimated a protracted timeline and staffing requirements of 44 onsite developers that exceeded Yet2.com's plans and budget. In September, Yet2.com selected Versata, an e-business transaction automation software and services vendor. The project team of two Versata consultants, two Yet2.com engineers, and two consultants (to customize the publishing solution) finished 307 site pages in 11 weeks. Immediately after Yet2.com went live, the site received far more change requests than originally anticipated. Yet2.com's engineering division handled the requests efficiently because they had automated the business logic when they built the exchange.

Shifting from How to What

According to Date, this next advance in computer systems entails a fundamental and progressive shift from procedural to declarative modalities, or what he calls a leap from "how" to "what." In a procedural mode, a user specifies "How, from step to step, the work is to be done" via hand-coding. In a declarative mode, by contrast, the user instead merely specifies what "the work to be done is." That is, when you have automated business rules, a user can specify applications in declarative, English-like statements. The system then automatically compiles these specifications into executable code, identifies related rules that should also change, and executes the application automatically.

Automating business rules dramatically reduces or even eliminates the need to write, test, and optimize code. Declarative rules can replace hundreds of lines of code. You can achieve an astonishing compression factor when one business rule replaces two pages of code. Additionally, you can extend the productivity value of rules-based automation through the extensive sharing or reuse of standard behaviors across systems and projects.

Because rules are created in relational contexts, rules that are relevant to other applications are automatically applied on relevant updates. As Date puts it, the burden shifts from the user to the system: "The application developer doesn't specify when the rules are to fire, or what events have to occur in order to trigger them .... Rather, we simply say what the rules are, and the system itself - the "rule engine" as it's sometimes called - figures out when they should fire. Productivity!"

What's the Payoff?

E-business transaction automation provides a business with four major advantages:

• Business rules-based systems enable companies to get project requirements right, even though these requirements may change frequently throughout implementation phases, so that the system meets real business needs.
• Rules allow for flexibility to make changes in dynamic e-business environments.
• The use of business rules in e-business applications closes the gap between business users and IT specialists; business managers can contribute more actively to changing the system and respond strategically to new opportunities as they arise.
• Using business rules significantly reduces the time required to develop complex, transaction-oriented applications, and shortens the development lifecycle for implementing changes.

Building A Business Rules-Based System

Getting project requirements right. A well-developed object model will enable users to identify the underlying functions and requirements to automate business rules. Early in a project you may have deadlines and milestones, but you generally don't fully know what all the project requirements will be. As the project proceeds, the design team works with business users and together they discover what the requirements should be. Because a rules-based approach engages business users early in the project cycle, it can help get requirements right from the start. By contrast, precoded documentation doesn't point out the issues. Only by seeing a running system can end users spot issues and understand how the system works. Unfortunately, at that point the system is already built, and it is usually much too late to make changes without affecting the schedule.

Building the model. At the heart of a business rules-based system are object relationships. Early in the development process, you must define these relationships in a preliminary object model. Object relationships provide the basis for referential integrity rules (including sophisticated cascade update and delete rules), as well as for sum, count, and replicate derivation rules.

Your first step is to construct a preliminary object model by reverse engineering it from an existing database, or by importing models from object modeling tools, case tools, JavaBeans, or Java classes. Or, the design team implementing the rules-based system can construct data object definitions interactively. Your users should define object relationships, code values, object names, and presentation rules as early as possible before going on to build serious applications. A well-developed model will enable your business users to build an executable system version quickly.

Changing as you go. A business rules system automates a number of typical object modeling issues that occur in most applications - including many-to-many relationships and object type hierarchies. One of the distinct advantages of a rules-based system is that you can preserve a greater degree of referential integrity as compared to hand-coding, which tends to bunch requirements together in the interest of saving time. Once again, the advantage is faster change management because you can quickly and effectively change the rule governing a requirement without rewriting lines of code.

Once the object model is in place, you should deploy the database and rules enforcement logic as early as possible to confirm the connection and as an aid to debugging. A key benefit of using business rules is to show end users real applications with real data. This way, your business can obtain early design validation, rather than discovering later that screens do not read or write data or perform transactions. By using live applications, a rules-based system can help get requirements right.

Defining processing logic. Once the object model is stable (though it will continue to evolve), you can begin to add the key rules that drive the transaction processing logic: the constraint and derivation rules. The general approach to defining business rules is to select a business function, identify its requirements, and then define one or more rules that implement the requirements.