Panelists

Veronica O'Grady	Sr. Business Rules Advisor at Inland Revenue, New Zealand
Michael Pezely	Sr. Manager, eBay Trust Science Group
Chris Maple	Sr. Programmer Analyst, MMG Insurance
Bob Dizinno	Lead P&C Solutions Advisor, USAA
Gwen Bradshaw	Business Rules Architect, Assurant Specialty Property
Brad Amodeo	Nokia Location and Commerce
Roberto Arnetoli	Chief Technology Officer, Prosper.com

Moderator

Kristen Seer

Senior Consultant, Business Rule Solutions, LLC

Topics

1. Is there any particular type of project that really lends itself to the business rules approach?
2. What was your primary objective in harvesting business rules?
3. How do you implement a rules engine to work with a software package?
4. How many of your companies actually have built or purchased a rules engine?
5. Do you find the rule engine interface lets you write rules in natural language, or do you need to transition the business rules into another form for implementation in the rules engine?
6. How are you handling governance?
7. Does the rules approach (versus an implementation in code) produce a more accurate representation of the original intent?
8. Are the people who are developing your rules largely developers or largely business analysts?

.

Welcome & Introductions

Kristen Seer:   Good afternoon, and welcome everyone to the Business Rules Practitioners Panel.  My name is Kristen Seer, and I'll be your moderator for today.

For those of you who have been to the conference before — and have been to this particular event — you'll know that it's Gladys Lam who has moderated this panel in the past.  This panel has always been her baby.  But this year we decided to change things up a little:  she took my "emerging trends" panel, which is the very last panel on the last day, and she entrusted me with the Practitioners Panel.  So, I have very big shoes to fill. 

But I have to say I'm really thrilled because this has always been my favorite panel of the conference — I'm always so impressed by the amount of expertise we have gathered.  And this year is certainly no exception.  We've got great panelists.  I'm always intrigued to hear what your burning questions are — because this is really your opportunity to grill these guys and find out what is working with them (and what is NOT working) ... what are their lessons learned? … what was the most painful thing that happened?  This is where you can really get down and talk to people who are out there, doing the business rules approach — people who have gained really, really valuable knowledge by getting in there and actually doing this.

This is always a lot of fun.  It's very informal.  The structure is that I'll start off by getting the panelists to introduce themselves (their name, company, the role they play) and then to provide a couple of dos and don'ts — the one or two top things that you should do and a couple of things you really should not do.  After that, I have a couple of prepared questions for them, just to kick things off.  But, really, I want to turn it over to you as quickly as possible so that you can ask your questions.  Okay?  Just raise your hand if you have a question.  And you can either direct it to an individual panelist or to the panel as a group.

Okay — everybody good?  Let's start.  Veronica?

Veronica O'Grady

I'm Veronica O'Grady.  I'm a Sr. Business Rules Advisor at Inland Revenue, New Zealand.  I work in our Business Rules Center, which is an enterprise rule management capability.

My big one do is:  Ensure that you have executive sponsorship, right from the very top and all the way down.  My big don't would be:  Don't underestimate the power of your sponsor.

Michael Pezely

My name is Michael Pezely.  I'm a Sr. Manager within eBay's Trust Science Group.  My team is tasked with protecting the eBay community from online fraud, as well as improving the trust and overall reputation of eBay.  We do that through a combination of big data analytics, applied research, technological innovations, and (of course) a powerful business rules platform.

I have a couple of dos and don'ts that might be a little bit different from some others since my focus is on fraud, and business rules for fraud tend to be a little different.  In my organization, successful rule writing equals a successful project.  So, do have analysts that are both business savvy as well as innovative.  And do not let the business try to give you the "how" when it comes to business rules — always push for your rules analysts to provide the how.

This is my second year coming here and I've heard people say, "Never build your own rules engine."  And I've also heard people say, "Build your own rules engine."  So, what I would say to that is that there's no right or wrong answer to that question.  It's based on your need; it's based on your organization; it's based on your resources.

Chris Maple

Hi, I'm Chris Maple.  I'm a Sr. Programmer Analyst at MMG Insurance.  That's still my title and I do still dabble in code, but over the last two years I've been involved in our implementation of a rules-based approach.  I represent our Process and Rules Centers of Excellence on our application architecture team, and I lead our BA Forum, which helps develop governance and best practices for analysis.  In practice, I spend most of my time as a business analyst.

My one major do is:  Do make sure that your concepts are well defined and modeled and that everybody is aware of the meaning.  We've been held up by misunderstanding about what we're talking about, more often than any other kind of problem. 

