The program allows JRules consultants, both internal and external, to objectively demonstrate their deep product knowledge making it easier for JRules customers to select the right consultant for a given job.

Gold certification demonstrates an expert level of ILOG JRules product expertise, typically acquired through extensive experience with ILOG JRules on real life projects. This includes mastery of advanced concepts and comprehensive knowledge of the product APIs.

For the months of September and October 2008, the certification will be offered at an introductory 50 percent inaugural discount. Use promotional code IL4034 to receive the discount.

This is a lesson not a rule

It wasn’t easy when the penny dropped inside your head

But now you know the joke you tell it to your friends…

Do any of these sound familiar?

• Function
• Stored procedure
• Table Look-up
• Algorithm
• Business process
• Front controller
• Validator
• Data transformation
• Message router
• Pattern matcher
• Composite and Command design patterns

As the application grew and the command objects increased, I found that there were a lot of rules in both my MVC tier and at the business/service tier.

While much of the time I have been arguing the benefits of a multi-channel approach to SOA and sharing rule execution, I have been ignoring a discussion about all of the integration points that might be at play in a single application. AJAX might even bring rules into play directly from the client—making it possible that just about any part of your n-tier architecture may require access to rules at some point. This brings me to the value of encapsulation as a driving principal with rule management—even for a single application.

Where are your rules? I am interested in your stories of where they are and what finally was your tipping point in using a BRMS? Please post your comments below.

CCB

CCB

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

In the post (I Want To Believe Redux) my goal was to describe the fictitious story about a bright architect that matured a in-house rules technology. Along the way, the architect experienced pressure points and addressed the requirements in motion. At the start, the architect might have reached different conclusions before proceeding with the effort—for we all lack a critical view of something on the horizon from time to time. Below are some of the key pressure points I have experienced while walking in the “wilderness”:

Many rules, many places
Rules are in too many places—across multiple deployed applications (BPM, vertical solutions, and channels), teams, servers and data centers. IT managers and architects eventually find themselves in a position where they are responsible for changes across these boundaries and are now thinking strategically about how to limit the impact of change across these deployed systems.

Rules are constrained by release cycles
When business level needs are translated into software projects, the changes that are required are constrained by the existing software development life cycle (SDLC) of each group or team. Moreover, many changes may have nothing to do with presentation, but simply involve behavior of a production system. Strategically, the IT manager or architect would like the change to be affective in-between formal release cycles.

The collaboration problem
IT and Technical team members need to collaborate with non-IT staff and business stakeholders. Requirements documents are not always up-to-date and the master of the policy must constantly be translated into a business language for audits, simple reviews and other requirements that require visibility. In fact, the process of translating business requirements into executable rule policies is very expensive because of the amount of human interactivity involved. Strategically, organizations should look for technologies that streamline human interactions to avoid waste while at the same time keeping the goal in view. This is the whole point around declarative approaches to software.

Inconsistent terminology
Architects and Developers do not share the same language with Analysts. Analysts often create and maintain glossaries to map technical terms to business terms. They need a way to manage this at the same time they solve their rule visibility problems. Consistent vocabulary reduces (and in cases removes) ambiguity and allows organizations to scale. This is a more abstracted version of a “contract first” approach to design but at the level of language and human behavior.

Shared execution (SOA)
Once a decision is created, architects would like to have the same feature across all of their deployed applications. They don’t want to touch other deployed servers that may be spread across data centers and geography. In turn, they would like to take an SOA approach to decision deployment so that all channels/platforms can reuse a policy.

Code has become brittle
Business logic has reached a tipping point in terms of algorithmic complexity. This complexity is making the rules opaque to the business analysts and complicates communication. It also is increasingly difficult to debug and test. Specific problems are in the area of re-cursive patterns, complex data structures and the amount of data that must be tested at various stages of a decision. The developer needs tooling to simplify rule expression and model how rules are used. Simplifying logic and the expression of rules is critical for adoption by business analysts and other non-technical consumers of a decision.

Tools are too technical
Business analysts need a tool that fits them: Non technical staff cannot use the same tools as developers and need to manage rule artifacts independently of the SDLC used by the IT groups.

Administrators need tools too
Usually administrators do not have tooling to manage how services are created and managed. They need tools that leverage their experiences and practices in the data center. Living with a solution and keeping deployment costs low is as important as up-front costs; however, these long-term costs are more more difficult to address because they require a broader view of an organization.

In short, the pressure points are real and ever present. I recall my first dive into test first programming and unit testing. In the end, I found I was still doing what came naturally, but the tooling added consistency, repeatability, and EVIDENCE that the code worked. As a byproduct of the effort, I discovered many other benefits that I could not have foreseen without using the methodology and tools—like knowing more quickly how a contract or object signature was going to stand the test of time—or make refactoring a lot easier—just watch all the tests break. The same is true for rules. It would be nice if humans could understand the world a priori; but we don’t. Fortunately there are some walking around with a flashlight.

CCB

There is the world as we see it and the world that could be. Imagining how is critical. If you can’t agree on a premise, then it’s hard to move forward in any direction. One is stuck in the question “why are we doing this?” Such has been the case in a blog I have been following entitled “I Want To Believe”. In addition, at TechEd this year I met several industrious architects that implemented their own rules “engines” on the .NET platform. This Blog and these engineers I spoke with seemed to be grappling with similar questions but from slightly different angles. In general, the question is the following: “How does one identify the tipping point for justifying a BRMS?” The answer is not elusive, however it may not be the same for everyone as you would expect. Consider the following evolution of a fictitious solution.

