ENNIS JOHNSTON WAS BROUGHT IN TO Norwest Financial Inc. three years ago to evaluate the bank's systems. His conclusion: "As our businesses were changing dynamically as every day passed, it was more and more difficult to keep the legacy system in sync with the business's needs. It was clear we were going to get to a point where [the legacy system] just wouldn't suffice."
Johnston, a senior vice president at Norwest (now a subsidiary of Wells Fargo & Co.), considered reengineering the core systems, but that, he said, would just put a shiny new front end on a tired old engine. Instead he decided to construct a system from the ground up！one that would deliver 100 percent of the functionality in the existing system and would be fully responsive to the myriad demands of the future. After much research, Johnston decided on a system that relied on the definition, capture and storage of business rules.
What are business rules? No mystery. They are nothing more than the statements that define or constrain every aspect of a business！that assert what its structure is or delineate its behavior in specific situations. For example, it would be the rare business that didn't have a rule that said that every customer should have an account number. Some businesses may have a rule that says that the record of a purchase order may not be entered if a customer's credit rating is not adequate. Logic dictates that that rule would generate another: Customers whose purchases exceed a certain dollar amount must undergo a credit check.
Thomas Yanchek, a business rules specialist who bears the title of application architect at Atlanta-based United Parcel Service of America Inc., calls these obvious and not-so-obvious rules the "Ten Thousand Commandments" of your business.
In the modern enterprise, thousands of policies and procedures guide how a business functions！how the books are kept, what discounts are given to which customers, when commissions are posted to salespeople's accounts, even when vacation time can be used. Of course these thousands of policies and procedures can't be stored in the CEO's head. And a loose-leaf manual containing all of them might be good for stopping a door but not much else.
In fact in most enterprises rules aren't formally identified or stored at all. Instead, though company executives rely on them daily, they exist only in the application code that runs the business processes. Thus the people most intimately involved in shaping how a business runs today are not the business units' policy-level executives but rather the IS staffers who convert business requirements into those millions of lines of code.
From this disconnect！between the company executives who shape the business and the IS staffers who actually create the applications that reflect the rules！flow a number of problems and, proponents of a Business Rules methodology argue, an even greater number of opportunities. The new Business Rules approach is intended to reconnect businesses to their rules by identifying them and making them explicit. And, in so doing, to align IS with the rest of the enterprise, thereby creating efficiencies in all business processes.
Say, for example, a company without explicit business rules decides that in order to run a store on the Internet it needs to change from $10,000 to $5,000 the trigger point for the credit check in its automated order-entry system. To do so, a software engineer or programmer would first have to locate the routine within the code！a process that could take days, depending on the complexity of the application and the adequacy of the documentation. Then he'd have to rewrite the code to change all instances of the $10,000 reference to $5,000.
If, however, that rule had been previously identified and documented, the programmer could skip the hunt through the code and！without passing Go and without paying $200 million！move directly to the relevant sections and change the $10,000 references.
And, most tantalizingly, if the rule had been stored in a Business Rules management repository, the routine might not need to be touched by a programmer at all. Anyone could find and change the rule.
And that means your IS people will have been transformed into business people.
The Business Rules-based consumer financial services system that Norwest's Johnston eventually created was named Sapphire. He says it provides comprehensive support for originating, funding, servicing and collecting accounts as well as providing for extensive reporting. It uses Mountain View, Calif.-based Neuron Data Inc.'s Elements Expert, a rules-based application development environment, to store and manage the business logic.
Using the Neuron Data tool allows Norwest a degree of configurability it never had, Johnston says. "Before, making the most elementary change of a moderately complex business rule！when, for example, a finance rate calculation needs to be modified because of a policy change！could take from 100 to 350 analyst hours. Using the business rules engine, the same effort is reduced to literally minutes."
BURIED RULES Whether a business's Rules are in Cobol or C++, they're likely to have varied histories, says UPS's Yanchek. Some originated in response to forces outside the company！such as to ensure compliance with environmental rules or government wage and hour regulations. Others define the specifics of how a particular company does business. "Those business rules," Yanchek adds, "come about from marketing strategies or best practices or business policies or standards or directives." A UPS rule, for example, is its requirement that in order to ship a package it must have two addresses, for both pickup and delivery, and it must know whether the shipment is hazardous.
"If I was sitting across from someone and talking about the business and its rules," Yanchek says, "I would extract three Business Rules right there": a package must have a destination address, it must have an originating address, and the shipper may need to disclose the contents of the package.
But most rules are neither obvious nor accessible. "Rules are buried," says Barbara von Halle, an acknowledged guru of Business Rules. The founder of Knowledge Partners Inc., a consultancy based in Mendham, N.J., von Halle is playing a role in publicizing this new approach not unlike that played by Michael Hammer more than five years ago in the then-new area of business-process reengineering. Von Halle explains that when the rules developed over time are hidden from view inside various application processes, they cannot easily be examined to ensure that business operations are internally consistent and, more important, that they match the enterprise's current goals. And rules buried in procedural code cannot be changed quickly！a real problem when the rapid realignment of a product or service is the key to continued competitiveness.
USING THE RULES The Holy Grail of the Business Rules approach is to have a company's rules codified and stored in a way that allows them to be managed without IS intervention. A company's business units would be able to modify the rules quickly, and the IT staff would be freed up for other projects.
It hasn't happened yet, but some companies are giving it a shot. Blue Cross and Blue Shield of North Carolina, headquartered in Chapel Hill, for example, partnered with Platinum Technology Inc. to develop a rules-based automated underwriting system that it rolled out in September 1997 after only a six-month development cycle.
The system, Amus (automated medical underwriting system), developed using Platinum's Aion rules-based and object-oriented development tool, evaluates applicant eligibility and medical risk by automatically applying underwriting rules rather than relying on an underwriter's evaluation of the application. According to John Friesen, vice president of actuarial and underwriting services at BCBSNC, building Amus involved converting the underwriting logic that usually resides in the medically trained underwriter's head into stored rules logic. In operation, the system follows the rules to assign debits in response to the codes representing the applicant's condition; those debits translate into a rate.
Friesen reports that Amus now handles more than 80 percent of new applications, cutting average processing time from days to minutes. With the new system in place, eight underwriter positions were eliminated！five totally, and three replaced with underwriting processors. And since the underwriting rules are now explicitly stated in English and stored separately, the company is training three staffers to change the rules when necessary！eliminating the need to call on IS.
"Humans come up with variant responses, but machines come up with the same answer every time, and it's right," says Friesen. Because of that predictability, the real payback on the new underwriting system, he notes, was that by reducing its error rate the company saved about 1 percent of its premium revenues！a sum that he says runs well into the millions of dollars.
Another, smaller operation that chose a Rules-based technology was PrimeOne Tele-TV, a San Ramon, Calif.-based provider of line-of-sight wireless digital television service. Terison Gregory, PrimeOne's director of decision support applications, was looking for a way to quickly develop a call center application that would allow customer service representatives to determine service availability based on the details of a caller's location. The solution he found was Vision Software Tools Inc.'s Jade package, which includes a Rules repository, a business logic server and a Rules-based application development tool, Developer Studio, which he reports allowed him to implement his call center within three months.
"We have had some changes to the core business rules that determine how we service the customer," says Gregory. "For example, how changing the power on our transmitter might affect different zones, or offering customers the option of paying bills in person and so having to determine the closest payment location to a given address." By having the rules explicit, "We've been able to effectively implement those [changes] with very little time to make them happen."
Gregory adds that moving to the new application has helped his budget. His shop now requires the equivalent of only one employee to maintain it. The skills Gregory needs now are more in the area of business analysis rather than programming. Once the details of the project needs are clear, he says, the tool will generate the executable. But Gregory notes that this small development team remains on the IT side of the line. "With the new tool, it's definitely less than it was, but we're not ready for end-user maintenance yet," he says.
THE RULES PAYOFF Some Business Rule theorists argue that a company ought to unearth its rules enterprisewide！a project somewhat like the one underway at Basking Ridge, N.J.-based AT&T Consumer Markets Division, whose directors meet regularly to clarify and codify business rules. But given the likely cost and the newness of this approach, few companies are likely to allocate resources for such an effort without compelling evidence from within their companies, or at least their industries, that the bottom line will benefit.
As a result, most Business Rules practitioners today espouse a project-oriented approach. "You need to look for practical results！something that will benefit the enterprise," says Marvin Brander, a senior member of the division's technical staff. AT&T's drivers, as Brander describes them, involve a search for greater efficiency in carrying out projects by bringing both business unit and IT personnel into a redefined and restructured requirements process.
Brander says AT&T has already realized some direct benefits early in its involvement with Business Rules by being able to consolidate business processes and retire one marketing segment's decision-support system. But what strikes Brander most strongly at this point is the way in which this approach has generated a shared clarity about business processes.
SELLING THE RULES Gladys Lam and Ronald Ross, principals at Houston-based Business Rule Solutions Inc., suggest that Business Rules will proceed along two parallel fronts: The front-end approach of using the requirements process to identify or define Business Rules, and the development of increasingly sophisticated business rules engines and other tools to store and manage the rules so harvested.
The state of the art in Business Rules technology today is the rules-based application development environment. USoft, located in Naarden, Netherlands, describes its Developer as a set of tools that gives users the ability to define, capture and store business rules in a single repository, with no further programming required to process those rules or call them for use. Once the rules are captured, Developer generates applications customized to the business function as needed. Greensboro, N.C.-based Burlington Klopman Fabrics, for example, used Developer to re-architect large portions of its IT infrastructure by extracting rules, validating them, storing them centrally and then generating applications far more quickly than had been possible under its legacy architecture.
Vendors acknowledge there is work yet to be done in growing both the tools and the marketplace to support a corporate Business Rules approach. Eric Kintzer, vice president and chief technology officer at Neuron Data, says, "We have customers who occasionally say, 'We need a massive enterprisewide rules repository.' Conceptually that makes sense, but practically, no one can afford that right now."
Today's business rules tools marketplace awaits two key developmental marking points: the entry of a major vendor that will validate the Business Rules approach by incorporating rules tools into application development or enterprise management suites and the squashing of the budget-devouring millennium bug.
A USER'S PLEA FOR RULES UPS's Yanchek acknowledges that incorporating business rules into project development can increase the cost of the requirements portion of the process. But he argues that what's actually involved is moving costs laterally.
"Capturing rules has been done all the time. Years ago we would put the rules in code. In the detail design process we'd say, for example, that the shipping number must be numerical and be valid. Now I have to ask upfront, 'What rules do you have about accounts?' So we've transported some of the time and cost from the detail side to the business requirements process."
At the Numeric Database Technology division of Reuters Information Services (Canada) Ltd. in Toronto, Catherine Lathwell, a senior programmer and analyst in the database development group, argues that a Business Rules approach keeps a company's development efforts efficient by ensuring that they conform to business objectives. Her unit recently used a Business Rules approach to break a logjam so that it could deliver a large project to market. The unit's part of the project involved linking two large databases on different platforms to allow clients to toggle between applications. Creating a set of rules to describe and guide user behavior clarified for developers what had to be done to complete the project, she says, ending a period of continuous disagreements.
Ultimately, Lathwell would like to have a central repository where Business Rules are stored and managed. For the moment, though, the company is devoting its energy to trying to forge closer connections between what a marketing person wants and the actual choices developers make.
The failure to implement Business Rules, Lathwell says, inevitably carries a cost. That's why the Business Rules approach has support from Reuters management. "Our main purpose is to focus development on the business. We think Business Rules will do that," says Lathwell. "Developers have to say, 'I'm making this tactical change because it's associated with this business objective.' That's so simple, but it doesn't happen. By the time something is on the developer's desk, he or she doesn't have a clue what the business case is. Our goal is to tie the two closer together！to make sure the priority calls are right, make sure the development that is happening has a business reason.
|
