Panelists

Mark Allen, CEO, Corticon Technologies

Jon Pellant, Chief Technologist, Pegasystems

Surend Dayal, Executive Director, RuleBurst

Val Huber, Versata

Jacob Feldman, Chief Technology Officer, OpenRules

Rik Gerrits, Chief Architect and Chief Technology Office, RuleArts

Moderator

Terry Moriarty, President, Inastrol, Inc.

Topics

1. the integration of business rules and business process management
2. the composition of the panel
3. recommendations on training
4. approach to and involvement in standards
5. vendor adoption of the SBVR standard
6. industry events that could accelerate the growth of business rules
7. reactions to the growth predictions/statistics given in today's Keynote
8. the vision two years out
9. the role of open source
10. the impact of embedding rules as an application component
11. the 'last' in-house program
12. changing our 'label'?

.

Introductions

Terry:  We are coming to what I consider to be the most important presentation of the RulesExpo, which is our vendor panel discussion.  The theme is "The Future Is Now" and I think that many of these products are the innovators in the area.  I want to start out by asking them first to introduce themselves because we have some high-level executives within the companies here.  And also I'm going to challenge each of them to tell us what is the one feature of your product that makes you be the future, compared to the rest.   So, Mark, do you want to introduce yourself ... who you are and what you do for the future?

Mark Allen:

I'm Mark Allen.  I am one of the founders and the CEO of Corticon Technologies.  If you saw my presentation yesterday you know that we are the vendor with the 'easy button'.  

What makes us innovative and unique is, number one, making it really easy for you to manage even the most sophisticated rules ... making it really easy for you to prove that your rules are right, making it really easy for you to integrate those rules into a Service-Oriented Architecture.  

We don't do all application development; we don't do the business process management things that some of the other vendors here do.  We just do the decisioning rules and try to provide the easiest way to do that.

Terry Moriarty:

Thank you, Mark.  Jon?

Jon Pellant:

My name is Jon Pellant.  I am Chief Technologist at Pegasystems.  

I would say what makes Pega the future now is the fact that we've successfully gotten business rules out of the back office ... out of these smart black boxes and into the mainstream of applications and computing.  We're using business rules to intelligently route phone calls and to intelligently route work to people.  That cuts the staff to handle that work -- to calculate, to automate smart business decisions, to get people out of the main operations and let them spend time on what's new in the organization, to let them concentrate on bringing new products to market faster than they have before.

We are in many different industries, and I'd say that we've brought the future to now by getting rules out of the back office and making it a mainstream technology that people can use inside of every business function they have.

Terry Moriarty:

Thank you, Jon.  Surend?

Surend Dayal:

I am Surend Dayal, the Executive Director in RuleBurst, responsible for our rules technology.  

For us, the future being now is really about genuinely putting the capacity to change the rules for their organization in the hands of business people.  That's something that has been our focus since 1995 when the company was founded by a software engineer and a lawyer.  The software engineer wrote tools that the lawyer could actually use to define rules; basically he had to make it really easy for him.  

That's fundamentally what we do.  The authoring and the authoring metaphors that we provide are all provided through familiar tools for a business person, not a software engineer.  I know there are some very sophisticated products in the market but you need to be pretty clued in to be able to write rules and manage rules in those other technologies, whereas, for us, it's very much about Microsoft Office as your authoring environment, and then you deploy the rules wherever you'd like.  That's how we bring the future to you.

Terry Moriarty:

Thank you, Surend.  Val?

Val Huber:

Hi, there.  Thanks for coming.  I'm Val Huber from Versata.  

We're the company that provides breadth of business rules, unlike some of the other focuses, which are perfectly reasonable.  Our focus is the breadth of business rules to maximize business value, including the particular transaction processing stream management process flow.  

We bring this to the enterprise class of application.  For example, Versata is used to run the unemployment insurance system for the State of Utah.  We are also used in hotel reservation systems -- systems with thousands of users and many hundreds of screens.

Terry Moriarty:

Thank you, Val.  Jacob?

Jacob Feldman:

My name is Jacob Feldman.  I am the Founder and Chief Technology Officer of OpenRules.  

What makes us different?  We provide a full scale business rules management system, but it is an open source system.  We are the only representative of open source here.  

Usually open source people never do marketing and let our products speak for themselves.  You can download OpenRules without paying anything.  And I will be happy to answer questions you have.

Terry Moriarty:

Thank you, Jacob.  And, Rik?

Rik Gerrits:

I am Rik Gerrits.  I am Chief Architect and Chief Technology Officer of RuleArts.  

Being last in line, it is pretty difficult to come up with something.  So I will just say that I think that RuleXpress is the tool that supports the business rules approach as it is meant to be ... as it is described in the Business Rules Manifesto.  We support vocabulary management, fact modeling, and rule management.

Terry Moriarty:

Thanks, Rik.

the integration of business rules and business process management

Terry:  I'll begin with a question that I have.  There has been a lot of discussion about how business rules and business process management need to integrate.  In fact, there's one industry analyst who has even dropped their business rules analysis form and has subsumed it under business process management.  It seems like this might be a trend.  Or are they wrong?  What I would like to understand from the panel is:  what is your opinion of the relationship between business process management and business rules ... and what are you doing to position yourself for that integration, if you see a relationship?

Mark Allen:

I'll go ahead and start.  In one sense, in the business sense, you can't have rules in isolation; they don't have any meaning.  Rules are part of decisions, and decisions have the context of the business process.  Systems don't exist in isolation.

Now, is business rules management a component of a BPM system?  Is it the same market?  You know, it might be someday -- just like you might someday buy your entire SOA stack, which includes everything, from one source ... when there are only three vendors left in the entire software universe.  

But right now, and for some period of time, there are many, many different vendors in the business process management space.  And many of them have very different approaches.  Some of them are much better for human-centric business processes; some of them are much better for integration -- heavy integration, heavy data; some are better for documents and content approaches.  

So we at Corticon think it's very important to be able to provide a rules system that works seamlessly across all different styles of process management as a technology.  Yes, there might be one day when one product supports everything, but I don't see that right now on the radar.

