With dependence upon automation increasing, responding to changes in business makes application maintenance one of the fastest growing line items within the budget. Sure, a good understanding of business requirements and a set of sound architectural disciplines somewhat ease application maintenance costs, however the overall pressures on cost continue to rise due to the criticality of data quality, internal auditing, and the external regulatory demands of numerous domestic and international jurisdictions.
However, considering the many steps that comprise the software development life cycle (SDLC), application maintenance cannot be viewed solely from the perspective of labor and infrastructure costs. First, application maintenance is time consuming, thereby delaying time to market. Second, application maintenance is risky to the business, as even the smallest application changes expose business to service disruptions leading to loss of income. But what alternatives are there to application maintenance?
Depending upon the type of requirements, there are a handful of alternatives to application maintenance that can potentially render solutions at the speed of business, such as rules engines and empowering business to self-serve their ad-hoc reporting needs. Additionally, unlike application maintenance, many of these comply with the capitalization rules regarding the tax treatment of IT expenses.
One of the Alternatives to Application Maintenance – Rules Engines
Unlike programs that automate a long series of procedural instructions representing a ‘logical unit of work’, such as capturing a customer request to trade securities, ‘rules engines’ automate relatively few procedural instructions that execute when certain pre-defined conditions are met.
Not to be confused with a branch of artificial intelligence that organizes collections of knowledge in English like “If-Then” statements called ‘expert systems’, rules engines utilize computer syntax. Also not to be confused with ‘database triggers’ and ‘stored procedures’ that are part of their associated database product, ‘rules engines’ operate externally as their own software product not part of the database. Last but not least, it is also important not to confuse rules engines with BPM Technologies even though BPM Technologies often incorporate rules engine functionality into their product.
Rules engines periodically search the records of one or more databases looking for a condition in the data before performing the typically few procedural statements associated with the particular condition.
For example, if the situation arises that an ‘active’ transaction contains a social security number that can be found on a government watch list, then the procedural statements may change the status of the transaction to ‘hold’ and route an alert to the compliance department.
Examples of the rules engine products that are pertinent to this discussion include Ruleburst, InRule, Blaze Advisor, SRE, Workflow Magic, Drools.NET, NxBRE, and BizTalk from Microsoft Corporation, which is an example of a BPM Technology combined with a rules engine. Architectural types of rules engines include: forward chaining, backward chaining (a.k.a., goal driven), and deterministic, the latter making use of a domain specific languages as do expert system technologies.
Unfortunately, as they exist today, ‘rules engines’ can be amazingly complex in their installation, implementation and maintenance, and as such, can represent a significant layer of complexity on top of application systems. When not managed properly with the appropriate governance, rules can become unwieldy to manage as they begin to interferer and conflict with one another.
When considering a ‘rules engine’ it is important to keep it simple and governed. From our experience a rules engine is far more effective as a business tool when imbued with the following features, resulting in a new approach to rules engines.
- Key Differentiator I – The first feature that significantly improved the concept of rules engines stems from the recognition that similar to the field of data architecture, rules can take on a ‘conceptual’, ‘logical’, and ‘physical’ form, and that there is business value in doing so.
Within this approach, conceptual rules are developed by the business and represent internal compliance and external regulatory rules from various jurisdictions. As examples, a conceptual rule could be an important section quoted word by word from the Gramm-Leach-Bliley Act (GLBA) by legal, or they could represent the data quality issues identified by various stakeholders of the enterprise using business terminology.
Logical rules in turn, developed by business analysts, associate logical rules with their associated conceptual rule utilizing a carefully developed taxonomy. For example, a logical rule states the related application(s), their data structures, and the business capabilities that are in scope.
The physical rules, coded by IT developers, associate the physical rules with their associated logical rule. For example, a physical rule is the specific database query that searches for a condition to be found in the data with its corresponding procedural statements, which may place a transaction on hold and notifying compliance. In contrast, the only component that exists today in rules engines is the physical rules without association to higher level concepts.
This first differentiator provides an easy method by which various physical rules can be traced back to the logical and conceptual rules that they are related to so as to easily identify rules that are impacted when changes occur to internal audit rules, external regulatory rules of the various jurisdictions, or data quality issues that stakeholders in the business are attempting to address.
Even more significant is the fact that this first differentiator requires a carefully developed taxonomy to manage the conceptual, logical and physical rules, including the taxonomy of their associated business capabilities, stakeholders, processes, and data. It is through the careful management of taxonomy and conceptual, logical and physical levels that avoids the confusion and complexity that result when these aspects go unmanaged.
- Key Differentiator II – This next feature follows closely when it is recognized that many of the internal audit and external regulatory rules of various jurisdictions are reusable among businesses of the same industry, making the conceptual rules reusable. Furthermore, given the circumstance that many businesses rent or buy the same software applications within a given business vertical, both the logical rules developed by business analysts and the physical rules implemented by IT developers also become reusable.
As such, there may be a market for conceptual, logical and physical rules among businesses within a particular vertical, particularly when they have deployed the same third party applications.
Therefore the opportunity to reduce time to market and development cost exists when conceptual or conceptual, logical and physical rules may be reused or leased within a given business vertical, which can occur well in advance of application vendors releasing product enhancements of applications they maintain – not to mention business testing and deployment that new application versions must undergo before they may be placed into production for use by business.
- Key Differentiator III – Perhaps most important is the third feature. When it is recognized that rules engines provide a low cost and rapid alternative to application maintenance, businesses will be better able to manage their use of capital in a more competitive way when certain types of requirements are involved.
As an example, let’s take the circumstance that compliance should be notified when a social security number is present on a government watch list. This functionality can be implemented utilizing the application maintenance SDLC process at a greater expense due to the number of participants and steps required to assure the appropriate degree of application quality control. However, when approached properly, the alternative of the SDLC for rules engine maintenance may achieve a significantly more competitive result.
The risk ever present in application maintenance is that even a simple change can have unforeseen implications to other areas of an application system, whereas if managed appropriately, units of code in rules engines can be independently added and removed.
Large financial companies that have made a large commitment to rules engine technology with thousands of rules find that the majority of their rules are internal audit, external regulatory or data quality related. For the most part, when rules are violated the approach that these companies have adopted is to illustrate each exception as it occurs on a data steward dashboard.
- Key Differentiator IV – The final feature provides a lasting effect, when it is recognized that issues being illustrated on the data steward’s dashboard have potentially occurred at some time in the past and may occur at some time in the future.
As such, it is best if the initial thought process and solution were not forgotten over time so it is the responsibility of the data steward to record the thought process and solution within the rules engine to make it available at some future date.
Such a repository of exceptions, their associated analysis and solutions can serve as a valuable searchable repository long into the future until the associated applications are retired.
Architectural Choices
Abraham Maslow coined Maslow’s Maxim (a.k.a., Maslow’s Hammer), “He that is good with a hammer tends to think everything is a nail.”
Also referred to as the Golden Hammer in software development, the tendency to solve problems with a single approach is more commonplace than we would like to admit. The alternative, however, requires the practice of engaging appropriate architectural discipline(s) by reviewing enhancement requests with a team of experienced architects that represent the architectural disciplines most pertinent to the company.
From the perspective of an enterprise architect, candidate solutions should be suggested based upon architectural principles contributing to the overall competitiveness of the business. As such, there are usually a number of choices to consider, each with their own costs, benefits and risks.
Application development teams and their associated solution architects tend not to weigh recommendations involving changes in business operations and user training or for that matter any approaches other than application maintenance or application development.
Other than true application requirements, such as the need to capture additional data fields during transaction data entry by business users, considering the variety of alternatives, such as a rules engine within a data governance framework, can quickly position the company to better compete, survive and thrive within the marketplace.
Architectural Principles for Rules Engines
A principle is a fundamental truth, upon which other truths depend. Although abstract in nature, principles can be used at any given moment by most anyone to evaluate any number of concrete alternatives to attain long range goals embodied within the principle.
If we adopt the long range goal to optimize competitiveness, the following are a basic set of principles that pertain specifically to rules engines:
Principle #1 – Develop taxonomy to manage the various components of rules or adopt a reusable industry standard if one exists.
Principle #2 – Leverage the business efforts of others by buying, leasing or licensing reusable ‘conceptual’ rules where they pertain to the same business vertical.
Principle #3 – Leverage the technical efforts of others for your purchased or licensed application systems by buying or leasing reusable ‘logical’ and ‘physical’ rules with well-developed taxonomies that correspond to the reusable ‘conceptual’ rules that pertain to the same business vertical.
Principle #4 – Protect against the potential costs of non-compliance by developing internal audit rules and external regulatory rules of various jurisdictions as ‘conceptual’, ‘logical’ and ‘physical’ rules that cannot be purchased where violations may have large financial or reputational implication.
Principle #5 – Use information to better compete by capturing data quality issues in the form of ‘conceptual’, ‘logical’ and ‘physical’ rules from various stakeholders across the enterprise where such data quality issues represent a significant competitive disadvantage or where addressing data quality issues may provide a significant competitive advantage.
Principle #6 – Enhance upward and downward maintainability of rules by providing full traceability between conceptual, logical and physical rules.
Principle #7 – Minimize business impact and technical complexity detecting violations of conceptual, logical and physical rules as early in the business process as is possible.
Principle #8 – Once an exception has been detected, optimize cost, time to market and risk by evaluating all feasible approaches to resolving rule violations, such as by including adjustments to user training and changes to business operations versus application maintenance.
Principle #9 – Record the research and resolution adopted for each exception detected as a violation of conceptual, logical and physical rules for future use.
Principle #10 – When application maintenance is required, routinely reevaluate the inventory of issues resolved by training and changes to business operations for inclusion in order to take advantage of the application maintenance process being performed.
An Additional Challenge
Although we may have done better if Confucius were quoted here, “He who does not economize will have to agonize”, we opted instead for the humor of Will Rogers.
The point to make here is that no matter how well-intentioned and capable our beloved IT people are, IT departments have a different psychology than business departments. Unlike business departments all IT departments are ‘cost centers’. They do not earn income for the company, yet they only grow in importance with the size of their budgets. The further away from the business they are, the more out-of-step they tend to become, and the greater their sense of entitlement for more budget.
Presently to limit the spending of IT departments, business executives provide limits in the form of budgets that constrain what IT departments can spend over a period of time. Unfortunately, reigning in budgets does not influence how IT departments think. In response IT departments are often quick to point out the various services that they will no longer provide with lower budgets.
Summary
Ultimately, there are two things that can go a long way toward achieving success with rules engines. First, a centralized architecture team with the business is needed to evaluate the best implementation strategy. This will ensure that issue detection is performed in the most efficient manner.
Second, a centralized data governance team is best to manage the rules engine within a framework of data governance. Already engrained in data governance is the criticality of developing and managing conceptual, logical and physical artifacts and their corresponding taxonomy. Also, most of the appropriate candidates for rules engines are data governance related, such as internal audit requirements, external regulatory requirements, and data quality issues.
While there may be other ways that prove as successful, the more that IT departments are willing to think outside the box, the better the chance that their businesses may prosper in a competitive marketplace.
Please don’t hesitate to let me know which articles in the “Architecture Made Easy” series are useful to your organization. In addition, corrections, enhancements, and suggestions are always welcome and are requested.
[“The New Philosophy of Enterprise Architecture” is the 13th article in the “Architecture Made Easy” series created by James V. Luisi.]