Panelists

Tom DeBevoise	Bosch Software Innovations
Jim Wray	InRule Technology
Dan Latham	Be Informed
Prakash Aradhya	Red Hat

Moderator

James Taylor

Decision Management Solutions

Topics

1. Roles on a typical rules project
2. User interface expectations
3. Educating users on the data dimension to the rules
4. Enterprise business rules management
5. Governance
6. Personalization
7. Rules in the Cloud
8. Advice to the customer

.

Welcome & Introductions

[James Taylor]   All right!  So, this is the Business Rules Vendor Panel.  I'm James Taylor — I'm your moderator and host for this little chat session with a few of our vendors here.  The way this is going to work is:  I have a few opening questions that I'm going to ask the panelists and then I'll take questions from the floor.

I'm joined today by four of our vendor representatives: 

• Tom DeBevoise from Bosch Software Innovations
• Jim Wray from InRule Technology
• Dan Latham from Be Informed
• Prakash Aradhya from Red Hat 

We're going to start off by focusing on the business bit of business rules — the business users and business usage of business rules.

Roles on a typical rules project

[James]   I'm going to start by asking you to think about a typical project.  Who makes the rule changes these days on a typical project?  Is it IT?  Is it the real business users?  Is it the business analysts?  And have you seen this change over the last couple of years?  I'll start with Tom.

Tom

Thank you, James. 

Since we're getting very heavily involved with business process management and the Inubit Process Suite, we really look at the process and the rules as one thing.  The recent research that we've been talking about is from the University of Georgia.  They've identified five impacts of operational business decisions on business process design, which are: 

1. Sequencing (what order the activities occur in)
2. Actor inclusion (who actually gets to do an activity in the process)
3. Gateway effects (what path does it take through the process)
4. Data integrity and access (such as thinking about Sarbanes-Oxley access to data)
5. Events (how do you detect events and how do you respond to those events)

If you think about these five different categories you'll see that they really define the process overall. 

Then, what we're seeing is that the processes are federated, and the roles depend on where you are in the organizational hierarchy.  The roles cascade down from the executive level, down to the different layers of the owners of the process.

James

Is this getting less technical, or is it still fairly technical?

Tom

The roles become more technical as you get lower, into the more detailed processes.  The more federated processes at the operational level are responding to operational conditions.  But at each level they are creating rules according to the objectives from above.  In many cases, the projects are coming from the disconnect with the executive or the GRC guidance, where something is not meeting the objectives of management.

James

Okay.  So you're saying it's that bridging of the gap between the executive intent and the operational realities that is driving who edits the rules and who edits the processes?

Tom

Yes.  And the rule changes could be resolved in changes in the process configuration itself, in BPMN, or they could be dynamic, as in operational decision management.

James

All right.  Jim, how about you?  What do you see about the roles involved in rule editing and rule management?

Jim

I've been in the business rules business for over six years, and in that timeframe I've really seen a big shift — from it being primarily developers and IT people who are highly technical, to it moving more to the business analysts.  I'd say it's probably 50-50 now, where we're talking to business analysts maybe half the time and the other half is with developers.

The big shift that we've seen over the past few years is that the business analysts are now bringing subject matter experts in, to look at the rules and verify that they are correct.  That's the big advantage they see to using business rules technology.  But I have yet to see where subject matter experts actually take the reins.  I may see this on some of the pilot projects, but after that the subject matter experts say it's not a good use of their time … that they still want it in the hands of someone who has the ability to think logically, to 'think like a computer'.

James

All right.  Dan, what do you see?

Dan

I see something that's a little bit different, and that's a good thing — that's why you have different people on the panel.  We do see that the users themselves are taking greater charge of the rules.  But I agree with the prior panelists that there's an evolution in that. 

With the subject matter experts we talk about policy, compliance, those kinds of things that now have to be modeled and integrated into the workflow.  And we find that those subject matter experts are going to stay involved.  Some of them work for the federal government; some of them work for your company.  You're going to get rules that are going to be modeled and delivered by all sorts of people.  But the business people are the ones that are going to have to make the risk decisions.  Because of that, we see more business people making that controversial decision as to who's going to control the rules.

James

Prakash?

Prakash

Actually the most diplomatic answer is, "It depends."  It depends on who is in control, right?  It depends on who should really be doing the change.  There are the business owners, the business analysts who understand the business ... they should really be doing the changes.  But does that really happen?  In our experience, it depends on who is controlling the solution.  So, most of the time it's on the IT/applications side … because they are the ones who are very much scared about exposing the assets (the operational assets) to the business users.

