Lawrence Terrill was presenting an introduction to the RETE algorithm at the October Rules Fest 2009 in Dallas today.

To those who don’t know what the RETE algorithm, it is basically what kicked off the Inference Rules Engine world when it was first developped in 1979 by Charles Forgy. So this is a very good way to kick off a technical conference on Business Rules. The algorithm has been improved upon since the original but this was still the original work that was done.

Some of the original purpose and assumptions of the algorithm were:

• Improve the speed of pattern matching
• To offer support for rule-chaining (not simply sequential)
• Have performance at the cost of using more memory

Some of the basics of Rete:

• Two parts to the network
  • Alpha network, which is a discrimination network
  • Beta network, which is the joins between the attributes of the Objects

Because of the technical nature of the presentation I won’t go any further on that topic here. You just have to attend a presentation like that to get something out of it.

Overall though, a very interesting introduction to the RETE algorithm.

Bookmark to

Andrew Waterman gave a talk on how they use game theory to understand ecological problems used in a small university in Mexico.

In the last 30-40 years cattle ranching has become the main form of agriculture from traditional agriculture. The location is now at risk of becoming a desert. Although the desertification is a slow process, it is obviously something they want to avoid and need to focus efforts on.

First comes deforestation and then a resulting erosion. The erosion can lead to desertification.

Their interest is to understand how the social ecological systems interact with each other. The people influence the land and the land influences the people. One of the questions is about selfishness and cooperation behaviours and how they affect the outcome.

To do this, they first created a rules based game inspired by a game called Pente. They created a rules that have 2 ways of making points. A selfish way, or a cooperative way.

This is used to try and understand the psychology behind cooperative play and selfish play and to help understand what the effects of policies in the real world might have what outcome.

They bring the findings to the workers to educate what the effects of their behaviours can be over time. They also listen to the workers feedback to integrate the results back into the game.

They then developed a role playing game (RPG) that expands the concepts further. They played with workers, academics and government players and gathered the feedback from each.

This is an application of COMMOD (some framework to help gather information for analysis), which does an analysis of the situation, develops a model, create a RPG and the create computer simulations.

The talk then went into the details of the architecture of how this was implemented, the architecture and the API.

This was an extremely interesting talk that showed how rules can be used for research purposes.

Bookmark to

David Holz started his presentation saying that the goal of his company is to eliminate all programming except in rules! Obviously it is a little tongue in cheek. But basically, how do you take rules beyond business rules?

They are trying to do as much as they can in rules and can see that writing rules using that approach has some advantages. Some of the disadvantages, is a loss of low level control and some performance in execution, but claims gains in productivity.

Some of the targets for declarative style are:

• Configuration
• Partial failure recovery
• Permissions Systems
• Job Control, workflows, state machines
• Continuous integration
• GUI layout and control

Based on that list, I’m not sure we are quite ready for this type of programming, but in theory it could be applied.

To achieve this, they created a Unified Rule Engine Model. This requires that all data is actually stored in Facts and you have a single knowledge base for the entire application suite. Then the rule engine controls everything else.

The challenges in having a Unified Rule Engine Model is that all the Facts need to be persistent, so your knowledge base is no longer simply in memory, it requires things to be permanent. Another challenge is how to support updates of rules without re-firing of a rule that was changed. Scalability is obviously another huge challenge.

My first impressions on all of this is that it is very interesting from an academic perspective, but I am not sure how much can be applied in the short term. Maybe it will have potential in the long term future, but I have doubts on the short term and medium term potential of this type of architecture.

The hurdles to making this production ready, stable enough, with the persistence challenges are very hard to get over. Then you need to have successful implementations, and to start convincing people that this is the way to go in the future from an architecture point of view. Hmmm.

The presentation then talked about Design Patterns in the Object Oriented World, and how it help software development. He wants to bring this to the rules world.

Some of the rules patterns he presented:

