Living The Transaction

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

Your business depends on software. So if your company is going to keep up with the pace of change, you must capture operational business policies and practices in flexible automated systems. Companies will increasingly need to automate the development of the business logic and processes that power e-business.

A highly competitive business environment puts a premium on change. Today, if your company deploys applications, you need to support iterative development because early in a project, a complete understanding of all your project requirements is rare; requirements are likely to continue changing even after deployment. Those building e-marketplaces or exchanges are in a race to claim "first to market" status. But the race doesn't end at the finish line. Companies in the running can transform the threat of competition into strategic market advantage if they can make successive changes to their Web operations faster than their competitors.

Yet2.com, an intellectual property exchange, found that taking an established business online entailed much more change management than it had anticipated. As detailed in the sidebar, "Intellectual Inventory," Yet2.com discovered that automating business logic allowed the company to get to market quickly and handle the amount of change its customer base required.

"At the simplest level, the e-business craze is all about giving consumers exactly what they want, when they want it, and at the price they want it," observed Jon Ekoniak and Timothy Klein, senior research analysts at U.S. Bancorp Piper Jaffray in the The B2B Analyst Newsletter. Rules-based automation, which affords companies a high degree of responsiveness in a dynamic demand environment, presents tremendous advantages to you when you are ready to optimize the value of customization for customers and partners.

In what follows, I first identify the e-business value of transaction automation, then I summarize the stages of building a rules-based system from developing an object model to making changes, and I outline the benefits of an automated system over conventional methods at each step. I also offer a brief case study illustrating how Yet2.com deployed its Web site quickly and made ongoing changes efficiently.

Managing Change Intelligently

Businesses first used Web sites for transactions such as ordering, fulfillment, payment, customer service, and supply-chain management. Now companies want to manage a growing number of operations and business processes on the Web, and, where possible, adapt them to the integration challenges and rigorous change requirements of e-business.

But whether your company plans to implement an online asset management system, broker relationships with buyers and sellers, or create online customer self-service, moving business processes online creates special demands for new, Web-based applications to handle transactions currently consuming people, time, and system resources. Most of all, companies like yours need the agility to deploy critical transaction-based Web applications in record time, and the flexibility and speed to make ongoing changes as fast as business opportunities arise.

Your company must be ready for constant change because as e-business rapidly evolves to include new partnerships and customers, the network of interrelated roles swiftly changes. Your e-business applications must be flexible enough to support this constant change without delay and with minimal error. Equally important, systems deploying new Web applications must integrate existing business processes.

To meet the change requirements unique to e-business, your must automate your transactions and business processes. One solution is to automate business logic and processes so that you need only specify the set of business rules governing various transactions and interaction processes. Then you can let rules-based technology optimize, sequence, and execute the business logic. Thus the rules are now extracted from the system-level coding layer, making change far easier and faster.

Automated Business Rules

The ubiquity of business rules, and their centrality in executing business strategy and policy, makes them an ideal point of entry for automation-based efficiencies. Virtually all businesses specify business rules, whether as policies, procedures, or in corporate data models. A business rule dictates how the organization executes business decisions, processes, and constraints essential to the company's strategy.

Many types of business rules exist. For example, a business rule might specify the constraints under which a preferred customer receives a discount such as, "Gold customers receive a 15 percent discount on all merchandise and free shipping within the continental United States." Or a business rule might define attributes that must be validated, such as "Dealers in Europe must be only from France and Germany." A business rule might express process-driven events, including notification procedures such as, "On orders that exceed $300,000, notify the sales manager."

Companies are rising to the challenge of e-business while human resources - particularly highly skilled professionals in Internet technology - have rarely been tighter. The shortage of IT personnel highlights the fact that most businesses would like to restore more control of business decisions to business managers and stem their reliance on Java programmers and other IT support.

Fortunately, this scarcity in human resources happens to coincide with the next level in "a continual raising of the level of abstraction" in computer systems according to Chris Date, an independent researcher specializing in relational databases, in his recent book, What Not How: The Business Rules Approach to Application Development. (See Resources.) While presentation and database aspects of applications have long been automated, aspects of applications that implement business functions have not been automated until now. In most cases, developers still hand-code business rules in an onerous, time-consuming, and error-prone process. One rule typically represents more than 100 lines of code, and a developer codes 50 lines of code per day.

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.