My one major don't is:  Don't just capture rule statements.  Things like motivation, examples, understanding how rules tie back and support enterprise goals — these are very important as well.  Sometimes when you've had a complex discussion about a rule, understanding how you actually arrived there (capturing that corporate memory) is as important to the business as the end result, the rule statement itself.

Bob Dizinno

My name is Bob Dizinno.  I'm a Lead P&C Solutions Advisor for USAA.  In my role at work, I head a team that concentrates mostly on business rules, but we are concerned with the entirety of business modeling  — process models, UI specifications, business rules, vocabulary, and so forth. 

Dos and Don'ts are somewhat difficult.  I would certainly second what Veronica said — executive support is extremely helpful.  My dos (or don'ts) would be dependent on where you are on the journey.  If you're just starting out, then just doing something is very, very important.  Picking out a project that is manageable in size yet can be representative of some totality that is significant is very, very important.

My don't would be:  Don't give up; keep at it.  Keep on learning, developing your skills and the skills of your team.

Gwen Bradshaw

My name is Gwen Bradshaw; I'm a Business Rules Architect with Assurant Specialty Property.  We track mortgage insurance for banks, and my division tracks claims and makes sure that all the documentation is in place for the property being repaired.  I've been working with business rules since the late 90s.

One of my biggest dos is:  Have fun!  Be creative; do not be afraid of what's out there.  If you need to, grab some crayons; draw it out.  Use a big white board … colored markers.  I've stolen my kids' Legos at times so I could build and shape what I was trying to create, letting these Legos represent certain types of documents.  And just have fun with it; don't be afraid.  I see a lot of times when people are getting into business rules they are kind of scared.  Unless you're actually designing a tool that's going to do brain surgery, most of what you're going to do can be recovered.  Now, I was in a session today where there was a life or death example, but most of the time you're not dealing with people's lives; you're dealing with things that will make their lives better.

As far as a don't:  Don't become cocky because what you really need is other sets of eyes.  You need to test; you need to evaluate your ideas.  So, don't be afraid of the ideas — be creative; put them together.  But then run them by someone you trust.  Kate and I work together, and I call her my 'rules therapist'.  When I come up with an idea — I've put it together, have used my crayons — I call her up and I send it to her and I say, "Okay.  I need therapy for this idea before we go any further." 

So, have fun with it.  It's amazing the potential that can come from this.  Our particular department — we are able to eliminate (well, not 'eliminate' because no one lost their job) ... but we're able to process so many transactions that if we lost our business rule set we would need an additional 2,200 employees, which represents $83 million a year for our company.  So, we're able to provide better service.  And it's a lot of fun — really, it is!

Brad Amodeo

My name's Brad Amodeo.  I'm with Nokia Location and Commerce.  Our division creates digital maps and points of interest, used in things like Garmin Navigation Systems, Bing Maps, MapQuest, and car navigation systems.  I'm a product owner for an internal application that provides functionality for data standardization and product validations.  Our business rules are around making sure that our point-of-interest products pass inspections.

Dos and don'ts:  First of all — on the don't side — if it's your first business rules project, don't try to take on the whole thing in the first iteration.  We had a very wide variety of rules and locations, used world-wide, and so that really was my first decision:  we needed to pick out one small area, get it done properly, and then expand it.  So, make it small, and then grow from there.

My do would be 'communication'.  As we went through the first project, I was very conscious about making sure that everybody knew what everybody else was doing and why they were doing it, so we didn't start building silos.

I'm sure we're not the only ones in the boat where you give IS what you need and they build you software — and then you need to deal with them if there's any change.  We really wanted to move away from that, but this extraction of business rules — the isolation of the rules from the application — was something new for us.  So, we had to be sure that everybody understood why they were doing what they were doing and just how to isolate the rules.

Roberto Arnetoli

Hello, my name is Roberto Arnetoli.  I'm the Chief Technology Officer of Prosper.com.  We're a peer-to-peer lending marketplace — we enable people to lend to each other.  We started using rules about a year ago, and we have replaced thousands of lines of code with rules implemented with Bosch Visual Rules.

The do, based on my experience, is:  Use a rules engine for what it is, which is something to manage rules, not something to do activities.  All of the different suites have become more and more powerful — you can even write applications with them.  But then you get into trouble with speed of performance, especially when you use it (as in our case) interactively with a website.

Kristen

Excellent.  Thank you.  That was already a whole lot of great information — the experience and the lessons learned.

In terms of don'ts:  Again, different suites have different functionality, but most of them now make it very easy to change rules.  The one thing I would say about that is:  Don't forget to test.  We still need to test those rules.