Simple Encapsulation
Most architects can imagine the need to refactor their code and encapsulate their logic into a single location. Imagine that our fictitious architect George has completed a code review of a new but growing code base and has noticed that there were far too many “If/Then” blocks in the presentation tier. So he gathered the troops and offered that these blocks of code should be wrapped by a single library and enforced with a contract using an Interface. This pattern, along with an existing investment in a model, solved the problem of centralized management from a code perspective. The “If/Then” blocks could not be fully removed from the presentation tier, but they did not bloat as the number of rules grew.

Hot Deployment
Now that the rules were in one spot, George realized that the code in the new library was changing faster than he expected and the BAs on the team wanted to see immediate changes. This issue alone was forcing many interim builds. His solution was to place a wrapper around the library and dynamically load it at run-time—problem solved. Now a new library could be deployed at run time by doing a simple file copy.

Services
Success breeds more success. Another project George was active on needed the same solution and rule content as well. He pulled out the latest SOA framework from his toolbox, refactored the existing code and was now able to share the logic. With the service he added a logger and implemented unit testing for decision regressions. It worked as expected and performed really well.

Many Decisions Many Masters
Over time, several more applications were deployed all re-using the decisions from the SOA solution he had implemented. However, now there were 70 different end points, at least 15 different contracts, and several business analysts and developers requiring changes on a standard schedule. Of the 70 end points, many were duplicates. They had to support versioned services for various applications in production and pilot new ones.

A small team had to be spun-up to mange the “Rule Server”, manage regression and work with system administrators to deploy the supporting libraries. Business analysts were supporting the effort by providing requirements documents. Most of the support time was being taken by the requirements process and not deployment.

The Technical Business Analyst
To lighten the load of the developers, George was able to recruit a full-time analyst to take on the task of working with other business analysts. He also invested in some templates for the requirements process that he knew he could later convert to code and compile later. What he really wanted to do was provide a lighter-weight macro language that the BA could use for expressing rules, but in the end had to teach the BA basic 4GL logic and flow constructs along with object references—something he could do once but probably not replicate since its nearly impossible to find a BA with skills that reach this level of technical acumen or tolerance.

Perhaps you can imagine now many other pressure points exist such as the number of rules under management, the algorithmic complexity of the rules themselves, versioning, a simple rule expression that a BA can understand along with an environment for them, tooling for system administrators, monitoring and the like. In fact it’s the pressure points around collaboration and scaling up the dimensions of a solution that often force the tipping point. And frankly, these are not even the business arguments—these are stated from the perspective of the architect. Some wait until the pain is there while others plan ahead for success.

In short, the need for BRMS is real and present—one simply needs to see the horizon.

Here is the URL to the original “I Want To Believe” blog post.
CCB

The image above illustrates a typical JRules bug report in our Jira bug tracking repository. As you can see, the bug in question impacts four code branches and has currently been targeted to be fixed in one branch. For this bug I may spend 1 day correcting and testing it in the trunk (latest code) and will then spend at least another day merging the code changes into the different branches for each product version. Some of the merges will be simple because they are based on the same Eclipse version while older releases may be more complicated.

This scenario must be very, very common for any mature software product, so why is (Eclipse) IDE support so abysmal!?

The basic workflow I use looks like this:

• Fix bug in trunk and commit code to SVN. I use SvnX because I have found the Eclipse plugins for SVN to be unreliable.
• Add a comment to Jira with the commit number.
• Update fix version in Jira.
• For each branch:
1. Use Araxis Merge to merge the code changes into the branch
2. Run manual and/or automatic tests
3. Commit code to SVN.
4. Add a comment in Jira with the commit number.
5. Update fix version in Jira.
• Mark bug as fixed in Jira to trigger QA testing, localization and documentation updates.

The challenge is that there are many manual steps in this process that distract the developer from the real task-at-hand: fixing the bug and running unit tests. Wouldn’t it be wonderful if:

• The IDE workspace used a local copy-on-write mechanism so that there was only one copy of all files that were equivalent across branches. I.e. the file would only be duplicated (in whole, or perhaps even in part) when a change that was specific to a branch was created. This would drastically reduce the amount of disk space required as well as allowing a single workspace to be used to manage several branches.
• Selecting a file in the workspace shows you the differences across all branches for this file.
• Editing a file in the workspace automatically merges the changes into all branches. In case of conflicts the GUI allows you to manually resolve the problems.
• Jira becomes branch-aware to allow you to track the status of a bug fix across branches.
• Jira is automatically updated with commit information.
• Committing a bug fix is capable of committing to all SVN branches with a single commit - even when the commit impacts files across multiple Eclipse projects.
• It was easy to automatically run the unit tests for all impacted branches after a code change.

Perhaps I am using the wrong tools or processes to deal with this? Should I be using GIT or IBM Jazz, Mylyn, IntelliJ IDEA or something else entirely? Can it really be the case that developing software 60+ years after Bletchley Park still feels so painful?

Does this sound familiar? What tools do you use to help you in your everyday software development?

Congratulations to all the Rules for .NET team for another outstanding release!

If you are deploying RES.NET using IIS 7.0 with Windows Server 2008, then you are no longer limited to the bassicHttpBinding. Moreover, the new architecture allows one to trim down the modules used by IIS–allowing for minimal features for your deployment. You can read about the new architecture here. If you want to read about the top 10 reasons why you should like IIS 7.0, then here is a link to a blog entry from Microsoft.com operations, “The Tasty Morsels Found in Dogfood…”

CCB