But I do think this is changing.  It used to be the developer sitting there, next to the business analyst, taking the important business rules into code.  Now it is shifting toward the business analyst side.  I agree with Jim — it's changing.  The business analysts are getting more on board with all the sophisticated tools that are available. 

Ultimately, who should be doing it?  It's the business users.  I don't think we're quite there yet, but it is transitioning.

User interface expectations

[James]   That's interesting because clearly there's a sense from all of you that there's a movement in that direction — a movement to less technical users using the rules, managing the rules, managing the process.  So, I'm curious — and we'll start with Prakash and work backward — what are the different user interface expectations that people have?  And how is that affected both by the need to make rule changes and also by the need to be able to show the rules to a subject matter expert (even if I'm not the one actually making the change)?  What do you see in terms of user interface expectations?

Prakash

So, there are different kinds of users that interact with the system, starting from the developer who just deals with the code ... who wants to see the code and doesn't care so much about all the cool tools.  Then there is the business analyst, who wants tools to create business rules.  And there are business users who want to be able to visualize the business rules and make minor updates and changes.  So, there are three different levels of users. 

Everybody will have their own favorite tools.  Developers obviously want to deal with the languages.  They want to have the maximum flexibility; they want to work directly with creating the business rules so they want this to include IDE integration.  The business analyst wants more sophisticated creation tools.  This could be in a spreadsheet-like tool or decision tables.  Or it could be some kind of drag-and-drop interface, with the ability to create the models on the fly.  That's the second level of tool.  Finally, there's the business user who wants to visualize the way the decision management is done.

Dan

At Be Informed, what we try to do is have everything working off of the models.  So, the documents themselves (the spreadsheets) come in and they are then transformed into models so that any one of these hierarchies we've talked about can easily work with, make the changes to, and understand the rules.  We end up with a common language where all users, at all levels, can actually look at and understand what's going on, make changes, and then see those changes happen, almost before their eyes.

Jim

I would agree with what's been said.  Different tools for different types of users is a big part of it — different kinds of controls. 

Another big thing that I've been hearing more and more about, out in the marketplace, is that there's a need for better impact analysis — the ability to test, even as you're writing the rules, in more of an iterative fashion.  People want the ability to see, "Here's what's going to happen when I make this change."  They also want to be able to see things retroactively:  "If I were to have made this change three months ago, what would my business results have been?"

James

Yes, and I think that's a reflection of the move to business users.  Because my experience certainly is that the less technical someone is, the more they want that impact analysis before they can trust the change they've made.  Whereas a programmer trusts their ability to make a change, a business user really doesn't.

How about you, Tom?

Tom

In Visual Rules we've been using a decision graph and decision table metaphor.  And having made a lot of very fine-focused changes over these ten years, we find that we have created a system in which both business analysts and technologists can understand what's happening.  For instance, we've implemented credit risk rating models.  Some are very large and complicated, so we'll take multiple spreadsheet pages and turn them into visual logic in decision graph notation.  We've had a lot of success with that.

To follow that up, there's the ability to test and simulate and, in particular, to store your test and be able to understand that's what is guiding the deployment of the rule.  We find that very important.  Also, simulation — actually being able to take a rule and change a branch of it and simulate it before it gets into the system.

All of these things are very important from the business analyst standpoint — to be able to see and understand what's happening.

James

Right.  All right.  Let me open it to the floor.  Let's see if you guys have a question because I've singularly failed to provoke any kind of disagreement from my panelists <laughter> so hopefully one of you has a really difficult question that they're going to argue about. 

So, anyone with a question, just come up.  There's a mic in the middle here; come and use it.  All right — first victim, uh, volunteer.

 

Educating users on the data dimension to the rules

[from the audience]   We've had rules in our users' hands for about ten years.  And while they're pretty good about building the rules, they still often have trouble understanding the data ... the element that is behind what the rule is talking about.  I would like to hear how you educate the users on the data running through the rules engine.

James

That's a great question.  It's certainly one of the big challenges with any rules-based system — do people understand the data they are writing the rules against?  It certainly comes up. 

Who wants to take a first stab at this?  We'll do this free-form.

Jim

Can I ask a follow-up question of the questioner?  What are some of the specific types of issues that you are having with understanding?

From the Audience

A big one is data interactions.  For example, they expect because field-A is there that field-B will always be there, and that's not the case.

Prakash

I think this starts with the human interactions.  There are different kinds of rules and different ways of creating the rules — there are so many different ways (authoring options) that are available.  The first and foremost is the interaction between the business person and the person who understands the rules system … it could be a developer or engineer who understands how the rules engine works.  (Every engine behaves in a different way.) 

