For as long as applications have been written, developers have included rules in their code. Initially, rules were simply buried in code. Over time, as relational databases became the norm in development, rules began to be embedded in triggers and stored procedures written in various implementations of SQL. But a subtle change is beginning to happen that will modify how business rules are being viewed with corporations.
Business rules have the potential to shift the focus of the application development process from technical constraints to business requirements by concentrating on business needs at the design stage.
Before you get confused about what this means, let me propose a scenario for how the role of business rules may change in the future. You are the director of a new line of business within the Newco Paper Manufacturing Co. Your task is to present a business plan and then ensure that a system is in place to service your customers for a new line of specialty paper. Now, because there are many other lines of paper, you need to make sure that the pricing of the paper and the incentives for your sales force will not cause problems across the company.
So you sit down with the management team to do your planning. First, you log on to your system and look at the rules sheet. On this sheet you see an overview of all of the business rules that have been programmed into the sales automation system for all lines of business. The rules sheet immediately gives you information about discounts and the situations that trigger different rates; it automatically tells you salespeople's methods and their level of commissions. Of course, you can zoom in on the detailed business rules for any particular business. You remember the old days when it would take months to gather all of this information by having a business analyst interview business managers from all of these areas; inevitably, you would have inadvertently introduced a rule for a new line of business that would conflict with some other area. Now that you understand this global view of your organizational business rules, you can begin designing this new business area without as many conflicts. Opening a fresh business sheet, you begin to write the rules for the new business line. The process reminds you of how in the old days you wrote macros for spreadsheets. When you write a rule for commissions for sales over $1 million, you are presented with a warning message that this rule conflicts with the commission policy for another similar business line. You are asked whether you want to continue or change the policy to avoid a contradiction. You change the commission percentage.
Clearly, rules are not implemented this way in software today, but I believe management should look at the rules governing their organizations so that when this type of software becomes available, their organization will be ready. I am not saying that the situation is completely bleak. Several software companies have introduced development environments, including Texas Instruments' Performer, Vision Software's Vision Builder, and USoft Developer, that focus on business rules. Although there may be other products that let developers create business rules, these three are taking the mantel of business rules as a focal point. (See sidebar, "Business Rules at the Core".)
To understand what organizations need to do in order to begin focusing on business rules, I will provide some guidelines regarding the goal of business rules -- how they can impact organizations, and some implementation issues to consider.
Unfortunately, not all technologies address business value as a central issue. Business rules should be the primary goal of application development, but by themselves they do not necessarily make application development any easier. Until business rules become an integral part of the application development process in an intuitive way, they will not add business value to the entire enterprise.
Products that take a business rules approach have been somewhat successful in shifting the focus of application development away from technology to business needs. However, unlike packaged solutions, business rules have not yet managed to make application development or implementation itself significantly easier. The opportunity -- and the challenge -- for development tool vendors is to take advantage of business rules, not only to shift the focus of design and development from technical constraints to business needs, but also to make the development process easier.
Whither the industry? To meet the needs of the hypothetical business manager I mentioned earlier, application development tool vendors must create a standardized set of business rules that can form the basis for developing applications. This process is similar to the packaged solution vendors' approach of offering standardized applications that vary by industry and/or function. Although this standardized set of rules will not fit the exact specifications of every implementation, the rules can be easily customized as needed. They can then form the basic framework for developing applications. Instead of having to create rules, developers would modify existing rules that have been specifically developed for an industry and/or function. In other words, developers would have a model from which to work.
Software suppliers have clearly shown a willingness to trade some functionality for ease of development and implementation. Although most development tools support the storage and use of business rules, the creation of these rules is still left to the developers and/or business community. This situation must change if business rules are to remain relevant in application development.
If and when vendors succeed in creating this standard business rule framework, they will be turning a weakness into a major advantage. Business rules themselves would become the chief differentiator. Packaged solutions are formed around the basic functionality of a particular industry or department. These solutions, however, have the same weakness as any application not using business rules: Their basic design is centered around technology, not business needs. To satisfy the business needs of the manager that I described in the beginning of this article, vendors must begin to create "packaged" business rules as part of an application framework. By doing this, vendors can combine the ease of implementation of packaged solutions with the business-focused functionality of applications designed around business rules. Business rules will not only remain relevant, they will become a major strength.
| Business Rules at the Core |
|---|
I have recently seen three vendors that have focused their strategies on the importance of business rules. They are:
|