Panelists

• RR = Ronald G. Ross, Business Rule Solutions, LLC
• CJD = C.J. Date, Independent Consultant, Author, Lecturer, and Database Researcher
• TM= Terry Moriarty, Inastrol
• RB= Roger Burlton, Process Renewal Group

Moderator

*/ ?>

• GL = Gladys S.W. Lam, Business Rule Solutions, LLC

Introductions

[GL]: Welcome to another panel session. Wow! All these die-hards ~ staying to the bitter end. You really want to hear what we have to say. I thought it worked so well last time that we would start with the panel members ~ our four gurus ~ to start off the conversation with their vision of business rules: where they see business rules going, where we are today, and what they would like to see happen, both in the next few years and in a longer-term perspective. And then I'd like to open up the floor to the audience and have you fire off your questions ~ as many as you can, and we'll have fun. Let's make it casual. So, relax, let down your tie and roll up your sleeves, and let's get going.

RR

*/ ?>

I think I'll start out by focusing on the 'good news' ~ some things we've seen in this conference, some things that we've seen in the last year of practice, and then talk about areas where there could be some improvement. In my view, during the last year in particular, we've proven that business rule repositories are possible and desirable and very effective. And now we have tools to select from to help us in that business-oriented rule management.

Secondly, I think that in the last year (and reflected in many of the presentations here) we've learned a great deal about business rule methodology, and we have proven methodologies that have been applied in practice and that are producing positive results.

Rule engine technology ~ I think this is a proven, available technology and certainly to a point where it can be used and applied successfully. Rule analysis tools ~ I think this is the 'neglected area' in terms of conflict identification and ambiguity and overlap (things of that nature). And there were some capabilities we saw out on the floor (and so on) to address that very important area. Raising the level of interfaces ~ so that business users can express rules. This is much better than we've been seeing, not perfect, but moving in the right direction. And finally, some integration with workflow engines ~ which I think is quite exciting, 'exciting' in terms of being able engineer businesses on a rapid, top-down basis. I think that's a very important innovation. On the 'down' side, all of those things I mentioned need to be better integrated, and they need to be, in many respects, advanced (more advanced than they are).

So I'd say, to sum up my "2 minutes," the most important need to see in the next year, besides the things that I've mentioned, would be that we need a higher-order of rule expression ~ a higher-order of expressive power. As many of you know, this is an area that I've been working on for many, many years, and still believe that this is necessary and desirable and possible. Secondly, what I'd like to see is much more intimate integration between the workflow engines and the rule engines, so that we have very, very powerful atomic-level, selective ability to respond to rule firing. I think that's a very important area as well.

CJD

*/ ?>

I'm very pleased to see that Ron keeps notes on 'punched cards'... [Ron: and when I run out of these, l retire ~ that's the 'rule'!]

I have a Trivial Pursuit question for you: back in 1991, who was Ross Perot's running mate? <pause> Nobody knows, right? Well, I'll tell you; his name was James Stockdale, and in the Vice Presidential debate in 1991 he began his presentation by saying, "Who am I? What am I doing here?" I feel the same way. I was 'roped in'; I was co-opted for this panel. I am not a 'business rules expert'; my field is relational database. That's what I know about and what I can talk about.

And I'm going to sound like a broken-record here. To me foundation is everything. You have to get the foundations right. To me the relational model is the right foundation, for business rules and so much else. My current research interest is temporal databases ~ time-dimension and so on. I discovered to my pleasure that to do temporal databases right, you have to do type inheritance right. Type inheritance was my previous research interest. To do type inheritance right, you have to do the relational model right. So if we are going to hope to succeed in temporal databases, we have to do the relational model right.

So I am lobbying hard to try to get the industry to implement the relational model. That's never been tried, you understand. We have 'SQL systems' but we don't have 'relational systems.' One of my favorite quotes of the moment comes from a guy called Gregory Chudnovsky. I don't know if you know the name? He's one of these two brothers in New York that have built a super computer in their apartment out of mail-order parts, and they've been doing research into the properties of pi ~ they produced 'pi' to five billion digits, or something, in their apartment. Anyway, Gregory Chudnovsky said, "If you do it the stupid way, you'll have to do it again." I believe that so strongly; I look at the products ~ and I'm not just talking business rules now, but everything ~ I look at the products and I see all the ghastly mistakes that are made over and over again. And, you know, we'll have to do it again!

So, in as much as this is relevant to business rules, as well as everything else that I'm interested in too, let's get the relational model right. Please! End of pitch.

TM

*/ ?>

