When candidate reusable business logic has been rationalized to a subset of distinct, single occurrences of each service, it is then possible to determine whether each should become a component operation or a business rule.
IDENTIFYING BUSINESS RULES
As each reusable set of business logic is reviewed, there are alternative ways to determine business rule logic. In general, business rules capture an organization’s policies, practices, and procedures. A business rule is a statement that describes how a business is organized, how a business decision is made, or how a business process works. Most business rules associate a condition to an action and naturally take the form of an “if ... then ...” statement. Business rules are typically used to solve various types of business problems, including: selection, assessment/scoring/prediction, classification, business threshold monitoring, configuration verification, diagnostic and prescription actions, or recommendation of a course of action based on synthesis of facts.
The significance of specifying whether the reusable logic will become a business rule or a component service is most important when a business rule’s tool will be used to manage the business rules, outside of the standard application’s space. In this case, business users can manage the rules themselves, and changes do not have to be scheduled through the application development area. However, these rationalized services can be reported to business users for them to work on in parallel with the creation of reusable component services.
The consequence of not utilizing a formalized business rules engine where appropriate is the loss of rapid reaction to changes in business policies and procedures that can be provided by their independent, user-managed control. The reliance on software enhancement/ backlog rankings and programmer scheduling can slow reaction time for the implementation of competitive and/or mandated requirements.
Once the candidate business rules have been isolated from the total candidate, reusable business logic set, the remaining candidates are extracted and associated with the appropriate component. Each component is responsible for a core set of common data, much like an object that owns its data. A key difference between a component and an object in object-oriented programming is that components are more loosely coupled with their data. In fact, any implementation that accomplishes what is promised by the component interface specification is a valid offering.
Extracted component services must include everything required for compiling fully executable code. When compiled, these component services become immediately reusable by the original programs that contained the source code and by new applications.
Whether the new reusable business logic is classified as a business rule, or as a component service, it is now future-proofed from rapidly changing technologies. The core business logic has been modernized as clean, well-structured, independent, non-redundant business logic that can be accessed by existing or new applications.
If we had not followed stage one and the steps of stage two correctly, we would potentially have had future modernization challenges. We would also not have gained the total return on investment for the work done. The major benefits continue to accrue once restructuring has been done correctly.