Ultimately, when you think about creating the business rules, the engineer and the business analyst get together and understand what they're trying to create.  A rule could be a technical rule (a purely technical rule enabling certain line items in the business solution) or it could be a business rule that is clearly visible to the business user (based on these business conditions you want to apply these certain things).  Creating the conversation — that education — between the two is going to be critical.  This involves educating the business analyst about all the different kinds of authoring options.  For example, it could start from something as simple as a spreadsheet, or it could be something more advanced. 

So, I think that's probably a good starting point ... educating both kinds of users and showing them all the different options.

James

Anybody else?

Tom

There can be a lot of disconnects between the data and rules that created that data.  Yes, this is a problem (a challenge) that we have.  For instance, with Basel II compliance:  At the time that the loan officer makes a loan he might have one set of rules.  Then, in the next month, those rules will change.  In that case, looking purely at the loan data is not going to give you the understanding as to what constraints and guidelines exist.  There's no way to look, physically, at the business objects or relational tables without the context that goes with it.

Jim

I think that testing comes in here as well — it's helpful to be able to test against your live data without actually being in the live environment.  Just yesterday we released a product that works with Dynamics CRM (which is Microsoft's CRM product).  We've had a testing tool in our product for a long time, but you had to hand-enter the data.  So, someone who's writing the rules could say, "Oh, I'm gonna enter these fields, and I know that field-A is there so field-B is always there."  But in reality you know that field-B is not always there; it's not always populated.  So, what you can now do is point to actual data from your production CRM system and load that in to the testing tool and see what's going to happen, before you ever push anything out into production. 

When you're doing your testing you want to give the users the ability to test against records that they are familiar with … where they know they've had a problem in the past.  Then they can pull those into the testing environment and make sure it's not going to break anything.

Tom

With Visual Rules at least a third of the effort of creating the model is in creating that library of tests, including use case tests.  Then, in the deployment of the rules themselves you can use those tests as a gatekeeper so that you have that assurance.  Getting to the data in your operational system and relating it back to the rule can be complicated if you have not created that connection between the rule and the application that created the data.

Prakash

This question brings up a really important aspect.  You have all these models and you create the rules ... but are those the right rules?  At one level there is testing and simulation, making sure those rules behave the way you expect them to behave.  But going beyond that, it's also important to analyze if you have sufficient coverage.  Have you covered all the different cases that you can think about?  Does the model really reflect all the different conditions?  Say we have four rules — does that cover 100% of my cases?  Is there anything missing?

These analysis tools are also very critical to help you find out where the gaps are. There are some sophisticated tools out there today that can, once you've authored the rules, do the analysis and tell you, "Okay, here are some of the gaps." 

Dan

I would add that there's an aspect of cultural change.  It used to take 9 months to make changes and now it takes 9 minutes.  But the fact that you can make the change in 9 minutes doesn't mean that you should make the change in 9 minutes. 

IT and the user have to figure out how we move ten times faster than we used to and still do that testing.  Our models are the same as what you've been talking about — you do the regression tests:  change is made in the morning, regression test in the afternoon, results the next day, implement in the afternoon (given everything moves the way it should).  And that's an environment that will be challenging to a lot of companies.

James

There's a lot of variety.  You see everything from "I've accelerated it from 9 months to 9 weeks (or 9 days)." to "I'm changing it 40 times a day." — there's a whole range of possibilities in there.  It makes a very different environment.

Okay.  Anybody else?  Next question.

 

Enterprise business rules management

[from the audience]   I've been playing with business rules myself for awhile, and I have a question.  One of my quibbles with the business rules execution-oriented vendors is that the concept of business rules tends to be a very project-specific thing.  So, you could do an impact analysis but it tends to be only germane to one, very-focused vertical application of business rules.       I'm curious to understand what demand you are hearing from your customers in terms of enterprise business rules management.  Is there anything about that in your product roadmap and strategy?  For example, for some of my customers, the entire organization is based on policy or legislation and they are looking for enterprise business rules management — where you can pull that string on one element of an actor or a piece of policy and be able to understand everywhere that rule manifests.       I've seen implementations or applications of business rules technology where there's really cool, neat stuff but it's all in a fairly focused context.  It tends not to be repository-based or really large in its scope.  Is this something that you're hearing your customers ask for?  Do you have roadmaps for anything like this?

James

I want to clarify one thing.  There are really two ways people use 'impact analysis'. 

• One is the design impact analysis — I've got a rule or policy; it needs to change.  Where's that going to have an impact? 
  
  
• Then there is the impact analysis that uses live data — if I make this change who would have been treated differently? 

Are you looking at both of those or one in particular?

From the Audience

Actually, my question is the former.  But you're right — often times, especially with eligibility decisions (where people who had been booted out 3 months ago would now be eligible, or vice versa) that's also important.  People can sue over that.

