BRForum 2009 Vendor Panel: Is BRMS at a Cross-Roads? Vendors Speak Out
Carole-Ann Matignon VP of Product Management, FICO Russell Keziere Senior Director of BPM, PegaSystems Tom Debevoise Senior VP, Innovations Software Technology Corporation Scott Irwin RTM Architect, Convergys
Stephen D. Hendrick Group VP, Application Development & Deployment Research, IDC
- What needs to happen, now, in the business rules market?
- What needs to happen in the business rules market in the next five years?
- Where are you going, in terms of standards and interoperability?
- What will you be doing differently in the future to respond to the needs of the customer?
- Is there a role for social media and networking in vendor communities?
- What innovations will we likely see in the rule management markets in the next year or two?
- Has there been progress in the development of business rule 'frameworks'?
|Welcome & Introductions|
|[Stephen Hendrick] What we have here is the vendor panel; I was tasked with the job of trying to come up with a topic that is relevant for this particular panel. Looking at the BRMS space, I will pose the question, "Is BRMS at a cross-roads?"|
This happens to be an issue I feel pretty strongly about. For those of you who will be here tomorrow morning, I will be talking on this particular subject, but I'm not going to spill my beans this afternoon. Today I want our four distinguished panelists to talk to you about the particular issues we're facing in this BRMS space.
With us here today are four panelists from the vendor community:
- Carole-Ann Matignon, from FICO
- Russell Keziere, who is Senior Director of BPM at PegaSystems
- Tom Debevoise, who is Senior VP of Innovations Software Technology
- Scott Irwin, who is an RTM Architect for Convergys
So, we have a nice blend here of vendors in the business rules space, as well as a system integrator. That should help get a good, diverse view of what is happening in the BRMS space.
Here are the rules that I'm going to play by: I'm going to ask two questions of the panelists. I'll ask the first question and have them each respond to it; then I'll ask the next, for each to respond to. That should take the first twenty-five to thirty minutes, allowing a couple of minutes for each response, per panelist. These are two open-ended questions, and I hope they will be provocative enough to get at what's going on in the BRMS space ... not only now, but in the future.
Next, we'll open it up to questions from all of you. If you folks think my questions are too softballish, feel free to ask really hard ones, okay? We'll get a microphone to wander around with, as soon as the panelists are done with the initial two questions, to make sure that all of you have an opportunity to talk — to ask your questions and to get good answers from the panel.
The reason I want to do this is to get a view into whether or not there is a state change that's going on (or needs to go on) in the marketplace. Let's see how the vendors will respond — is there consistency in their answers across each one of those questions, or is there divergence? ... either within a question or across questions.
I have no idea what's going to happen but we'll find out.
So, why don't we take responses in sequence; we'll start with Carole-Ann and then go down the rest of the members of the panel, in order. Carole-Ann, can you talk to us about what you think is the single, most important event that needs to happen in the BRMS space in order for this market to stay healthy?
In order to answer the question, we need to understand what has happened in the past. So — very briefly, because we're not going to go through a fifteen to twenty year history on BRMS — we've seen a lot of progress on execution; we've made a lot of progress on management ... how to empower the business users.
What we are seeing now is a lot of activity, a lot of excitement about getting to the next step, with more analytics as part of the strategies or the business rules that we deploy. So, what we need to get right, right now, are the measurements — being able to have more confidence that we're doing the right things, that we're deploying the right strategies.
The fact that the economy has become more challenging is probably emphasizing even more the need for us, as an industry, to better manage the KPIs, to better expose them to the business users. Thinking back to the sessions this morning on pattern-based strategies, I would say it's about better seeking those patterns — how to better model them — and about really measuring that you're doing the right thing so that you can adapt in the right direction and improve over time.
So, I think this is the major theme for this year, and that's something we need to provide, from a vendor's perspective. But we also need to get the collaboration of our partners on the services side. For the customer, I think you'll get more success if you get onto this bandwagon of continued improvement and closing the loop.
Okay, thanks, Carole-Ann. Russell?
In a similar vein, anything that the BRMS vendor can do to help visualize and guarantee business success ... to help people who are investing in the technology to be able to forecast a foreseeable result within a reasonable timeframe. People ask, "Well, how should I create a business case for a BRMS project? How should I do that?" What we see now, practically, from our customers is that they start a project and get returns on it that they can report within a quarter. Continuous improvement (iterations of improvement) in transforming the business can occur almost below the radar because the projects are funding themselves.
Making investments like we have is extremely important — for example, in terms of helping project management and testing, bringing of Scrum-based iteration planning and management to the particular aspects, and turning the BPM system we have in on the project of developing the rules solution. So, I agree with Carole-Ann that it is making sure that:
- when you begin a project you can visualize the business success,
- you can, with certainty, assure the business that you'll be able to deliver, and
- you do deliver that result within a timely fashion.
That's certainly leading to our growth and adoption in the marketplace.
Okay. So, so far we have two votes in favor of process improvement and added lifecycle capabilities to deliver faster ROI. Tom?
From Innovation's perspective, the big thing we are focusing on is truly empowering the business analyst and the manager with truly being able to get the agility they need when making rule changes. This year we particularly saw this in the credit risk area. Obviously, credit risk is a very 'hot topic', and we worked on tools that give those managers and analysts the ability to go in and change the model themselves, and to publish it and have it out there rapidly. We feel it is very important for the industry to move tools that do this, in an understandable, self-formatting manner, into the hands of the analysts. And it's not enough to just say that ... or give it lip service. We need to really make the tools simpler — more intuitive to use — and more expressive in terms of the problem-solution set that can be addressed. If we can do that then 'rules' becomes a strategic capability.
For ten years now our industry has been trying to promise that we're going to be eliminating a lot of the software development lifecycle. However, publishing a new model, whether it's a credit model or a logistics supply model, is really not a software function. It's a management function. So, we need to get beyond the IT focus; we need to get to a state where information technology is an enabler — an important enabler — but it's not the means for running your business.
Thanks, Tom. So, what I heard from you was an emphasis on empowering the business analyst ... a real focus on agility and a real desire to continue the maturity of what's already been going on to make the rules more strategic. Interesting. I was hoping the agility thing was going to go in a new direction, but we'll wait and see whether we get that a little later on.
As I sit in an architect's office I am starting to see that rules systems are moving from the fringe in a diagram, further and further into the center of the diagram. That's exciting to see. I can only derive from that that, really, these rules systems are being accepted — they are proving out; they are delivering return-on-investment.
Another thing I've seen is that I'm being asked, more and more, to marry predictive analytics with rules systems. The statisticians who are building all their great models want to ensure that those models are actually available in the policies and the rules that everyone's writing.
I'm also seeing more and more requests to handle higher and higher volumes. Companies are starting to look at every interaction that they're having with their customers as an opportunity for a sale or a reduced cost to serve. Rules systems can be applied to this — to drive out costs and to increase revenues, with every interaction. That means that the volume of executions of these policy engines is just going through the roof.
Finally, I see that customers are really trying to apply these rules systems to move from a reactive system into more of a proactive system, and then to further reaching out into preemptive services.
Okay, thanks. That I think was pretty interesting.
So, I heard a lot of very different, very interesting statements being made here. The fact they're being made with respect to talking about the business rule space — from the standpoint of what's going on today — suggests that the technology that Scott's talking about is actually here. It has landed. And if that's the case, that is a pretty important development in this particular space. The idea of rules moving into being the core of application development, the whole notion of marrying analytics with rules, having a real-time focus, moving from rules in a passive state to being more in an active state ... that is all pretty fascinating stuff.
I think I will keep going in the same vein of continuous improvement — trying to improve the systems incrementally. Where I see the future in the next few years (or, more probably in a three-year timeframe) is creating more adaptive systems ... getting systems that can learn from every single interaction with your customers and adapt themselves.
Of course, there are some parts of the system that you do want to control — I don't think those will be adaptive, for example, where you have very heavy regulations. But there are many parts of the system that can learn from all the interactions ... typically, marketing applications or fraud detection. Those are very good examples of places where you can have self-adjusting systems. So, I think that is going to become more and more typical of the future architectures.
That's very compelling — this whole notion of feedback in the rules space is not something that we've seen a whole lot of. Sure, it has existed in discrete little market areas like fraud. In some cases, neural networks have been used in conjunction with rules to get dynamic pattern changing going on; you can check every transaction with respect to fraud using a changing focus to ensure that your pattern-matching is up-to-date based on what's happening from a transaction standpoint per account. So, that's actually pretty cool!
The notion of feedback and learning, though, is really interesting. It will be interesting to see if somebody in the audience will test these guys later on and ask, "Okay, if you want to deal with learning from the feedback, how do you do it effectively?" It sounds to me like that could be a tall order.
Five years is a long time. In this morning's keynote we heard a vision that I believe is probably palpable to many of us here. When I talk to our customers I hear them say that they want to solve business problems. Often they don't know whether they want a business rules engine or a business process management system or more business intelligence or all of the above.
I believe that in five years we won't be thinking in terms of application development or individual segments of this business enablement but that there will be a convergence. In fact, we see it now with the consolidation in the market and in the investment in R&D. We see the market trying to bring tighter and tighter integration and cooperation ... between business rules and business intelligence, between business rules and complex event processing, and between business rules and business process management. So, I believe that that convergence will be in place in five year's time. Steve, what do you think?
Yes, I think Russell's on to something here, from the standpoint of the convergence that will, in fact, take place in the industry and that I think, in some respects, needs to take place in the industry.
I agree very much with what Russell is saying with respect to a convergence. In particular, we need to move beyond debates about engines, like Rete versus sequential, versus this, versus that. When the people I work with — the executives and the analysts — find this kind of debate going on in a white paper they stop reading it.
We need to look more towards an integral model of this business enablement. Let me give you just one quick viewpoint of that model. I believe that we have been so process-focused in a lot of our organizations that we're missing the forest in the trees. For ten years now we have been simply connecting one activity after another, based on business process modeling tool. I'm not saying the process model (the process viewpoint) isn't valid. But if you step back and regard it as a non-process model and consider "what are we doing with the event of the incoming order/requisition/supply-chain issue" then you can focus on the rules and the decisions that are surrounding that event. That will give you better control when you go back to your process view.
So, to summarize, if we can move beyond these very eclectic arguments about Rete and sequential and this thing and that thing (using artificial intelligence terms) we can move into the questions of "What is the problem that we're working with?" ... "What is our toolset?" ... "Do we have a process view, or a non-process view (an event view)?" And we can begin to bring it all together.
It's really obvious that the companies that have been heavily invested in this process view have had a very poor model of risk as they executed their processes and, in a lot of places, their results in this last economic downturn outdid the scale of the actual downturn. I know that, in the people that we're talking with, we need to take (as Russell described) a more integrated approach.
That's actually pretty interesting. So, Tom's contribution here really focused around the fact that perhaps we've been a little too process centric, from the standpoint of how we've pursued IT up to now. That's actually fascinating because, when you think about people, process, and information, what does that mean? Process pretty much has been in the lead up to this point. Are we going to flip this around and have it lead by ... people? ... information? Probably information.
And if that's the case, maybe you all want to think about asking these guys, in a few minutes, "If you're going to be information-led — if you're going to be data-driven from the standpoint of how you run an IT shop — what are the implications of that?" Not only that ... it's not just a technology issue. It's the question of how do you sell it, from a go-to-market standpoint? To what extent is IT ready for this kind of change?
There are a number of specifications that are evolving out there. Typically, when I see many specs and then vendors having to support all the different specifications, all of a sudden everyone is saying things like my tooling can run with your engine and your engine run with my tooling. And then the open source guys tend to creep in. As a buyer I then have a business problem: Do I really care what kind of engine it is? What I really want to know is: Can you solve my problem for the lowest cost?
I think if you're a pure-play business rules system, evolution just means you need to move further up the food chain. We've seen a lot of companies get snatched up by business process/complex-event processing. I think we need to keep moving higher and higher and higher.
Okay, that's great. Thanks.
We are going to shift gears now and get some questions from the audience. I know you guys are just dying to roast these guys. Okay, so while the microphone is getting staged, do we have any questions?
Who wants to jump in?
I can take that. Standards are obviously very important for the industry to mature and to help customers not be locked in with the vendors. Obviously, there is value in being more open.
Today there have been some efforts in trying to standardize on the business rules side. The BPM side is more mature, with BPEL and some other notations, but on the BRMS side there is no standard. There is an effort by the OMG to create a PRR (Production Rule Representation) standard. And there are also some efforts that are joint with the W3C.
What is really missing from those efforts — you know that standards take a lot of time — is the involvement of end customers. I don't think we see enough of the end users voicing their opinions. So, in those standards we have a lot of academics who are talking about how to model business rules and we don't get really practical use cases as to why you want it. Their debate is: Do you want standards for modeling, or do you want standards for interoperability? There might be some overlaps between the two but there are also differences — really key differences — in the way we approach the problems.
So, if that's something that's important to you I really encourage you to voice your opinion, to be vocal, within the OMG or W3C ... or just to rally a few vendors around you. Because we will be really happy to support it, once we get the true requirements.
I certainly agree with support for the evolution of standards. But I will also point out the interoperability problem is an immediate and pragmatic one. We call this the "wrap and renew" problem. This is about taking the investment you have in your existing legacy architecture and "wrapping" it with lighter-weight, pre-orchestrated business services, composed in a BPM/SOA layer with rich rules.
What we've done at Pega is taken the rules engine and turned it in on the problem of maintaining that distributed, composite application so that it has the high availability and performance with rich interoperability. We use our AES (or "autonomic event services manager") to monitor and watch this wrapped-and-renewed extension of your legacy, to ensure that it's high performing and to be able to predict and anticipate potential fault points or latencies or lack of adherence to strict SLAs from constituent subsystems.
That's just one example; I'm sure my colleagues have other examples. You can actually use the rules engine very intelligently for a wrap-and-renew exercise of your legacy. We have a lot of customers doing that.
What Russell describes is a very valid way of managing your legacy system, but there are some important considerations in doing that. Take the case of the Federal government, which has done a lot of work in this area, with many of their applications maintained in that way. What they are discovering is that there are problems in their ability to react to the legislative changes that are hitting them. In particular, the Social Security Administration, Medicare/Medicaid, the Department of Defense and the way they have to do their supply chain management — at some point each is seeing the pattern emerging that those systems are so broken that they have to abandon them.
You have to understand that you can run that way, but you're only going to run that way with a five- to seven-year timeframe. So, the time to plan for the next system is now. And you need to decide exactly what patterns you need ... what is your vision for the business model that's going to exist in the future.
Obviously, the way we developed systems in the past is not the way we're going to develop them today. You can see true examples of eight- and ten-fold increases in SLA, depending on the type of business model that you're trying to implement. And you will have much more agility in terms of responding to the organization's needs. Basically, you need to understand what areas you need agility in — is it marketing, product development, manufacturing, supply chain? And you need to anticipate where are those systems — the legacy systems that you are maintaining using these old techniques — are going to break. Then you can decide where you need to start something completely green-field.
I don't think vendors typically put the ability to export out of my tool into their tool high on the list. So, to Carole-Ann's point, hearing from customers that these things are important is key in getting specs like that moved forward. Until then, hopefully, most vendors do support some type of ability to reach out and execute somebody else's framework.
Okay. Let's go to another question if we can.
Are you talking about integrating more the business modeling capabilities? Is that what you're referring to?
[From the Audience]
I'm talking more about keeping the rule traceability. Part of the whole business rules approach is being able to understand what's being executed at runtime, tracing it back into the business policies and the operational rules. That's very important, especially in the requirements and the regulations that we're having the meet now-a-days in compliance. The tools just aren't meeting that need, and we're having to do things in very awkward ways to make that happen.
So, I think that for traceability we have one challenge, which is that business rules are for agility. They are built for change. They are built not only for day-one ... but also for tomorrow and for next year and for the foreseeable future. So, there is some inconsistency between the traditional 'modeling' approach and the business rules approach.
It doesn't mean that it's totally incompatible. I do believe that the need for traceability is still there and that's why we (and all the vendors) have been adding, over time, more capabilities around the repository, for example, adding tagging or meta-information so that we can keep track of where those business rules are coming from. It might be simply referencing some regulations; it might be referencing when we input the models from the modeling side of the house. We want to know who has been creating them and maybe carry some training data information. There are a lot of things that we can import and can carry into the repository, whether it comes from the business side or is the more technical, data-centric information.
I do believe that there is opportunity for improvement, though, because this is not standardized; what is carried is not common to all the different vendors. So, right now it's more of an ad hoc kind of implementation every time.
[From the Audience]
I appreciate that response. I would just add, please listen to what we need to address our business problems ... try to understand what the customer is trying to solve. I think we've missed that mark for ten years. We've done some good things and some different things but we're really in new times now. The tools that we need to bring to bear on certain problems simply aren't there when we need them, and now we're behind. So, I would encourage you to reach out to customers and listen to their experiences and what they are trying to solve.
In answer to that, I think a lot of vendors do listen to their customers. Last year, at Pega, we came out with a virtual enterprise repository because we had so many customers who are very large organizations and they had different systems in different parts of the organization. They expressed a need to have us federate all their multiple rule repositories and to create a universal registry and repository. And we did that.
However, this does not answer your question of providing that for the rest of the world. For us, it was an investment of R&D effort to help solve the problem by creating greater transparency/portability and inheritance ... by enabling reuse and training across a large enterprise or organization. So, if you will, it's a step in the right direction to what you're asking for. But our customers explicitly asked us for that.
The OMG is working on PRR to create a standard rule modeling equivalent to BPMN (business process modeling notation). That's part of the production rule standard, where you'll be able to exchange executable models. So, some of those standards are emerging. But they're going to be three, four, five years away ... still a number of years away. And they've been a number of years away for a number of years. Part of the reason for this is that we have different visions for how the rules should run and execute; there are different visions for how everything should work.
So, going back to the question of what should happen over the next five years, we should at least be able to clearly define what the vision of rules is and its place in the organization. At Innovations our focus is on giving people a diagram that's visually easy to understand and is a quick way to document that traceability you need. One of the reasons I'm working with this company is that I didn't find that ease of understanding and quickness so much in natural language — even after all the time people have spent working on natural language.
With business process modeling notation it's very complex to apply it properly. And once you've got the diagram fully detailed with all the decorations, it looks like a Christmas tree, so we lose the business analysts. What I would ask you to consider is this: is the output (the artifacts) of your development/modeling understandable by the analysts? Ask them directly, "Do you understand what this says?"
What are the use cases for discovering the changes that need to occur and the impact of those rule changes on the organization? Those are the questions we have to come back to. We can't affort to lose the analyst on this most important point because the diagrams (notations) are too complicated — or you're using some type of object model with very eclectic things. We have to get away from that. We have to come up with something that's simple.
I think we're part-way there, for example, with predictive modeling. Go into your statisticians. They create those great models that they know and love. Then, if you export those in pUML to produce a spec, we can import those or invoke them within our systems.
The spec is the key and I agree that's typically going to be moving slowly. Talking to the customers we work with, they want to be able to leverage their existing investments. They haven't really asked to be able to import things ... can you continue to maintain that rulebase in a different toolset? But I think that when those specs do come out, vendors will be looking at them and the forward-looking ones will be adopting them in quick order.
I have one challenge for you. I hear people claim that everybody wants it (every end customer wants it), but none of those end customers are part of OMG or W3C on those efforts. So, please — get them to be vocal; get them to participate. They cannot be demanding something without saying it. Actually, I don't know if that's a challenge; it's more of a plea.
[From the Audience]
Well, I can't control what others do; I wish I could. But I agree with you — participation is important. There has to be the willingness on everybody's part ... compromise has to occur for things to move forward. However, we've had a long time to do this and it's holding our industry from really getting the full value out of this. People who want to get into the market won't because they don't want to be locked into a proprietary system. I think that by keeping things like they are it's starting to diminish the value of the products.
And yet we've seen tremendous adoption and people using this technology to achieve some pretty terrific business benefits. So, while I take your point, I don't think it's affecting the growth in the adoption by people who are serious about achieving business transformation using this stuff.
We rolled out our community over a year ago, so we do have this notion of ideas that customers as well as non-customers can submit. So far, we've had lots of very interesting, very intriguing discussions on the community. Yes, it's true that I'm a big fan of Twitter and all those different things. I think it's a tremendous tool to be able to interact with customers.
About a month ago we made an announcement on social media enablement and discussed the capability that, Stephen, you're describing ... for example, the ability to have a sticky-note that can capture, at runtime, a user's reply and have that comment (or feedback) tag made into a case that is reviewed. The note is linked to the underlying intellectual property and business model (or business rule) and is driving an ongoing discussion. It's early days, but I think you're absolutely right — this kind of interaction will be very useful to make it easy for people to comment on the rule and on the process.
In a session tomorrow with Troy Foster, our CTO, I'll be describing our position on this. In a nutshell, Innovations is taking a strong position in the internet of things and, particularly, in conjunction with Bosch's commercial and auto product development tool. The basic strategy we're working on is something called a "mediated event analysis." That allows the type of mash-up/mark-up that we will see, going forward, in Web 3.0. (Web 3.0 is the idea that includes social networking — it is the internet of 'things' whereas the Web started out with 'pages' and then moved to applications and e-commerce.)
We'll be seeing a higher and higher level of integration, particularly with medical devices and all the various types of integration that will be able to occur when your rule base is scattered all across the internet of things. Of course, all of that needs to be managed, in terms of how you actually deploy and work with it, but it's a very exciting time.
A social network is yet another channel for you to interact with your customers. It's another opportunity for you to increase revenue.
It's interesting to note that the more I've looked into this, the more I see how many companies are out there trying to mine things that you are twittering. So, I do see the mining of that type of social media, along with virtual agents and decisioning systems, is going to be valuable in trying to determine what's going on out in that social area, with respect to your company and your service, and how you can treat those people.
Stephen HendrickOkay. Great. More questions?
The innovation that we're working on (I hinted about it in the discussion of KPI) will be about authoring: exposing the business rules in many different ways to the business users, who are used to decision tables, decision trees, score cards, or just forms. As part of the rules management application, we're going to create a brand new kind of representation that is going to really boost the productivity of the business users.
We have more innovation, also, in terms of managing the KPIs and being able to have more out-of-the-box equivalent of BAM (Business Activity Monitoring) modules, which we will probably call "Decision Performance Management" — something like that — once we agree on something that's not "BPM" ... so "DPM" maybe?
Another big thing we're working on at FICO is how to get all those technologies working together. So, back to your initial point on getting an ecosystem (rather than just a discrete set of technologies), we're working on getting that all together to empower the users to mix and match ... to do a 'decisioning mash-up' using predictive models and business rules and all those technologies, but without losing (compromising) the best technology for the right kind of problem.
I do believe that one size fits all is not the solution to the diversity of technologies. I think diversity is good — we just need to make sure that the technologies can be easily assembled together. That's something we are investing heavily in.
I can predict that we will unify rules and process, finally, so we can have a single object model for authoring, testing, and delivering a unified approach to process and rules, and extend it into CRM. I predict that that will happen — in fact, it has happened; we delivered it several years ago.
Our twelve-month innovation is that we're going to be releasing the mediated event service broker. Think of this as the reverse of web-services (where everyone is contracting with something). This is going to be the reverse of that — an outward-bound metaphor for the organization, based on the mediated event analysis (the mediation) pattern. As I implied in my earlier discussion, it provides a very powerful use case tool, and it vastly simplifies some of the problems we were trying to solve with business process modeling notation.
I just tried to IM my patent attorney and she hasn't gotten back to me yet. <laughter>
We'll be moving more into tighter integration with predictive analytics — that's something our customers are looking for ... more and more tight integration with the execution of dynamic real-time scoring, based on the models that you've done. A lot of our customers are really driving the scalability, with the applications that they're trying to do, so we'll see ever higher and higher, increased scalability.
The other day I got a request for 20,000 events a second, and that is really holistically treating the event. That includes materializing the data, persisting any kind of state change after that, and carrying out actions on behalf of that execution of that policy. So, real real-time.
I think if you read between the lines here, what you're hearing is that there are lot of very innovative, very sophisticated ideas being played out now. This is coming largely from the rules space but really involves the integration of analytics, business rules, event processing, at the very least. This creating a very exciting time in the business rules market space, and I think this is long-needed, quite honestly.
I think we perhaps have time for one more question.
Sixty-percent of the business we do includes a framework that has rulesets within it that help to accelerate the ROI. This is particularly the case in healthcare, in insurance, in banking and financial services, in AML fraud, and in compliance. But we also have horizontal frameworks for basic functions such as case management, project management, test management, goal requirement gathering, and requirements documentation. We've been laying frameworks into the system, and it's a significant part of what will be a $55 million R&D budget next year. And much of that is going to go into extending those frameworks.
We've heard it described that one choice you have is to go horizontal or to go vertical. I think that there is an option to provide a horizontal platform but also to make particular bets in industries that have an appetite and a need for out-of-the-box capability. We've seen tremendous uptake, particularly in the customer interaction / customer relation management framework because that's where the rules can be most effectively tested ... when the customer interacts with them.
We do go the extra mile, above and beyond that, to create real applications. You may not know FICO if you're not in the financial services industry. But we do have those best-of-breed applications that cover the entire customer lifecycle — for marketing, originations, account management, collection & recover, and fraud detection. So, today nine out of ten trico transactions go through Falcon for fraud detection. We do have more than just a few templates for business rules. We get the full models for detecting fraud plus some business rules for flash frauds and all those things that go together.
Innovations has the credit risk rating platform. This is a Basel II IRB [Internal Rating-Based Approach] model, which we've sold to eleven banks. This year, we added Fannie Mae, and we'll have an announcement the week after next on another large bank. Certainly that's been a successful business model for Innovations.
Working with various customers and the value-drivers that they've produced policies for, we've been able to drive best practices, working with churn analytics and those kinds of models. So, we've been able to package up those kinds of things as offerings within the tool.
|[Stephen Hendrick] That's great.
I think we're pretty much out of time now. So, I'd like to thank the attendees for your great questions; they've been good in terms of exercising our panel. I'd also like to thank our panelists — Carole-Ann, Russell, Tom, and Scott — for their participation. Let's have a round of applause for everybody up on the panel.
# # #