Jon Pellant:

If you want to see one product do everything you can go to Booth 101.  <laughter>

But seriously...  It's critical that business rules and business process are together.  What you really want is the ability to model your business.  You want the ability to decide and be proactive in what and how you react and proact to events happening inside your system.  

If you relegate a business rule engine to a subcomponent of either one you're already limiting how you're going to leverage business rules -- you have to initialize it, you have to know what decisions you want to make, you have to give it the facts that it needs.  Whereas, if you can indiscriminately switch around control from rules to process, process to rules, rules to integration -- if you have that flexibility to model the type of behaviors you want -- then that rule engine can do much more for you.  It can look at what's happening in your business and say, "Ah, ha!  Here's a pattern that we want to be proactive.  I want run this process."  You have the ability to be much richer in how you're going to model the behaviors that you want inside your organization.  

So, yes, we at Pega think it's critical that they come together.  It's critical that they come together with all other types of business activities that you want to model and make executable.  

Surend Dayal:

I have a similar view to Mark on this one.  There's no question that the combination of rules and BPM is a lot stronger than the two things operating in isolation.  But that doesn't necessarily mean you need to have the same package doing both.  

For a lot of the work that we do, one of the big things you want for the rules is the capacity to re-use them.  If you have cached a set of rules centrally you have them available for re-use -- you might want them to be used in your CRM system; you might want the same rules to be used in your transaction processing system; you might want the same rules to be used on the internet.  

One of the good things about SOA is that it really does give you the capacity to have a central decision service that is a first-class citizen in an architecture.  That service can be used by a lot of different things -- it's not by determined by SAP in one application or Siebel in another application.  You can have the same rules supporting multiple applications.

Val Huber:

Not to break the string here, we at Versata are in violent agreement (not just reasonable agreement ... violent agreement) that business process management is part of the picture because our view is that it all needs to start with the business.  

The business views what happens as a series of business processes.  There are business automation engines that can automate that element of it, but we all know what happens -- then you get to code the notes.  We at Versata believe you should use rules to solve the notes.  

Our view is that you start with the business process.  You draw it and, when you get to an activity, you need that same rule repository to drive the screens by which someone would act on a piece of work as well as for the rules by which that transaction is processed.  You have the complete rule environment supported by a single repository, taking you from the business rules, down through screens and transactions.  

Our focus initially has been one of automation and we think that's been very effective.  But as we look toward the future, we don't think it's enough.  What we'd like to see is merging that with the business process policy view, in a functional organization that says, "Here are our policies and objectives, and this is why we have these processes."  We would like to merge that in to the goals and objectives, in addition to just the execution, and make that all completely traceable down the stack.

Jacob Feldman:

Integration between business process management and business rules management has been discussed very actively for the last five years.  I don't think it's a matter of the future; it's a matter of everyday reality.  Today, all vendors (including OpenRules) maintain that their rules engines are good citizens of Service-Oriented Architecture when BRE is well integrated with BPM.  

Probably IBM acknowledged this fact best with WebSphere (the latest version) when they published the business rules components inside their Service Component Architecture.  And now any vendor can satisfy this requirement using the IBM invocation mechanism that is well documented.  Therefore, I believe this is no longer a question to discuss.  It's a matter of reality.  

At the same time there are several differentiators that BRMS brings to BPMS, for example so-called state machines.  Rules implemented as state machines allow you to do dynamic orchestrations with business processes.  There were several presentations about this, and I can do a demonstration of OpenRules state machines for you.

Rik Gerrits:

I have little to add to this discussion except for the fact that I think that rules and processes should be separated and be distinct disciplines when it comes to modeling and management.  We think that rule re-use is optimal when you think about rules independently from processes.  

When you are thinking about your rules, you should not be thinking about the processes simultaneously.  Of course, when it comes to operations you have to tie them together.  But only when you think about your processes and perhaps want to automate them is it the time to tie the rules to processes.

the composition of the panel

[from the audience]:  I just noticed that there are a couple of significant absences from this panel, like ILOG, Blaze, and Aion.

Terry Moriarty:

The panelists are people who are breaking new ground, who have started having the greatest level of innovation in their products ... in moving us in a different direction. 

RuleArts is here because they have, in my opinion (and I picked the panelists), the only tool that has been build from the ground up with the business rule analyst in mind, and I think that's significant.  OpenRules is here because they are 'open' ... they are open source and I hope we can get into a discussion on what's the role of open source. 

Those are some of the reasons why these particular people are here.

recommendations on training

[from the audience]:  Other than the training that is offered through your individual companies, what training would you suggest for the business person, along with your own company's training?  What other kind of training would you suggest that we take, to get to from here to there, to move into the rule-based environment?

Jon Pellant:

I think it's imperative that you get the training from the vendors themselves.  But, in general, you're going to want to look at things a little bit differently ... starting by forgetting about what you've learned about software development.  You should concentrate on, "How do I model decisions?" and "How do I model how I want things happen inside the business?"  

A lot of that you can do just by looking at your subject matter experts and trying to figure out what they are doing.  And then, pay particular attention to when they are not doing what they say they are doing.  That's actually the hardest problem when it comes to business rules and modeling a business ... figuring out those dozens and dozens of ways they do things not nominally.  When you start looking at that, you're getting into your specializations and exceptions, which is where the richer sets of rules are.

Val Huber:

I think that's pretty good advice, actually.  The critical skill in using a rule system is, paradoxically, using the rules.  

Our objective is to make the whole system rule-based so there is no code.  That's an objective and we will approach it asymptotically, meaning there is still Java code you're going to have to write.  If you provide a Java exit, some developers will use it too often, so there has to be management training ... attention to making sure the business is getting the value of the rules.  

In other words, it's not just project team training.  It's management.  And, maybe even more than training, it's getting consultants who have done this before ... someone who can say, "You're going down a path that's going to lead to a more difficult situation."  Look for people who have actually done projects using rules ... big projects.

Mark Allen:

I definitely agree with Jon that vendor-specific product training is important when you get to that point.  However, if you're trying to get your arms around the general business rules approach, there's one place that you can go that's time-tested.  That's the training that Business Rule Solutions does -- I think it's called "Attaining Edge" now.  It's very good just to get an understanding of the overall business rules approach, independent of whether you are going to be automating those rules or not.

Jacob Feldman:

I might add that you may need training in generic business rule methodology (like has been mentioned) but then from the vendor's perspective I think something is wrong with a business rule product if business analysts need training.  Most of our customers (and we have a lot of customers) -- especially the business analysts -- don't need any training.

Surend Dayal:

From our perspective, certainly there's not a heavy training requirement for people to actually write rules.  For all the projects we've worked on, far and away the most important thing has been that the person knows the business.

There can be an attitude issue for people who are doing rules.  In fact, for a lot of the projects we work on with our customers, we help them identify the sorts of people who are going to be good at articulating the rules of their business.  Typically the characteristics of those people are that they are technically literate.  That doesn't mean they need to know how to program in Java or anything.  But if they are struggling with how to figure out Windows Explorer then it's going to be a bit of an issue when you try to get them to write complex rules in a document.  

On the flip side, the other thing needed is the capacity to think logically, and a lot of policy people actually don't think that way.  They think more in terms of analogy or providing a set of examples, which for a rule-driven system is not the best way to express knowledge.

Rik Gerrits:

I agree fully with Mark when it comes to training.  You need to start by finding out what a business rule really is.  Then somebody needs to help you start harvesting your rules, so that you start to understand what they are and where they are and who owns them, before you start implementing them.  Lately I have met customers who didn't yet realize that you can treat a rule as a separate thing -- as an object.  So there is still a lot to be learned, long before you start implementing rules.

approach to and involvement in standards

[from the audience]:  One thing I've noticed is that each of the products has its own niche ... its own kind of solution that it provides to the bigger business problem.  In fact, most people end up using two products -- one for some part (such as for writing and managing the rules), and one for some other part (such as for rule execution).  That means it's more important to come up with a standard for these things.  So what are your views on standards ... what approach are you taking towards coming up with a standard?

Jon Pellant:

I'm actually very involved in a few of the standards being worked by the OMG.  I've contributed to the PRR [Production Rule Representation] spec, the finalization for SBVR [Semantics of Business Vocabulary and Business Rules], and others.  We're tracking this work very appropriately.  

But the problem you get into with the standards space is that there are just a lot of them.  If you look just at what's going on in process right now, you're in five different standards bodies with seven different aspects of process.  You've got a process definition standard; you've got an exchange standard; you've got a notation standard.  They're all over the place.  

Furthermore, a lot of the difficulty you get comes when you look under the covers of all of us -- we're very, very different technologies.  We have different representations; we have different goals.  So any effort to try to normalize that isn't going to do any one of us a service.

The modeling and the standardization has to go up a level of abstraction -- it's got to get out of the individual atomic rule and get into "How do I model decisions?"  Until we get enough maturity in the industry to demand the higher-levels of abstraction I don't think you're going to see too much happen in the standards space.

Val Huber:

I would agree with that.  I would characterize that as a top-down approach, which I think we do need to work on.  

However, I think that from the bottom-up, even if we don't quite understand how things are going to integrate, there are standards we can use that provide a kind of bridge -- like using open source things such as Eclipse, XMI standards for storing meta-data, so at least the models are interchangeable.  I think that's a short-term step, but I think it's valuable.

Surend Dayal:

It's certainly our view that the lack of a standard representation format is one of the things that is holding the industry back ... and one of the reasons why this conference is probably smaller than you'd expect for something as important as what we do.  

We, as a company, have actually done quite a bit of work on interoperability just ourselves.  For example, we can take rules and run them in Microsoft BizTalk, and we can run the same rules in ILOG, and we can run the same rules in an open source rules engine or our own rules engine.  To do that we had to come up with our own XML format and then use that to transform between the different rule engines.  

The obvious thing would be to have a standard for use to do that translation.  And certainly we'll be heavily backing the OMG's work in this area because I do think that, as a market, independent of any of the individual vendors, that's one of the things that is keeping this market smaller than it should be.

Mark Allen:

We also agree that standards are important for the growth of the industry.  Corticon's position is we absolutely want to participate in those standards.  

Jon makes a point that it's not an easy task because of the differences in the products and approaches.  Another point to note is that there different things that need to be standardized.  We need to standardize the way that we interface with the rules ... the way that we call them as decisions.  We're all saying that it's the right way to do it -- abstract the decisions out of the process, out of the application -- but there's not a standard way of doing that.  

So for a few years we (Corticon) have been doing a web service-based way of doing that.  We've been promoting this as open, saying, "Everybody -- this is the way that you should architect your system, whether you pick Corticon or not."  And a lot of our partners in big companies in the industry have picked this up and now say this is the way they integrate rules.  

So that's just one standard -- how you call rules -- that hasn't yet been standardized.  Another one that is absolutely critical is:  what is the meaning of the rules, the semantics of the rules themselves?  Inside that decision service, how do you translate that to another engine ... to another representation, to view it in another form?  That is another big, hard problem.  

And, so, yes.  In order for this industry to really mature and be able to take off, like the relational database industry did, it's going to have to standardize.  We absolutely want to participate in that effort.

vendor adoption of the SBVR standard

Rik Gerrits:  To be honest, the only standard that I am interested in is SBVR.  I wonder why the vendors didn't mention that.  RuleXpress is SBVR-compliant ... at least it tries to be.  I would like to ask the other panel members to discuss whether, or when, they are going to support SBVR.

Surend Dayal:

That's the problem with standards, isn't it.  Picking the one.  

Rik Gerrits:

Ok.  That's fair.

Jon Pellant:

We've got more than 110 different models of behavior in our system ... 117 in the version that we're showing here.  We haven't quite mapped that to SBVR.  We don't see how to define a process verbally.

So we decided to go with the approach where a form or a picture says a thousand words.  It's something that you can delegate and map to in individual things.  We've found an expressive way to model very complicated business activities, and we're going to be sticking with that.

Mark Allen:

