ILOG BRMS V7.0 is a major release, and that is probably a major understatement! Based on the foundations of the JRules 6.x architecture, BRMS V7.0 has two major overarching themes: business user empowerment and enabling platform agnostic decision services. Supporting these two themes are a panoply of technical advances across the whole product stack.

The BRMS team has worked incredibly hard over the past 18 months to deliver what is without a doubt the most ambitious release we have attempted since I joined ILOG (my first release was JRules 4.6). As an indication of the work involved, the first construction iteration for BRMS V7.0 started 19th November 2007! Here is a very quick round-up of the major new features. I hope to dive into the details of each of these over the coming days and weeks.

Hats off to the business rules support team!

This morning the email below caught my eye, as it typifies the high-quality diagnostic work of the support team. Jun is helping troubleshoot an out of memory issue with Rule Team Server. A key component of the success of JRules is the ability to support customers and engineers in the field, and filing high-quality (actionable) bug reports for R&D when necessary.

In my previous email I gave some suggestions based on the information we received. What kind of diagnostic steps have been taken on the customer’s side? Do you have any additional findings?

The server logs alone are not sufficient for us to draw any conclusions.
In order to effectively diagnose the problem, we must first obtain as much background information as possible.
What we need to determine is whether the OOM is caused by a memory leak or a lack of resources given the current load.
We can start by addressing the following:

1. What is the current heap size?
2. Does increasing the heap size help avoiding the problem?
3. What is the size of the rule project? e.g. number of rule artifacts, decision tables, variables, dependencies, etc.
4. From the server logs, as I pointed out earlier, there are NullPointerException and ConcurrentModificationException preceding the OOM. Is it always the case that OOM follows these particular errors?
5. What type of activity leads to the NPE, CME or OOM? Do you have steps to reproduce these errors? Can you provide sample projects along with the steps that would allow us to replicate the problem?
6. Do you see any evidence indicating a possible memory leak? If so, do you have any profiling data that you can share with us? An indication of a memory leak would be increasing memory utilization over time that is not released and collected by the GC and inconsistent with the load requirements.
7. Are there any customizations done on the RTS?
8. Do you observe any memory fragmentation from the heap dump?
   The following link introduces a troubleshooting tool for OOM, provided by IBM. This could provide a good starting point for diagnostics on your customer’s side.

Besides the questions above, please share with us any additional findings/observations you have made. As soon as we have these information, we will be able to move forward with the investigation and provide possible lead.

Sincerely,

Jun Wang

You may have seen the news: ILOG is now a fully owned subsidiary of IBM. Over the coming months, all the legal, HR and MIS work will take place that should ultimately culminate with my employer becoming simply, “IBM”.

It’s been a tricky few months for a company blogger, because a lot of exciting things have been happening, but I have not been able to blog about anything related to the acquisition for legal and regulatory reasons. Now that IBM owns all the ILOG stock some of those restrictions have been relaxed.

On Thursday all the Paris-based ILOG staff spent a day at the IBM site at La Défense, Paris. Despite some initial grumbling about changes to morning travel routine, and the crowding on the RER and metro lines, there was a real sense of excitement amongst the people I spoke to. The whole IBM team did a good job at explaining how the acquisition would unfold over the coming months and we were made to feel very welcome. I particularly appreciated the R&D break-out session that was led by Ed Lynch from IBM. Ed is a straight-talking Canadian and was the motor behind the adoption of Open Source at IBM, as well as the ILOG acquisition. Ed is also the integration executive for the AptSoft acquisition, now the WebSphere Business Events product. I think we are very fortunate to have such an outspoken champion.

While IBM’s initial interest in ILOG was driven by BRMS to complement SOA, they are clearly very impressed and interested in all the other technologies we bring to the table, for supply chain management, visualization and optimization. IBM is one of the few technology companies with a breadth of products and solutions that can benefit from the entire ILOG portfolio (and in fact they are already users of many of them!), so it is going to be very exciting to see how the integration strategy plays-out.

Today I am back at my desk in Paris, working on ensuring that Rule Studio for Java will meet IBM’s product requirements. We’ve had to make some minor packaging changes to align ourselves with standard practice at IBM, but I’m pleased to say that so far the process has been very smooth!

2009 is shaping up to be an exciting year — we’ve got some great new features to deliver in JRules 7, and with the leverage and visibility we gain from IBM I’m convinced we have a unique opportunity to deliver the value of BRMS to a potentially huge new audience.

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.