At their most basic level, business rules are the tenets that reside in the management brain trust. In their finished form, business rules can be a line of code such as “Value=Qty*Price*(1- LOOKUP Order Discount)” on a database server, credit-limit guidelines on a server in the sales department, or commission structures housed on the old PDP-11 at corporate headquarters.
Given the complexity of client/server environments, companies can no longer afford to have these rules scattered throughout an organization. One solution: a three-tier architecture that splits the rules apart from the application logic and hands developers more flexibility in managing these new resources.
“When you begin to build systems, it’s key to think of business rules as the building blocks,” said Hugh Ryan, director of new-age architectures for Andersen Consulting Inc., in Chicago.
“They are the asset of the application,” echoed Ted Pock, vice president of development for Dynasty Technologies Inc., the Naperville, Ill., maker of one of the first three-tier architecture-development tools.
Corralling these far-flung business rules into one manageable place –separate from the database server and the application — certainly sounds good on paper. But without a standard business- rules server, the process can be tricky.
With client/server, “it’s a little chaotic — sometimes the users are doing it,” said Richard Finkelstein, president of Performance Computing Inc., a Chicago database consultancy.
Companies developing client/server applications should take a hint from the mainframe model and have a data administrator whose job is to guard the rules, according to Finkelstein.
“This person would understand the business rules, implement them correctly, and then review the code to be sure it’s correct. But because of the proliferation of applications, that’s become less and less practical,” he said.
At the very least, “you need a good place to document all the rules and develop a mechanism to export these rules into applications,” Finkelstein said.
Symantec Corp.’s Enterprise Developer and Uniface Corp.’s Uniface database application-development software take the first steps on this route. Both products have their own repositories that import and export rules and data to a number of third-party development tools.
“Our engineers wanted to be able to share information across projects,” said Brian Vickery, systems analyst at Fluor-Daniel, an engineering/construction firm in Greenville, S.C., which tapped Enterprise Developer to ensure consistency among different internal groups.
Before Enterprise Developer, “changing the coding [for business rules! was not a clear-cut thing — it was easy to revert back,” said Vickery. With the Symantec software, changing the rules is still “bureaucratic, but the change is easily instituted and enforced.”
Splitting up is hard to do
Triggers are one way to store business rules in a database rather than having them reside within an application. One problem with this approach, however, is that triggers affect only one server, so changes must be recoded in every database in which they appear.
Also, it’s often not enough to enforce the logic on the database. For example, consider the rule, “All meals on expense reports that cost over $100 must have supervisor approval.” This requires the system to check whether this condition has been met on the client side, at the point of entry.
“If you did not enforce the rule at the time of entry, you’d let it churn through [to the database] and then it would generate an error message. That’s an incredible inefficiency,” said Ted Schlein, vice president and general manager of client/server technology for Symantec, in Cupertino, Calif.
Unfortunately, enforcing the rule at both the client and the server can lead to a maintenance nightmare.
“You have to find every application and change it there. That means you have unsynchronized logic,” said Finkelstein.
The answer? “Use triggers for the rules that are fundamental to the organization and that will remain consistent — for instance, `No customer should exceed their credit limit,'” Finkelstein said. Other rules should be placed in the application code and managed via the repositories of products such as Uniface and Enterprise Developer, he added.
“As you start deploying business rules on the database server [in the form of triggers], that works until you have a certain number of users, somewhere in the neighborhood of 60 to 70,” said Dynasty’s Pock.
Another option is the handful of tools that currently support a three-tier architecture, including Dynasty, which offers flexible partitioning so users can place business rules wherever it makes the most sense.
“[Three-tier architectures] are the next step. You start to see the application slowing down, or you constantly need to change it because the business rules are always changing and you say, `This is too volatile an environment. Let’s pull it apart,'” said Mark Tebbe, president of Lante Corp., a Chicago systems integrator.
Instead of making global decisions on where to put business rules, companies typically go by trial and error to see what works, said Dynasty user Jim Abramson, manager at Grant Thornton, a Chicago C.P.A. and management-consulting firm. “You have to look at the business process, what kind of response time do you need, and how good is your communications line.”
Given the constant state of flux of most businesses, these requirements will often change.
“The good thing about Dynasty is it allows you to repartition the system dynamically, so it’s not a traumatic thing to regenerate the application if you’ve made the wrong choice [about where to put rules!,” Abramson said.