I think to get a full answer you're going to have to talk to our CTO or one of the people in our engineering organization.  What I've been told is that SBVR doesn't support everything that we do in our product.  So what we have looked at is how to import SBVR into our product to provide a subset of the logic.  

We actually are making some progress.  But I'll tell you ... as soon as a customer demands it, we'll accelerate it.

Jon Pellant:

I think that says it all.  If you guys demand these things then you'll find the vendors changing them.  But so far we haven't seen a lot of that demand.

industry events that could accelerate the growth of business rules

Ron Ross:  Okay, if it's not standards then what is the most important event in the industry that could happen to accelerate the growth of the technology area and services related to it?  What are you thoughts on that?

Jon Pellant:

What do you mean by the 'technology area'?

Ron Ross:

We're here to talk about rules technology.  I just want to clarify ... we don't have a problem with process technology, but we're focused on rules technology.

Jon Pellant:

You're saying "growth of the industry"?

Ron Ross:

Any of these:  Growth of the industry, acceleration of people's interest.  What's the tipping point?  What's missing?  What could be done to accelerate it?  What other vendors ... and I don't want to mention Microsoft, IBM, and Oracle, but you know if there are other big players who need to be in the market space, what is it that would tip the market, in your view, toward greater interest and activity in this arena?

Jon Pellant:

Well, if you look at the companies that you mention, they all do have rules initiatives.  Matter of fact, Oracle just created a very big rules presence in their organization; they essentially took JESS and are sticking with it.  Microsoft has a couple of rules efforts.  IBM has seven rules engines.

So all of these companies do have it.  The problem is that when you look at the enterprise from the top down, rules are all over the place.  Rules are, in a declarative fashion, coming down from the top -- for example, "We will be profitable; we will underwrite business that only makes 19% profit."  You've got a lot of these declarative sandbox statements coming from the top down in organizations.  

Then, you've got a set of rules that are looking at the business and saying, "How do we want to react or proact in that business?"  There are these ECA [Event-Condition-Action] style rules that are looking for business events and trying to decide what processes need to run, given certain sets of events.  Also, we've got inter-process decision rules, which are probably the classic kind, what everybody thinks about ... where you come to a diamond shape and you have to make a decision to go 'left' or 'right'.  This kind of rule tells you "how do I do that?"

At this point we have a lot of environments, with people using different technologies and different pockets of things.  There is no holistic view of rules.  So, I think one of the tipping points is going to be when people start looking from the top down and start managing rules holistically.  It will begin when people say, "Ok, let's track these all in a single repository, even though they're going to different engines."

I think that's a lot of what has to happen before rules becomes its own thing.  Otherwise, it's going to be just a plug-in ... simply features of different product sets.

Val Huber:

I have pretty much the same view, putting it perhaps differently.  If we argue about "what's the syntax of a rule?" (something we do need to do) that's going to bore our business sponsors to tears.  In fact, it will annoy them greatly.  

We've got to show them business value.  We've got to show them that putting the system into place gave them greater agility, reduced their costs, helped them make better decisions ... we have to do all this in a way that is compelling.  The message needs to be that they cannot not do it, because their competitors are doing it.  

Until we deliver that kind of business value, this is just a technology; it's not a solution.  So I'd like to see us compete and define 'business value' ... at least in some limited way.

Mark Allen:

I definitely agree with what Val is saying about promoting the business value.  We are doing a little bit of this today in terms of the case studies, but I think a lot of it is still very technology focused.  

One of the big, big problems I see is that there is not a clear definition of 'rule'.  'Rule' means something different to probably every person in this room.  Yes, you can repeat back a little definition such as "some atomic unit of logic" or "the constraints."  And then?  The problem is that all those are implemented in very different models.

We think this industry can take off if we focus on clarifying a particular type of rule that happens to be incredibly important ... and I will assert to be the most important.  And that is decisioning rules.  If we focus on that and we recognize that now, with a Service-Oriented Architecture, all of a sudden we have a home ... a place to fit decisions, I think this could take off.  

We're definitely seeing that in our business; we're riding the waves of the Service-Oriented Architecture, with business process management that allows the orchestration of services.  And all we do are decisioning rules.  We don't do all those other types of rules.  If we take that kind of focus, I think we'd benefit the industry as a whole.

Surend Dayal:

I have a fairly simple view on this one, which is that everyone here at this conference is actually pretty smart and they really know this industry very, very well.  It's like it's an academic club.  

The important thing for us to do to get this out into the mainstream is to really dumb it down -- to have some very, very simple messages in terms of business value for the end consumers of these products and these approaches.  

Certainly, from our business' perspective, the industry has matured a lot.  I've been doing this since about 1991, and for about the first ten years I had a very hard struggle convincing people why they would even bother with this approach.  

That's actually quite different today;  we have a lot of people saying, "We accept that this is a really good approach."  Now the question is, "Which one should we use?"  But still, that's the educated group.  The people within the broader IT community who are educated about rules is still a very, very small proportion of the addressable market space.  

I don't think it's really going to take off until the big guys (like SAP, Oracle, Microsoft, IBM) really start to embrace the notion of rules as a first-class entity, whichever definition of rules you choose to use.  Certainly, for us as a company, that's been one of the reasons why, strategically, we've aggressively gone after working with those bigger organizations -- that's what will then take this over into the mainstream.

Jacob Feldman:

The name of this panel is "The Future is Now" and I want to try to address some new horizons that I can see in this area.  We have been working in this area some ten years and now have a lot of real world customers.  I think we (as vendors, regardless of what products) have already achieved the commodity level; our products do what they are supposed to do as a 'rule engine'.  

But we put ourselves in a kind of a box when we limit ourselves to the 'business logic' only.  Basically the early expert systems promised the externalization of business logic, and this was a popular area for ten or so years.  Now, I see a new tendency among many of the smartest companies ... and it is not just 'business logic'.  They use a rules system as a practical tool to move from data to knowledge representation and to extract knowledge from massive data.  Yes, there are a lot of buzzwords for this.  Semantic web is the most promising approach, but there are still only a few, initial steps.  There is almost nothing really practical here yet.

