BRForum Practitioner's Panel
Business Rules Forum 2006
Vendor Panel ~
The Future Is Now
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
Terry Moriarty, President, Inastrol, Inc.
- the integration of business rules and business process management
- the composition of the panel
- recommendations on training
- approach to and involvement in standards
- vendor adoption of the SBVR standard
- industry events that could accelerate the growth of business rules
- reactions to the growth predictions/statistics given in today's
- the vision two years out
- the role of open source
- the impact of embedding rules as an application component
- the 'last' in-house program
- changing our 'label'?
|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
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
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.
Thank you, Mark. Jon?
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.
Thank you, Jon. Surend?
I am Surend Dayal, the Executive Director in RuleBurst, responsible for our rules
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
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.
Thank you, Surend. Val?
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.
Thank you, Val. Jacob?
My name is Jacob Feldman. I am the Founder and Chief Technology Officer
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.
Thank you, Jacob. And, Rik?
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
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?
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
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.
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.
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.
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
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.
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
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.
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
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?
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.
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.
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.
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.
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.
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
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?
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.
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.
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, 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.
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.
That's the problem with standards, isn't it. Picking the one.
Ok. That's fair.
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.
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.
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
|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?
What do you mean by the 'technology area'?
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
You're saying "growth of the industry"?
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?
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
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
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.
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.
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 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
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,
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.
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.
We'll consider that a challenge.
reactions to the growth predictions/statistics given in
|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.
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.
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.
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.
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.
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
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.
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
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.
That's two years from now? It's now. It's today.
Under development ... it's today.
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.
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.
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
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?
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
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
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
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.
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
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?"
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
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 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.
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.
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
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?
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
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.
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.
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.
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.
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).
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?
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?"
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?
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.
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.
|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.