• A consumption pattern (and some other related patterns
• Event queue pattern
• Continuation Pattern

Still a very interesting presentation although I’m not sure how the first part could really be applied today. The Design Pattern part of the presentation has a lot more potential and I would be interested in seeing more on the topic in the future which David Holz is hoping to work on in the near future.

Bookmark to

Greg Barton and Mark Sturdivant’s talk is about a rule based system that Southwest Airlines developed mainly for Dispatchers, Supervisors and Operations staff.

The system is all about to track an Aircraft, where it is going, what are they doing, etc. What happened in the past, what is happening now and what will happen in the future. They also want to track Stations (Airports) such as capacity, gate capacity and staffing capacity.

All of that information is to try and anticipate any problems that might occur in the near future in near real time while things are changing constantly (situational awareness).

The inputs for the system are:

• Aircraft positions at their originating stations
• Schedules
• etc.

A fleet of 500 aircraft can generate about 70000 change events per day caused by delays, changes of routes, weather, maintenance, etc.

They overcame multiple challenges in designing the system so that it would support their needs. One of the more difficult ones was to support a system failure and then coming back online and dealing with the time elapsed and the events that occurred during the downtime.

The system is there to giver alerts to the ground operations groups and allows them to take decisions to react to these warnings. The system does not currently suggest any course of action (yet).

Very interesting application of rules to help address a simple problem that gets complex because of the amount of information and changes in variables that happen in a day.

Bookmark to

Thomas Cooper is the keynote speaker for the conference. He wrote the original book on OPS5 way back when and has continued to work in the field since.

Some of his speech was some kind of review of what he live from an evolution perspective.

In the late 70’s and early 80’s he worked at Digital (DEC) and they were working on first generation knowledge systems (R1, OPS4, OPS5). He worked on XSEL which was basically an interface for sales people to select functionality instead of part numbers to build Vax Systems.

When they started to try building teams, they realized the best rule writers were not programmers. They needed people that could handle complexity and hired people other than programmers. Programmers had a tendency to write very cumbersome code.

They also worked on developing a Monopoly game that was built in OPS5 including random phrases that would show “personality” and they attached it to a speech synthesizer and gave them different voices. Very cool stuff for that era if you think about it.

He then went on to challenges of building very large expert systems that keep evolving with large number of rules. The maintenance became a problem. New people would get 3 months of training and then 9 months of contributing. There was a 40-50% rule change rate per year. The number of parts the system needed to handle, number of rules all variables that started making this become a maintenance and a performance nightmare.

They started working on technology improvements, worked on standards and conventions (rules, rule groups, rule naming, formatting, etc.). They had to be careful to to start rebuilding a procedural language. All of the things we assume will be present in today’s systems were just not there back then and they had to build all of the functionality themselves.

Here are some of the things they were telling new people to learn to work on their systems:

• Think in terms of rules and state
• Strive for rule independence
• user refraction
• use general and special case rules
• Etc.

Today, he was hoping that the rule technology would have evolved. It has but not as much as he was hoping for. Design Patterns are lacking in the industry. Temporal models are not as evolved as he would like (CEP and Effective Dated Domain Models).

Very interesting keynote that kind of gives us a glimpse of how things were when the pioneers in the industry started.

Bookmark to

Dr. Leon A. Kappelman started talking about enterprise architecture. He started by referring to the financial industry in the US and the fact that their models did not see interactions between the different organizations and the effects the failure of one might have on the others.

He mentioned that in 2007 he started working with a group of people on Enterprise Architecture, and they collected articles and created a book called “The SIM Guide to Enterprise Architecture”. The books is not available just yet, but should be available shortly.

He defines Architecture as the set of descriptive representations about an object. Architecture is modeling. It is about having a way to communicate with all the people involved in a project.

Models are imperfect by nature. A map is not the actual highway, it is a representation of reality. But the point is that it must be useful, do we agree on the meaning of the symbols in the model.

So why bother about Enterprise Architecture? If you can’t see it, you can’t manage it, especially if it’s big and needs to change.

Enterprise Architecture is what you need to know about an enterprise to know the enterprise. EA is modeling the enterprise. It is about creating a language to communicate with people.

A very interesting presentation overall a lot of it referring to John Zachman’s (who is presenting next) model.

Bookmark to

John Zachman started is presentation saying that the contents he wants to present us is usually covered in 7 days but he will cover it in 1 hour with us. He also made a joke about being an antique because he is using an overhead projector.

The architecture is useful when the problem you are trying to solve is complex. You create a model and when you build it it becomes an instance of that model. You could build more of those things based on the same model.

If you want to change something, you would want to start from the architecture. If you don’t have an architecture how could you know where to start making the right change? You either need to reverse engineer the architecture or start over.

Zachman speaks at an unbelievable rate and uses a lot of metaphors to communicate his message. But he basically starts explaining the reasoning behind the Zachman Framework (Abstractions versus Perspectives).

Final words: Architecture is Architecture is Architecture. The framework is applicable to enterprises as much as it is to building planes or buildings. The framework is an ontology not a methodology.

Leon Kappelman came back to put some more final words

• This is a new way of life
• It will take time and determination as well as vision, courage and commitment
• Do not get discouraged
• Set realistic expectations
• Don’t assume anything
• Learn!

There was more covered in this presentation that I could not write, so much info in so little time.

Bookmark to

Rolando Hernandez and Fred Simkin are presenting on Visual modeling to define the rules and requirements.

Textual specifications don’t deliver what is expected. The enemy of successful rule based application is ambiguity and the source of the ambiguity is text, especially when dealing with different cultures and different languages.

The ambiguity leads to bad code. Bad code costs time and money.

What works for rule based applications is not the traditional modeling used in software engineering. So to resolve the problem of ambiguity you need clarity.

“A picture is worth a thousand words.”

There are no visual representation for rules such as BPMN for business processes. So Rolando’s company has been using visual models at customer sites to help put something in a visual manner.

He is looking to the community to see what standards could be agreed to so that Rule systems can evolve. A set of standards that is not product specific.

In practice they have been using this at customer sites and they took some of the models, printed them on large paper (A0 or something like that) and put them on a table in front of the people that needed to be involved. The fact that the SMEs could touch the models, interact as a group, mark the paper with highlighter and a red pen made the review process much more efficient than trying to look at these models on the screen, etc.

Interesting presentation. I wish they had covered in more details what they would propose for the visual representation.

Bookmark to

Mark Proctor gave a talk on where he sees things going in the future of rule systems.

He obviously gave a very brief introduction of Drools and then went on to presenting a “brain dump” of ideas he has been thinking about.

In Drools, he would like to see:

• More expressiveness to support nested accessors
• Supporting method calls (not simple to resolve)
• Support for an else
• Logical Closure
• Logical Modify
• Duration, Repetition and Cron
• Execution Groups (Agenda Groups, Ruleflow Groups, Activation Groups)
• Meta-Rules for controlling which rules would fire, controlling the order, etc.
• How to make a large stateful rule engine (which requires persistence) as opposed to using stateless rule engines (Multi-Version Concurrency Control). Basically how to add functionality similar to some of the databases to allow transactions, rollbacks, etc. and allow stateful rule engines
• Positional Slotted Language (POSL?), basically provide a rule engine that can support hybrid structure for slotted and positional rule language. (The examples he gave us here were helpful in understand what he has in mind)
• Federated queries

Based on Mark’s presentation, we can expect Drools to have some of the functionality that other rule engines have or new syntax that would simplify the rule writing.

Some of the concepts he introduced are still fairly abstract and dry, but they show that one of the key people behind Drools is really thinking forward to where things can go next.

[Update]

Mark later posted his presentation on his blog. You can find it at: http://blog.athico.com/2009/10/drools-where-do-we-go-from-here-orf09.html

Bookmark to

Luke Voss was presenting on how over time he was struggling on how to represent his knowledge for computers to use.

He recently worked on what he called a “toy rule engine” in which he uses relationships between facts, not just pure facts. So the rule engine uses 2 “fact” bases, the facts and the relationships.

His representation was then presented in a graph and he tells us that Graph Theory can be leveraged to give him some of the tools he needed to deal with the data when it is structured in such a way. But now how can you use this with a rule engine?

So he turned to pattern match for structural matching and also worked with helpers so that you could use a visual pattern designer to express your pattern matching statements. This is used to generate some code.

For exploring, he uses a sub-graph query viewer, working on the unstructured data set as well as a local navigation explorer to explore the data that you have available.

He then covered some of the theory behind dealing with graphs.

He closed his presentation saying that to him, it is easier to deal with visual models rather than text models. He is thinking that there is a relative closeness between rule applications and routing problems. He also sees opportunities to extend the rule engine language for joins by inject information. He is in tune with Mark Procter’s vision of some of the features that might come in future versions of rule engines.

Bookmark to