I had the advantage, in putting on this conference and being the vendor sponsor contact person, of seeing all the vendors who inquired about participating in this conference. And for a variety of reasons at this time around, there are probably (I'd say) about twenty inquiries about this, and that they would be interested in sponsoring the conference and being involved in the conference in one way or another. And that leads me to believe that we are at the point of an explosion in technology. And that can be good.

On the other hand, I'm seeing lots and lots of 'point' solutions, and I really was interested in going to the XML standard and it was very good to hear that they moving into several parallel movements in the area. But in trying to build a way of passing business rules back and forth, I was disappointed to hear (in my opinion) what I heard which was that the focus seems to be very much at what we would consider to be a Zachman Row-5 level. And that until we get the top part of Zachman working right ~ to understand how the business people really think about themselves ~ and we can pass them between our rule repositories to start with and I just feel like I'm back in the data warehouse environment, where they started bringing out ETL tools. And here they are doing the movement of data back and forth and they knew they needed to have metadata and so they tried to make themselves be the repositories, so they kept adding the functionality because that integrated environment that we need to pull it all together still doesn't exist.

So on the 'good' side I think we're going to have lots of products out there that we can choose from. On the 'bad' side we're going to have lots of products we don't want to choose from because we're going to be so confused about each one picking one point very well. Having gone through this for the data warehouse environment where then each one of these tools charges a million dollars for their one little solution, we can't afford to pick the 'best of breeds' and have everything ~ because there's no integration. Each one does a little piece. We just seem to be repeating history, over and over.

So... The 'good' side? ~ there's a lot of interest. The 'bad' side? ~ there's a lot of interest.

RB

*/ ?>

I'm a self-confessed 'process bigot.' Also, like Chris, I'm not really sure why I'm up here except that I do believe, very strongly, that if we can separate the business rules from the business processes we get remarkably stable business processes, much more than what people believe.

And I just have to go back and also echo some of the things that Terry had mentioned... If I go back ten years ago when I taught my first class in business process re-engineering at the time and we had incredible numbers of people coming, it was the latest, greatest thing that was going to solve all our problems. and about 1995-1996 all these stories started to surface, like two out of three fail, it doesn't work, people didn't get what they wanted. And people said, "Okay, well, we're not doing re-engineering any more. That's all going to be abandoned." - gone away and so on.

But interestingly enough, while people stopped using the "re-engineering" word, they didn't stop using the "business process" word. When I look at what a lot of people are doing today, when I look at the seminars that I am teaching today, I get more people today than I did ten years ago. More and more people doing these things because we are now on the second bounce. I think these things always go through this incredibly optimistic cycle: "it's going to solve all our problems!" ... "silver bullet" ... "tried it; didn't work" ... abandon it.

However, some people will quietly keep going along in a very evolutionary, learning style and go forth from that. I think if I look toward the future my fear is that we're going to treat business rules like a silver bullet in the not distant future and we're going to jump all over it and everyone's going to think it's 'easy.'

The real question here is ~ my real question in all this ~ how are we going to get the right rules? Whereas now, in this conference, I've seen so much emphasis on the mechanics and the technical things about "how do I put a rule into 'here'?" and "how do I use it in a workflow?" The question is "is that the right business rule?" and, if it is the right business rule, "how did I get that?" and "how do I get my business people to share their knowledge and turn around new rules quickly enough to be effective to make business results happen?"

That's my concern. And that whole process of creating the right rules is something that I think is going to take a long, long time for us to get to. We're going to have to change our corporate cultures to do that.

GL

*/ ?>

Thank you, Roger.

RR

*/ ?>

Can I have a minute for rebuttal?

GL

*/ ?>

Is that allowed??? <audience laughter>

RR

*/ ?>

What's the business rule?

GL

*/ ?>

All right....

RR

*/ ?>

And, Roger, I'm not rebutting you. I just what to rebut something that Chris Date said. He does belong on this panel. He claims ~ and this is just an issue of terminology, I think ~ that he is a 'database guy.' When he says 'relational model' that's a little bit better, but he still, in his heart of hearts, thinks of himself as a 'database guy.'

But if you've read his work carefully ~ and that takes a lot of effort, I might add (but it is well-written, so you think you're understanding it anyway) ~ Chris has done some of the best and most advanced and forward thinking of the true integration of constraints and business rules in with data management capabilities that there is anywhere.

So Chris and I have this ongoing argument ~ and it's one that's probably never going to be resolved ~ which is that I say, Chris, why don't you call yourself a "business-logic server guy" instead of a "database guy"? And then people will understand why you are on panels like this.

CJD

*/ ?>

Touché ~ no good response to that. I know what I know. I know the relational model. That's enough for me....

But the thing is, this business rules stuff was in the relational model thirty years ago! We didn't call it "business rules," that's all, but it was there. It was just not implemented.

RB

*/ ?>

I'd also like to suggest that it has been in the English (and every other language) for the how many millennia so far, as well. If you really pick apart what people say already, all the rules about rules were already there in the structure of our language.

CJD

*/ ?>

That's true, but we're not just talking about 'rules' per se but rules that we can automate. In order to automate (to mechanize), you have to formalize. That was the relational contribution.

---

GL

*/ ?>

<to the audience> See what happens? If you guys don't start asking questions they'll just talk to each other!

Okay. The rule of the game is: we have a question mark for when this ends. So, we go as a tag team as long as I see hands; we'll just keep going so we can see how long we can keep our gurus answering questions!

Where do 'rules' fit in the 'web' paradigm?

[from the audience]: I think in terms of the recent paradigm shift where now everything is dealing with the web. I remember when we made the shift from the mainframe to client-server. Now we've made a shift to the web. And there has been a little hiccup there because, obviously, we've had something of a Dot-Com bubble crash. But I think that ~ and please tell me if I'm wrong ~ that model is still the latest paradigm. If that is the case, how do business rules fit in with the latest shift we've had, from mainframe, to client-server, to web-based applications?

TM

*/ ?>

You've hit one of my hot buttons. As far as I'm concerned, the web is just a delivery channel. The difference, at least in a retail organization, is the fact that we are moving to 'self service.' And the banking industry started this twenty years ago with ATMs. The banking industry did online banking before anybody was talking about the availability of the web.

So what we've moved to is exposing what we know about a customer to that customer and, as I had one client finding, their tag line for their marketing was "Stick with us. We know you!" while behind the scenes saying, "Oh, my goodness! They're going to figure out we don't know you!!"

