The Value of Assessments

Many organizations have considered assessments, formal and informal, of business rules technology when looking at reengineering efforts or at new enterprise development projects slated to involve business rule technology. The promised value of using business rules—often generated by one or more of the business rule vendors---is hard to ignore, especially for industries whose IT systems have ever changing and complex functional logic, or where the rules that run the business needs to be outside the control of the internal groups that implemented the old rules in a cryptic, traditional manor. The “leap of faith” many organizations currently take when they assume that detailed requirements are being translated into production code makes little sense for regulated industries or for any industry where the implementation of business rules is a business asset.

So, how can an organization move from this vague feeling that business rules can help them to a specific, thought-out strategy for the inclusion of business rules? An excellent first step is a business rule assessment. These short-term, focused efforts can be done with internal staff, or by using an outside consulting services provider.

During the assessment, a series of discovery meeting are scheduled during which thewhich the attendees answer questions grouped in various ways to help determine the organization’s readiness and aptitude for adopting business rules technology. There are usually separate meetings for technical management, development staff, business analysts, production deployment, and testing staff.

These assessments can have several outcomes. The organization should develop a final report, based on the information gathered at the discovery meetings, concerning the suitability of business rule technology for the organization. Another possible outcome is the definition of a proof-of-concept (POC) project. A POC is a detailed description of the requirements of such a project along with a project plan illustrating how the POC can be implemented within the structures and processes of the organization. A previous Down to Earth Business Rules blog entry discusses the merits of these POC projects. In other cases, the assessment will focus on helping make specific vendor choices for business rule development technology, again, based on specific information gathered during the discovery process.

After the assessment, an organization can be ready to step into a business rule project with a much-increased knowledge base as to how this technology will impact their firm specifically. I highly recommend firms just beginning to think about business rules take the time to conduct an assessment. If schedules and the staffing model permit, the assessment can be internally conducted. An internal assessment has the added benefit of allowing for even more learning about the organization and about business rules by the internal group conducting the assessment. This knowledge then stays within the organization. When time is short or the staff is not available, an alternative is to contract out the assessment to a firm with previous experience in these areas. Deciding whether to outsource an assessment is akin to a make-versus-buy analysis on the business rule applicability knowledge derived from the assessment.

Why do so few companies actually manage their business rules?

The products and services offered by today’s modern companies are increasingly virtual constructs modeled and defined through business rules and enforced by automated computer systems. Insurance policies, lending agreements and other financial products are often essentially contractual agreements between a provider and a consumer. These products and services amount to risk mitigation or behavior governance strategies to produce a financially beneficial outcome to the provider while offering something of value to the consumer. Such contractual agreements are really nothing other than a product or service modeled through the use of business rules and resulting actions, which combined, govern the relationship and responsibilities of both the provider and consumer.

Products and services that are defined through business rules force the creation of additional business rules that govern the company’s operations. Activities such as billing, fee and rewards calculation, verification of eligibility, and compliance require that a new, but related, set of business rules be put in place which both support and constrain daily operations to ensure that the terms of the agreement are met. In addition, most companies must comply with federal and state regulations, resulting in another set of business rules that must be enforced.

Through all of this, we can see how business rules lie at the foundation of modern business, from being the actual product or service itself, to governing the necessary supporting operations that make adhering to the agreement possible while also complying with regulations. Executing, enforcing and complying with ever more complex and numerous business rules is, increasingly, becoming the business.

Interestingly enough, very few companies actually document and actively manage their business rules as the intellectual property, legal commitment, or competitive advantage they are. A business rules management approach, at a minimum, provides us with knowledge about what the rules are, where they are, and what the overall impact of a business rule change will be. Business rule management is not necessarily the centrally controlled or bureaucratic process it appears to be. However, scattering business rules and their documentation across the enterprise in use cases, requirements management tools, manuals, and -- most often – in code, does not a business rules management approach make.

So, given the importance business rules play in the modern enterprise, why do so few companies actually manage their business rules?

