I have spent an inordinate amount of time lately talking about the benefits of language—something you might appreciate since your are currently reading this blog AND understanding it. Language is a sort of human-level contract we have with each other and by using it we can find our way to understandings—flawed as that may be at times. In fact, some people have developed a discipline of double checking their language and stop to ask questions—feedback to make sure the intended receiver understood the implications of the message (and no, I am not going to talk about TCP/IP).

The requirements process depends upon language to discover critical business features and those that use it will eventually attempt to describe what they learned to developers. However, the understandings (requirements) themselves undergo a transformative process, probably not unlike a Kantian meat grinder in the mind of the business analyst—inputs transforming into logical outputs on the other side. However, even such a rigorous empiricist like Kant expected that new knowledge had to under go the test of common sense. This provided the critical feedback loop to make sure that a proposition was worth its value–so much for a priori knowledge. At this point, one has to ponder the following question: “If the empiricists cannot establish a rational basis for a solid requirement that can stand the test of time then who can?” This is the equivalent of asserting that at any give moment one may be 50% certain about the requirements but if any assumptions change all bets are off—and this includes any assumptions not imagined at the time the requirements were written.

All of this boils down to uncertainty that cannot be eluded in the requirements process because it is conducted by humans and assumptions change. Managing change and embracing it is fundamental to human experience and needs tooling.

Change and ambiguity are closely related.  While working in the financial services space I discovered that for a bank, there is no single balance to an account. The concept of “Account Balance” is understood at all levels of the organization, but this concept often translated into 30 or more concrete variants. All of these had to be understood to support the requirements process. In talking about the fields, the developers did not always share nomenclature. They also used odd-prefixes and suffixes in class names common to their language and they were prone to using synonyms introducing confusion along the way. To avoid this, the business analysts kept a glossary of terms to track the differences and help remove the ambiguities.

Using the vocabulary of a BRMS binds the language of business to the concrete and executable model of the code. This solves several problems:

1. Removes ambiguity by mapping terms to concrete equivalents.
2. Offers levels of validation that non-executable requirements cannot—completeness, regression, versioning, difference and many more.
3. Developers enjoy receiving something that they can use—saving time without waiting to till GUI is available for testing.
4. Concepts or content that don’t belong in a rule can remain affixed to the rule in the form of a description—why is this rule important to the business and what might happen if it did not exist.
5. Requirements expressed as rules can be kept current and eliminate the tendency for them to become stale.
6. Changes can be deployed without shutting down production systems.

It’s true that you can’t express everything as a rule—let’s not fall into myopia. Nor will a BRMS solve all requirements pitfalls; but it is tooling that helps organizations scale by helping us use our language better. In the end, it’s all about words and what they can do…not software.

CCB

You may have noticed that the BRMS Resource has had a makeover recently, expanding it to cover JRules, Rules for .NET and Rules for COBOL. 6 month trial versions of both JRules and Rules for .NET are now available and the content available to help you evaluate Rules for .NET has been expanded.

Don’t hesitate to send your feedback to the BRMS product managers!

The ILOG and Wipro relationship has grown to provide our customers a combination of services and products for Legacy Modernization. The webinar held on June 19, 2008 was very well received and highlighted how the combination of ILOG JRules with Rules for COBOL and Wipro’s service with their Business Rule Extraction methodology can provide increased business value for our customer’s Legacy Modernization projects.

Wipro’s Legacy Modernization business rule extraction method is a four phased methodology (Extract, Catalogue, Realise and Manage). The design and implementation of those extracted business rules in JRules and Rules for COBOL provides the ongoing and future maintenance and management of those extracted business rules. Rules for COBOL provides native execution in COBOL by generating a COBOL subprogram from the rules that were authored in JRules.

The webinar attendees indicated through polling questions that COBOL still runs their organization’s business applications - 55% of the attendees stated that 75% of their applicaitons remained in COBOL with 35% of the attendees having 75% of their applications on the mainframe but not necessarily all in COBOL. For the polling question on business drivers for their legacy modernization project, there were 45% of the attendees stated that the key business driver was to improve IT time to deliver business changes and 23% of the attendees stated that the key business drivers was to lower IT integration costs.

The combination of business rule extraction with business rule management providing for a choice for deployment - Java or COBOL - is an excellent way your organization can begin to provide business value with your Legacy Modernization projects sooner rather than later.

I recently had the opportunity to take a look at the newest member of our BRMS family, ILOG Rules for COBOL. We’ve supported JRules running on zSeries (both zOS and zLinux) for a few years now, but there is still an enormous number of legacy COBOL applications and it is not always easy to convince the zSeries administrators to install and configure a Java VM for efficient execution. To compound matters the last time I looked, invoking Java from a COBOL batch application was not trivial either. Throw in a teaspoon of Java vs. COBOL internal company politics and season with Java pricing differences, zAAP hardware/pricing acceleration, and Rules for COBOL becomes a compelling solution for a significant number of the Global 2000.

The workflow is pretty straightforward:

1. Import COBOL Copybook into Rule Studio for Java
2. Generate a BOM and Vocabulary from the Copybook data structures
3. Author rules as usual
4. Rather than exporting a ruleset archive, generate COBOL sub-programs (source code) from the rules, either from Rule Studio or from Rule Team Server
5. Include the generated sub-programs into the target master COBOL program and deploy the code to the mainframe

The advantage with this approach is that enterprises can divide-and-conquer their legacy modernization, incrementally externalizing their business rules from COBOL applications and moving them into the BRMS. They can continue to execute the rules as COBOL minimizing the disruption to their system infrastructure. They may also deploy the same rules to JRules, for re-use in other applications running outside the mainframe, and because the BRMS is the system of record for the business rules consistency is guaranteed.

If you are embarking on an SOA legacy modernization project I encourage you to look at the Transparent Decision Service support in JRules and Rules for COBOL. In my opinion the two are very complimentary as they allow you to “think big” while still “starting small” and avoid rip-and-replace, often associated with project failure in large scale legacy modernization projects.