Is there any particular type of project that really lends itself to the business rules approach?

[Kristen]   I know many of you are already at the point where you've gone through multiple rules projects so you're not at the very beginning of this.  In that experience, is there any particular type of project that really lends itself to the business rules approach?  And what kinds of benefits did you see out of that? ... what kind of ROI, if you measured that?      Let's start with Michael.

Michael Pezely

Sure.  Anything where you have rapidly-changing data is, of course, a great case for business rules, whether it's pricing or fraud or any of the many other things that lend themselves to a rules project.  But it's not only the obvious things that lend themselves to good rules projects. 

One of the things we like to do when evaluating a project request is to ask, "Is this truly the best approach to implement this this way?"  When my team thinks of the "best way" we're generally thinking about the customer experience:  How's the customer experience going to be versus doing it some other way?  Then we list out the pros and cons of those different approaches.  Whenever we find those cons we definitely let the business know what that con is so that they're fully aware of it.

I can give an example.  Recently we had a business rule request come to us.  We have a policy (a rule) on our site where if you're a member whose account is forty-days past due, we restrict your buying and selling activity.  This is not controlled by business rules; this is all code.

Someone in the Collections Dept. started asking questions like "Why do we restrict the buying of these accounts?  It's not costing us any money to let them still buy."  So, one thing led to another; they did the analysis and came back saying, "Hey, this could bring in $20 million more revenue if we allowed the users to continue to buy but not sell."  The typical thing happens — they bring their request to IT (or PD) department who looks at it, and it's the typical IT cycle.  It's going to take six months (maybe) just to get it started.  It's definitely more time-intensive than one would think, and you've got to deprioritize and reprioritize and do a whole lot of things.

So, they came to us and asked, "Is there a business rules solution to this problem?"  We looked at it and listed out the pros and cons.  In this instance the con was that our approach would mean that it could take up to six hours, from the time a member paid their bill to the time they could sell.  But they could buy all they wanted in the meantime.  So, there was a tradeoff.  With the original approach there would be immediate, instant selling access.  You have to weigh those and let the business make those decisions.  If you wait you're going to lose out on (potentially) some of that revenue, but you're impacting the customer experience.  It's the age-old question:  business versus customer.

What we ended up deciding to do was a bit different approach where we did a little experiment.  We took some of those users (not all of them) and started this process so that we could measure "Is this $20 million number realistic?" — Can we really gain this revenue?  Also, what's the cost to the customer experience?  Are these people more likely to just not come back to sell if we take this kind of action on their account?  And what's the customer support cost of these customers coming in to us, asking whether or not they can sell immediately. 

I don't have an ROI on this yet; it's something that we're just doing now.  But this is an example of how we would go about trying to figure out "Is this the right approach?"  If it is, we can roll out something like that on the business rules platform in days to weeks, instead of months.

What was your primary objective in harvesting business rules?

[Kristen]   Okay.  Good.      Some of you are more on the business side; some are more on the IT side.  (And some of you do both.)  So, this question is for the business side:  What was your primary objective in harvesting the business rules?  For example, why were you going after the rules — was it for that knowledge retention for the organization, or was it more targeted toward the system implementation?  Also, what was your biggest challenge in doing that?  I'll direct that first to Veronica.

Veronica O'Grady

The Inland Revenue started its enterprise rules management journey a couple of years ago in that we were motivated to do things really differently, fundamentally differently in the future.  We wanted to take all of our legacy systems and decouple the hard part of rules out of those systems so that we don't have to spend millions of dollars and change on those old COBOL, mainframe systems (and the other various types of coding) that we have in place.

We wanted to do things faster and smarter in the future.  In doing so we realized that the business rules are our platform of logic and we could manage them as a corporate asset rather than some piece of code deeply hidden in something cast in editions of code that sit on top, over time, as more and more changes comes in.  So, we decided, as an organization, that for us to get the real benefits of managing our business rules we needed to start with our source documents — our legislation, our operational policy — and then build the rules up, one layer at a time.  That way, when we start to do products and services they're directly linked back to the legislation that enables our operations as a tax administration, something that we had never done before.  And in doing so we're not only decoupling rules from our legacy systems but we're also starting to operate rules in a new world, in a transformational way that we haven't done before either.

This has led to us realizing up to 70% reduction in development effort, simply because we have our foundation rules from our legislation in place.  And we're proving time and time again that this "up to 70%" is holding true.