Tom

This is in the realm of what we call simulation.  The way we approach this with our tool is that you're able to create rule sets where you can impact (and replace) large segments of your decision tree and your operational decision.  In Europe, we've been using this in our credit risk rating platform for stress testing banks.  We can change underlying assumptions, such as the loan-to-values in certain neighborhoods, and then rerun the impact and look at the overall health of a portfolio of loans.

This relies on the modular design of the rules themselves.  If you have created a good federated design, you can take out a portion of the entire rule set and then run based on new assumptions.  So, yes, this is something that our large financial customers are very interested in.

Jim

As you've mentioned, what you've probably seen is that, in a very focused environment, there is a lot of really cool stuff, but once you get out in the wild, and you're dealing with big systems, it becomes more difficult to implement.  We see that all the time.  These can be really tough problems to solve because you're trying to figure out all the different data sources that someone might put into a rules engine and all the different data sources it might affect. 

With our product, you're going to be working against our SDK to do some of that work.  For example, when you're loading data in, we could create this great out-of-the-box tool that demonstrates wonderfully … works great in 70-80% of the scenarios.  But then there are going to be situations where there are just unknowns that we could not have anticipated, and it's not going to work quite so well. 

That said, there are times we do know about the environment (and I referenced the products that we've built in conjunction with Dynamics CRM):  We know the data it's running against; we know how it's going to be executed; we know what types of events the rules would be executed on.  In those cases then we do have, on our roadmap, to provide impact analysis in that product line.

Most often, you've seen it with the horizontal tools, where it's BPM, Rules, and Analytics — everything's rolled up into one package and you have to buy in to that whole package.  You're going to see more best-of-breed solutions starting to build on top of other technologies and having connectors that provide the impact analysis in other types of tools — analytical-type tools for the rules.  That will be really helpful.

Dan

Let me give a possibly different look at the same challenge.  The way Be Informed is put together,  the rules are written once; the roles and responsibilities are defined once; knowledge is captured once and modeled.  And then, no matter what the process is, each time the invocation is going to be on a dynamic basis, based on the characteristics of the transaction.  From the standpoint of how the rules can be managed, if that rule changes then it could change the business processes but that is all dynamic within the system. 

To comment on the second piece, which was the risk analysis, it's the same kind of thing.  You can take a year's worth of historical transactions (as an example) or build your transaction load and run it against those systems and determine what the outcomes are going to be.  As an example, one of the systems we built was for immigration.  In that system, we can take all the applicants for immigration and we can run that load against the system, based on the laws and how we want to change the laws, such that we can allow more immigrants from one country to come in by changing the law.  So, you can change the rules to change the dynamics of how a country runs or how a business runs.  You can anticipate what your lobbyists are going to do in Washington to protect you, and if this happens what's the cost going to be.

This game is getting very sophisticated … what you can do, both in a predictive way but also in a change-modeling way.

Prakash

Initially, when I heard your question I wondered if we are really looking for an impact analysis tool to figure out if rules (the BRMS) is the right solution?  Are we looking at:  Does it really have an impact on business value when we create that solution? 

To be honest with you, not every solution needs a BRMS.  We might love to see more and more BRMS, but the reality is that if there is something that will be built once and deployed, and you never have to deal with it again, then you probably don't want to use a BRMS.  Yes, there are some instances you can think about where a BRMS is a good fit:  some decision that has been made all along and it's made real time, taking advantage of all the real-time business events that are happening.  When you're creating that kind of solution, a BRMS makes logical sense.  But beyond that, when you consider the impact, you really have to ask, "Does a BRMS really help?"  You have to look for situations where the solution is going to add value:  wherever the policies change, wherever the regulations are heavy so it definitely adds a lot of value, where there's a lot of agility to build on.

I can give an example.  One of the government agencies has tried to do a scaling system based on multiple constraints that exist, and it has such a volume of data that with someone sitting there and doing it manually it would take something like one to one-and-a-half years to get a response back to the client.  Now, with all the systems in place they are able to bring it down to something much, much more manageable.  Where it was unacceptable for somebody sending in a request to wait one and a half years to get a response back, we can now do it in a reasonable time ... a few days response time.  This is an example of a good impact that a BRMS can have on a solution.

James

All right.  I know we had another question, in the back there....

 

Governance

[from the audience]   We have a rules engine, and we've been in production about twenty months and we're just now starting a governance process.  I would really like to hear, from some of your successful installations, what some of the key points of the governance process were.  We think we know what it is, but I would like to hear, from the most successful programs you've seen and have put in, what should be in a governance process.

James

Great question!  So, governance processes.  Who wants to go first on governance?  What are the key things in a rules governance process ... to make sure it works?

Tom

Governance is either we have new objectives or we're out of compliance with some existing objective (and let's not talk about technical performance here) — we're simply not meeting the objectives of the organization somehow.  For compliance, there needs to be a development methodology that has some way to put metrics on achieving the new levels of success, while not breaking the old process. 