So I don't really think that it is as much the paradigm of switching to the web as it is exposing our knowledge to the customer. Every time I hear someone say "Well, the Dot-Coms have it nailed!" (and they dare to bring up Amazon to me) realize that they are collecting the knowledge about you, and they look so integrated because they are forcing you to tell them everything about you. Everyone is giving you an ID, giving you a password (heaven forbid you should forget it, especially on Yahoo)... <laughter> ... driving us crazy; we can't keep them all straight. One has to have seven, and one has to have a number in it, and ... oh, it's horrible!

But I really think that it has to do with the self-service and the exposing of knowledge. On the web, they make us have an ID and log-in and they put cookies on our machines to keep track of us (because if you delete a cookie, you're dead with them), that it's something that the other channels can't do as well. It isn't until we think of them as being a channel (for example, I can go into a bank and expect to see the exact same service at the branch, as I do on the phone, as I do the ATM, as I do on the web), making it the web (holding it up there) is just putting a smoke-screen in front of the real problem ~ the exposure of customer data to customers.

[from the audience]

*/ ?>

So you think it's all CRM?

TM

*/ ?>

I think a great deal of it is, yes, absolutely. Because all of a sudden the customer has become the sales person.

[from the audience]

*/ ?>

What about business-to-business?

TM

*/ ?>

The same thing.

RB

*/ ?>

I would suggest CRM ~ just seeing "customers" ~ is really a very short-term issue. I think it is stakeholder relationship management. It is your suppliers, your partners, your channels, your customers, your owners, your staff. And, I agree with Terry wholeheartedly, it's all about having a relationship, as opposed to twenty-five applications, each dealing with a part of a relationship. It's the bringing of that together. The web is only one channel into that.

RR

*/ ?>

I hate to agree. That's no fun. But the web is not the driving force for why we are here.

The driving force for why we are here is that change is accelerating and complexity is increasing, and this is a compelling business problem that people are looking for solutions to. Now in many cases, they haven't diagnosed the problem properly, but they will. And that's what's behind this movement.

TM

*/ ?>

I just want to make one more point ... One thing that Amazon does do that is getting into a more 'business rule' paradigm, once they know who you are that ability to say "people who bought the book that you are interested in also bought these other books" ~ these books that have been published may be of interest to you ... that personalization ~ is business rule-driven. I just wish that they'd realize that whoever is out there buying the information management book is also buying Harry Potter books. And I'm not interested in Harry Potter.

Business processes as the basis for business rules capture?

[from the audience]: I build data warehouses. I believe that the approach to discovering business rules ... first I develop business rules and then the model ... but I also believe that what you need to do is you need to develop process with the users and that the interfaces for process-to-process is a transformation of information based on business rules. So I would like to know if there are any tools (or direction by the vendors) that start with business processes and look at the transformations (that is, the lines between them) to be the basis of business rules capture?

RB

*/ ?>

I think we're starting to see this in some of the workflow engines. I, of course, being a 'process person,' believe wholeheartedly that the rules are only valid if you use them to do something or to make certain decisions or transformations. And those happen in business processes for someone to whom we are delivering value. So it has to be related, somehow, to that.

However, that same rule may be used in many places. So I think that what we're seeing right now is that many people, again, may be repeating the mistakes of the past ~ putting business rules into applications rather than seeing business rules used across the organization. I would reserve judgment to everybody else as to what the best technologies are for that, though.

RR

*/ ?>

Let me answer the question, not with respect to technology but more in the area of concepts or theory. There are two distinct questions here: one is "what's the best way to express the business rules?" and the second is "what is the best way to capture the business rules?"

In terms of expression, the way to define things declaratively is clearly based on terms and facts, as opposed to anything that's procedural in nature. That way, you get clarity without any particular undue assumptions about the implementation or the disposition of those rules.

As to the capture question (the second question), Zachman has six columns in his Framework and there's no accident, because there are six fundamental sides to the requirements problem. Process is one of those six, but in fact there are questions to be asked about each of the six columns (deliverables for each of the six columns) that lead you to certain kinds of rules.

So I would suggest that process is important, yes, but so are the other aspects of the problem space. And each one contributes in its own way to certain kinds of rules.

Two fundamental (and different) metamodels?

[from the audience]: As you just stated, one of the aspects of what Ron and Chris and, certainly, the Business Rules Group have promulgated is the idea that, to a great extent, what we believe is that the business rules have to be attached to 'data things.' On the other hand, the OMG model (which Sridhar talked about) and some of the statements that you, Roger, made suggest that the preference is to attach rules to process, and only indirectly to data. The implication of this is that there are two fundamental metamodels that the tools will be built upon and they are different. And since most of these tools cannot deal with the fact that there are two separate metamodels, they will go one way or the other, and there could be a split in the industry and a split in the ability (in the fundamental nature) of which tools can connect to which other tools. I see this as a risk. Could you address this dichotomy and whether you see the risk that I see in this?

TM

*/ ?>

I think this is an age-old problem of the split between the programmer mind and the data management mind. And programmers automate processes. Therefore it is natural for them to look at it from a process perspective. Many of us who have either switched to the data side or come out of the data side are responsible for managing the data aspect. Therefore, we see everything from the perspective of a change in data.

I have honestly and truly switched (and there's nothing worse than a convert) to the data perspective. And that's because I look at things from an enterprise perspective.

When I'm out there with the people in the business intelligence environment, who have loaded their data warehouse, are only interested in the data, understanding the relationships and the data, understanding what it means to them from how well their operations are doing, but they don't actually care which operation it necessarily came from, that is the perspective of the data. And, in that perspective, the business rules are attached to data.

But when I'm trying to put a process together within a new business environment, or I'm re-engineering and they want to understand which business rule is controlling how that process is going to flow, and I'm doing my swimlanes and things like that, I'm now in the realm of process.

A business rule has to be able to be attached to both. There is no either-or; it is the union between the two. And lots of processes (no offense!) exist strictly to 'move data around.'

This really hit me when I was working with banks. Banks are moving data around. The most complex thing they get to is opening an account and closing an account. They are moving data back and forth; they are holding data back and forth. There are really not a lot of complex processes in that kind of industry. That's not true in other organizations.

RB

*/ ?>

When I first started looking at this a number of years ago, I realized that a lot of people got stuck in the Information Engineering model. The Information Engineering model basically said, "Look inside a Business Area. Do you Business Area Analysis (and so on and so on). And ultimately you'll get to something called an 'Elementary Process.'" The word "process" was only used at the small, local level.

Really, what I'm talking about, and what a lot of other people are focusing on now, is not that definition of process. It is process from the time some initiating event happens from the outside (which starts things off) to the time some closing event happens (when everything is satisfied). That's a "business process" from outside to outside.

I think that's different than what we've talked about before. In the past, the Information Engineering people talked about putting processes together to create "procedures." In the business process vocabulary, those terms are exactly the opposite. The procedures are lower level than the process. So I think that we are still hung up on our own terminology issues.

RR

*/ ?>

Chris, remind me if my memory doesn't serve me right.... Putting aside (for the moment) the issue of whether the database products on the market are truly relational or not, isn't it a fact that the relational database products won out over the navigational, programming-type database management systems that were prevalent in the seventies?

CJD

*/ ?>

Dr. Ross, I believe you are correct.

RR

*/ ?>

Okay. So now that we've established the facts of the matter, the movement of that community to establish rulebases in a procedural world is going to hit a brick wall. It is not going to work. Come back in five years and tell me if I'm right or wrong.

They will be successful in producing some specialized, system-level tools to do certain kinds of analyses (and so on), but in terms of addressing the business problem, a declarative approach is the way to go, and it will ultimately win.

RB

*/ ?>

If I look back and see how things mature ~ look at how my children mature (hopefully, they will one day) ~ people go through three major phases. They go through a dependent phase; where as young children they are very dependent upon their parents. They go through a completely independent phase, where everybody moves off and they do totally their 'own things' and they don't look at anybody else. But ultimately they do come back around (apparently they do come back, and sometimes never leave again after that) and they go through an inter-dependent phase.

I think that perhaps we are somewhere in the middle of all that right now. Whereas at the beginning, everything is dependent upon your approach / your view. And then they split off and they do it their own way, without looking at anything else.

I think the real message here is we have to do as John Zachman says: get all of these components to be able to 'stand on their own two feet' and now focus on how we package and put those components together. Maybe we are asking the wrong question about which is the right way to do it. You have to have all perspectives and define how they work with one another. After that, it's just a 'methodology question': which methodology do you prefer about getting the connections right.

RR

*/ ?>

Gee, I don't know if I'm responding to that or not.... The UML community is facing (whether it knows it or not) a significant turning point. They are attempting to transition to a 'model-driven' approach, as opposed to a programming approach, which eventually is going to cause them to want to be declarative, as opposed to procedural, in the way that they create things. This, in turn, is going to eventually have the effect of making obsolete a lot of the programming skills that currently exist out there.

Usually when that happens that creates a sociological barrier to moving forward on theory. So there is a significant dilemma that's faced there. Hopefully the community will make it. I will wait and see.

It is time to redesign the business model!

[from the audience]: Based on everything we've heard in the conference and at this panel, I'm wondering if the right message to take back to our corporations and our clients is: It's not just about business rules or the web or the database; it is time to redesign the business model, recognizing that we have new tools, new channels, new options available. In order to move the business forward, let's not over-promise; recognize there are elements that we can do and if we realign the entire business model, not just the rules, not just the processes, or the technologies. That's how I'm summing it up. Does that sound valid?

RR

*/ ?>

It sounds good. Do you want a chair up here?

RB

*/ ?>

I like it a lot! You can speak next year.

RR

*/ ?>

What I say about that is that companies (organizations) are realizing that the 'guidance process' is broken. And that is a process, Roger, the guidance process itself is broken. And there needs to be a whole new approach. You call it a comprehensive business model; that's part of the answer. But it's the guidance process that needs to be addressed because it's the most broken in organizations today.

RB

*/ ?>

I would suggest the challenge you're going to have with that, though, is at this point in time, when things are not going so well economically, you are going to go back and suggest we need to put more money into something which is seen as not productive ~ not directly delivering the goods and services of your business. But if you really look at the cost of the things that go wrong in your organization (the true cost), what happens? It all comes back and is traceable back to the point that our guidance process is broken. I would agree.

RR

*/ ?>

Wow ... point of agreement! Opposite ends of the panel.

TM

*/ ?>

I don't know if any of you have had the opportunity of watching your business actually formulate its business rules. In the most part, it is utter chaos. They have no process; they have no way of thinking. I swear they just sit down at dinner and do the thing on the napkin. And meanwhile the competing side is doing it on that side, and they both give it to you as 'business rules' and it very often lands in our laps to say, "You know, these don't work together." There is no process of how a business develops its business rules.

Although, I was very lucky to actually be at one company who had facilitated sessions with the management of their company ~ big bank, all the way across ~ and they went through "what are the characteristics of our customer?" They came up with the criteria for their customers; they defined a product for that customer (one that would meet the majority of them). They kept a transcript of the entire discussion. And when I came to that company two years later I was handed the transcript and was told "this is where we are going; you'd better understand it."

They completed a very successful five-year program, all the way through. They had all the contingencies in place ... that if the new technology that I was representing failed, all the backup was there for the old technology to keep going. And you know what happened? The new technology never made it and it never hiccupped at all.

So if you have an opportunity to get involved when they are putting their business rules together in an organized way, it's incredible. And they know they are "doing business rules."

But I watched another company put together an incentive program for their bankers, and we were coding it as the managers handed it to us. And we were saying, "This makes no sense to us!" Ultimately, we were the ones who had to go back to management and say, "You'd better rethink this." It all depends on your culture.

How to explain business rules to management

[Kristen Seer]: I work for Business Rule Solutions so, Ron, you cannot answer because I already get to talk to you enough! I came up through the data management field and we did some things really, really well in that arena. One thing I thought we were always really miserable at was explaining data management, justifying its costs, and quantifying the benefits to management so that they would understand what we were doing, would foot the bill, and would be happy with the results. And I see some of the same stuff happening with business rules. I'm interested in hearing from you how you think we can do a much better job at doing that.

TM

*/ ?>

I don't think I would ever go into the business and say, "I'm going to put together a business rule environment for you." I think you have to start with some business need that is business-rule driven, needs the flexibility to change, is very hot and important to them, such as CRM. (It's amazing! I thought it was data warehouse, but now it's CRM.)

But the point is, you've got to hit a business initiative that is very important to them and then demonstrate to them, very quietly, "oh, that's a business rule!" and "oh, that's a business rule!!" Don't tell me what are your requirements; tell me what you do ... tell me what you need to do; tell me what you need to know.

Ask the questions as if you're not doing a business rule environment at all. But then, as you go through this process (this is, at least, what I have found), you start saying (and I work at the enterprise level), "Oh, this statement and this statement are in conflict. How are you going to resolve that? You need a process to resolve it."

Very often the guerilla attack will work more than a frontal attack. It also helps to have a sponsor.

RR

*/ ?>

Did you say "gorilla" or "guerilla"? <laughter>

TM

*/ ?>

I said "guerilla" ... it's the "guer..." not the "gor..."

RB

*/ ?>

I have a view on this as well. (We're just agreeing far too much here....)

I see the issue in all of this ~ I see it happening in business process projects; I've seen it in so many things ~ there's no criterion by which to judge what is a 'good' whatever (rule, process, and so on) from a 'bad' one. We have no criteria ... unless we ask the question, "who cares?" ... "who are we trying to serve?" ... "what are the criteria by which customers will judge us to be useful or not useful, will stay with us, will be loyal to us, will buy more from us?" What are those criteria? Which is exactly what I understand that Terry was just saying.

If you start with the stakeholders and say "who cares?" and "what do they care about?" And you get everybody to agree that these are the criteria by which we will make our decisions on conflicts, as opposed to using criteria that are internal, power-oriented criteria, then you've got something.

But without the criteria, you'll never get through a reasonable conflict resolution process. Yes, we need a process, but the process needs guidance, which are rules about how you develop rules (and so maybe they are metarules?)

[from the audience]

*/ ?>

Guidance alone won't do it. We need a culture change.

RB

*/ ?>

We need people with the incentive to actually follow the guidance. I agree with that.

RR

*/ ?>

I have a great answer, but I'm not going to tell you. <laughter>

TM

*/ ?>

I just wanted to throw out one other thing. I don't find that the problem is within the business community as far as understanding the need to get a process in place to start managing their business concepts and their business rules. Once it's explained to them, they understand its value to their business, which I think was a lot harder to understand when you're talking in terms of just data models and data elements and stuff like that.

It is I/T that I find has the real problem in understanding this. And I have been smacked around by I/T so much that I am going to switch. I am going to build an application this way ~ the way we want ~ 'cuz I want to be able to say, "See! It will work!!"

Because as long as we are dependent on other people, who are more interested in how to build WebSphere and Java code and yesterday it was C++ and tomorrow who the heck knows what it's going to be and are more interested in MQSeries as opposed to application architecture and how you actually architect messaging systems for business value, we're going to fail. So I'm going to go become one (again).

Do we now have three separately-managed things? Data, Process, Rules

[Bonnie O'Neil]: I'm going to revisit a topic that was discussed earlier. I think it's fascinating that we have a 'process person' and a 'data person' on the panel. That is really cool! Barb von Halle and I used to laugh a long time ago when she and I used to sit and giggle about how she would go up to a person and say, "Hello. Are you a process person or a data person?" What I think is so interesting about business rules is that business rules are not 'processes,' and business rules are not 'data.' To use Terry's wonderful word, they are a third kind of thingee. Given this, I think that Ron has touched a little bit, during this conference, on the fact that rule engines are now starting to incorporate workflow, which is way cool in my view.

RR

*/ ?>

...sort of vice versa...

RB

*/ ?>

...and also workflow engines are incorporating rules...

BO'N

*/ ?>

Yes, but they are incorporating them as a separate thingee (hopefully) and not part of the paradigm that it had. Because I think what happened before is that you had 'data tools' that tried to sorta, kinda 'do rules' but not really, and they called them 'data things' (or whatever), or they put them in the 'comments' field, or some kind of after-thought place. And then you had 'process tools' that sort-of put rules into part of the process; they were an attribute of the process.

And then, I love the 'object people' who want to encapsulate the rules and bury them underneath everything and hide them, so that "oh, isn't this encapsulation such a wonderful thing!" And I go, "no, it really isn't, because you need to percolate them up to the top."

So, my question is: do you see this trend of the tools becoming a (hopefully) permanent fixture, such that the tools will really treat these three things as separate things, and be able to manage them together but separately?

RR

*/ ?>

Oh, that wasn't the question I was hoping you'd ask

BO'N

*/ ?>

Oh, well, you can answer the question you were hoping that I would ask, too.

RR

*/ ?>

Actually, on the panel here I don't think it's quite accurate to say that we have a data person and a process person. Really, what we have are business model people with an emphasis on the knowledge aspect of it.

TM

*/ ?>

And I wanted to know who was the 'data' person and who was the 'process' person because I'm schizoid and I'm fightin' with myself all the time. <laughter>

RR

*/ ?>

In any event, I think you're seeing something new here, which is business model people with an emphasis on a 'knowledge focus." I won't say 'knowledge management' because I think that overrates, in effect, what we're trying to do here. But certainly we have a knowledge emphasis. Would you agree with that, Roger, being sort of the business 'process' person on the panel?

RB

*/ ?>

Do I have to say, "yes"?

RR

*/ ?>

No, you can be silent and we'll take that for "yes"....

RB

*/ ?>

I really, really strongly believe that rules are a subset of 'knowledge' ~ some of your knowledge can be represented as rules, other parts are hard to do. If you really do it well, you can take what you know (because people work off of their knowledge and now we're trying to put some of that in an encapsulated form where technologies can do it). I think it's in the knowledge domain. I really do. So I would agree with Ron, yes.

TM

*/ ?>

My concern, when we are talking about tools (especially the ones that are my sponsors and therefore part of my customers) they are very implementation-oriented. They are Row-5; they are for building systems; they are for automating workflow.

We are talking about much more the discovery and integration of business knowledge, and that's not where they are primarily represented. Other people who were here last year, who were addressing the business rule management and the expression of that from a business terminology, weren't here this year. And that's where I see the huge gap ~ the ability to capture it in that way and manage it in that way.

Ron and Gladys have made tremendous strides between the RuleTrack and the Ptech tools and trying to integrate them in, into the knowledge management tools. I think they are still coming off as 'one point' solutions because we don't have the standards going on for "how do I transform from that business perspective into that technology perspective?" We're getting standards about "how do we move, back and forth, this way?" (if I were to talk in terms of Zachman's Framework), not how to move this (other) way.

So I'm real concerned that the important aspect to our business people in business rules management is helping them manage their knowledge. And that's not being delivered.

RB

*/ ?>

A key part of that is that a lot of this knowledge right now is sitting in the minds of people who are going to retire.

RR

*/ ?>

Wait a minute, Roger. That was my answer that I was going to give that I wouldn't give. In fact, the paranoia that you can sow in a company by telling them to go look at the gray-haired guys who are about to retire ... who have all this knowledge in their heads and when they're gone you don't have those people to go ask when you don't know. Or you can pay them four times their salary in consultants' fees and bring them back on. But that only goes so far.

TM

*/ ?>

I think the other concern is, look at the people who are trying to figure out how to capture the knowledge. We're not exactly the youngsters any more either. <laughter>

RR

*/ ?>

On a more serious note.... Actually, Roger (on the other end of the panel there) has been addressing the issue of knowledge management and, it just so happens, in the Ptech environment. So there's a real interesting synthesis going on. One of the directions that I think you'll see in the coming year ~and, Roger, correct me if I'm wrong ~ is some merging of the two ideas about knowledge management: the business rule basic idea and the business process view of knowledge management, into a consolidated view. And, in the process, a Zachman focus on architecture and business modeling, all in one offering. I think that will be an exciting thing to see. That's sort of a prediction.

RB

*/ ?>

Yes, I think you will see that in the not-too-distant future.

RR

*/ ?>

That's because we talked about it out in the hall just before this session.

TM

*/ ?>

Ron, since you mentioned Ptech I do have to say, of our vendors that were here to handle this type of problem that we are addressing, it is the Ptech and the Popkins that we need to look towards to help us solve this problem. I don't think it's going to be coming from the other rule vendors. Because they are working to build the application, once we have the business rules. But somewhere we've got to get them!

RR

*/ ?>

And we can't blame them because that's where the big bucks are.

RB

*/ ?>

But also, I've been involved in these kinds of conferences for a long time and I can remember (and I'm sure Chris can as well) things called "CASE World" and "Database World." I remember one time (at CASE World) we showed up and there were 80 vendors on the floor all of whom claimed to be "CASE tool" people. Then CASE started to get a bad name; six months later only six had the word "CASE" in their brochures. And after that, a lot of them weren't even in business any more.

So you have to be really, really careful in the early-adopter phase when a lot of people are trying stuff. I would suggest that you look closely not only at the technologies but also look at the companies and the capitalization behind the technologies and ask, "Do these people have the money and the commitment to last the shakeout?" which clearly will happen as these types of technologies come forward. But that's the same old thing that we've always faced, I think.

CJD

*/ ?>

I'd just like to pick up on something that Bonnie said. This may sound like it's coming completely out of left field, but you understand that I'm in a group of one here on this panel.

I don't really agree that 'rules' are a third kind of thing. I don't even really agree that there is a distinction between data and process, in a sense. Data in a database is essentially a representation of a predicate (of many predicates). Rules are predicates too. Processes are predicates as well; they just happen to be executable ones. But it's all predicates, basically.

There's a deep unification. If we really look to the foundations, instead of arguing at some kind of metalevel where I'm out of my depth, I know at the deep level this is all the same stuff.

[from the audience]

*/ ?>

It's all about 'truth,' right?.

CJD

*/ ?>

It's about consistency, not "truth"; we can't handle "truth." <laughter>

What about the resistance from I/T?

[from the audience]: Terry addressed this a little bit; she had her solution; but now I'd like to hear everybody else's solution. I'm in the I/T area and I have seen things come and go and, unfortunately, what I have been seeing is that the I/T people are very good at killing off very good ideas. And I think that this business rule stuff is just the greatest; I think that this is the way for us to come up with really good, excellent business rule solutions (that is, technical solutions to business problems). Now, how are we going to fend off all these I/T people who are going to come in here and claim that they can present business rules sufficiently in a Rational use case?

RB

*/ ?>

Can I just say one thing about that? I think these are the same people who fought 'database.' These are the same people who fought process-types of solutions. These are the same people who fought imaging, the same people who fought every thing that's come along until it became part of the mainstream. I think we can just expect it again. But I do think that hopefully the "truth will win out."

RR

*/ ?>

You know, I'm not sure it's even a case of 'winning'; we face this all the time, when some of our business sponsors see the value of the rule management tool, but the I/T people (or one of their consultants) say, "No, no! Rational and ReqPro (and so on) is the way to do this." You have to consider who the audience is. It's apples and oranges. The rule management tool, if it's a good one, is for the business users. And that doesn't exclude Rational; it just says, "Look, that is for the I/T people." And they're not the same. It's not the same audience, not the same problem.

[from the audience]

*/ ?>

<question about a business person using a tool like Rational>

TM

*/ ?>

I can't imagine a business user trying to use Rational ... or ERWin, or a lot of the products that are meant to be for developing applications and databases and things like that. Use the tool for what it is intended, regardless of what the vendor may say.

But to address the original question... There was a group of us that were trying to figure out how to move our development organization, which was very large, and we were asked, "How many programmers do you have to have to require a data analyst?" That's like asking, "How many lines of code do I have to have in a program?" It seems like such a ridiculous metric.

So we were trying to figure out how to handle it, and we came up with the analogy: "How do you guide a herd of elephants in the right direction?" We said that, if you try to stand in front of them and if you actually get them going, you're going to be stampeded, and you can't control where they're going. If you stand behind them and you try to push, you may not like the product. But if you can find the lead elephant and climb up on top of him and get the lead elephant heading in the right direction, you have a real chance that the herd will follow!

What I'm trying to do is, within the developer organization, find the lead elephant. That's the only way I can figure out to do it because there are just too many. And there are too many new products coming out, and the developers all want to try the new coding language and the new technology and now we get VB.NET.

RR

*/ ?>

Our approach is basically only to enter a situation if there is a clear business sponsor who has the compelling need. It's just isn't going to fly if it's an I/T initiative.

Scoping and where to look for rules?

[from the audience]: Ron, this one's for you. When I mentioned about using business process in the discovery of "rules," if you don't take the business approach, how is it that you scope what it is that you are trying to accomplish in the definition of business rules?

RR

*/ ?>

If you don't take the 'business' approach or the 'process' approach?

[from the audience]

*/ ?>

If you think of something like an IDEF0 model, which first you can model in a swimlane or an organizational model, you always get to some point where you say, "This is where I'm going to discover business rules." And it is a point in your process ~ whether it be a high level or a lower level. For example, if you are looking at customer propensity to buy, your high-level process would be "Identify Customer Propensity to Buy" (followed by whatever). How are you getting to the point so that you know which business rules you are looking at?

RR

*/ ?>

I thought the question was going to be about 'scoping'? But I don't think that it is; I think that it's about "is there any other way to look at a problem besides a high-level business process view, to guide you to where to look for rules?" Is that the essence of the question?

[from the audience]

But it's also "scope" because if you open it up and just say, "Let's discover business rules!" there has to be a context.

RR

*/ ?>

You know, the question of 'scope' is really not a business rule question at all. We follow what we believe to be the Zachman approach to 'scope,' which is basically: you look at the six questions (the six columns) and you list the items of importance, you get consensus on that, and that's your scope. And you don't develop a business solution (a business model, much less a technical model) until you do that. I think Zachman is right on target. We use that approach consistently, and it works quite well for us. So that's the answer with respect to 'scope.'

With respect to process and discovery of business rules... Let's suppose that, instead of a 'process person,' you were a 'scheduling person.' And you lived and breathed (for example) the NFL and their scheduling for the next season. Now, how would you think about discovering the rules of the scheduling? You'd probably take a timing approach (a scheduling approach) to the problem, as opposed to a business process approach.

Or, if you were coordinating things in geography in terms of the distribution of your assets or resources ... if you have forces to allocate in Afghanistan, you would look at the geography of the problem and you would focus on that to develop your rules, such as "don't land the troops within x-number of miles of the enemy."

So, I really think it's a matter of methodology. And I think that Zachman has the right answer, which is that each of the six questions has to be addressed and each of them will lead you to business rules.

RB

*/ ?>

But I would suggest, though, that you cannot just say that all the six columns are important so "Go out and find the answers!" There has to be some method to do that. And I think that process gives you the context within which to ask. Even in a scheduling approach, you are scheduling again a series of activities that are taking place, which is called a 'process.' Even dropping troops into Afghanistan, you're trying to accomplish a purpose and that purpose is accomplished by doing something.

So, even if don't call it 'process,' the question is, "What are we trying to do?" "What are we trying to accomplish?" and "What are the rules that are in play in order to do it?"

RR

*/ ?>

Zachman's approach, if I could restate it, is that you can look at any complex manufacturing problem (such as building a business solution, and I'm not going to use the word 'process'; I'm going to call it a 'business solution') has six sides; it's like a cube. Zachman says that you want to hold all five variables constant except for one and look at that, one at a time. You can rotate this cube, get a different perspective of it, and ask different questions.

Well, again, you need all six questions, really, to fully understand the problem. And as you rotate that cube, you'll get six different perspectives on what types of rules there are involved with the problem.

TM

*/ ?>

I think that where you start, and where you start scoping, is very dependent on who the business people are that are in the room. If I'm trying to look at "what does it take to understand how a call-center needs to work?" I may take a very process-oriented approach because they are at the operational level. But when I'm working with Marketing and I'm in there trying to help them understand "what is a customer?" ... "what is a household?" ... "what is an organization?" ... we're not talking 'process;' we're talking 'concepts.'

Either approach ~ as long as it's appropriate to the group of business people and the problem you're trying to handle ~ will work. At some point in time, even within Marketing, I'm going to get down to "And how do you want to do a campaign?"

So at some point in time you're going to get to the process side. If you start with the thingee there will be the processes needed to manage thingee. For every thing I need to manage a customer, I can start out with "what is a customer?" or I could start out with "manage customer." It really depends on how comfortable the people in the room are. And so if you have the Zachman going for you, you're just saying, "Oh, at this point I'm starting here, and I'm moving this way." But then this other time, it's "This time I'm starting there and moving that way."

RR

*/ ?>

Roger, with respect to Afghanistan, even before the process is taking place, there should be some strategy development, should there not?

RB

*/ ?>

I would completely agree.

RR

*/ ?>

Okay, which we hope that there has been.... So, in our methodology, actually, the strategy development comes first, before process, because that essentially outlines the element of the solution that then you want to build your rules, your process, your concepts around.

RB

*/ ?>

But I would also suggest, Ron, that for any particular strategy there might be multiple processes. So each one of these independent variables, we have to understand how they work with one another, and I do agree that we cannot just only look at one. All I'm suggesting is that quite often process is a good place to start.

RR

*/ ?>

But until you've established your goals and selected your tactics and identified the risks that you face it's sort of hard to choose between the alternative processes.

RB

*/ ?>

That's right.

TM

*/ ?>

Well, I think we should all say "thank you very much" to Debbie for having gotten them going. <laughter>

GL

*/ ?>

Now you see why I put them at opposite ends of the table.

RR

*/ ?>

But wait! You could equally ask, "What's the data for doing that?" You could equally ask the question "Where should it take place?" You could equally ask, "How long should it take?" You're just focusing on the one thing because it works.

RB

*/ ?>

The only thing I would suggest is that, if we throw out to all the people in all the organizations, "Well, there are six different ways to play it, and there are six different places to start, and you can sorta start anywhere, and you sorta go from one to the other,..." we're going to have a nightmare in our organizations.

RR

*/ ?>

We don't say that, Roger.

RB

*/ ?>

What I'm saying is that we have to be careful what message out there. That's all.

RR

*/ ?>

Absolutely. There has to be a methodology.

TM

*/ ?>

I just wanted to throw out that I believe that Zachman's Framework is an analysts' tool to help us figure out where we're going to start the discussion. I'm not ever going to throw it out to the business and say, "You've gotta talk about all this kind of stuff." It's going to help me assess the situation to figure out which column I'm going to start in. (Hopefully we start at Row-1.)

A message to take back home...

[from the audience]: I have a comment and a question. The comment is that I'm brand new at this, so if this is very elemental, please excuse me. I think it's very useful (and I've heard several comments that reflect that) to go back to the very simple level of what we're going to bring back to our organizations so that they can make the decision of if this can help them, how it can help them, (and so on). I think the analogy of the fact that they usually have a goal and a place to go and they need assistance getting there is a good analogy. Sometimes having the good analogy that we can agree on and enforce is also helpful. So that's something to think about ~ the herd of elephants, the having a map to get somewhere ~ I think those are all good analogies. The question is for Chris. What is a 'predicate'? If everything is a predicate, what is a predicate?

CJD

*/ ?>

A predicate is a function that takes parameters (like all functions do). And when you substitute arguments for the parameters you get a value (like with all functions). And the value you get is a 'truth value.' So it is a 'truth-valued function.'

For example, the age of person-P is x. That's a predicate. Now, if you substitute a certain value for the person-P and a certain value for the age x, the result is either 'true' or 'false' ~ so, a 'truth-valued function.'

---

GL

*/ ?>

Okay. Any more questions? ... You mean we're going to let them go? Yes?? All right! Thank you very much, everyone, for staying. And thank you very much to our gurus.

# # #