Panelists

Ronald G. Ross, Business Rule Solutions LLC

Martin P. Colbun, National Association of Security Dealers (NASD)

Stan Graham, CSC's Health Plan Solutions

Mark Myers, Northern California Power Agency (NCPA)

James Sinur, Gartner, Inc.

Moderator

Gladys S.W. Lam, Principal, Business Rule Solutions, LLC

.

Introductions

Gladys S.W. Lam   For those of you who don't know me I'm Gladys Lam, the Conference Executive Director.  That's the name they gave me, but (actually) what I do is act as the tiebreaker between Ron and Terry -- my real job is the in-between person being torn in both directions. I've moderated the Forum's Practitioners' Panel since we started, and it's always been a lot of fun; we get excellent information out of it.  I'm expecting that we're going to have just as much fun today, because we've got a lot of information -- a lot of experience and knowledge on our panel. What I like to do is begin by asking each panelist to give your name and company, and then to give us a really quick description of the business rule project or initiative and your role on the project, recapping your experiences very quickly (just to remind everyone).  Finally, give us two benefits you see in the business rules approach and also two critical success factors. I would like to start off with that, and then I will ask a couple of questions, just to prime the panel.  But, remember, all of you in the audience can jump in at any time with your questions. Let's get started. Ron, can we start with you?

Ron

We can if you like.  In fact, I work for Gladys, so I do what she says to do!

I'm Ron Ross, Business Rule Solutions co-founder, with Gladys, who is the 'brains' of the operation.  I am going to give the two biggest benefits that excite me the most -- perhaps not the most important from all different perspectives.

The first has been touched on several times today:  improved business communication, at the business level -- getting people to talk to each other in terms that they understand.  Within industries, even across value chains, we have seen time and time again that people have no idea how valuable this is until they actually see it happening within their company.  That's point number one.

Secondly, a major benefit is creative business thinking.  People are always saying to 'think outside the box' about such-and-such problem.  But that's hard to do if you don't know what the structure of the box is.  Mark Myers was talking about the importance of business architecture; I talked about the importance of guidance and how business rules fit in with that.  It's only when you know exactly what your overall strategy and approach is that you can begin to think very creatively about how you could do it better or do it differently.

So those are my two benefits.  For my first 'critical success factor':  Number one on my list is that you cannot depend on outside consultants to do all the work.  If you do try to outsource this part of the business, you are missing the point.  This is not a body-shop kind of thing.  Certainly, you do need expertise to get started; you need mentoring and coaching.  But this is something that's a must-have in your own skill set and in your own company staffing.

My second critical success factor:  From day one, there has to be business participation.  And that's not just loose business participation.  It has to be structured business participation.  I stole one good idea from Mark Myers (which he kept from me for a long time, but he told me the other night at dinner).  Even on an initial business rule project he would suggest setting up an 'appeals board' -- a group of business people to which you can take business questions and business issues, things that maybe your team can't resolve, but this body can resolve and then feed back to the team.  That's a great way to start re-engineering and re-thinking the whole guidance process and activities in the organization.

Marty

Hi, I'm Marty Colbun, Chief Technology Officer of NASD.  The benefits are numerous but here are my two.  Initially you have a number of different sets of knowledge, or processes, that typically end up in certain individuals.  So one key benefit is the consistency and standardization among those processes and knowledge you get by coding this knowledge in the business rules.  That starts to take away that key person dependency.

A second thing is your ability to be able to present that codified knowledge in a way that you can easily develop and deploy to market.  One of the challenges you have with complex development projects is typically time-to-market, where you may miss that market.  The more you can actually codify those rules and put them into play very quickly the more you improve your ability to get and achieve the business success that you're going after.

For success factors, I would talk about business partnership.  Make sure you are aligned with your business partners; make sure that the roles and responsibilities between business partners and the technologists are clearly laid out.  I would say to make sure you have a good set of metrics -- everything from return on investment (ROI) to the softer, intangible benefits.  When you start to look at risk in an organization you have to have those clearly identified so you can measure things at the end of your engagement.

Stan