This starts with the development — development is assured that they are changing the proper artifacts to meet the objectives — and then has an already-existing testing program that moves through to production properly.  Also, some customers (and again this is on the roadmap) want to have a physical signoff so that, top-down, there is a division owner actually certifying that all of that has occurred ... that you've selected the proper development artifacts, done the proper testing, and so forth.  In other words, you have the four-eyes concept implemented in your workflow and are actually approving the change as it moves into production.

From the Audience

Can I summarize that as impact analysis and source control?

James

I think the key thing here is that there is a need for a methodology.  You have to actually explain how you're going to do this.  The sense of "test first" is clearly something important.  And that there's a very clear definition of roles — who's allowed to do what, change what, approve what — being really clear about that.

Tom

For us, impact is that we know that (say) these three things are related to the change we want to make.  That's the first level.  Then we might make those changes and make certain that we are achieving the objectives that were laid out.  And, finally, we go through the methodology and have people sign off on the fact that the methodology was completed.  That's what we're doing with our central repository control.

Jim

I started my career out at Deloitte as a business process guy, so (putting my consultant hat on) you want to make sure you have a clear understanding of what the governance processes are, defining whose opinions are going to be important.  If you don't get that nailed down you can throw as much technology as you want at the problem, you're not going to solve it.  So, first and foremost, that's the most important thing. 

Then, once you understand all that — once you know what the timeframes involved are, you know who the people involved are, what information they need to see — the technology problem becomes a lot easier to solve because now you know:  Is the workflow approval going to fit the bill?  Are you going to use a BPM tool that you have in-house?  Do you need something that you don't have?  You can do that gap analysis of:  What do I need?  Do I have clear processes defined?  What does the technology provide?  Is it going to fit what I need it to do?  If I put my consultant hat on, that would be my recommendation to you.

Dan

Governance, to me, is just another process.  It has roles; it has responsibilities; it has knowledge.  It's a workflow that you have to build and you have to manage.  Technology can help you manage it but it's no different than any other workflow that you have in the company.

Prakash

Yes, I agree with all the comments that have been made.  My sense is that governance is the most critical piece in the organization because (and we talked about this earlier) it asks:  Who should really be creating the rules?  Who should really be interacting with the business rules?  Yet the reality is something different than what we want.  The business users who understand the business should really be the interface with the business rules, but the reality is that the IT operations guys are doing the most critical work.  Why is that happening?  It's because of the gap in trust between the two.  IT operations is trying to keep it controlled for fear that if it gets out of their hands something might get messed up when the business user doesn't do something right.  It's a very risky proposition. 

So, I think it's very critical to have solid governance built into the system.  We've talked about how it used to take 9 months to create a change in the system and now we can bring that down to 9 minutes, and if you enable that kind of change that's a huge level of risk in the system. 

An organization wants to be agile but at the same time doesn't want to take too much risk.  One way is to keep a clear audit log.  Then if there's an issue with anything that's changed, you can go back and look at the audit log.  Also, the workflow is a very critical thing, —having a built- in workflow within the system is great.  Finally, the tools are important — the ability to do some impact analysis — so that whoever makes the change can use those tools and make sure the changes are consistent.

James

I would add something from my own experience using different tools over the years.  I think you've done a very good thing by not attempting to put in governance before you have some experience.  I see as many projects fail because they put in too much governance, as ones that fail because they don't put in enough governance.  Some organizations have an obsession with "I can't put any rules into production until I've defined an entire governance process, for a product that I've never used."  So, here is one definite best practice:  Don't attempt to define all this before you have at least some experience using the tools.

Tom

So you think we should wait until the first failure to put our governance process in?

James

It depends on what project you're on.  On some projects, that would make sense.  It depends on how expensive your governance process is and how expensive a failure is.

My experience is that there is no one governance process within an organization. You shouldn't think you're going to maintain all the rule sets, in all your systems, using the same governance process.  Some are going to change much more often than others; some are going to be much more important — the cost of failure in some will be catastrophic while the cost of failure in others will be mildly irritating.  And so you need to build some flexibility into your process to allow for this.

Tom

The customers who are asking us these questions are the large financial institutions who have been doing this for years and who have huge, complicated, multi-thousand-rule rule sets.  There even the best testing becomes challenging.  So, yes, there comes a point where you absolutely have to have a governance process.

