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.