August, 1997
It isn’t often that I find a product that makes me say "wow." In fact, I've been accused by some of judging products against a standard that none can achieve. So if a product comes close to meeting my expectations and surprises me with capabilities I haven't anticipated, I definitely take notice. The USoft tool suite (www. usoft.com), which provides a business rule-based application-development environment, is such a product. All I can say is that this product is way cool!
For nearly 20 years, I've been involved in developing applications for financial service organizations. I've heard people lament that the business environment is too dynamic-that requirements change faster than we can deliver the applications that support those requirements. Yet I've found that the data and process models I've developed have moved with me from one bank to the next with minimal changes, There appears to be more in common across the financial services industry than not. What really surprised me was that the same set of data and process models worked equally well for telecommunications organizations. A significant portion of information requirements appear to be common across all organizations. A certain underlying structure is necessary simply to be "in business." Yet each company has its own unique needs and requirements that must be configured within that common structure. For example, every financial service organization must allow its customers to withdraw money from their accounts. The data that must be available to accomplish the "withdraw money" business process is identical. All of these organizations must be able to detect when customers attempt to withdraw more money than is available in their accounts. Each organization's reaction to this situation is unique. One bank may react to an "overdraft" state by preventing the transaction from completing. Another bank may decide to honor such withdrawals for its best customers, extending temporary interest-free loans to cover the shortages. Still another bank might cover the withdrawal sum but charge a hefty fine for its act of kindness.
I've developed the following theory: Much of what it takes to be in business is common
across all organizations. This commonality is reflected in what the organization must do
(its processes) and what it must know (its data) in order to operate effectively. An
additional set of processes and data is required to compete within a specific industry.
However, the procedures and business rules that an organization establishes to control its
behavior within these common processes are uniquely its own (see Figure 1). In other
words, the "what I do" is generic (data and processes), but the " how I do
it" is unique (business rules and workflow).
I've been searching for an application-development environment that lets me build
applications based on my common data and process models and can be easily customized to
support the specific behavior of each unique organization. The USoft product line does
this.
The "USoft approach" to developing applications is closely aligned with the three-level architecture:
* Define the data layer in terms of a data model.
* Specify the expected behavior in terms of business rules.
* Develop the workflow in terms of the GUI "look and feel."
I tested this approach by developing a product-evaluation application. I had a Microsoft Access application developed in parallel to the USoft implementation so that I could measure any productivity gains of one approach over the other. The applications were created by developers experienced in each technology. I provided the requirements and performed the testing.
THE DATA LAYER
The same data model used to generate the Access database (see Figure 2) was scanned into the USoft development environment using its Bridge tool. USoft supports a number of data modeling tools, including Logic Works' ERwin, Powersoft's S-Designor (renamed "Power Designer" in the latest release), and Popkin's System Architect.
All the business rules expressed in the data model are automatically implemented in USoft-such as identifiers, cardinality between entities, subtype/supertype relationships, default values, domains, and attribute optionality rules. A default application is generated from this specification. The supported database management systems include Oracle, Informix, Sybase, and Microsoft SQL Server. USoft uses either the DBMS's native middleware or Tuxedo to connect to the server.
USoft generates a default form for each entity in the model that supports the Create, Update, Delete, and Query processes. A single form is generated when the relationship between the parent entity and its dependent entities is mandatory. You navigate the model by selecting from a list of related entities. The product displays a separate window for each selected entity and synchronizes the windows when a new instance is selected in the parent entity's window.
Although it generates a functioning application, the GUI design is rudimentary. The USoft architects claim that this is by design. They want you to focus on the business rules that the application must support without being distracted by its "look and feel." That aspect of the application is addressed in a later step of the USoft approach.
BUSINESS RULES LAYER
According to USoft's David Dozier, who developed my product-evaluation application, rules can first be categorized into business-based rules, which focus on the application logic and are platform independent, and implementation rules, which focus on technology-such as the interface. While other development tools "bury" the business-based rules within the implementation rules, USoft segregates them for easier management and maintenance.
Business-based rules can be further categorized as either structural or declarative. Structural rules (such as allowed values, referential integrity, and relationship cardinality) are inherent to the model itself Declarative rules are too complex to be captured as part of the business model and must be defined separately by the analyst/developer.
Declarative rules can be further classified as definitions (logical views that define a specific "state" of interest), restrictions (which prevent user actions that violate the rule), and corrections (which automatically perform some change to the data based on user actions). These types of business rules are specified through a language that extends the standard SQL syntax. Table 1 provides examples of each type of rule USoft supports, the business rule statement, and the syntax required to support that rule in USoft.
A "Decision" is another type of business rule that USoft supports. The Decision rule consists of a condition and the actions to be taken when the condition is true or false.
One feature I like about USoft is the ability to specify a business rule in terms of another definition business rule. For example, if I'm interested in tracking incomplete evaluations, I can have USoft consider any evaluation whose close date is not set (equal to nulls) to be an incomplete assignment. I can then incorporate that rule into the code of another rule that restricts an evaluator to three incomplete assignments.
Once you enter the rule, you can test it through the prototype. A test of the "Evaluator Technique" rule in the Table 1 example will demonstrate the power of the business rule approach. This rule prevents product evaluations from being assigned to unqualified evaluators. However, the business rule is also invoked if you try to remove a technique from an evaluator and that person is assigned to an evaluation that requires that technique. In the Access application, the programmer must ensure that each process (maintain product evaluation and maintain evaluator) properly supports the business rule.
The USoft developers are quick to emphasize that their SQL-like syntax is too complicated for the average business user. However, an experienced analyst entered and tested the business rules represented in Table 1 in no more than 30 minutes in an iterative fashion. When the application didn't behave as I expected, we analyzed the problem and fixed the business rule immediately. My business rules were analyzed, prototyped, tested, and verified in manageable chunks, which kept me focused on a specific business process. Once I was comfortable that my application was behaving appropriately for that aspect of the business problem, we were ready to move on to the GUI phase of the application design.
WORKFLOW LAYER
Workflow design involves customizing forms and menus to provide the
desired interface. USoft supports all ActiveX controls. It easily supports look-ups to
parent entities through drop-down boxes. Subforms for dependent entities can be embedded
into the form of the parent entity. It took approximately 15 minutes to develop the
Product Evaluation form shown in Figure 3, which lists the person assigned to individual
evaluations for each product release. Selecting the Techniques tab displays the list of
techniques supported by that product release. Selecting the Evaluator References button
displays the Evaluator form. New evaluators can be created and assigned to the selected
product evaluation.
At first glance, developing GUIs in USoft is not very different from designing the Access application. Both use property windows to customize the behavior of each GUI object. However, USoft has some unique features that give it an edge over the traditional GUI-development environments I've used. USoft provides an inheritance hierarchy that lets you specify the behavior of objects at the higher level that objects depicted at the lower level inherit. For example, the buttons displayed on the Product Evaluation form were defined at the top level of the inheritance tree. The check-mark button commits any changes and closes the form; the "X" button closes the form without committing changes. All the behavior associated with these actions is specified once, including the positioning of the buttons relative to one another on the form. When a new form is created, these buttons automatically appear. You can modify their behavior at the local level.
It is also possible to attach display behavior at the column level. For example, I wanted to be alerted when a product has an associated incomplete evaluation. My USoft developer specified a display rule attached to the Product Name column, which caused it to be displayed in red whenever an incomplete evaluation was detected.
One of USofts outstanding features is its ability to perform impact analysis, which displays the list of constraints in which a given column participates.
With Teamwork, a companion product, you can link the business objects used to specify the requirements for the application to the business rules represented in the application. While my USoft developer apologized that the product could not generate the business rule syntax used by the application from the English descriptions held in Teamwork, I was pleased with anything that could be used to support the traceability from requirements to design.
USoft does not provide any report writing facilities. Any business reports your user community requires must be developed with other products (OLAP products or report writers).
Overall, USofts approach to developing applications closely mirrors my own. The product evaluation application was developed much faster than its Access counterpart and expressed more business rules.
The newest component of the USoft suite-Web Ruler-is scheduled for release in fall 1997. It will generate either standard GUI applications or Internet Java applications based on the same business rules engine and is geared toward business analysts.
If you're interested in incorporating a business rule approach to application development into your organization, be sure to check out this product.
Terry Moriarty, president of Inastrol, a San Francisco-based information management consultancy, specializes in customer relationship information and metadata management. Her common business models have been used as the basis of customer models for companies within the financial services, telecommunication, software/hardware technology manufacturing, and retail consumer product industries. You can reach her at terry@inastrol.com.