Designed Application Flexibility Using Business
Rules
Why Application Flexibility?
While this should have been apparent
from the significant failures of many of the so-called ‘Best of Breed’ approaches, resulting in incredible wastage of
resources, both human and monetary, the following excerpts form a very recent
article, ‘ What's Wrong With Application
Software? Business Changes, Software Must Change With The Business’ by Olin
Thompson dated
“ Business changes constantly, in
small ways and large. It is rare to find an application product that can change
once it is implemented. This gap is a reality leading to dissatisfaction and
the application being a drag on the business. This gap, the lack of the ability
to change, costs the business dearly. Software needs to be the agent of change,
not the enemy of change.”
“Successful companies are
increasingly taking on new business models and business processes as an ongoing
way to outmaneuver their competition. These companies have found that there is
an inherent conflict between the fluidity and agility with which they want to
run their businesses and the rigidity and control with which their systems operate.
This incompatibility between agile businesses and static systems has hampered
efforts to change the business effectively and rapidly to capitalize on
business opportunities. Whether a company is aggressive in its adoption of
change or conservative, change is inevitable and ongoing.
A gap exists between the change needed by the business and the ability of the enterprise architecture to accommodate or facilitate those changes. “
The ability to successfully address this gap forms the core of this presentation.
Business Rules Implementation
Business rules provide a formal way of managing and automating an organization’s policies and procedures so that the business behaves and evolves as desired by the management. Generally a business rules system is an automated system in which the rules are separated, logically and physically, from other aspects of the system and shared across data stores, user interfaces, and applications. As long as the person who understands the business defines the rules directly, there are many advantages, including elimination of the serious problems created by miscommunication between analysts and programmers.
The implementation of this concept here is effected through incorporation of the following:
· Simple and yet powerful rule definition capability – the experienced user defines the rules logically in English and this is programmed in directly for implementation
· Unlimited data/functionality access for incorporation into the rules
· Rules remain separated from the application code and thus any sensitive rules (e.g. related to pricing, compensation, commissions, technical quality parameters and others) can remain totally proprietary to the company without causing any problems with application software upgrades
· Practically unlimited customizations and modifications can be carried out and implemented rapidly to support fast changing business environment
· All technology within the Oracle RDBMS and Tools sphere
Technical Design
The basic architecture of the design using Oracle Forms and PL/SQL is shown in Figure 1. The example here pertains to a salesperson commissions application, where there can be almost unlimited variations of the logic to determine the effective incentive for salespersons, depending on diverse factors such as product, customer, region, promotions, environment, marketing strategies.
Rule
identification (10 A/N) key Rule
Maintenance Functionality Short
Rule Description Rule
Type – Additional qualifier(s) for the Rule Latest
Rule Update Date User
Identification of the designer of
the Rule
Figure 1.
The following figures show the rule creation and maintenance capabilities.
The Validate Rule verifies the syntax of the PL/SQL code inserted into the ‘RULE _TEXT’ field.
Figure 2 shows the Setup Parameter feature. This allows the rule designer to set up multiple (unlimited) additional parameters (constants) independently of the Rule, if so required by the business logic for the rule.
Setup Parameter Function Shown
Figure 2.
The Simulate Rule feature – Figure 3 - allows the simulated execution of the rule to determine if the programmed rule logic returns the desired values. Designers of the rule can enter appropriate values for all the related variables (tokens) of the rule to check the correctness of the calculations.
Figure 3.
The Copy Rule feature - Figure 4 - provides the rule designer with the flexibility to reuse a rule by copying the content of one rule to create another rule and then modifying it as required
Figure 4.
Demonstration
The demonstration shows the simulation of diverse commission rules using the described architecture.
The generic application flow diagram is given below in Figure 5. The commissions are calculated at the time of the creation of the invoice to the customer on shipment of the order.
CRM - Salesperson
Accounting
System
Customer
Order
Accounting
System
|
Customer
|
Invoice
Order Information
Salesperson Information
Salesperson
Commissions
Figure 5.
Once the rules have been set up, the salespersons are assigned the appropriate rule(s) as dictated by the marketing strategy and related incentive schemes.
The steps involved in the execution process of the diverse triggers, stored procedures and functions are shown in figure 6.
Code Execution Process Flow
Call Commission_Rule_Package. Simulate_commission
Salesman
Click on
Commission Rule table Simulate button
Pass rule code Display
Return rule text
Call Execute_Rule
Return Commission
get_rule
Rule code return commission
Return Rule Text
Parse_#Rule
If SQL if PLSQL
Next_token returns commission
Execute_sql also
uses DBMS_SQL.FET_ROWS Execute_plsql
uses DBMS_SQL.PARSE DBMS_SQL.EXECUTE
Substitute_variable
Substitute # variables
With Values passes by external entity
When calling the simulate_commission
Get_parameter Commission rule param
Figure 6.
Rules-driven Commission
Figure 7 displays the salesperson’s commission elated
information. Sales commissions are calculated for a salesperson depending on
the commission percentage or using a commission rule.
Figure 7.
If the commission by percentage logic is used, then the commission is calculated using the fixed percentage entered in this field. If the commission by rule logic is used, the commission is calculated using the rule identifier entered in the commission by rule field.
Other extensions and variations to this feature include the splitting of commissions between salespersons when sharing territories, customers and products and providing for sliding scales. The applicable rule may contain more complex logic if needed.
The split commission feature – Figures 8, 9 and 10 - is used to set up the default commission splitting percentages among the multiple salespersons, if applicable.
Salesperson
identifier
Total
Percentage of commission distributed among salespersons
Figure 8.
If the split percentage of commission total is not equal to 100% then a warning is issued – Figure 9.
Figure 9.
Commission
Rate
Figure 10.
Scope of Applicability
The method described in this presentation has wide-ranging applicability. The technique has been applied to major business areas such as pricing, discounting, costing, overhead applications, driver definitions in activity based costing, maintenance data analysis and subsequent triggering of appropriate actions, focused business activity monitoring, quality assurance, testing, order processing optimization for handling very high volumes, dynamic increase in warehouse management efficiency through highly flexible putaway, pick and replenishment strategies, inventory valuation, to name just a few.
The use of PL/SQL enables total access to all data available in the Oracle database, thus allowing virtually limitless scope and flexibility to the rules designer. Particularly advantageous is the significant reduction of compatibility problems between software releases, as the customer specific rules (i.e. business logic) are no longer hard coded into the forms, reports and any custom stored procedures, packages and functions. Since the rules are written in native PL/SQL, all capabilities of the language are available including executing stores packages, procedures, and functions directly from the rules. The capability of business rules generators such as BRIM from Dulcian Inc. thus becomes strongly complimentary as power users can use such tools directly to generate the PL/SQL rules code using the built-in UML components. The bridge to java is thus also available through the well-known Oracle’s and other third party tools for web deployment and PL/SQL to java conversion facilities.
Measured against the requirements
stipulated in the previously referred article from Olin Thompson, this
technique substantially addresses the following (just to use a few examples):
· “The next generation of enterprise architecture must allow for business change to be adopted on an on-demand basis as the business evolves.”
This is what the described method is particularly geared to resolve.
· “Lower the penalties for modifications Today, the penalties for modifying are so high that companies find it difficult to justify all but the most important changes. With the dropping of the cost, time, and quality penalties, it becomes increasingly practical for the system to be responsive to the needs of the business.”
This design architecture allows rapid and substantially lowered cost of implementing minor to major changes as demanded by the changing business environment, thus addressing this very significant issue.
· “Provide flexibility for options not initially conceived by the vendor Companies need best practice, but they also need "our practice" and the ability to respond to the needs of customers and others. If the vendor has not built in the option, the company should be still being able to provide the function required.”
A key element in this approach, as those ‘Best of Breed’ offered by many financially successful vendors have not at all resolved the ‘our practice’ issue, resulting in significantly financially unsuccessful business and ROI issues for the customers.
What Do We Need?
The next generation of enterprise architecture must allow for business change to be adopted on an on-demand basis as the business evolves. As we stated in "What’s Wrong with Application Software? It’s the Economics" enterprise architecture must provide the cost, time and quality characteristics to make change a practical choice for the business.
What are some of the business characteristics required to meet the challenge of change?
Lower the penalties for modifications Today, the penalties for modifying are so high that companies find it difficult to justify all but the most important changes. With the dropping of the cost, time, and quality penalties, it becomes increasingly practical for the system to be responsive to the needs of the business.
Provide flexibility for options not initially conceived by the vendor Companies need best practice, but they also need "our practice" and the ability to respond to the needs of customers and others. If the vendor has not built in the option, the company should be still being able to provide the function required.
Change on demand The change process should be quick and painless. The delay between need and solution should be minimized.
Provide feasible small modifications as well as large Modification projects are often very large, but to be responsive, the system must be economically changed for both small and large requirements.
Controlled change process The change process must be a solid, controlled process with built in management and quality.
Provide the business user visualization and evaluation of potential modifications Assist the business user to understand what the system will look like and how it will operate after the change to avoid surprises, rework and to further user acceptance.
Evaluate and pinpoint the change effort The full impact of any change must be known in advance. This includes the impact on the system and the cost and time required to make the change. This information will increase the management process and avoid surprises
Continually maintain the "as installed" version of the system Any change should be reflected in the "total system" including documentation, user manuals, help text, etc.
Sustainable product enhancements Modifications should be maintainable in the future to evolve with the needs of the business and the advances made by the vendor.
Integrate the acceptance of new vendor releases with modifications New releases from the vendor will come and any modification should be easily re-evaluated and reapplied as applicable at a realistic time, cost, and quality.
___________________________________________