I'm Stan Graham, CTO of CSC Health Care.  For my critical success factors, having concise business requirements is always a good place to start.  Without that, I think you're asking for trouble before you embark on a project.  Reinforcing something Mark said, speaking for my experience in our organization, having some people who dedicate themselves to this type of deployment is essential, both on the business and the technology sides.  It is a different paradigm for many people; it's new to them.  So the ability to have someone who will be passionate about this type of approach and follow it through to the end is, I think, a key success factor.

For the benefits, 'speed to market' is the name of the game for us.  Also, flexibility and customization to meet unique needs.  As a vendor we have many clients and their solutions often have to be tailored specifically to those individual clients.

Mark

I'm Mark Myers with NCPA.  I think the number one critical success factor is really to have executive support.  As I said in my discussion, you can push up from the bottom, but without support at the top the effort will eventually run into some rocky spots where it will be tough to move forward.

The other critical success factor is actually having the business rules approach integrated into the business.  When you see people using and understanding the reference models that are produced as a result of the business rules approach then you know that it's truly integrated into the business.  When I see my developers looking at a fact model before they go develop their XML and say, "Let me get the terms right," that means we've done something good.

For the benefits:  A huge benefit in my industry is getting the information out from being in people's brains and onto a piece of paper.  In other words, we have knowledge transfer.  That is a huge benefit you almost cannot put a dollar value on as people start to retire and you are still able to move the business forward.

The other benefit (which may be selfish):  This is really fun technology to work in! It's exciting to come to work and to learn these techniques and actually move things forward.  So, the benefit is that it's an enjoyable workplace.

Jim

Jim Sinur, with Gartner.  My job is watching several industries and several vendor sectors, business rules being one of them.  Before that, I spent time delivering three large-scale rule systems.

The benefits that our customers tell us at Gartner -- and the ones that I've experienced -- have been around cutting costs for developers, wherever those developers happen to be -- whether they happen to be power users on the business side or they happen to be classic developers,  there's a definite time savings and money savings.  This can get translated into leverage points to add creativity to the business for competitive reasons.  We're seeing more and more organizations use their rules as a weapon in their own industry.  So I would say the benefits are time and cost savings, and competitive advantage.

After having been through this a couple of times, the things that I think are critical success factors fall more on the human side.  The first is gaining the trust of the people who actually have the domain knowledge, so that they don't feel you're going to steal their jobs or use those rules against them.

A second area is: Once people start maintaining the rules, letting them know how they can actually test them to be assured that if they change these rules they're not going to goof their business up. Because now they have all this agility and, in some cases, this is like giving an Uzi to a four-year old.  You can shoot yourself in the foot really easily.

Gladys

Okay, thanks.  I see we already have some audience questions.

.

How is the 'business rules' approach different from earlier 'expert systems'?

Wasn't this tried before, with 'expert systems' (and the like)?  And didn't it fail, or at least not catch on?  How is 'business rules' different?

Jim

