Discovering and analyzing your business policy change templates is one of the several key aspects documented in the ISIS methodology, and that must be addressed as part of defining your Rule Governance processes.

The reason why a BRMS component is brought to a company’s IT application mix is because it facilitates the implementation of decision services, but also, and more importantly, because it helps manage their rapid evolution. It is thus surprising that the task of preparing the system and its supporting organization for business policy change management does not always get the attention it deserves.

Note that we are not talking here about preparing for change at the level of the business rule elements, which are the atomic building blocks of a policy. These are usually (or should be) well covered by generic rule governance processes for authoring, validation and deployment. We are talking about change at a macro-level, where it is expressed in terms of raw business policy statements instead of individual business rules. Think change to a paragraph of the underwriting policy used as the reference document by the loan underwriters, for example.

During the application analysis steps, the main questions to the business stakeholders revolve around capturing as accurately as possible the definition of the business policies that will be implemented by the system. However, when analyzed from a snapshot, the policy can appear monolithic or prompt a decomposition along some logical or system-related concepts which are not adapted to the future need to accommodate business changes.

Therefore, another critical task that must be addressed early on in the analysis process is focused on producing an inventory of the probable ways in which the policies may or will change, and with which frequency.

This requires the policy managers to reflect on their experience and come up with as many concrete examples of discrete policy changes that have they have been witnessing regularly in the past. These examples can then be arranged in a taxonomy of business policy change templates.

The most frequent changes are usually the most simple and precisely described ones. The more complex and less frequent ones will often contain some unknowns. For example, the possible templates for a loan pricing application may be:

• Changing the base rate values (may occur weekly).
• Changing the add-on, minimum rate, or fee values (may occur monthly).
• Creating or retiring “specials” for selected regions or channels (may occur quarterly).
• Creating or retiring the pricing structure for a new product (may occur once or twice a year).

Of course, not all changes are predictable. Important and unpredictable ones come, for example, from external regulatory rules or from newly devised company strategies. But for the more banal and recurring ones that can be identified and dissected in advance, the benefits are multiple.

Some of the artifacts that can be prepared for a given business policy change template are:

• A template for change submission, which precisely describes the change and the different parameters involved.
• A process map to implement the change, detailing which rule should be updated, created, or deleted, in which package, whether an update to the rule flow is warranted, etc…, and which specific resource is needed.
• An accurate time and effort estimate to implement this change, from authoring to deployment. The estimate is developed and agreed upon by both IT and business stakeholders, and helps in setting the release schedules and expectations.
• A set of rule templates to facilitate the implementation and reduce the risk of introducing defects.
• A precise test plan and set of test cases. And since the scope of the change is well defined, it is easier to apply techniques such as Delta Testing, which help get extensive test coverage and minimize the updates needed on test cases.

For traditional software, requirement tracking is an important pre-requisite to smooth system maintenance. It allows to analyze the impact of a requirement change to the underlying implementation, and plan the change accordingly.

Business rules management systems take maintenance to the next level and make it a standard activity. It should thus be expected that the efforts on requirement tracking are pushed accordingly to collect and analyze the patterns in requirement change.

To know more about Rule Governance, join me in a 1-hour webinar on May 28th (click here to register). Like our mission states, we are here to help your business handling change and complexity, and rule governance is a key element to make sure you can attain such a goal!

Informs Practice is one of two annual conferences of Informs, the Institute for Operations Research and the Management Sciences. A group extremely vested in building strategic decisioning systems with thousands of practioners around the world, definitely worth spending a couple of days with. What impressed me the most is the ability of this community to address business needs with smart, pragmatic, mathematical and computer-based solutions. A great example of the benefits of Business Analysis and a great lesson or inspiration for IT as a whole.

My goal was to leverage the experience we gained building both optimization and rule-based systems to generalize some fundamental best practices applicable to the implementation of decisioning systems in general, what ever technology is involved. When you look at such systems, here are some common characteristics which come to mind: 

Yes, some decision processes are non deterministic and a decision made through different paths. In other situations, some users change their mind in the way they make decisions and want a computer to assist them in the process. That makes decisioning systems hard to test. In some situations, decisions are made on intangible elements, or intuition, a challenge for our usual way to model things and implement heuristics. Or the human brain is just too powerful and outperform the computer (e.g. visual pattern recognition, optimized way to allocate resources developed over years of experience). Some decisions are not black and white, some are based on fuzzy information, some others are really complex either in terms of number of variables involved or the type of search algorithm. Some users or policies require the decisions to be explained or traced. Some rules are unwritten. And to complicate things even further, decisioning systems are usually involved in processes which are subject to frequent change, for instance a change of policies (internal or external), strategy, organization or business model.