Also, through the establishment of our various professions in the rule space — we have rules author, rules analyst, and rules architect — we are re-using not only our analysis but we're also re-using our rules.  We can reduce the amount of development effort for a product down to days and weeks and, as a product goes through cyclic change the following year, it's down to hours and minutes — something that the business hasn't had before either.

We can model what that change looks like across our entire platform because we can see every product, channel, backing-system, or service offering — whether it's internally-faced or externally faced — using one rule.  And that's not something we've had in the past either.

It's fantastic; we're seeing real benefits to how we manage our information.  We have consistency in the use of our legislation.  And our customers have a much better experience as a result.  They are getting consistency from our web and consistency from our call center staff as well.  For the first time we've got a platform of business rules that is an asset for the organization.  And it's our platform for future transformation.

 

How do you implement a rules engine to work with a software package?

[Kristen]   Great.  Now let's give the IT side a chance.  One thing I often get asked:  There are so many organizations out there that are buying software packages, and they're not really sure how the rules fit into that and how to actually deploy the rules and implement them in a rules engine that works with the software package.  Are you configuring the software package?  Are you customizing the software package?  So, I want to ask about what some of the challenges are that you face in that kind of environment.  And how do you solve those challenges?      I'll direct this first to Brad.

Brad Amodeo

Well, we went through the first generation of our application — the first project where we really wanted to separate business rules.  Therefore, we built it all in-house.  As I mentioned in my dos and don'ts about taking a little bit at a time, we built a proof-of-concept and showed that this worked — that users could now change business rules without having to change the software. 

And so the application grew a little bigger, grew a little bigger, and then once it was fairly widely deployed, users started asking for more complex rules.  At that point I came to the realization, "Okay, do we want to reinvent the wheel, or not?"  Although I love building custom applications, that was the point where we really didn't want to reinvent the wheel. 

We did take a look at a variety of vendors.  Now, our particular application was in .NET, but I did look at all the rules engines because the critical success factor was that we could change business rules when we needed to, to make our application as flexible as possible.  I was even willing to jump platforms if I needed to. 

We found the rules engine that we're now using (InRule), and it turned out that it was flexible enough to meet all of the needs that we had.  I even spent a lot of time with the users checking that this would grow to handle their future needs — I understand what you're asking for today, let's assume we can solve that, what's next after that? ... and what's next after that?  It took awhile to go through that to really get our requirements. 

We did look at a variety of solutions to integrate into our application.  Our goal was to make our rules engine somewhat of a technical island.  In other words, the rest of our application would still work and we could, theoretically, pull one out and put another one in.  Of course, it's not all that easy, but we architected it so that we could get as close to that as possible.  By doing that it allowed us to use the solution that we purchased as-is and the rule writing is so robust that we feel like we are doing custom code but it's all within the rules engine.  And the way our application communicates with the rules engine, it doesn't care what's in the rules engine.  So, we got the best of both worlds.  We control how our application talks to the rules engine, but the users can write whatever rules they want.

We are in the process of rolling this out.  It really is border lining on the wild, wild west because our application is used by people all over the world who are responsible for a variety of products.  There could be people in France, working on point-of-interest products that have (for example) all of the tennis clubs in France.  They have their own set of rules; they have their own set of requirements.  I didn't want to build a funnel that everybody had to go through in order to get their jobs done.  So, the application is built so that they can write their own rules and then run them and get what they need to get done.

Building it that way — growing from an in-house solution to a purchased solution — there was a clear decision there.  And then building the application so that it was easy for users to author whatever rules they wanted, whenever they wanted, without us having to change the application, that worked very well.

Kristen Seer

Okay!  Well, I've got a ton of questions I can ask, but I want to turn it over to you guys now.  So, do you have any questions for our panel?

How many of your companies actually have built or purchased a rules engine?

[from the audience]   This is for the panel.  I'd be interested in knowing how many of your companies actually have built or purchased a rules engine?  And what are some of the challenges with that rules engine?  We heard from Michael on this, but I'd like to hear about this from some of the other panelists.

Kristen Seer

Did everybody catch that question?  Okay.

Veronica O'Grady

Yes, we have a rules engine.  We use Oracle Policy Automation.  It was purchased as part of a wider, enterprise tax management suite when we started the transformational journey a couple of years ago.  When we were initiated as a business unit, at the time, it was myself and my manager; we were given this technology, a blank piece of paper, and a reference architecture that had nothing other than a green box that said "business rules." 

So, we had to figure out what that was, in the architecture — what the toolset could do and then how do we position the entire capability, bearing in mind the rules engine was but one component.  We spent a lot of time understanding what an enterprise rules management approach is.  Thankfully the toolset that was given to us fits that bill quite nicely, and it has become quite a critical component as to what we're delivering in respect of the rules and the solutions and our thinking. 