James

Yes, absolutely.

Tom

But I do agree with you.  You just need to start doing it.  The benefits will be there.  It's when you get into these highly-matrixed situations that you need the governance process.

James

All right.  Thanks very much. 

We have another question here, right by the mic.

 

Personalization

[from the audience]   I want to touch on another aspect of governance, starting with the question:  Who does the rules?  Is it the business user or the technologist?  The answer is certainly that there isn't one way that fits everybody's needs.   But what I don't see in any of your products is something that would help me (as a CTO) bridge the gap, where I can allow some business users — because they might be knowing the product and be capable of changing the rules — without worrying that they are going to break the performance of (for example) my web site.  And vice versa, I don't need to teach them how to expose a web service … because that's something that they should not need to know.      So, have you guys thought of having a layer over your rules, where they could help governance, where you could actually personalize what can be changed within a rule and by whom?  I would like a business user to be able to change a decision table or to move some of the components of my rule but not necessarily break it all apart.

James

All right.  So, that's an interesting question.  You'd like to let people personalize how they can interact with the rules in a way such that different people have different kinds of permission, based on their own personal experiences.

Prakash

Let me take a stab at that. 

You're right.  Everybody has their own choice on how they want to create business rules.  But at the end of the day that may not be sufficient; you may not be able to create all the rules using one pattern of options.  A lot of the business users just want to get started, say in a spreadsheet format; they don't want to switch to a new system of working just so that they are using the rules engine.

So, I think it is important to provide the flexibility to the end user, whoever it is — whether it's a developer or a business user — to provide different kinds of options.  That could be a spreadsheet.  Or you might want to replicate the spreadsheet in a decision-table-based tool, where they can visually see things, make changes, and see the impact right there.  Or for developers, who don't want to see a picture, they might want to be able to understand the rules language and to deal at that level.  Finally, there are new kinds of business users, who don't want to understand all these decision tables and spreadsheets — they just want to work in plain English.

Those are all the different options.  Everybody has their own preference.  So, you probably will not be able to achieve what you want with only one choice.  It will likely need to be a combination of multiples of those.  That's where I feel it's important to have the interaction between the technologist and the business user.

Dan

I must step back for a second because the other three people on this panel are much more experienced with business rules than I am.  My background is more at running businesses and so, as a CEO, you really want to look at "How can I innovate?" and "How can I grow my business much faster than it can move on its own?"  That calls for a linkage of people and process and rules — all of those things. 

As I look at the question in one context I thought your answer was superb.  In another context it needs to consider:  What is the relationship of those rules to all the other facets of my business?  And can I link those logically to roles and responsibilities of individuals?  Can I link those to given processes?  Can I link it to knowledge, which can be either rules or just pure knowledge that's given to the knowledge worker?

If I spend my time on those linkages and those relationships up front then I think that question about personalization starts to go away because the personalization is already there.  The CEO has gotten involved in saying, "Look.  Here are the priorities.  Here's how this relates to this.  And how these things relate to the others."  Those aren't going to change.  Consequently, as you move forward, the users are going to have more freedom to make the decisions.

Jim

The whole personalization question is always a tough question.  Everyone has different opinions about what the best way to work is.  But if I understood you correctly you are getting at making sure, from a CEO's perspective, that people can't make rules that are potentially damaging to the business?  Did I get that right?

From the Audience

That's right.

Jim

Okay.  Yes, so, the way we've tackled that in our product for years is by providing a security model — role-based security — around who's allowed to edit rules, who's allowed to view rules (that sort of thing), who's allowed to publish changes into certain environments ….

From the Audience

And I want to make sure that this doesn't harm performance ….

James

Right.  These conditions can be changed by this person; all the conditions can be changed by this other person; this third person can't change any of the conditions but can change the allowance.

Jim

You're talking down at the detail level?

James

Yes, within a rule.

Jim

Yes, we've done that for years.

So, for example, you can absolutely give someone universal rights — they are, in general, allowed to edit these rules, but there are ten of them that are highly sensitive and we're going to flip the switch on those and override their default so they cannot do it.  Or vice versa — you could say, at a high level, they are not allowed to edit any of these rules except for these four or five. 

Going beyond that, I could see you wanting to steer people into certain ways that they author rules by following certain patterns.  That's something we've discussed in the past, but it's always been a little bit cloudy, a little bit tough to pin down as to what that would be.

Prakash

To add one point, I think you are looking beyond just the rules.  For example, these rules can be accessed by this user; these rules can be modified by this other user.  I think you are probably looking within the rules to the level of some conditions (some values) and saying, I want to let the business user change only this particular value. 