The logic that seems to work today (and didn't on the projects that I had earlier because people were secure in their jobs and they had a stable environment and you were coming in to their environment), most people today have so much on their plate now that if you tell them, "We're going to give you some relief on these administrative tasks and you can be doing things that are more challenging, more fun" (to steal a term from Mark), it tends to work very well.

But you're always going to get the difficult person that you're going to have to deal with -- the one who just happens to have the most crucial rules.  So you have to win over his trust and let him know that, "Not only do you know these rules you'll be able to change them faster.  And because of that you'll become more valuable to the organization, in the long run."  In other words, you let him know that he will have a more key role -- that instead of being an impediment he'll be leveraging the business.

It really helps if you can be, in essence, an apologetic for rules.  What you're really saying is that I'm not going to hurt you; I'm going to give you something that's going to help you.  The message is:  "By this approach, you become a crucial cog."

Let's face it, everybody asks, "What's in it for me?" Whenever we have conversations, this is going through my mind, and I bet it's going through their minds. We just don't always admit it, right?

Ron

I'd like to add something to that.  I do think that a distinguishing factor between the 'expert systems' in the 1980's versus the business rules approach is that in the expert systems arena was typically more one-on-one; its message was, "Let me surgically extract what's in your head."  That could end up feeling like a lobotomy on the other guy's end.

Now, in the business rules approach, you're typically structuring the business project with many participants who are playing many different roles.  And these are people who are pooling their knowledge and structuring their knowledge so that, in fact, everyone tends to be creating a new vision, a new structure within which they know they will all have a stake.

Frankly, in most organizations where we have been involved, I see very little of the resistance that you might expect of people hoarding (or wanting to hoard) special expertise.

Jim

I agree.  There is more collaboration.

Ron

Definitely! That's a big difference.

[audience]

I would agree with everything you've said.  I've been working with expert systems and now business rules as a consultant, struggling with trying to get the trust of the business people.  Unfortunately, business doesn't always 'get it'!  As recently as last year, we did a business rules project in a large home mortgage company.  They laid people off within six months of the completion of the project.  Maybe the project was just motivated by reduction of workforce, but it seems like that problem is still out there.

.

What to you see as a 'gap' -- something missing that needs to be addressed -- in the business rules space?

As a services provider in this space, my question for Marty or Mark is:  as you look at consulting companies -- to bring them in to use their expertise -- what are you looking for?  Specifically, over the next twelve months, what do you see as a gap (something missing) in the business rules space that needs to be addressed?

Mark

When you bring in a consultant to help you in a business rules project, there are very few consultants out there that really understand how to walk you through the business architecture.  I think there is a big place to train and bring business analysts online.  It is a very rare talent to be able to find these people to help you through it.  That's the space I see needing to be filled.

It's like Ron said.  You've got to have the business knowledge transfer; so it's not a long-term engagement.  It's a short-term engagement to get the company going because -- and I totally agree with Ron on this -- you cannot outsource this because this is your business.  It's not something that someone else can do for you.

Marty

I guess I would be the contrarian and somewhat disagree with that.  I would tell you that any time you look at expertise for any technology you have to look at where it is on the adoption curve.  Is it innovator , early-adopter , majority , or laggard technology?

What you're seeing right now with business rules is that it's still 'innovator'/'early-adopter' technology.  So there isn't a plethora of skills out there.  You do need to get experts in -- subject matter experts who really know the technology.

And I think the first thing you need to look for is good, smart people that know that particular technology.  You don't always have that in-house.  So while you wouldn't want to outsource it, I don't think you have a choice if you're going to go ahead at adoption of some of that technology.

One of the biggest things lacking that I see in the business rules space right now is standardization of the way the technology is implemented and used, and how it 'bolts on' to other applications.  So, for example, application interfaces are ways to integrate it in with other systems, except today this isn't standardized.  This means that programmers -- who typically make these decisions on how to implement this type of logic -- look at it and say, "Why would I use a rules engine when it takes a lot more time to get it into code and to interface with another system?"  If some of those standard 'bolt-ons' were there, such as we see with application servers, we would see higher adoption rates than we do at this point in time.

Jim

From my perspective what we're seeing, on the process side, is the emergence of a process center of excellence so that that people can share things that have worked for them.  I think the same thing has to happen on the rules side and on the policy side, so that there is a sharing within corporations, so that rules and process both become a fabric of the culture.

I think if you can get a consultant who can help you do that ... that's what customers ask me, day in and day out, "How can I get help making that happen?" (setting up the center of excellence, getting best practices ensconced in my culture).

.

Do the people you are talking to see an investment in business rules as a pre-requisite for outsourcing and taking out fundamental costs?

Back to taking out 'cost' and the comments about outsourcing...  Do the people you are talking to see an investment in business rules as a pre-requisite for outsourcing and taking out fundamental costs?

Jim

What I see is that most organizations will not outsource anything that is core and mission critical.  And they don't believe that rules are that way; they believe that rules are core and mission critical.

The things that they do tend to outsource are things that are not mission critical and not core in differentiating themselves.  If they can keep the rules and have the processing done some place else, that is a candidate.  But they're not going to let go of those rules. In other words, they could outsource some of the utilitarian parts and just retain the rules in-house to be tweaked.  We're seeing a number of ASPs being set up that way.  And where there's a really short chain between the time a businessperson makes a decision and the time it takes effect, that's what people want to hang on to rather than let go.

Marty

I would also say that when you start to make outsourcing decisions, what you're trying to outsource first and foremost are your capital-intensive, fixed costs.  You're trying to turn them into variable costs.  That typically equates to networks, data centers, desktops, servers -- that type of thing.  When you start to look at application development, to the extent that you had all the skill set you needed in-house, you would probably keep all of that in-house.

Invariably, when you end up with technologies that are leading edge or are not heavily adopted, that's when you have to go to external sources.  I think that your cost equation starts to become looking at what it takes and what it costs to build that logic and those interfaces within specific applications versus creating more shared services approaches to using these rules and getting economy of scale over time with standard development languages.

In my case, where I had a very expensive development language (in PeopleSoft), it was a no-brainer, where I made money day one.  If you have a situation like that, that's low-hanging fruit that you should be able to do very well with.

Ron

I have something that's from slightly different direction.  This is something that came as a surprise to us in our consulting activities -- something that I would not have predicted five years ago.  We have worked with a number of organizations in the last several years that were fully intending to buy a COTS package.  But we used the business rules approach to develop the specifications that they wanted the vendors to propose to.

If you think about it, that makes pretty good sense, in that you get a very accurate statement of what architecture is required and of the logic in terms of the rules that need to be implemented.  Some vendors very quickly figure out that their package cannot satisfy either the rules in their current form or the likely rate of change in those rules over time, and they drop out.  Very interesting -- I never would have predicted this.

Jim

I'd like to pile on here to say that there are a lot of templates that are starting to come out of the rules sector and out of the BPM sector, where you basically instrument these processes -- jumpstart processes -- instead of buying packages.  I see this as a very real, strong trend.

Ron

I'd like to add just one more thought.  (Is that piling on to your piling on?)

Looking ahead five years, the very idea of starting and developing your own business vocabulary for a problem that other people share will seem hopelessly old fashioned.  Why should you invent your own vocabulary, starting in-house?  We'll see off-the-shelf vocabularies.

The standards are coming, within a year or two, that will support very direct, very fast adoption of business vocabularies.  I have to be careful about saying 'integration', but I will say 'incorporation', within your own business operating activity.

.

What has been your experience with business rule projects that cross organization boundaries -- even supply chains?

Have any of you had experience with projects that cut across organization boundaries, even across the extended supply chain?  What went well?  What didn't go so well?

Mark

The projects we had that tried to cut across various organizations were admittedly much more difficult to implement.  You are starting to compete with lots of different business users and their needs.

I think the thing that's important is getting a standard architecture for the systems when you start trying to cut across boundaries this way.  If you've got your business architecture done, then you can begin to get all the business users agreeing on how you'll implement and how you're going to do coding -- how you're going to make that implementation.

I've seen lots of fights when one IT manage didn't want to implement this way, and he wasn't going to do what the architect said, and they were going to go another way.  You've got to get that kind of thing resolved before you try to implement.

Jim

I have seen two different levels of that issue.  One is inside of an organization, where you are trying to figure out who the rule steward is, and you can get into some severe 'food fights' in terms of determining that.

That gets exacerbated when you start getting into supply and value chains.  In that case you can't just say, "Well, we can make the decision because it's our company, and we can control who is the steward."  Now you have to negotiate on who the steward is; it may be a consortium of three executives, representing three different companies, in order to decide to change a rule that could determine the profitability of those three companies.

I think we are in our infancy in that area -- in trying to address those issues. I have only seen one organization find a way to collaborate on rules that affect multiple corporations.  After all, if you tilt the rule in one direction, you could goof up two others.

So trying to find the right kind of governance environment for supply and value chains is, I think, a real challenge.  And I don't see a lot written on it.  Frankly, I don't see a lot of experience out there. So I'd be interested in hearing any of that.

Mark

Actually, that's one area where the municipalities do have a whole lot of experience.  In the municipality electric industry they form together pools to be able to do settlements and buy power together.  So they have to come to an agreement on how these settlements happen.  It's a very interesting negotiation that happens.

But the key to making it work is that they are in this thing together and they have to come to an agreement.  They have something that ties them all together; sometimes it's a common enemy that gets them to say, "We're going to make this thing work out."

So for examples of that, look to some of the municipality utilities.  You can see some good examples of collaboration.

Jim

Is that dynamically? Is that a real-time agreement that they come up with and dynamically change?

Mark

Yes.

Jim

That's excellent.  I'll have to research that.

Marty

I can give two examples, internal and external.

Internally, we've had success when there's been a particularly strong business sponsor backed with leadership from the top that's said, "Here's your mandate; it's going to happen."  And really forced a number of lines of business in line with a particular solution that they would not have lined up with unless it was mandated from the top down.

Externally, we register and re-register every broker dealer in the securities industry -- that's about almost 800,000 broker dealers every year, and we do it from this point, starting today through January 1.  We have a number of constituents; we have the Securities and Exchange Commission, we have the members in the securities industry themselves, and then we have the state regulators.  Each quarter we go over a set of initiatives and requirements for their particular system with them -- what's going to be in their system -- and we set up 'bus schedules' of when these things are gong to leave.  We end up with a negotiation that meets some of their needs (not all their needs).  We've found a way to prioritize, doing these in application development sessions so that we can nail down their requirements.  This keeps work moving forward until the next quarter when we get together with them again.  So there's a constant negotiation to build these systems externally.

Ron

Let me add one thing to that. In our organization, Business Rule Solutions, when we formed it eight years ago (or so), one of the problems that we'd identified was that requirements methodologies coming out of the IT department in no way, shape, or form addressed this problem of helping different functional areas of an organization (or lines of business, or even supply chain kinds of interactions) to function well.  So, essentially that put us in the position of having to invent something that would work in this space.

I'm going to give my partner, Gladys Lam, a lot of credit because she came up with what we called the 'Policy Charter' technique, which is actually structured business strategy.  It can be applied project-level; it can be applied function-level, line-of-business, business process, or even cross-businesses.

Now, this is purely business strategy, structured in such a way that you can then further the development of requirements in a number of areas, including process and vocabularies, and then move on into things like use cases (and other areas).

If I could identify one of the reasons why so many organizations have so much trouble with this cross-functional integration issue it is because the methodologies -- especially those offered today from IT -- are totally inadequate.  They do not provide that business strategy piece (or deliverable) that you need to start out with, to try to iron out the strategic questions, the goals, the risks, and so on before you get downstream in the nitty-gritty.

[audience]

In a recent project, there was a client in the gaming industry where each of its individual business units was treated as its own business.  In order to do negotiations between the business units (for example, 'comps', giving out free rooms and everything) they decided to use a business rules approach.  They used business rules to be that negotiating point between the organizations, rather than pulling IT into it.  So the business rules solved the problem.

[audience]

We have another collaborative use case to support what you are saying.  Voluntarily, organizations getting together in the supply chain came up with the CPFR policy book (for Collaborative Planning, Forecasting, and Replenishment).  And CVS and Gillette, working together under that policy guidance, worked with the technology vendors in their own organization to implement a reference implementation of that policy.  Together they achieved some tremendous results in terms of making sure that Gillette razor blades are in CVS stores in a just-in-time fashion.

Again, this was not using business rules per se.  But the guiding principle was that externalized and shared industry model that brought willing participants to a success.

.

Is the market ready for this new approach?

I have a whole other spin on the question out there.  As vendors begin to develop pre-packaged applications using rules technology (which may even be a leap beyond conceptualization and people building it in-house), I really would like to get the panelists' head around whether or not the market ready for that?  And what do you see as the pros and cons (or challenges) to stepping into that space?

Stan

From our own experience (that being a software vendor with packages), we've been evangelizing this for about six months, while we've been trying to try to get our solutions out to market.  Increasingly our industry is embracing it even more.  Anything we can do that can deliver solutions flexibility and with the high degree of customization that these products offer.

So, right now we're treating it as a differentiator in our market because we appear to be the only one (we know of) that's this far along integrating business rules engines inside of a software vendor package that's approaching the market from a standard package approach.

Jim

I'm seeing a great uptake both for the business process templates and the rules templates.  Given the fact that, if you look in the CRM industry, you'll see a significant uptake in OEM of rule engines and the selling of rule packets.  So if you look at a Corticon, a Pegasystems, an Onyx, they're moving that way very quickly because they realize that, as a package, they are not flexible enough.

The clients that I talk to at the business level (as distinct from the technicians I talk to), when they mention this, all shake their heads and say, "Yes, we don't want to pay the price for these big, stinkin' packages.  Sometimes they come out with body bags when they're all done, and sometimes they work out just great.  But they're awfully expensive in the long run."  These clients are looking for more of a jump-start.

So, I know the client demand is there.  The issue is, "Is there anybody out there writing them yet?"  I think that's missing, and I've said that to Gartner management -- that we have horizontal Gartner analysts cover horizontal technology; there are vertical analysts that cover industries, and they're really good at covering packages, but not templates.  So, we need to gear up, and I think it's a challenge for Gartner.

Marty

I think that, as a consumer of technology, if there were rules engines customized for vertical industries they would sell very well.  I think that's been one of the challenges with adoption -- interfacing with existing systems and how you integrate them.  And, two, because they're not in any vertical industries, there's a tremendous amount of work that has to happen to customize.

Mark

I think one of the things the engine vendors need to address is the shareability of rules.  In our particular industry, we might develop a settlement system.  But everybody who gets bills from that settlement system has to then develop a 'shadow' settlement system to make sure that the settlement that they got was accurate.  So everybody's redeveloping all of these same systems because the rules can't be shared.

If the rules could be shared across different rules engines, you could literally download them, put them into your analytical software, run whatever completeness checks you've wanted to run, put them into your rules engine, process your data against them, and verify the answer. ... really reduced costs, by doing that.

But the fact is that today we can't share them -- they're proprietary.  I think that's one of the areas that need certainly to be addressed.

Ron

Let me just add a prediction -- I'm going to be more aggressive. I think that the industry is going to be absolutely amazed by what happens in the next five years, in the sense of being blind-sided by capability that right now visionaries are seeing and vendors are beginning to develop the platforms for.  Standards are about to emerge and have breakthrough potential for changing the whole equation of how we go about thinking of engineering business.

I'm not even going to say 'application software packages'.  I'm going to say 'engineering business' -- and I mean literally that.

So, let me just say I think there are a lot of surprises in store, and I think a lot of people are going to be shocked.

.

How do you measure the productivity increase that comes from using the business rules approach?

This is something that we've been getting from our clients all the time, and I hope you have a really good answer.  By using the business rules approach, how can you measure the productivity increase? What are areas where you can really collect metrics?  Can you help us?

Marty

Clearly, I think that you have to look at programming as a unit of work.  At the technology level you should be able to measure how much time and effort it takes to build technology in a rules engine and your time-to-market vis-a-vis doing it in a traditional development language.  That's one area of metric at a technology level.

On the business side, your capability and the ability to get to market with what they're trying to do is clearly another measure.  And, again, you can measure that in how long it takes to actually build, release, and put technology into production.

The third area that you measure is quality.  The fewer problems we have on system launch the more you're going to free up dollars, down the road, for doing other development.  So clearly the quality equation is another key metric that you want to incorporate into your measures.

Stan

One opportunity that companies like CSC have in their engagements is that they're implementing these kinds of projects -- implementing change that involves rules implementations -- with the adoption of some formalized change management process like Six-Sigma.  This means you can truly define and measure (and improve) what your results are.  Having that on a project I think is key.

Jim

I'm seeing a lot of applications of Six-Sigma, both on process and rules.

.

Do the business people have a different perspective on the business rules approach?

It seems strange to me that the speakers that we have today are all from the technology side, in the sense that we have two Chief Technology Officers, an industry technology officer (etc.), so my question is:  We talk so much about the business side of this.  But your partners as such are not on the panel.  I'd be curious to see if, Martin, you could give us a few words that talk about how your business partner might see this a little differently.  And then also could you relate that to this:  Are we still in something that's so technology driven that we don't have any business speakers that could say what the impact of these changes that you've implemented are?  I'm just curious if the panelists could comment on this.

Marty

My answer to your first observation would be that this feedback should change the next Forum -- that we will see some business folks on the panel to give feedback on their results.

What my business customers tell me is that the rules we've implemented (for our billing stream) have improved their ability to get to market as we've changed billing streams.

In many cases, they would have six to twelve month development cycles; in fact the first thing we measured was how long it was going to take us to change PeopleSoft and how much it was going to cost us when we changed the billing engine.  It was about 6-8 months to go ahead and do the project, and it was about 1 to 1-1/2 million to implement it.  We did it in 3 months, for about $200,000 - $300,000.

So the first thing they would say is that they got to market quicker, and they got to market cheaper.  And, additionally, they've been able to change the parameters they've needed to continue to modify the billing streams as the technology-to-market has changed.

So they're pretty happy with the results.  At least, that's what they tell me.  And they give feedback on my review, every year, on my incentive compensation.

As a business owner it's good feedback to know that you want to see more business people talking about the technology and how it gets implemented.  I would say that the technology is still early; it's been around for several years, and it has been implemented in some pretty sophisticated applications and systems across a number of different industry protocols, but it's not been adopted heavily at this point in time.  And to get it adopted heavily it probably needs to get some verticalization within industry segments where there are some specific standards that are built and then some integration to bolt-on to existing systems.  And I think when we see that you will see it come out of the early adopter stage and start to hit the majority.

Ron

As conference co-chair, this is 'off the record' ... if I can speak publicly, 'off the record' (is that an oxymoron?):  If any of you have ideas, please let us know.  That's a great question and we struggled with it a lot, in terms of putting the conference together -- exactly how we do get the right audience and the right speakers -- because there definitely is a message here that needs to go to the right people.  So if any of you have suggestions or thoughts about that, we would be very receptive to that, in looking forward to future conferences.

I'll also add this one thing.  I think one of the speakers mentioned this -- but several of our larger clients don't allow their people to speak publicly about this.  They just will not speak publicly, and I can understand why.  There are some good things coming up.

Jim

It's the same thing for business process management; it's very difficult to get people to talk about the business advantage that their process is getting because they don't want to give away their advantage.

.

How would one position himself to be a provider, bringing business people online to the business rules approach?

How would one position himself to be a provider of training to bring business people online to the business rules approach?  Some companies recognize the need and will go out to the web to learn more; others come to conferences like this to learn about it.  How would someone go about getting into that special niche?

Ron

One good way is to write articles for the BRCommunity.  If you're not familiar with the BRCommunity, that's a non-commercial site, with lots of good articles and, in fact, a transcript of this panel will go up on the site. How many of you are familiar with the BRCommunity?  One good way to get visibility is to write for us and describe what you've accomplished, and so on.  So there's an opportunity there.

[audience]

How does your suggestion jibe with what you said about companies not wanting to have their work be in the spotlight?

Ron

There are many ways of generalizing and disguising so that you can still get across many points without revealing specifics.

Marty

I would say that referenceability is one of the key aspects.

One place to begin is with your vendors.  They actually provided a great deal of knowledge to us; after all, they had great business knowledge, as well as technology expertise.  And we were able to leverage this because we were going to be a good reference account for them.  And in actuality we are because they did a great job for us and we're using them for future work.  So I think referenceability is really critical to getting any business off the ground and really growing.

Eventually, you do get to a cross-over point where you still do want the references but it's not critical to your sustainability of business.  I think at that point your business model changes.  But clearly, referenceability (for me) would the first thing that you'd have to look at if you wanted to get adoption.

Jim

Also, you might want to partner as a subcontractor with a number of rule vendors because what we're finding is that the rule vendors' and BPM vendors' ability to service their accounts is getting outstripped by the demand.  They're looking for good ways to augment their own staff.  So if you don't mind being a subcontractor to some of these vendors, they are looking for people.

.

What can we expect from the standards activities that are underway?  What would you advise for what we are implementing today?

There are many standards activities out there today -- the OMG, the W3C, and the like.  I know things are emerging and things are converging.  But for those of us who are implementing today, what kind of guidance can you give us?

Mark

Ron's probably the best one to speak to this, he works with the OMG.  Also, Jim for his industry perspective.  But my spin on this is that, from what I hear, there are a lot of things coming down, some new standards that will be coming our way soon.  However, there are still some basic, core things that you need to do.  No matter what standard comes down, you need to define your terms and you need to define your facts.  I totally believe that no matter what comes down, those two things will be portable.

When you're in this kind of position of waiting for new standards, I think the question is (at least, what I've asked myself), no matter what happens, what do I need to do that's reusable, no matter what the standard is?  That's the tack I've taken -- to define my terms and facts, and then apply the modeling technique.  Then, how we share that, or how it gets transferred around, or how it gets imported into another program, it will still fit in.