So, we need to look at business rules as they are used by business people to present business knowledge today.  And I can give you two examples.  Yesterday, on the Fair Isaac website there was a very interesting announcement.  One of their European customers is now using rules to monitor out-of-hospital patients.  To do this, they represented in rules not data but new knowledge.  They are not extracting business logic; they are representing knowledge in rules, today.  Any business rule vendor can do the same thing.  My second example is a large medical healthcare provider.  They are using OpenRules to represent best medical practices -- for example, for heart attack, for diabetes, etc.  People who describe new knowledge in OpenRules are not technical people; they are business analysts, medical experts.  

Think about it.  They are writing new best practice cases, packaging them as 'knowledge units' presented as OpenRules Excel tables. It is something that they sell to their customers on top of their software.  This is something worthwhile to look at, a really valuable example to follow.  We are in the business rules consulting space, and we can see that some of our vertical customers are moving in this direction -- using rules to go from selling data to selling knowledge.

Rik Gerrits:

I'm sorry -- I have to go.  I would like to add that I cannot agree more with Surend.  The organizers of this conference must do everything in their power to get Microsoft to this conference as a sponsor.  We will try to do the same in Europe.  I think that will make it fly.

Terry Moriarty:

We'll consider that a challenge.

reactions to the growth predictions/statistics given in today's Keynote

Terry:  My question follows on to what Ron was asking.  I listened to Stephen Hendrick's keynote yesterday where he was talking about the growth:  it was organic, and it was slow, and Microsoft and IBM had to jump in.  I found that the growth projections we were given were not very encouraging ... something like 19% over the next few years.  And he said that only 2% of developers he surveyed said they'd ever been involved with rules.  I'm wondering what your reaction was to his presentation ... to his projections.

Jon Pellant:

It's actually no surprise to me.  I've been looking at this market for ten years.  We've been sizing the market; it was a $150 million market ten years ago, and it's a $180 million market now.  

I do think you'll see some changes in that market.  I think you'll see IDC and Gartner starting to drop the BRE-specificness of the market totals, and they'll start looking at the broader sense of "what are intelligent systems?"  You'll see the numbers change there.  As a matter of fact, right now they're only attributing a certain subset of our revenues to the business rule market, and I think next year you'll see all of our revenues going to the business rule market.  So you'll see that kind of elevating as you broaden the definitions.  

But I'm not surprised by his facts because this still remains a point engine within point solutions of a larger development.  In order for rules to take up a broader scope, we have to reverse the role of the rule engine ... to where it is driving a lot more of the business intent.  That's where you will see a larger value being tied to it.  And once the value is there, you're going to see a larger set of software revenues associated to the market.

Surend Dayal:

In fact, I had a discussion about this exact question after his presentation.  Certainly, from our perspective, we see a lot more growth than he presented.  The problem is where do the analysts slice it? ... particularly when you are starting to work with an SAP or an Oracle or a Microsoft, where you cannot readily classify the revenue as part of that versus as part of the rules market.  

For ourselves, this last year we were more than 100% growth, and we see that continuing for a few years yet.  I'll give you one take on that:  just the work we are doing with SAP alone has brought it home to us how small the rules market is, as a market of itself.  Our co-marketing agreement with SAP alone is going to at least double the size of our business over the next year.  And that's a tiny proportion of their addressable market space.  It's only in one vertical, and it's only in one subset of customers in that vertical.  So for me, it is all about getting the mainstream guys on board with this approach.  

As they start to realize the value, to them, of having a rules approach then the other big thing that's fairly obvious is that there's going to be some consolidation in the market over the next three or four years.  This could be horizontal consolidation, in terms of the vendors who are here (or who are not here) consolidating, or vertical consolidation into the big players.

Mark Allen:

From my perspective I think that the projections that Stephen put together are absolutely fine, and that's the only way that we're going to be the dominant leader in this market ... if the market grows at 20% and we continue doubling every year.  <laughter>

In all seriousness, as Stephen points out, the 20% is considerably more than the application development market as a whole.  I think one of the problems is that this is still very confusing to people.  What are all the different types of rules?  How do I actually use rules?  When do I use rules?  There are so many different products and so many different approaches ... and we're not all doing the same thing.  

Part of the answer could just be to send a very simple message, like "When you have a decision in a process and you want to externalize that logic, use a business rules system!"  Believe me, that is not the message that's getting out there to the customer.  We are still telling people that this is new, but why is it that this is still so new?  

So I think there's a lot that we as an industry have to clarify, just about the simple, basic approach to using a rules management system.  That will help to accelerate the growth.

Val Huber:

Looking around at my competitors here at the table, I feel comfortable making the following suggestion since they're all civilized and reasonable people.  I think that we all realize that we benefit from having a respectful competition but the groundrules have to be defined.  And my view is that the groundrules have to be around business value.  

I like the UServ demo.  What's the business value that we could define around the UServ demo?  Is it:  I could build it faster?  ...  I could change it faster?  ... People would understand it better?  And let's define this not just as something that you can either succeed at or fail at -- let's get some metrics around what it took to build it, what it took to change it, etc.  

That's not the only scenario.  Maybe some people would want to focus on decisioning logic.  So there can be multiple scenarios.  But let's define some scenarios ... attach business value to them and define some metrics around which that value is realized.  Let's try to deliver results that business people can recognize.

Jacob Feldman:

I doubt that outside of this hall people understand that there is a rules market.  When we go to real clients they aren't really looking for a 'rules' engine but, instead, for a 'decision support' engine.  Rules engines have a good reputation for creation of practical decision engines.  You will notice, if you look at vendor web sites, everybody uses magic words such as 'decision support' or 'decision science' instead of just 'rule engine'.  

A rules approach could be put forth as the most practical approach available today to decision services.  When we go to customers they don't expect us to build a rule engine for them but rather a decision service.  So, I completely disagree with his estimate.  Our market is much larger than this estimate for pure rules.  

Today we have our nice niche in business application development, but we're looking out to a much larger market in the future.  I believe that the rules approach has a really nice future.  Look at the semantic web structure that's being built.  Business rules are on top of this structure and this may have a real future.  The foundation is not here yet but we have a practical foundation we already can use with today's Java classes, Excel tables, XML files, or database objects.  These are already here and people use them today without waiting for the future.