But we're also dealing with more than just what goes into that rules engine.  We have the senior-level executive sponsorship in the mandate to take consideration of all rules so we have visibility on all rules and what has been the most appropriate way to manage those — if in some instances it has to be coded, or if it goes into OPA, or if perhaps there's another type of technology that we require.

Our challenges have been around the cultural and the behavioral implications of bringing through such a technology.  We sit in the business; none of our authors are IT; we're all legal, economic, and public policy background.  In fact, we don't have any contact with IT other than in a business partnership.  So, we've had to build bridges with our policy developers, our IT folks, and our service designers.  And we have to continually educate on the value of the enterprise rule capability and the ways in which you can support it — technology agnostic as much as possible.  We're constantly fighting fires and we're constantly educating. 

We do a lot of proof of concepts to demonstrate how rules can work in the way that we're offering the service of a business rules service.  We demonstrate performance, load, volume, integration, whether it's with our twenty year-old mainframe or our web channel or our voice channel.  We constantly demonstrate back to the business and to IT how we can do things.

In the two years that we've been established we've had to develop rules reference architecture integration patterns, callings patterns, and work quite closely with the project in the product development life cycle so that as a capability we're included at the very start and not something they try to squeeze in at the end — that rules start to drive the change, not be something that falls out of a requirements document. 

That's continuous education.  It's both an opportunity and a challenge.

Kristen Seer

Anyone else want to respond?

Michael Pezely

At eBay we have a fairly mature business rules platform.  We've been using business rules for over twelve years.  We've used both third party rules engines as well as in-house.  I would ask how much customization do you plan on doing to your rules engine?  If you think you're going to do a lot of customization I would tend to lean toward an in-house solution; otherwise, a lot of times you'll get stuck in a situation where your vendor is creating all this new, cool software and you're stuck using what you started with because the cost to bring that in means you have to redo all these customizations.  At least, that was our experience.

Roberto Arnetoli

I mentioned earlier that we use Bosch Visual Rules.  Before that we really, like Brad, evaluated a lot of products.  We also developed our software in-house with .NET, and the first approach was, "Okay, we need to find a business rules engine of some sort that is .NET." 

Soon, however, we realized that was one of the challenges — it shouldn't be technology driving like that.  As long as we found something that was well-integratable with our service-oriented architecture and really communicated in true web services and XML we would be fine.  We actually went with Visual Rules, which is a Java-based solution, without problems at all.

What I found was that, with many of the different products, there is a tendency to reduce the amount of coding, but these products still are more for developers or business analysts that can deal with code.  And we wanted to really allow every single person (potentially) in the company to use it.  So, we went with Visual Rules because you can do anything just visually — even the most complex rule.  We have plenty of rules.  We manage our offers and products and pricing, where we have 150,000 combinational prices at any one point, live on our web site, and it's all with rules "out of the box."

There was one thing between Java and .NET where a function with negative numbers works differently.  That was the only little customization we had to do.

Kristen Seer

Anyone else?

Gwen Bradshaw

At our organization with the twelve years I've spent, everything's been built in-house — our team built the rules engine.  We have not used any of the vendor rules engines. 

As a business user, I have loved my experience with business rules.  I have enjoyed the authoring tools that our company has been able to customize to what it is we do, as a business.  So, I have found that it's very user friendly for the type of business rules that I create.  It fits very nicely with what I'm trying to do.  I'm not on the IT side so I don't know if there are behind-the-scene challenges that they have, but as a business user I do love that we have our own software. 

Two years ago, when I identified that if the rules engine could just do this as well (using the decision tables to help us find an opportunity for improvement) we could really save a lot of money.  I went to the head of the group and said, "Hey, I've got this idea."  He said, "Wow."  So, they were able to modify and push that out in the rules engine within a month.  There's a real responsiveness having an in-house team for modifications.

The challenge, though, is that we then also have to take care of documentation and training internally.  There is no team that is funded by the particular company.  Veronica, I think it was your session where you talked about how you had the training from your business rules engine vendor.  And that's one of the areas that we struggle a little bit with — making sure all the team members have adequate training on the software because we're responsible for creating and managing that ourselves.

Kristen Seer

Okay.  Next question?

Do you find the rule engine interface lets you write rules in natural language, or do you need to transition the business rules into another form for implementation in the rules engine?