Ron

I have to confirm that because I don't think our clients would forgive us if there was a standard that came out that I participated in and it was incompatible with what had been done in the past.  Let me give you a very brief insight to the most important things.

But before I do that, a couple of relevant program notes for the Conference.  On Thursday after there is an open session with the OMG Business Rules SIG and the Business Rules Group.  It will be open to questions and discussion, which makes it a great place to find out what exactly is happening from the people actually doing the work.  The reason they are here is because we had a meeting scheduled for post-conference (Friday and Saturday) to continue to work on the standard.

Just to give a very brief answer to the question.  The OMG put out an RFP for a standard called "Business Semantics of Business Rules" at the beginning of last year.  In response to that, a consortium was formed of a number of leading groups, including Unisys, the Business Rules Group, Business Rules Solutions, Terry Halpin of Northface University, and now several repository companies.  It was a pretty substantial list responding to the RFP.

Work has been going on continuously for at least a year on that response.  In fact, we've been using the Unisys worldwide conferencing facility; we have meetings weekly and often twice a week.  There is a lot of very intense work going on.  Our current objective is to deliver our submission to the OMG in its final form in the early 2005 timeframe.  I would give that a 90% chance of happening.

This is a very, very important standard because it integrates the business-facing approach in business rules and that sort of ability to develop vocabulary (as Mark say, terms and facts and structured vocabulary) with predicate logic and formal logic, and all done in such a fashion that communication between machines, therefore businesses, can take place at a semantic level, as opposed to a more technical level.

