ABSTRACT
Business Rules are defined to drive and control various aspects of an enterprise. As well-codified rules can effectively influence successful behavior of an enterprise, so too can effective methodology guiding rules – pockets of knowledge – be defined to influence successful execution of a BRMS-aided legacy modernization initiative. This whitepaper lists top eight of such key guiding rules for a successful and cost-effective BRMS implementation.
INTRODUCTION
In practice, there is multitude of guiding rules driving a BRMS initiative. As the saying goes, “there are two great rules of life; never tell everything at once”, this whitepaper pays attention to top eight of such key rules.
Business rules are codified policies guiding and driving business decisions. Usually, these rules are hard-coded within the legacy applications. As the business needs change, these deeply buried rules need to be updated as well. However, these applications are built by developers with skills honed over long years of business growth, and many of the original developers might not even be accessible anymore.
For the current team to be effective in maintaining such applications, it needs to be equipped with the insight of application structure, semantics of the code, and the interconnections of the modules. In reality, many teams don’t fare well always in their efforts to update the legacy systems to incorporate changes needed. But even assuming that a team completely comprehends the changes and successfully finishes the work at hand, it is then typically confronted with the elaborate activities of promoting the code-base to production systems, which are non-trivial at best.
The point is, irrespective of the magnitude and scope of the proposed change, there is a heavy dependency on the IT team by the business stakeholders to implement recurring operational changes and to maintain business agility.
BRMS SOLUTION
Business Rules Management System (BRMS) provide an answer to this challenge. BRMS makes it possible to externalize the business rules onto a separate system that can be managed outside the province of the business applications. These systems have utilities and user-friendly medium to enable business users to author and update rules to reflect the changing business requirements
Methodology
A brief introduction to a methodology for BRMS development, depicted in the below illustration, would provide the contextual backdrop to better understand the proposed eight rules. As the graphic suggests, BRMS methodology is an iterative process. At a broad level, the methodology consists of two parts: ‘Rules Definition’ part and ‘Rules Development’ part. ‘Rules Definition’ part aims to arrive at a clean set of codified rules covering Planning, Discovery, and Analysis phases; and ‘Rules Development’ part takes those rules-set to create executable versions on a BRMS system by performing the Design, Authoring and Validation phases. Two relatively non-cyclical phases are the Vision and Integration phases. Vision phase provides the overall objectives and goals for capturing and managing business rules; and Integration phase is executed as needed when the validated and deployed rules need to be consumed by business applications.
8 RULES TO FOLLOW
Rule 1: Nothing is more difficult than to take lead in introduction of new order of things
Externalizing and implementing business rules impacts the operational model of an enterprise in that it alters the way business makes operationally significant decisions. Therefore, be mindfully aware to engage the senior management, in a timely manner, to provide the necessary oversight and make critical resources available to ensure the success of the project. The importance of this rule is hard to overstate.
Rule 2: No Enterprise Initiative is an Island
No enterprise initiative can be a completely independent exercise disconnected with other initiatives. This is especially true for Business Rules implementation. Responding to business drivers such as time-to-market, business-agility, customer service, and product innovation, an organization is likely to undertake several enterprise initiatives related to process optimization, legacy modernization, application integration, and data management. Business Rules implementation would be one such piece of the overall puzzle. Understanding the dependencies between these initiatives in terms of resources, timelines, stakeholder objectives, and short- and long-term imperatives can prove to be invaluable during Business Rules implementation planning and prioritization.
Rule 3: Context is Power
While new applications being developed can make use of BRMS systems, more often than not, enterprises need BRMS to support modernization of their legacy systems. If progressively updating application logic with minimal business context is hard, holistically unearthing business rules peppered across many applications can be a lot harder. Its one thing to understand the syntax of the code, entirely another to understand the semantics and any implied meanings. One needs to be keenly aware of the business domain knowledge. It is this context that can help in prioritization, rules jurisdiction and impact analysis.
One way to acquiring this business domain knowledge is taking a top-down analysis approach. There is no better tool than associated process definitions to understand decision points. Starting with the overall business vision, mission and value chains, proceed to arrive at the first or second level of process decomposition. As required, conduct workshops and interviews to gather and validated all the decision points. These decision points reflect as business rules in the application.
Rule 4: Ask yourself: Is Pineapple a pine or an apple?
Remember the answer is it’s neither; pineapple got in its name pine for its shape, and apple for its delectable taste. Sounding out and guessing the meanings of the terminology used in unfamiliar applications and domains can be equally misleading. It cannot be overstated on the importance of getting right business vocabulary comprising business terms or noun concepts and fact types. Many a times, the naming convention employed would not be entirely intuitive or consistent. For instance, within a manufacturing company, a part number could assume multiple names across various divisions (warranty, customer service, sales). Further within particular a naming convention, certain range of part numbers could be reserved to indicate non-parts information such as region or supplier information. Strive to get a consistent vocabulary for the analysts navigating through many such myriad variables and naming conventions.
Rule 5: Normalization enables the regimen to achieve efficiency
Paraphrasing Wikipedia, normalization can be described as any process that makes something more normal and conforming to some regularity. This regularity can manifest in two forms: structural regularity and semantic regularity. Structural regularity enforces rules definition based on pre-defined structures. For instance, it could be that the agreed upon convention for all rules is “condition first and effect last”. Aiming for structural regularity among rules will make the style familiar and hence help achieve faster validation of rules by the business team. Further, consistent rules makes it is easier to isolate redundant rules.
Semantic regularity comes into play around ensuring usage of correct rule conditions and actions. Not dissimilar to the concepts of database normalization, rule normalization involves making sure the rule actions are fully dependent on rule conditions, and actions are fully dependent on all conditions. If the actions are not fully dependent on all the conditions, separate them out. Aiming for semantic regularity among rules will help achieve cleaner, rationalized and less redundant rule sets.
Rule 6: Efficient traceability leads to effective rules
When large number of rules are being excavated and defined from disparate systems in an iterative fashion, there spawns a need to trace and search related rules, a need to traverse through a methodical classification to compare and contrast captured rules. Only when one can find related rules in a meaningful way, can one even attempt to eliminate redundant rules. Mapping the attributes of captured rules to the defined taxonomy is one way to achieve this traceability. Note, a given rule can be mapped to multiple entities in the taxonomy. Imagine this activity as assigning ‘tags’ to the rules, and the ‘tags’ are coming from the well-governed taxonomy.
Rule 7: Look for chasms before taking small steps
Iterative development involves building solutions progressively given only partial scope within each iteration cycle. Like in any project, there are some aspects that are conducive to iterative development, and some not. In a rules implementation, rules discovery, excavation, analysis and development can happen iteratively. However, the underpinning factor to enable this is to arrive at solid information architecture. The taxonomy and data model should be defined as completely as possible because changes in taxonomy results in rework.
Rule 8: Out of sight is not necessarily out of mind
BRMS implementation can be executed in a distributed team model with teams within or across shores. In general, rules discovery, categorization and analysis activities place major emphasis on business user interaction, and need continuous validation. On the other hand, heavy-lifting activities such as rule excavation, development and testing activities can be significantly time consuming work that provides windows of opportunity to be executed with minimal user interaction. Having said that, as in any distributed agile/iterative project, the key step is to isolate and contain the factors that are heavily dependent on a particular environment or subject matter experts. Activities of rules analysis and development that are amenable to distributed development model include: Asset analysis – given a set of identified assets for rules sources, remote teams can perform deep dive analysis of code base and scripts; Rule-set Analysis – given an approved taxonomy and rule sets, remote teams can perform first iteration of checking for redundant rules; Rule Development-given a set of approved rules in the agreed-upon rule definition template, remote teams can develop the rules in BRMS; Rule Testing-after gaining sufficient business knowledge, remote teams can develop test scenarios and perform scenario testing.
CONCLUSION
Principles of Business Rules approach and methodology advocate externalizing operations-guiding rules as well-codified statements. Applying those principles onto itself, this whitepaper codifies key methodology-guiding rules for successful implementation.
Mahesh Alampalli 