Rules and Requirements

Business rules, such as those marked in Figure 1, identify functions and their requirements, and then implement the requirements. In conventional processes, business rules implement business requirements, and programmers input business rules into the programming process. In order to write procedural business logic, you must note, for example, that the customer balance is the sum of the unpaid orders. But - and here is the change - in a rules-based approach, business rules are the implementation. Again, in place of procedural hand-coding, you can state business rules declaratively so long as you specify them in an executable manner.

Rules-based automation does not come at the expense of control. You can use familiar object-oriented techniques to add code to express exceptions that are not automated by rules. Additionally, you can extend the set of rules using object-oriented techniques so that they can be used with multiple applications. For example, you can build reusable graphical objects for use in client applications and guarantee their reuse via archetypes.

Users can provide reusable Java methods that can be referenced as action handlers or as functions in business rule expressions. You can preserve extensions and customizations over iterative changes to the business rules. However, you will reduce the risk of wasted effort if you defer customizations and extensions until you review the basic object model and declarative business rules.

Rapid Iterations Via Rules-Based Automation

Once the data model is basically correct, users next begin tuning the form layouts and adding any customized or event handler logic required - an ongoing, iterative process. While the most obvious effect of rules-based automation is a dramatic reduction in hand-coding, this time-saving result is actually a small part of the complete automation story. Figure 2 illustrates that automation addresses everything from design to maintenance.

In the design phase, a business rules compiler translates business rules into Java components that execute in the logic server. The compiler automates all design functions that normally require a significant amount of time. One of the functions, transaction mapping, is the process of analyzing every transaction and determining which rules to code. Figure 2 shows that the "balance" derivation rule must be processed in a number of transactions (inserting orders, deleting orders, and so forth). Not only is all of this processing time-consuming, it is also highly error-prone.

In addition to automating transactions, business rules also automate key architectural elements of application design. In conventional systems, you must partition logic to the proper tier: client, application server, or DBMS. The business rules compiler automates this task, reducing network and I/O traffic and guaranteeing database integrity.

Because rules are unordered assertions about data, it is the business rules compiler, not the designer, that determines which rules affect which transactions. You can state rules in any order (breaking free of the "tyranny of the von Neumann architecture" as Date notes), and the rules compiler determines the correct, efficient logic order. So, if the derivation of B depends on A, then the Java code to derive A will execute first.

Managing Change

The advantages of automating business rules over coding are easy to see, as are the benefits to testing whereby only rules (specifications), not coding, need testing. But the biggest payoff in automating business rules is maintenance. As Figure 2 indicates, the problem in most maintenance is that you must re-execute major portions of the entire life cycle, from design to testing. With business rules, you simply enter the new specification.

The business rules compilation process re-executes the design automation (transaction mapping, logic ordering, automatic partitioning, and optimizations) and code construction. During the maintenance cycle, the system takes full responsibility for managing the logic, fully preserving any customizations and extensions made manually. In comparison to conventional systems, a rules-based approach supports a real, iterative application life cycle and easily adapts when requirements change.

Staying in Control

The value of business rules-based automation for business logic and related processes is increasingly apparent as more and more businesses migrate critical processes online and engage in e-business. In this competitive, dynamically changing environment, companies cannot afford to delay adjusting business plans or responding to customers and partners.

The challenge facing companies across industries is to restore control of business decisions and strategy to business managers and to shorten the development lifecycle to implement strategic e-business initiatives. Innovative new technology in rules-based automation allows companies to design, build, and maintain complex, transaction-oriented applications largely without hand coding. The net result is a faster, more accurate, and more flexible system ideally suited to the rigorous pace and demands of e-business.

Presley Becerra [pbecerra@advantechs.net] is vice president of Web technologies at Advantechs Programming and Consulting Inc., which specializes in business rules application development.

Resources