So it's extremely exciting from a number of points of view, and I'm very hopeful that this will emerge sometime next year.  There's no significant alternative to it at this point within the OMG or within the marketplace.

Jim

What companies have been doing, that I've been seeing, to get ready for this is to put their rules into some kind of repository and let the repository vendor be responsible for any transformation.  My guess is the transport mechanism is going to be XML in some way, shape, or form.  And if you have a vendor that can deal with the XML and the transformation, the rules that they have in their engines are going to have to conform.

If this gathers the steam that it's going to -- having the rules not based necessarily just on the rule engine but on some kind of repository that has transformation -- that will give number of organizations the ability to protect themselves.

Ron

In fact, two of the members of this consortium I mentioned (which is called the 'Business Rules Team') are Adaptive and Mega, both of whom are repository vendors who understand the importance of being able to do exactly that kind of thing.  We're anticipating a lot more people joining the consortium once we get to a point of stability.

Marty

I'll give you one more pragmatic view, from a customer perspective.  If you look at the standards themselves, I believe that most standards get set in a defacto way by major players in a particular industry.

So, for example, if you remember some of the 'database wars' in the late 80s where there was a consortium put together to define call-level interface.  And the number of vendors got together; they had collaborated -- Sybase, Microsoft, several others -- and then Microsoft at the last minute made a left turn and said ODBC is going to be the standard.  And it became the defacto standard for call-level interface -- much different from the consortium's.