Such qualifiers clearly would not apply to a standard accounting or record-management application such as a CRM system, or an embedded real-time program such as in an ATM or your car ABS.

Although technology can help addressing many of these above challenges, and object-oriented programming in particular, it is not the only solution. Project Management has also to adapt and leverage new paradigms to make sure these projects can cope with so many potential hurdles.

Here are our top-5 picks in ISIS which we will develop further in subsequent posts:

1. Iterative development. Ultimately, you want to put a working system in the hands of your end-users every 4 to 6 weeks. So they can provide early feedback to avoid late discoveries of misunderstood needs or help uncovering mismatch with changing requirements. This is the key concept of the Unified Process, as well as the Agile Manifesto. An approach which is unfortunately not natural in the IT industry yet, but clearly a plus to handle the challenges identified in the above picture.
2. Focus on Time To Profit. It is key to define iterations which each bring some value to the business to anchor the project on the right track, get acceptance and traction from the business and solidify the business case of the solution under development. Business-driven iterations as opposed to purely technical and/or contractual releases or builds like we too often see in classical project life cycle such as the waterfall approach.
3. Intelligent tracking. Most of the IT projects get in trouble because of non realistic tracking. Weeks after weeks, you hear the usual “I’m 80% done” and the percentage keeps the same… Even more so with decisioning systems, estimates need to get revised to account for changes and implementation challenges. Not only you need realistic “pictures” (a project status at a given time), but you need to juxtapose these pictures to make a “movie” and highlight trends which will help you resetting expectations or reevaluating the scope and objectives. In ISIS we have added charts to our weekly status report to explicit potential drifting in workload estimate or track the quality of a deliverable through the evolution of issues found, analyzed and fixed.
4. Project governance. Governance has definitely got a lot of spotlight since the Enron debacle, and a lot of negative connotations for many people since then. However, increased scrutiny surely helped businesses avoid costly mistakes. There are all sorts of governance (e.g. corporate governance, IT governance, SOA governance, rule governance); the project governance should be seen as a positive oversight, an assistance to the project manager to maximize the chance of success. In particular, a steering committee can help the project manager negotiate changes with the business or suggest mitigation actions to address implementation-related issues. ISIS provides checklists and guidelines to make such a governance process work for all the stakeholders.
5. Risk management. We sometimes hear “if we only knew what we know” and this is indeed the title of a great book on knowledge management. Unfortunately, we actually know much more than we want to admit when we start an implementation. For instance, in ISIS, we have a tool to evaluate 193 pre-identified risks and 48 classical project management mistakes. Needless to say, with such a long list, the saying should become “if we had known what we knew then…” Definitely worth spending time in a fair, transparent and upfront risk analysis.

These are only 5 of many foundations of ISIS but key ones to ensure success. As we have seen over the past 20 years and learnt from hundred of projects. They do require quite some discipline though, but the rewards of getting a decisioning system used for many years make them worth the effort!

It was designed 5 years ago and used in ILOG Professional Services worldwide on dozens of projects. Leveraging ABRD mitigates the risk associated with new business rules initiatives by providing a well documented and structured approach for developing rule-based applications. ABRD allows organizations to avoid using ad-hoc processes or having to expend significant time and effort creating their own best practices.

ABRD is an Eclipse plug-in the same way ISIS is. In fact the following diagram outlines the relationships between ISIS, ABRD, and OpenUp.

OpenUp represents the base, the foundation, defining the core principals of software application development such as: collaborate to align interests and share understanding, balance competing priorities to maximize stakeholder value, focus on the architecture early to minimize risks and organize development, evolve to continuously obtain feedback and improve. ABRD is called abrd_openup plugin and extends OpenUP. ISIS has a common plugin to include any elements which are reusable for BRMS, Optimization, Financial Industry or SCM projects. Each plugin in ISIS provides container for knowledge management for specifics industry or practices.

I encourage you to book your agenda May 7^th, this Wednesday, for a web seminar and register at https://iloginc.webex.com/iloginc/onstage/g.php?t=a&d=828310442&SourceId=00005 and go to www.agileitarchitecture.com to have more information on ABRD, BPM, CEP and other agile technologies.

You can also get more information about ABRD by visiting the following web sites:

• ILOG’s BRMS Resource Center
• ABRD’s deployed instance
• my blog on Agile IT Architectures

Let us know how ABRD works for you!

PS: here is a link to the recorded webinar.