the vision two years out

Ron Ross:  Even though the title of the panel is "The Future is Now" let's talk about "The Future is the Future."  There's a little bit of techie in all of us.  So tell me what I'm going to be excited about two years from now as things I will see from you guys.  Take this any way you want -- in terms of metaphors, or enticing business people to get more directly involved, in terms of underpinnings of architecture that are more powerful in terms of connections to other forms of intelligent systems, or ....  Take this any direction you want.

Val Huber:

Speaking for Versata, our focus has been on trying to automate complete systems from business rules, giving massive time-to-market gains.  What we want to see is then linking that back up to the business,  where we can put those rule-based execution elements in the context of what the business is looking for -- things like capturing business policies and linking which business policies are satisfied by which business rules so that there's business traceability in terms of capturing the requirements and policies, and traceability right down to the rules.  That way, IT and business are actually singing off the same sheet of music.

Ron Ross:

That's two years from now?  It's now.  It's today.

Val Huber:

Under development ... it's today.

Jon Pellant:

That's already there today -- go to Booth 101.  <laughter>  

Seriously, though, if you can look out into the future what you're going to see is the systems more closely aligned with the business.  Right now we have a huge gap between the way the business thinks about their problems and the way IT thinks about their problems.  What we've been trying to do is create an environment and a technology and a platform that allows us to start breaking through a lot of those misconceptions and start bringing control of the systematic processes of the business closer to the business.  So I think you'll see execution on that front.  

I think if you want to measure business value, start looking at the revenues that these technologies are making.  That's one measure of business value.  And what we're doing is taking off really well, according to our revenues.  

I think also we're going to see the door open wider and wider as you see these types of systems solving business problems more efficiently and providing better business value.  You'll start to see this becoming more visible to people, whether they call it 'business rules' or whether they call it 'process'.  Frankly, I think that what they call it will change.  I think we'll all be sitting here in three years very surprised what we're calling this market.

Mark Allen:

One thing you will see is the Corticon model-driven approach to managing the decision assets of an application.  You're going to see that modeling environment built into some of your favorite products.  That's about all I can say at this point.

Jacob Feldman:

I don't think you can expect a final, correct prediction from one vendor.  Sometimes a small open source company may show more innovation because we can allow ourselves to try out a lot of things, without worrying about hiding anything.  We are also working closely with leading universities in Europe and the US who are researching the same topics.  As a result, we recently introduced an integration between business rules and machine learning areas.  It was interesting to watch leading American businesses come to a European university to see where this may go in the future.  

For example, I recently had a very interesting conversation with people from an innovation center for a large United States healthcare insurance provider.  The lady who runs the business told us that the biggest problem they face is their huge data volumes, for example, the claim processing data that comes for all patients from different sources using different procedures.  All this data is coming into the same central place; their database doubles or triples every few years.  They have to accommodate the data, and they don't know how to handle/extract knowledge hidden inside this data.  They have applied different technologies and feel there are still no practical solutions.  Now they are looking into the business rules approach because it is the only practical tool available today where you can represent knowledge extracted from data and produce some concrete decisions now.

I think that things like this are our future.  And hopefully the best vendors will work to produce different integrated techniques as machine learning and optimization.  I expect that you will be able to see more results in this direction in two or three years.

Surend Dayal:

For our side, what I can see quite credibly within two years is that when you buy a copy of Microsoft Office you've got a rule authoring environment embedded in there ... just bundled with it.  This means anyone in the business can describe a flowchart or write an Office document and then know that that business logic, that decision logic, can get deployed to their ERP system or their decision systems.

the role of open source

Terry:  I'm not an open source person; I don't highly understand it.  But I do know that, in other industries, it gives me access to a lot of technology that I can start learning from.  I can begin to understand what that part of the industry is all about because the open source tools are readily available.  I'm curious to know:  what is the role of that open source capability, which seems to have revolutionized other technology areas in other industries.  Where is it for us?  Besides Jacob, is it coming?  Is it essential?

Mark Allen:

Our feeling on open source is that it is great.  Use it as a starting point ... learn.  Go and figure it out.

Ultimately I think the decision about what you'll end up working with is going to come down to total cost of ownership.  But, initially, I think open source is a great way to get your hands dirty and to begin to understand what business rules are all about.  That's definitely important.  It's a great way to increase awareness.

Also, open source does tend to work better in certain industries than in others.  Where issues around usability and the user experience are really critical, it's very hard to get that right in the open source model.  It's possible that things will change.

Jon Pellant:

We see open source as being very successful, and we use a lot of open source in our product.  Where we see it as successful is for those functions that are not where you want to invest heavily, or where don't see yourself adding value as a software company.  We make decisions on how we will invest our development dollars by asking, "Should we develop something here, or should we use something open source, or should we go buy something?"  It's all part of our decisions that we build, buy, or go open source.  And we make that decision for 'open source' many times.  How many times?  Maybe three out of ten.  

But as far as open source for high value stuff?  We're software companies ... we all have to feed our families and put our kids through school.  So we're going to find some area in the market where we can add value and charge money for that ... where we can make a business out of it.  That's where we're at.  We're all for open source for those things that we don't want to invest development in.

Val Huber:

It's pretty much the same answer for Versata.  We also make substantial use of open source.  We use JBoss, MySQL, Eclipse, and so forth.  And we get a lot of value from that.  Just like Pega, it allows us to focus on the things where we can add value.  

What characterizes all these gets us back to the standards question.  There are clearly standards for SQL; there are standards for an application server.  That allows us to build on top of those.  So where there are standards and open sources emerge, they are fabulous for us because it allows us to bring innovation to the market, to you, more quickly.

Surend Dayal:

I think open source is actually a very good thing for driving vendors to innovate more because what we see with open source (similar to what we see with Microsoft and some of the big guys) is commoditization.  For example, we have open source rules engines now, and Microsoft has just shipped a rules engine with its latest .NET Framework.  