The reason I say this is that there are ways you can protect yourself when you start to work with some of the standardization you want by the way you code, change, and the particular technologies you're using.  And then I think you can bet on some things like XML that have been out for some period of time and are tried-and-true and will be around.

And I think you can look at the ones that are probably more up in the air and simply realize that you may need to redo some of the work that you do but, overall, you do get benefit from doing projects you're working on.  So, I wouldn't be overly concerned about some of those standards being completely baked at this point.

Jim

I agree with you.  To support your point, IBM's doing that right now with BPEL.  BPEL supports system-to-system very nicely, but it does not support human interface or human-to-human activity.  IBM is basically dictating what the human standards are going to be to OASIS.  If OASIS doesn't go along with it, they're going to take it to OMG.

It's very clear that the big dogs will have their rule here.  Hopefully it's more than big dogs that will be attracted to this.

Ron

A couple of points...

One is that IBM was the other submitter to this RFP but their submission was at a 'system' level.  Even IBM understands that business semantics for business rules at the business level is not the same thing as standards at the system level for system designs and platforms.

Also, there's a separation from production rules, which is what inference engines are built with.  That's a separate standards activity, which is much more technology oriented.  Recently IBM joined that group, obviously to (more or less) the terms of that standard.

But, you know, that's good because it looks like, therefore, there will be a standard for 'production rules', hopefully within a year or two and maybe sooner.

---

Gladys

I see Terry standing outside and I think she wants me to finish.  I thank you for the questions.  They were great questions.

Thank you especially to the panel -- for all your time preparing and then sharing all your experiences and knowledge with us.  Thank you for participating.  It has been a great exchange.

# # #