companies do business, changing processes and practices at the
same time.
These changing business rules must be clearly defined into systems so that they can be easily understood and changed as the business changes. There are two challenges to achieving this goal. First, you have to keep the capability to quickly access existing rules to insure that they are still relevant. Second, you must allow the professionals responsible for business planning to be able to incorporate their thinking into systems easily.
The problem is that we still use 3GL and 4GL development tools as the starting point for creating the complex logic that drives applications. The resulting code often ends up being more technology-focused than business-focused. A basic database application, for example, requires the developer to think in terms of querying database tables, executing joins, and manipulating database input and display fields instead of concentrating on business-related concepts, such as checking a customer's credit limit. Clearly, thinking in these terms h
as very little if any relationship to the actual business process the application is being designed to address.
A new breed of development tools promises some relief. These tools often aim to go directly from business rules to code. Unfortunately, they still have a way to go before you can put them directly into the hands of the business people.
What Are Business Rules?
A business rule is a simple statement that governs the validation, computation, and presentation of data. Developers using a business rules approach design applications by creating a concise set of business-oriented rules that defines the business process and operating constraints of the organization. Business rules can be a good solution for separating and centralizing the data handling or logic specific to an application.
The business rules approach has the potential to be very valuable in environments of rapid change. Changes in business operations need only be reflected in the business rules, not thro
ughout the entire application. Unlike procedural coding, an application developed using business rules will not necessarily need to be modified to accommodate changes to the underlying data structure.
Of course, easily making changes to an application requires that the business rules that form the application's foundation are logically separated from the application data and functionality. At the same time, these rules must be easy to access. The most common approach is to store the rules in a rules engine. This engine is the access layer through which developers and business professionals can view, modify, and manage the rules that govern their business processes and the applications that support them. As business rules and users' corresponding requirements change (and they always do), developers can simply change the business rules that form the basis for the application. The current alternative is to search for rules buried in stored procedures and database triggers within SQL statements.
There
are two main ways to look at business rules. First is the data-centric approach, where business rules define the way that applications interact with data. The other is the business-centric approach, where business rules define the business policies and logic associated with an application.
The data-centric approach to implementing business rules is by far the most common today. This is the reason business rules are most often implemented as triggers and stored procedures within the database. For example, a standard business rule tied to a customer name field might require that before a customer is added, the customer information must also include a valid phone number. Any time a new customer is added to the database, this business rule is triggered and validates the data.
The data-centric approach can be implemented in one of four main ways:
Database-driven:
Business rules are stored as procedures or triggers in a SQL database. This approach is highly focused on spec
ific data fields or tables. Any development tool that can interface to stored procedures or triggers (but not necessarily create or manage them) could potentially be called a business rules development tool. Using this definition, products like Oracle's Developer/2000 or Powersoft's PowerBuilder could be business rules-based products.
Database-independent:
Business rules are stored procedures or triggers in a database, but they are generated and managed by the development tool. This approach effectively moves the creation and management of data-centered business rules up one level to an application development tool rather than a database-specific tool. A good example of this type of product is Vision Software's
VisionBuilder
, which automatically generates the appropriate stored procedures and triggers that reside in the target database.
Client-based:
Business rules can also be encapsulated at the client, although few vendors mar
ket this as a differentiator. In this case, the logic associated with database interactions is coded into the client side of an application, and stored procedures or triggers would not generally be used. Most two-tier client/server tools take this approach. However, typically in these situations, the data and the business logic are wrapped up into the application logic, leaving no clean separation between the two.
Server-based:
Some second-generation development tools have used this definition when talking about business rules. In this scenario, business rules created in a development tool become middle-tier application services that reside on an application server. Client-side applications invoke objects, methods, or functions on the server that contains business rules. Thus the main application and data-related logic reside on the application server and not the database itself. Examples of products associated with this type of approach include Forte's Advanced Application Devel
opment Environment and USoft's Developer.
The business-centric approach is usually implemented in a logic-oriented way. Instead of specifying constraints on specific data elements or tables, a logic-oriented approach captures the higher-level business logic and rules associated with different situations. At run time these rules are then used to generate appropriate responses and actions for specific situations. This approach is a business-oriented application of expert systems technology. Neuron Data's Elements Environment is the embodiment of this type of business rules approach.
Where IT Fits In
All organizations are facing stiffer competition and time-to-market pressures. Increased investment in information technology is one of the most popular methods for dealing with these pressures. Most organizations have come to realize that IT advantages can easily translate into business advantages like improved productivity, communication, and efficiency. Business applications are there
fore more often being looked at by the business people they are designed for. So what's the problem?
If the IT department is to be a critical part of the business management team, the business practices and processes at the heart of the organization must also be the core of its applications and systems. These processes are therefore being coded into the applications during development. Then what? Are you as a business manager comfortable running your operation on autopilot? How do you know what business constraints and policies form the heart of your applications? More important, how do you know the ones being used are still valid?
A business rules approach is a good way to foster a more business-focused mentality within the application development life cycle rather than an adherence to strictly data-driven concepts. Applications, the theory goes, can be developed around the basic needs of an organization, not the constraints of the methodology being used. While this theory is definitely valid in
many circumstances, there are two other values to business rules. First, they increase the ease with which users can specify and later modify their business requirements to developers. Second, they give developers the ability to make changes to an application as these business requirements change.
Companies should consider a business rules approach to application development for projects in which business logic plays a key role -- for example, when multiple applications need to access common data or when continued application changes will be driven by changes in the underlying data. It is also appropriate for organizations involved in a data warehousing or business process reengineering effort. Basically, rules are most valuable anywhere there is a high demand for a proper understanding and exploitation of corporate data.
No Rules
While a business rules approach can be used in a variety of situations, it may not be applicable to all development needs. For example, decision suppo
rt applications and executive information systems would not be ideal candidates since they are not ordinarily update-intensive. In addition, organizations that are comfortable building desktop-oriented applications in rapid application development (RAD) environments such as Visual Basic or PowerBuilder, or that have experience developing small applications using low-end tools like Access, may find it easier to continue creating small applications using these tools.
A business rules approach is very difficult (but perhaps extremely beneficial) when an organization has a poorly defined business process. A rules-based approach provides a methodology for describing business processes in an unambiguous form so they can be automated. While all organizations theoretically have a set of business rules that define their business processes, a great many do not have any formalized understanding or representative model for this process. Defining effective business rules when the business process itself is vague cou
ld prove impossible.
Another possible negative consequence for a development team working with a poorly defined business process is losing focus and turning application development using business rules into a business process reengineering effort. A business rules approach is descriptive and focuses on the automation of specific business practices currently in place. Business process reengineering is prescriptive and analyzes whether a company's overall business operations are correct. This distinction is very important and must be clear to both the developers and the business professionals involved in a development effort.
Rules as Components
Competition and time-to-market pressures are not going to ease up any time soon. In addition, the Internet has fundamentally changed the application development process by greatly simplifying application deployment and opening up development to more people such as Webmasters. As a result, development cycles are getting shorter, and managin
g change within applications is more critical than ever.
Component-based development is becoming increasingly popular as a way not only to create flexible, mission-critical applications but also to increase the productivity of the development process through code reuse. Business rules will make up only one type of component. Other components will be made up of application functionality, data, or resources that are encapsulated. However, from an overall operations perspective, business rules components could end up being your most important asset.
The rise of the Internet and the Hyper-Tier computing model means greater access by more people to more data from more sources. To remain competitive, firms must increasingly look to enabling unified access to data and applications from many disparate and formerly unconnected sources. This means developers must focus on flexible, scalable applications with a large amount of distributed processing. At the same time, organizations need to be more aware of p
roviding consistent definitions of elements and greatly increased use of metadata.
The beauty of using business rules is that business professionals can write the rules that govern their business processes in the natural language they are comfortable with. Developers then build the application around these rules while retaining the actual rules as the application's foundation. In effect, the rules are the common language between developers and the business community. The alternative is for users to define their requirements and then pray that the developer clearly understands them and, more important, accurately creates the application around them. Without business rules, there is no clear, traceable, and bidirectional path from requirements to code.
Unfortunately, we are still not close to defining business rules to the level of abstraction that would really make this scenario possible. The application modeling and development tools that currently support business rules do not provide an intuitiv
e path from defining rules in plain English to generating application code. Once business rules are articulated by users, developers must still define these rules within the application. The benefits of business rules disappear if they are not easily understood by IS professionals and the business community. The widespread use of business rules within application development will occur only when tools increase the level of abstraction for defining rules and have improved support for the translation of rules into code.
Where to Find
Compendium Research
Boston, MA
Phone: 617-720-2936
Internet:
http://www.compendium-research.com
Play By The Rules