We are hearing requests for that level of granularity a lot, especially from the financial customers; they would really like to have that kind of granularity for the business user, and with governance so that it's even more controlled.  So, yes, it's doable but again not every tool can support it today.  But we definitely have it on our roadmap.

Jim

I would say that, peoplewise, what you describe is going to be really tough to manage.  When you are talking about a large-scale rule implementation, you could be talking about millions of points you're trying to apply security settings to.  That could be a bit of a challenge.

James

How about you, Tom?

Tom

We're doing the same role-based security privileges.  It depends on how you organize your projects.  If you have particularly-sensitive rules then they need to be isolated in a manner that's easy to manage.  But you also should not discourage creative exploration.  It should be very simple to set up a sandbox and allow people to do their own visual sensitivity analysis. 

You can see how complex it could get.  However, if you can allow the people who have the vision to go in and tweak things then they can make an argument for an improvement that you haven't quite seen.  It's amazing the level of understanding of these rule sets that the people can get and how they can impact things like credit ratings and so forth.

James

It's interesting to me, listening to some of these questions, to think back a few years — when all our systems were written in code. Then it would have been inconceivable to even ask somebody, "How do I make it so that some of my business users can control some of my decision logic in a way that I define?"  You just wouldn't have thought of this in the list of things that were possible.  So, one of the things that is interesting — and a challenge for the vendors — is that as people get more used to these technologies, the questions get more difficult:  "That's okay.  I can do THAT.  But I want to actually do THIS too!" 

And so we see this escalation in business ownership and in business sophistication.  You meet business people who feel a sense of ownership of their systems, and five years ago you never met anybody who thought that way about their systems.  And now, increasingly, you do.

Jim

I will say, too, with that evolution it's my job (as director of product development) to pin people down as to what they actually need.  That is getting increasingly difficult.  As you get further away from people who are grounded in technical realities you hear, "Why doesn't it know what I want to do?  Why doesn't it know this is how I write rules?"  It gets really challenging to nail that down to where it's something that can be used by a broad audience in a meaningful way.

James

That's true.  You're almost starting to have to deal with consumers as input to your product design, instead of just programmers.

Jim

Yes, but it's fun.  It makes us better.

James

We've got time for one more question, and then I'll ask the guys to do a wrap-up.  Is there anyone who has a question who hasn't asked one yet?

 

Rules in the Cloud

[from the audience]   This is an obvious question, and I can't believe it hasn't been asked.  What's the impact of 'cloud' as a service on your models ... on where you think business rules are going to go?

James

How does the growth of the cloud (and the growth of software-as-a-service applications) change what people are asking for in your product or how they are using your product?  What do you see in terms of decisions-as-a-service or the move to using cloud-based services?

Tom

I think the industry is wrestling with the different pricing models for accomplishing that.  The technology isn't the problem.  We understand what the technical requirements are.  What we need to understand is the business model for moving forward with these products. 

Corticon was there for a little while and then they took theirs down.  IBM is also up there.  So, the whole industry is looking at this, and I think in the next 24 months we'll have it nailed down.  It'll be there.  It'll be available.  It might not be the way you want to go, but it's going to happen.

Jim

I've experienced something with 'cloud' (and I think this goes beyond rules in general).  We've worked on a couple of deals recently (Microsoft shops primarily) where, the whole way, they were saying, "We're going to use Azure.  We're ready to go.  We're going to deploy this thing out there so we can scale out as much as we need to."  And then, when it came time to pull the trigger, it was, "W-e-l-l-l-l, we're going to host it all on our own machines." and "We're not quite comfortable pushing our data out to the cloud yet." 

I think that's where the market is right now — people are still not totally sure they want to pull the trigger on public clouds.  So, the interim baby step is that we're going to be running inside people's corporate clouds; they're going to go that route first.  Then eventually, down the road, we'll move into more of the public cloud. 

But I agree; the technical hurdles aren't that tough.  These are still servers; they just happen to be located somewhere else.  So, technically it's not that hard a problem to solve.  Getting the financials nailed down around it and making sure there's an appetite out in the market to move to it are the primary concerns right now.

Dan

Agreed.

Jim

This is the most agreeable panel of vendors.  <laughter>

Dan

As you said, from a technical point of view, it's just not an issue.  From a risk point of view it's an issue.  Who wants to take how much risk?

Prakash

Absolutely.  The technology's already there; there's no big challenge. 

We have made a strategic move to move to the cloud, and there's a lot going on in support of that.  We've created OpenShift in the cloud environment so that we can host solutions (and so forth).  We've been getting a lot of pressure from our customer base to be able to provide the product.  There are some middleware products in OpenShift so we already have BRMS deployed in the cloud.

