This panel discussion delved into the use cases for Services vs. Extensions. The most memorable analogy was that Extensions are like the relationship between a parent and their children, while Services are a like a peer-to-peer relationship between consenting adults. All the panelists agreed that both serve a valuable purpose, however there is some technical work to be done to ensure that the Extension lifecycle is as rich as the Service lifecycle and that the programming model for Services is as simple as the programming model for Extensions.

Yesterday afternoon I sat in on two sessions on IBM Jazz. This incredibly ambitious project aims to break through the functional silos between the tools commonly used by developers: source code control, bug tracking, automated build, agile planning and development process support. It also exposes all these tools through Eclipse with an integrated user interface. At the core of this approach is a unified data model and central repository that stores all development artifacts, from source code, definitions of teams, projects, milestones, executable development process definitions etc. There was some talk of connectors to external systems (such as bi-directional synchronization for SVN) but my impression was that you would not get the same unified Jazz experience in a heterogeneous environment.

The process section of the demo was impressive — allowing a project leader to define the artifacts, roles, permissions and allowable state transitions for development artifacts. For example, during the demo the development process prevented a developer from submitting code without referencing a bug report during a stabilization iteration, submitting code with unused package imports or code that contained strings that were not localizable (externalized). Process definitions are defined in XML documents and are hierarchical, allowing a sub-team to specialize its development process while still adhering to the process of its parent team. Jazz supplies a couple of process definition templates, including one that models the “Eclipse Way” process used by the Eclipse Foundation as well as the Scrum development process.

Of course — the $1M question, how much will it all cost? Jazz is not open source and given the functional breadth of the offering you’ve got to imagine it is going to be pricey. Can it displace Rational ClearCase et al for large IBM shops — almost certainly. Can it displace SVN+Jira/Bugzilla+XPlanner/Rally for cost sensitive companies? Unlikely.

When I get dropped into a large codebase I like to use a software metrics tool to take a macro look at the organization of the code. Over many years the Object-oriented programming community and others have come up with a suite of metrics that can be computed for most programming languages. Architects and developers can use these metrics to detect bad “code smells”, find code that would benefit from refactoring, or perform an impact analysis before a major refactoring gets underway. Many of these are well described in Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin.

There has been relatively little research into defining metrics for rule-based systems. Here are the only two papers I could dig up - perhaps you know of others?

• Coupling and cohesion metrics for knowledge-based systems using frames and rules
• Applying metrics to rule-based systems

The traditional software metrics I find most useful are those that deal with code responsibility and dependencies (afferent and efferent coupling). These metrics are very useful when trying to understand the potential scope of a refactoring for example. Determining code dependencies is relatively straightforward, because a Java method that invokes 10 methods has a dependency on those methods. Things are trickier in the rules world because a rule may have 10 rules that must fire to set up its conditions (preconditions) and then 5 downstream rules that will fire once its actions are triggered (postconditions). Through Static Rule Analysis we may be able to detect some of these dependencies however.

Rules also have dependencies on the Business Object Model, parameters, variables and the Vocabulary, and these are much easier to determine as they are explicit in each rule.

Below are some ideas for metrics that might be useful for rule-based systems.

Afferent Coupling (Responsibility) : Ca

• The number of rules that will fire when a rule’s actions are executed
• The number of rules that reference a VOC phrase
• The number of rules that reference a BOM member

Efferent Coupling (Independence) : Ce

• The number of rules that are required to fire for a rule’s conditions to be true
• The number of BOM/VOC references per rule

Instability

Instability is defined as the ratio of efferent and afferent coupling. Of course it is easy to create a rule with an instability index of zero — just ensure the rule can never be fired! Instability is therefore a tradeoff between responsibility and independence.

I = Ce / (Ce + Ca)

Large or Complex Rules

The presence of many large or complex rules may indicate a “rule smell”. A few ideas:

• Rules that reference many VOC elements
• Rules that require many bindings
• Number of characters
• Number of conditions
• Number of actions
• Number of variable or parameter references

Packages, Ruleflows and Rule Projects

Zooming out from the individual rules themselves, many of these metrics can also be applied to packages (an average measure for the rules within a package), ruleflows (because they also have pre and postconditions) and Rule Projects (average measures as well as reporting dependencies).

Conclusions

I’ve outlined a few ideas for rule metrics, but what do you think? Is this approach applicable to rule-based systems? Do you have any techniques you use to detect bad “rule smells”?

For the past week my team has been in the “cool down” phase of a release. The “cool down” analogy comes from physical exercise, but it is equally applicable to the mental strain of getting a product ready for delivery to production. The last couple of months of a product release are invariably very busy as we process the bugs found by our Quality Assurance team and Beta testers. Working on these very detailed bug fixes or micro-features is very mentally demanding, so once the code is stabilized we have a one week period during which team members can work on anything of interest. It’s a very stimulating and productive time, as developers get to zoom out and see the big picture again, and explore synergies with technologies outside business rules.

Most of the developers take the chance to dive into a new technology, such as learning some Ruby or the Google Web Toolkit for example. On my team we’ve been looking at EHCache for performance optimizations, studying some of the scalability patterns in the Eclipse JDT and building a batch-processing prototype using Apache Hadoop.

Of course, after the “cool down” comes the “warm-up” for the next release — which for us is planning user stories and working on high-level architecture and specifications. These occur during our inception/elaboration iterations before we get into the main construction phase of a release.