[from the audience]   There is a school of thought (and I'm part of that school) that says that the optimum way of describing business rules, documenting business rules, is in natural language.  On the other hand, with a lot of these tools that claim to be business-friendly there is an interface that involves a certain degree of programmer-ese — putting terms inside brackets and writing the rules as some sort of symbolic arrangement.      So, my question is two part.  Have any of the panelists found that that is not a problem — that the business can fully understand and assimilate and verify and reason the rules presented using the rules engine interface?  Or, alternatively, have any of the panelists experienced an integrated, seamless transition from rules expressed in natural language to rules implemented in a rules engine?

Bob Dizinno

I'll take that — at a minimum to just disprove that my only function was to separate the panel. <laughter>

We're much the same thought as you that everything should be expressed in natural language.  The implementation in a rules engine often does not represent all the rules necessary for the rule groups and rule sets that are needed by the business to understand how to execute that degree of capability.  So, I have to have all my rules beforehand in order to understand that particular rule group and rule set.  Some subset of that is then a better candidate for the particular rules engine.

Gwen Bradshaw

With our group, we have a kind of 'pseudo-code' that we use.  It's almost natural language, but it's not quite.  Most of our analysts have no trouble stepping right in, being able to read and understand it.  We do have some folks who struggle with that — people who would like it to be more of a natural language.

What I've found, though, is that those folks are not necessarily the ones who have that natural business rules thought pattern.  You can put a business rule into natural language; you can put it into pseudo-code, but at the end of the day, if you don't have that foundation, that logical thought pattern, it really doesn't  matter what you're using — you're going to struggle.

Veronica O'Grady

I'd like to add something.  We write our rules in a natural language, but there's obviously a particular syntax and mindset and thinking process that goes into how you write those rules.  The way that we've written them — with our legislation as our base layer and then working our way up the various layers of interpretation — helps to provide a very rules-rich platform that is in natural language.  The rules engine then takes that natural language and does some behind-the-scenes work, creating the executable rules and the files that support them.  

So, our team — sitting in the business with a team of people who have legal, economic, and accounting backgrounds — doesn't do any traditional coding or programming.  The software that we use creates the files necessary for integration. 

But to do this there is definitely a mindset — a whole pattern that goes on in the head — and the energy and the innovation that it takes to make those rules work is quite inspiring.  As Gwen said earlier, it is a very, very creative framework.  To have an author, an analyst, and an architect and then somebody else pops their hand up and can actually talk through the structure of a sentence — what it's going to be used for in the outcome — and then you see that rule work in practice, it's a very beautiful thing.

Brad Amodeo

I'll add in a little bit.  In our case, most of the people using the application are people who have done complicated things in Excel or Access.  So, they're not developers per se, but they are technically oriented. 

That said, with the rules engine we've implemented, one of the features we use quite a bit is the ability to provide templates.  So, if there are some things that are going to head down that programming rabbit hole (be a little bit more complex), the technical team can create a template and make it available.  And then it really is even closer to natural language.  That's the best of both worlds, and that's what we're doing.

Roberto Arnetoli

With the tool that we're using you can actually use natural language.  So, every single node in the visual design suite that we have can be written in two levels.  You can write it in natural language and then somebody else may write it in a technical way.  There are ways to switch on and off which view you want so that it can appear as totally natural language (or not).

In addition to that you can break down the rules into sub-rules so even if, from a natural language perspective, you stop at one point, that can call another rule that might be more technical and therefore not be in natural language.

Veronica O'Grady

We were able to demonstrate one of our acts, when we got some of our services text sent back to our policy developers a year ago. 

We take the legislation; we use policy isomorphism — flat harvesting rules so that they directly reflect the source material.  That's the foundation layer; from there, the interpretative rules are overlaid, i.e., rules from operational policy, guidelines, case law, contracts, etc.  It's all nicely referenced back so that you can see the rules structurally by sections. 

When we first showed this to our policy people, they were really bored.  They asked, "Why are you bringing this to us?"  We replied, "Well, we're showing you the rules in their entirety and how they operate between each section, for the goods and services tax set, so you can model the new changes coming through."  And they said, "But this looks very different to the act."  We pointed out, "That's a really good thing because you're seeing these rules as they are, not that we've had to go into our mainframe system, take them out of COBOL, get somebody out of retirement to translate them, and then get somebody else from legal technical to try and put them in an order and then bring them back to you.  We've just written them in a Microsoft Word document."  That's when they started to get quite excited because suddenly the rules had meaning — and had meaning back to the source documentation.

We were also able to get our legal team on board to say that, technically, those rules were accurate in relation to the law.  And we can now model what change looks like in respect of it, because of the way they have been written.  Yes, it's natural — and, yes, you do see the syntax; you see the element of technology going on in the head.  But that's certainly come a long way from where we were.

Chris Maple

I'll chime in on this.  We record everything in a general rulebook.  We use RuleXpress.  For us the primary goal is to enable corporate memory in a single source of the truth.  Right now we're still hand-coding in C#.  We'll go to RFP and select a rules engine this year. 

But, really, regardless of how it's automated it gets a lot easier when you have that other independent source of the truth that you can always go back and point to.  I really think you need to look at how you're going to implement rules distinct from what you're actually trying to do with business rules.  If you're not trying to enable corporate memory in a single source of the truth then some of those implementation approaches end up deficient.  We actually let our concept models inform our physical data models, and our coders are taking the terms that we express — that's what they're using in their code. 

It's not the most efficient process; we know we can improve on it with a rules engine.  But we wanted to make sure that we were very good at understanding the analysis piece first and actually getting that single source of the truth before we took the next step of making a better deployment.

Kristen Seer

Okay.  Next question?

How are you handling governance?

[from the audience]   I'm going to shift gears completely.  I'm a rookie so please bear with me.  How are you handling governance?  How are you handling who definitively says, "Yes, this is the right rule!"?

Veronica O'Grady

We pushed very hard — this is where our executive sponsorship becomes so valuable.  Our Deputy Commissioner, who's basically one level down from the top guy (our Commissioner), said that if this is going to be real — if this is going to be what makes transformation a real thing for the organization — then we have to have the say. 

So, we've been given the mandate to determine, from an all of rules perspective, what happens to them and how they're managed and then what is the technology that supports them, whether it's our internal rules engine or if it's being coded for a particular reason, and how that's going to be consumed so that we have visibility and traceability across all of the rules types.  It's been quite challenging.

From the Audience

I'm actually asking about the human side of it.  Everybody thinks the way that they write a rule is the right way.  How are you governing that?

Veronica O'Grady

It's mandated — we actually direct that.  We've told the business that, for all business rules conversations in the future, that can only happen in one location and that's with our team.  They've actually had to outsource all future rule management conversations from what would have typically happened in a project, in a business unit, in a forum — however else they've decided things in the past.  That no longer happens in practice; it comes back to us.  And where it does occur under the radar we force the hand and we get architectural exemption and we force them back into line. 

So, over a year we've established some really sound governance practices where we steward the rules.  We leave the business to own them, but there are very clear practices in place as to how rules get changed from last year, moving forward.  There's also a lot of education and cultural change associated with that because, as you see, people think that's theirs, that's their priority, and then how do they do it?  But having the executive sponsorship has meant that it's our mandate — it's our role.

Chris Maple

Here's our governance process.  We have a business domain team — that's a business architect from each of the business domains.  They are responsible for owning all of our standards and best practices for analysis.  Now, in reality we're still training up some of those resources.

We have a BA Forum within that group — all of the people who are doing analysis meet as a forum — and we develop standards and best practices.  We suggest them, and right now they're pretty much all accepted because they trust that we're good folks and that we're trying to develop that business architect ownership.  So, we are still in the process of moving that ownership back to the business domains.

All of our vocabulary — any of our terms, concept models, rules, rule groups, and decisions — any time that those are created, modified, or touched in any way, we have a subject matter expert who is approving that the content of those is correct.  We usually review them a decision at a time:  what are of the terms and the rules in a particular decision?  We assign ownership.  So, a domain owns all of those, and there's a business architect that takes responsibility for owning those.

One thing we've started doing that's really worked out well for us is we have a BA Peer Review.  We're a little bit new to this approach, but this is what we're doing:  A BA sits with another BA — we make sure it conforms to our own standards and best practices that we've developed as a team.  This peer review enforces that quality assurance element.  A lot of times we find that just by describing your own unit of work, you catch yourself in things that you could have patterned better or improved.  Really, it creates an opportunity for an iterative, best practice improvement because you get BAs collaborating.  You'll find patterns and best practices that you should have that you don't.  So, that's how we're building up our best practices and standards, through that peer review process.

Gwen Bradshaw

We play Rock-Paper-Scissors. <laughter>

When I started working with business rules there was myself and my boss.  We would spend time in a room with some McDonalds and Diet Coke, and if we got to where we agreed we'd put it through.  But it has grown since then. 

So, governance is a real challenge.  Right now there are four architects that are on my team, and we do have different ideas.  It is a creative process.  We are still working through how we handle that.  But at this point, really, what we do is just get together and we talk it through.  We explore the different areas.  We really try to foster that creativity because there are many right answers to put some rules together. 

We then evaluate them back and forth and try to come to a consensus on which way we're going to go.  There have been some times that we've said, "Well, let's give this a try."  We have a test area where we can play around with an idea.  Our IT group is building us a "sandbox" where we can play with these ideas even more and see what the impact is, and then compare those areas to evaluate what is best.

But really, if you're just starting out, you can just have conversations ... and sometimes it  does come down to Rock-Paper-Scissors.

Kristen Seer

Next question?  This will be the last question.

Does the rules approach (versus an implementation in code) produce a more accurate representation of the original intent?

[from the audience]   Some of you have talked about this ... have stated that the quality of interpretation of, say, legislation into rules was more accurate than the interpretation of legislation into code.  This is because, to get to code, there are a number of translations that happen on the way down and then you can't really have the business verify what's in the code without testing every possible combination since it's not in a form they can consume.      So, is it a common finding that, in fact, when you go to the rules approach (versus an implementation in traditional IT code) you get a more accurate representation of the original intent?  Any comments on that assumption?

Roberto Arnetoli

I would agree with that.  I think that many tools (including the one that we use) offer a visual way to look at a rule in a way that is easier for a business user to verify.  You don't have to rely necessarily just on some interpretation by a developer.

In addition, there are tools (certainly the one that we have) that enable easy creation of test cases, which are readable in natural language — you can add a lot of description into them. 

Because of those features, I would agree with you.

Gwen Bradshaw

Personally, I think it's a misnomer that you won't end up in spaghetti code by using business rules.  It is possible to get yourself so twisted around in your business rule trees that you're not sure how you ended up at the end or how certain things happened. 

When we first started working with business rules in the late 90s we thought, "This is great!  We're not going to have spaghetti code.  We're not going to have to remember what went wrong.  We're not going to have to fishtail through all of the process."  Yet as we expanded and built and built, we found that there were some processes that we'd scratch our heads and go, "Okay — what is this doing?!?" 

We found decision tables really was the answer to making sure that we had our business rules doing what they needed and so that we could verify that what we had built was correct.  We could sit down with the business and say, "Do you agree that if these five things are true this would be the outcome?"  And then we test to make sure that we built that.

Bob Dizinno

I would add that our approach is we've adopted SBVR, and I've come to feel about rules that a rule is computation whose outcome is 'true'.  By using a very structured vocabulary and a very structured way of engineering and architecting rules — rules in groups, one rule versus another rule — that the outcome should have a consistent interpretation.  It's possible that someone can misunderstand, but it should minimize to the greatest degree any misinterpretation of what the intent and outcome of a given rule should be.

Kristen Seer

All right.  Unfortunately we're at the end ... <from the audience:  Just one more question!?!>  Oh, it's up to the group — are you willing to stay for one more question?  Okay. Go ahead.

Are the people who are developing your rules largely developers or largely business analysts?

[from the audience]   I have a simple question.  Are the people who are developing your rules largely developers or largely business analysts?  Just quickly say which one it is.

Gwen Bradshaw

Business.

Brad Amodeo

For us it's the business analyst.

Bob Dizinno

Business, with some people who are on the business side that were on the IT side.

Chris Maple

A mixture.

Roberto Arnetoli

It depends.  I talked earlier about use of natural language and how it depends on what level you're at.  We are doing some complex stuff that obviously requires more technical people.

Veronica O'Grady

We have dedicated rules authors and a separate rules analysis profession.

Michael Pezely

Business.

Bob Dizinno

What's the motivation for your question.  It sounds like there's another thought or question behind it?

From the Audience

No, it's just a question of whether business rules is bridging that business-developer gap, or whether it's still requiring a lot of technical skills.

Roberto Arnetoli

In my view business rules are really bridging that gap, with the exception that if you have to run something that is performance related.  For example, we're on a website backed by business rules.  As we've said, you can write a rule in many different ways, and while a rule can be written by a business analyst or a business person, sometimes it is difficult to make it happen fast.  So, you have to have the technology behind that.  We produce an answer to a borrower application with multiple options in 0.143 seconds on average.  But this is because we have a collaboration between business and technology.  It wasn't just business.

Wrap-up

[Kristen]   Okay.  Well, I want to thank our panelists for sharing their valuable knowledge and insights.  And thank you all for your questions and your participation as well.      Gladys had a number of traditions with the panel.  So, I wanted to start a new tradition of giving our panelists a little treat as a thank you.  So, I brought some stuff from Canada — it's all maple-related. <applause>  Thank you all very much for attending.

# # #