If you've got all the technology that works there that's great.  But we still haven't figured out the pricing model.  That's still a challenge, understanding how much people can really consume.  Can the host justify a decision as a service in the cloud?  What is the value of that to the customer?  Quite a few customers have deployed these products and have built solutions and deployed them as software services so we have quite a few examples of that.  But monetizing, creating decision services, I think it's still early.

 

Advice to the customer

[James]   I'm going to take the moderator's privilege and ask the last question.       Think about customers you already know, who are already using your products.  What I'd be interesting in hearing from each of you is one thing that you would say to your existing customers as a piece of advice:  something that they're not doing (or that very few of them are doing, or that they're not taking enough advantage of) that would make a big difference to the ROI they got out of using business rules and business rules management systems.  What is that one thing you see some customers doing but most don't, or that no one does, something that just isn't getting the traction that it could.       Let's leave people with something concrete.  I think many people here have a rules engine so let's give them some practical tips.       Why don't we start with Prakash down at the far end?

Prakash

Some tips ... one thing that I'm seeing is that the people who are relatively new to the BRMS system don't have a correct understanding of how the BRMS system works.  Traditionally they come in with the view that "If I send out a question, I get a response back."  But that's not really the way the rules system works; it's a decision system.  You create the business rules, create all the data/data models, and tell it, "Okay, here is my condition.  Tell me what I'm supposed to do."  There needs to be a change in the thinking paradigm.

James

So they really need to invest in understanding what this new kind of system is — don't just use the technology as a technology.

Prakash

Exactly!

Dan

My comments will be three-fold.  The first is:  What impact does this kind of technology have on the business operation?  This is from two points — one is cost and the other is time.  From a cost point of view, when you're talking about 30% reduction in operating cost because of the new kinds of things you can do, that's noteworthy.  When you're talking about getting into a market in thirty days that you've just figured out you weren't into, that's noteworthy.

The second piece of advice is:  Multiple times I talked about rules, I talked about knowledge, and I talked about roles and responsibilities.  If those things get documented correctly (and no one's to say that they will, but assume they do), then you can move as fast as you want, and things become much easier, much quicker — the business people can become involved, etc.

The third is the risk equation and particularly as it relates to compliance.  Compliance is going to kill us — particularly in this country — in fact, it is killing us in this country.  So, compliance is a set of rules that have to be integrated into the workflow for the knowledge worker.

I'll give you my parting shot:  last century Drucker said, "We increased worker productivity in the factory fifty-fold.  What we need to do for the knowledge worker in this century is increase it fifty-fold."  The kinds of things that you're involved in are where this fifty-fold is going to come from.  And so going out there and taking a risk — putting together that pilot we talked about — those are the kinds of things that I see customers hesitant to do.  But it's a new world, and if you don't do it, somebody else is going to take that step and you won't catch up.

Jim

The biggest tip that I'd give our customers — especially new customers — is to clearly state what your goals are … clearly state what the roles are going to be.  This dovetails with what you're saying:  You need a clear definition of what it is you're trying to accomplish. 

I can't tell you how many deals I've worked on  where there's just not a clear definition.  I'm trying to pin these guys down:  What are you trying to do?  What do you want to use our technology for?  I can help you figure it out, but you've got to tell me.  And they don't even know.  "Ah, management says we've gotta do this thing.  So, we're just kinda going through the motions." 

That's the biggest thing you can do for success.  And that's true of any technology.  You've got to clearly define what your goals are and what you're trying to accomplish, or you're just going to have a whole bunch of software licenses that aren't really implemented and aren't doing you a whole lot of good.

Tom

That's interesting because most of our customers are coming to us to solve a specific problem!  They know exactly what they want.  A lot of times it's because their backs are up against the wall.

So, if I had anything to tell those customers it would be, like the panel has said, to evangelize the benefits of using the product to the other groups in your organization.  You can use that in an entrepreneurial way to (as we discussed) set up private clouds.  We've been talking to two customers already who are talking about using our product to create a private cloud.  They're going to use charge-back to put those services out there.  So, you can monetize your own technical success and expand your agenda to include other, similar problems in your organizations.

James

I'll just add that I used to say the median number of successful rules projects at a company was one.  A company would get a technology; they'd use it; it would be very successful — and then they would singularly fail to change the way they would build the next system.  So, I would reiterate what pretty much everyone on the panel has said:  You need to not just use it to solve the current problem that you have but go look for the other decision-making problems that your business suffers from and see how it can improve those as well.

Wrap-up

[James]    With that I'd like to thank our panelists.  Please join me in thanking Prakash, Dan, Jim, and Tom for their time today.  Thank you!  <applause>

# # #