Here are a few high-level business reasons that I could think of for this lack of management, in no particular order:

• Business rules have only recently become recognized as key company assets.
• Although rule engines have existed for over 20 years, business rule management tools and methodologies are still in their infancy.
• Only in the last 10-20 years has the business and regulatory landscape, products, and services become so complex that a rules management strategy is becoming essential.
• Since business rules change so often, old rules go away, and new ones are created, companies treat them as throwaways rather than as assets that need management.
• Companies are overwhelmed managing other aspects of their business that were positioned as critical much earlier than business rules (i.e., BPM, CRM, ERP, Just in time XYZ etc.).
• Companies have seen so many past promises about management approaches and technology evaporate that they are reluctant to adopt new trends until they have been proven by others.
• Managers are not around long enough to see value or implement long term strategies.
• Companies generally do not take an overall view of their business which means efforts are departmentalized and large efforts uncoordinated.
• Companies do not realize the savings from retaining and maintaining their intellectual property such as the expertise embodied in their employees.
• IT shops are unfamiliar with rule engines so anything related to rules management is equally unfamiliar.
• There simply hasn’t been enough hype around business rules for most managers to notice.

Naturally, it is too simplistic to say companies do not manage their rules. Insurance companies have been forced for years to manage rules to some extent due to mandated state filings on changes and proposed coverage. Similarly, companies who regularly audit their business activities must be able to prove certain practices are in place and business conducted according to regulations.

In that case, why aren’t companies managing most of their rules the same way they manage some of their rules?

The Strategic and Tactical Reasons for Prototyping

We have found that organizations considering the application of a business rules solution to a specific business problem reap both strategic and tactical value from prototyping prior to embarking on a full-blown project.

Strategically, prototyping identifies risks and avenues for mitigation of those risks as well as providing the basis for informed decision-making. Management has the information to decide on the most cost and process effective approach to achieve business goals.

The risk management value comes from projecting tasks that allow the organization to identify potential problem areas in technology, process, resources, or skills. The risk management goals of most prototypes typically revolve around evaluating multiple approaches in order to select one to move forward with, validating certain assumptions, and learning enough to be able to, with reason effectiveness, plan out implementation details.

The decision-support value, while similar to the risk management value, often has somewhat different goals. Normally, prototyping for decision-support revolves around gathering enough information to make a business decision with regard to the use of the business rules engine. Decision points may include whether or not to use a rules engine, which engine to use, or how to approach or plan for the use of the business rules engine.

Fortunately, a single set of prototyping tasks often provides both strategic values.

Tactically, prototyping builds practical experience in staff, allows for testing of integration mechanisms and process changes, and can ‘prove’ that the selected business rules approach will add value.

Many organizations have never used or have no experience with a business rules engine. Prototyping provides a mechanism by which people can get their hands dirty and experience the details of how business rules engines work. This is important because real life is frequently quite different from the theoretical concepts esposed by salespeople. Additionally, prototyping gives the organization the means to effectively plan how to shorten its staff’s business rules learning curve.

The best way to integrate a business rules engine into an existing or new architecture is not always obvious. Prototyping allows the technical staff to test and evaluate integration alternatives including evaluating both in process and out of process approaches, data marshaling, and transport mechanisms. When, as is often the case, existing environment limits the viable options, prototyping can surface the costs associated with working with or around those constraints.

Technical integration isn't the only area that may require validation of approach. Oftentimes organizations need to evaluate how implementation of business rules may affect their software development processes and approaches. Prototyping allows the organization to test their preconceived approach to handling business rules in their processes by applying their proposed process to the implementation of business rules.

Finally, and possibly most importantly, prototyping provides a low-cost approach to validating that the proposed business rules approach brings business value to the specific project. Business rules is a relatively new technology in many industries with all of the concerns regarding the expense, resource cost, and change management that accompany any significant implementation. Prototyping allows management to "get their feet wet" with minimal risk.