Do you have an equivalent to ILOG’s “cool down” period? How do you balance individual professional development or technical research with ongoing product development?

I’ve always been very interested in the interface between people and technology, and I’ve worked on a couple of large products that simultaneously targeted several different user roles. A BRMS is probably one of the most challenging of such products because the list of user roles spans developers, policy managers (aka line of business managers), system administrators, business analysts as well as others. Each one of these roles brings a unique culture, set of expectations, education and toolset bias to the BRMS. Some vendors attempt to cram all users into a “one-size-fits-all” model, essentially ignoring the needs of one or more user roles. The poster-child for this approach is the plethora of tools for developers, of course built by developers, that attempt (and usually fail) to make inroads amongst members of the “business” roles. There are many examples within the BPM and BRMS communities. The converse is also true - tools that although very popular with business analysts fail to gain acceptance from IT more generally.

You can usually see the heritage of a successful product by looking at how they manage and store their artifacts within their repository. There are essentially two models for this: text-file based or database-based. Developer-centric products tend to favour text-files while business-centric products tends to favour database storage. There are pros to both approaches:

Text Files

• Everything is “code” or “configuration”
• Integrates well with configuration management systems
• Integrates well with text-based tools (search, print, find/replace, difference)
• Changes are isolated
• Easy to work offline (disconnected)
• Possible to automate changes
• Easy to perform ad-hoc searches

Database

• Everything is “data”
• Relational integrity between related artifacts
• Easy deployment (always deployed!)
• Easily shared with team members
• Easy to define security policy and permissions
• Powerful/performant query model
• Integrates well with reporting and business intelligence tools

Think Windows registry vs. Linux configuration files, or mbox email files vs. Microsoft Outlook PST file.

Unfortunately, as you may have seen, it is very hard (perhaps impossible?) to build a single repository that combines the best of both the file-based and database development models. In addition, one is also faced with a workflow challenge: do I want to work alone on repository artifacts or do I want to collaborate with my peers? If I want to collaborate with my peers how frequently do I want to exchange information with them, and how do I want my work to impact theirs? If you and I are collaborating on a set of resources then we can either take an “optimisitc” view of the world or a “pessimistic” view. I.e. I can assume you will not modify my resources or I can assume you will. In technical terms I may wish to take the pessimistic view and “lock” a resource I am editing to prevent you making changes, or I may wish to let you go ahead and make your changes concurrent with mine, postponing the decision on how to reconcile the two sets of changes until the last person has completed their change and the impact of the changes is better understood.

I remain convinced that the solution to this problem is to provide two repository implementations, one tuned for developer-style use cases using an optimisitc locking model and workspace isolation, the other optimized for business-style use cases, using a pessimistic locking model and a shared workspace. The challenge then literally becomes how do you synchronize these IT and business workspaces to ensure cross-role collaboration? The solution requires a robust synchronization framework that can detect modified artifacts in each workspace, prompt the user to reconcile potential differences, and move artifacts from one workspace to the other.

If you are familiar with the JRules 6.x architecture this should sound familiar: Rule Studio uses a file-based persistence model and workspace isolation, while Rule Team Server uses a database persistence model and a shared workspace for Policy Managers. In between we use a synchronization module to move artifacts to and from the two environments. No compromise BRMS indeed!

This week I am working with the Rule Studio team and the Product Managers on fleshing out and prioritizing the User Stories we will target for our JRules 7 release. I recently moved back into R&D, after over four years as a JRules Product Manager, so it is going to be interesting to see the release planning process from a developer’s perspective this time around.

If you are not familiar with Agile development methodology, User Stories are the central communication tool between product managers and the technical team working on a release. A User Story is a short (a paragraph or two) description of a usage scenario from a specific user’s perspective. I’ve found User Stories to be more useful than prescriptive requirements as they conveys the “What” and “Why” of user interaction with the product, whereas requirements inevitably get bogged down in the details of “How”. Sometimes you need a mixture of both, but even then a good user story can help frame a set of requirements within an overall context. User stories also reinforce to developers that they are building software for someone other than themselves!

For example, below is one of the simple stories that motivated changes to how JRules Rule Studio supports Rule Execution Server in JRules 6.6.

Quick Publish of RuleApps

Cynthia uses Rule Studio to develop rules for a RES-based application. She tests her application frequently; running a client deployed to Tomcat as well as using JUnit tests. Every time she builds within Rule Studio her RuleApp is automatically published to her RES server instance over HTTP. In addition she may choose to automatically publish the RuleApp to the file system.

User Stories are not the result of a product manager’s fertile imagination - most are the result of interviews with real customers or internal users such as pre-sales engineers, R&D, support or professional services. The User Stories are prioritized using the weight of evidence backing each story. Frequently requested or strategic stories are prioritized higher than more rarely encountered stories. The art of a good product manager is being able to come up with a set of coherent User Stories from the diverse comments collected during interviews. For a given release it is also common to have an overall theme that groups the User Stories (e.g. Business User Empowerment) or conversely to ensure that the selected User Stories provide something for a range of product stakeholders.

Next week we will perform the “estimation games” with the product managers. During an estimation game each development team votes to determine an initial rough estimate for the development effort for each user story. These rough estimates are then used to select the user stories in scope for a release, and ultimately to draw up a tentative iteration schedule. One of the challenges with this approach is to estimate the user stories that cross team boundaries and to determine the technical dependencies between user stories. I’m not sure we’ve found the optimal approach yet for cross-team stories, so I’d welcome your tips.