I think that really ups the ante for people who are selling IP-based solutions and charging for them.  The customers will now say "Well, what's the value add?  Why should I use the one that I have to pay for as opposed to the one that I can get for free?"

Jacob Feldman:

As the only representative of open source here I have to tell you that three years ago at this Forum a very well-known representative of Gartner Group said the following when he was asked about open source:  "This is a socialistic approach.  They don't respect what they are doing and it's doomed."  <laughter>  

Thinking back, consider MySQL, which is probably the most famous open source pioneer.  Inintially it was not considered seriously by Oracle or anybody else.  But today MySQL has 33% of the database market share; they are number 3 after only Oracle and Microsoft.  They are ahead of DB2; they are ahead of Sybase.  And today, you heard that our respected commercial vendors have all said positive things about open source.  

I also want to make a clarification.  People often say, "Oh, open source is attractive but it's not the best implementation and not a good for serious business.  There is no responsibility, no support."  It used to be that way.  But today major corporations are involved in the open source movement.  If you look on the SourceForge website, you will find about 40,000 open source products.  Maybe several hundred of them are really used and, of those, maybe about 50 to 70 products are used actively by many business customers.  And all of these products -- I am talking about successful open source products -- are well-documented.  Usually you may find serious companies that provide good technical support behind the products.  These are companies that are very responsive to their customers.  

This is the kind of open source we want to provide.  And we are not the only company for open source business rules.  If you go to Manageability.org or JavaRules.org you will find 40 different 'rules products'.  It so happened that OpenRules and JBoss Rules are among the leaders, but 2 to 3 new open source rules products are coming out to the market every year.  Many of them are good because the rule engine itself became a commodity.  This is a fact.  And everybody acknowledges this, even at this conference.  But open source is a serious business; people compete between themselves and with commercial vendors. By the way, don't worry about our employees; we feed them well.  <laughter>

So, the open source space -- it's here, it will stay, it will influence.  This is just a little bit different business model ... one that doesn't require a lot of marketing.  It has free QA provided by hundreds of very ualified people worldwide.  It makes everything available so there is no mystery behind complex software.  At the same time we understand and really appreciate all the commercial vendors who put in so much energy and helped create this market.  Together we are all good vendors of much needed software.

the impact of embedding rules as an application component

Terry:  I'm not a technologist person so I hope I'm not saying this wrong....  I also hear about rule engines starting to be embedded in other products.  For example, WebSphere comes as a component inside this other product that we're using.  My question is:  right now we are all rule vendors and rules people on our own.  What do you think of this model of the other types of technologies starting to scoop business rule engines into them?  What impact is this going to have on our industry, if any?

Jon Pellant:

If people are finding value in rules engines I think that's a good thing.  If they are going to embed a rule engine in their projects that's very good.  There are companies out there that made a bulk of their living in embedded rule engines, and that's a good thing.  

I think you are seeing rules capabilities showing up as required features in platforms and in application servers and in process management environments.  In fact, having rules engines in process management environments is a mandatory thing if you're going to be on the Gartner slide.  

So I think you're finding rules, and business rules in particular, as a feature showing up in a lot of different, disparate places.  And I think you'll continue to see that.

Val Huber:

That's a good point.  These are the providers; you guys are the consumers (at least in large part).  Building on what Jon said, why aren't you demanding solutions like (for example) SAP to be built on rules?  We all know the story ... the people who really made the money on SAP were all the vendors who knew how to install it.  The reason it was so expensive to install it was that they were whacking code.  So, demand package solutions built on rules so you can customize and extend them without learning the internals of what somebody else built.

Mark Allen:

It seems to me that we are in an interesting phase in this industry ... kind of like where we were in the database industry, pre the relational standard.  Prior to that time, people were building databases into their applications all over the place.  That's where we are now with rules.  They're an absolutely critical part of the application.  Everyone is just beginning to understand that externalization of the rules from the rest of the logic just plain makes sense.  

People don't argue with that.  But how to do that?  People have an open question there.  In all the different standards these issues are open questions.  

When we look into the future of this industry, what we think is going to play out is that ultimately there are going to be standards ... ultimately there are going to be best of breed rule systems, just as there are best of breed databases.  There are going to be open source versions; there are going to be non-open source versions.  And the customers are going to demand that their application works with a rule system.  

We're already starting to see that, and that's driving some of our business today.  For example, IDS Scheer, the world's leader in process modeling, has announced an integrated solution that's going to be a part of their suite.  It provides the reference models for SAP.  And guess what -- it's also going to provide the reference models for Oracle Fusion.  

So customers are already starting to demand this.  They are saying, "Ok, so I'm going to model my rules in this powered-by-Corticon stuff.  Well, then I want to execute it in Corticon as well.  How do I make that call?"  

We're starting to see this today, and ultimately we'll get there.  The market will mature toward that direction.

the 'last' in-house program

Ron Ross:  I'm a former journalist (some of you may remember the DataBase Newsletter from a thousand years ago), so I can't help but be provocative.  I think all of the panel would agree that the rule engines are replacing (by whatever name) decisioning or data validation or business rules.  They are replacing the implementation of that aspect of applications as currently done in traditional application programming languages ... procedural languages.  When is going to come the day that we'll see the last in-house program written to do decisioning, or data constraints, or business rules?

Jon Pellant:

Just like any technology, there is an adoption and a maturity cycle going on.  People look at rules and it looks quite simple.  Rules are very simple.  And the first thing they're going to do is say, "I can do this myself!"  And they're going to start (probably) in a spreadsheet.  And then, maybe, it's "I can just have these decision tables in a database."  And then they find out ...  they mature and they learn all the reasons why they don't want to.  

And then they end up buying a rule engine.  Then they try to get that rule engine deployed in their enterprise applications.  And before they know it they've got things all over the place.  Now they need rule management:  "I've got five different rule engines; it would be nice if I could do rule management on all five of them!"  

So it's just part of the maturation process of the market as a whole.  When you see "the last one" you're going to be in a very mature market.  And, even then, there's still going to be (statistically) someone out there crafting their own rule engine in their garage.

Surend Dayal:

I don't think we'll see the end of application code for the decision making as long as system integrators can make a lot of money out of putting people into organizations for periods of time.  Maybe once the customers get mature enough to make the conversion model based on function points or capability rather than the number of body hours ... maybe then that will change.

Val Huber:

I think that's a fabulous answer.  It's going to be driven by business value.  It will happen only when somebody won't pay you to write code, and they'll only pay you to write rules because they can't possibly compete otherwise.  It's Paul Bunyan with the chainsaw versus the axe.

Jacob Feldman:

I wanted to say "never."  We hear for years all these hype promises of "programming without programmers" and end-users who do programming -- we all understand that these are just marketing extremes.  And extremes usually never are correct.  The truth is always somewhere in between.  

There is a tendency in the rules approach to ignore its own contribution to business application development.  We're successfully moving decision and business logic to enhance our business people, and we've already succeeded a lot.  We in the business rules world have a lot to be proud of.  

But there always will be a place and a need for good developers; they're always going to be needed ... now and in the future.  Just probably not as much as it used to be.  We can already see the demand for IT specialists going up while the availability of such specialists is down.  And in particular, in universities there is a really a big problem finding new students for IT programs.  

So, in the future there will still be a need for software people but for fewer people with higher qualification.

Val Huber:

I think that's a wise answer.  I just want to add a bit to it.  I don't think it's going to be a matter that this is the last COBOL program or the last Java program.  I think what happens is that today the applications are mainly code calling out to a rules engine, and tomorrow they morph into mainly rules calling out to code.  That amount of code goes down, down, down, down, down ... but asymptotically; it never goes to zero ... we hope ('cuz we like to program, too).

Jon Pellant:

I want to add one observation.  We can equate that process with what's happened in other industries, like electrical engineering or mechanical engineering.

First of all, look at Boeing with the 757.  When it came out, it was largely an engineering process by Boeing -- then getting the engine companies involved, and then the landing gear and the tires ... all those things together.  They build prototypes on prototypes to get things to function together.  

With the 777 Boeing decided to partner with GE and United (at the time).  They decided to standardize on CATIA; they decided to standardize on their modeling repositories.  They partnered in this approach with those top two vendors and got the 777 to market in record time.  

You look at the 787 -- they've taken that to extremes.  Everyone who contributed anything to the 787 -- whether it's the window designer, whether it's the person screwing on little caps to the tires -- whatever part went onto the 787 was done through a third-party standardized model that all vendors shared.  And they got the 787 together without any prototypes; they built the first one that's going through production.  So there's an example in the mechanical engineering industry about what happens when people start sharing their models and their decisioning ... standardizing on those kinds of things.  

Look at electrical engineering and you'll see the same thing.  You go back to 1983 -- it was very difficult to get to that 100,000 point ... just like in software, getting to the 100,000 feature point.  They couldn't get 100,000 devices on a chip ... not because the technology wouldn't let them do it but because the engineering process wouldn't let them do it.  So what did they do?  Instead of laying out chips they decided to come up with abstractions and models for what goes onto a chip ... the behaviors, the rules and constraints about the physical layout -- and they started designing the models.  Then they wrote software that took the models and automatically generated the chips.  

I think that's what you're going to see happening in software.  People aren't going to code any more.  To be honest, they're going to be doing behavior models, and those behavior models are going to automatically generate the code.

changing our 'label'?

[from the audience]:  I have a question that I think has been answered from one direction or another but maybe not head-on.  And that is:  in the future, if this conference considered its focus, should it be known as "business rules"?  Is that what we are actually talking about, or is there some broader domain, or broader focus, that encompasses the subject that we are trying to address and make known.  And, if so, what would that be?  And, if not, is it just business rules that we should be talking about?

Val Huber:

I think you're right.  I think the 'business rule' term is a problem for my company -- and I suspect for some of the others -- because some people, quite reasonably, define it as a component technology that does decisioning; other people define it as a way to build complete enterprise-class systems.  So we probably need to start teasing those areas (and possibly others) apart so we can be clear, "Am I on the right continent?"  

I don't think it's unreasonable to have all the areas come together at a 'business rules' conference, but I think we do need some terminology clarifying what our basic objectives are so that we understand, "Am I in the right tent?"

Jon Pellant:

I think that says a lot of it.  

If I were empowered to name things -- to create the next in conference -- I would call it a 'business modeling' conference.  And I would look at not separating rules from process from integration from everything else.  It's just a question of "What do I need to do to build a model of that business?"  How broad is that that requires me to sufficiently model the activities of my business and have that be automated?

Mark Allen:

Naturally you would expect that I have a slightly different perspective.  

There are modeling conferences, and there are a lot of different approaches to modeling.  There are a lot of things to model outside of decisions.  That's what we do -- decisions.  Whether this evolves into a clear focus, this is a way to help enterprises make faster, better, more agile decisions, which ties directly to business value.  Here are all the examples of ways of doing this, by using this particular type of technology, which integrates into all of your other technologies that you are using.  

That's one approach, and that happens to be the approach that Corticon is taking as a company.  I can't tell you what direction the industry should take because there are obviously many, many other constituencies, and they are all very valid.  

Jacob Feldman:

I agree that sometimes we as a vendor don't like our products to be labeled as only a 'business rules' tool.  Even more we don't like to be labeled as a 'business rules engine' (or BRE tool) but rather BRMS.  But at the same time I come especially for this conference (and I've been coming for five or six years now) because it is a Business Rules conference.  And I say we should consider the words 'Business Rules' as a brand name.  Everybody -- all our customers -- know us as a 'business rule engine' (or just 'rule engine').  

So, we should stick to this name.  Frequently a good name is more valuable than implementation itself.  'Rule Engine' is our unique label.  It doesn't matter what it means.  I would be completely against name changes.  The products may go much wider than rule engine, but we should stick to this name.

Wrap-Up

Terry:  With that I'd like to say, "Thank you very much."  Thank you to our panelists for sharing their experiences and their directions and their opinions.  And thank you to the audience for coming and joining us at the Conference.  Please join us out in the RulesExpo to see these vendors in action.

# # #