Nicolas Robbe, ILOG’s VP Product Marketing, does a great job of positioning ILOG and BRMS in the SOA space in a recently published video interview by SYS-CON TV from the SOA World West 2007 conference in San Francisco.
James R. Reid, senior director of technology—Analytics, Equifax
James covers how ILOG’s BRMS is integrated into Equifax InterConnect. InterConnecct is Equifax’s decisioning platform which automates credit and lending processes.
Some points from James’ presentation:
For rule development, typically the business requirements come in from the business user/analyst. Within the rules studio Equifax have their own custom plug-ins on top of the BRMS. For instance, a BOM plug-in to verbalize all BOMs.Equifax have written their own custom rules language so business analysts can interact directly with the data - write attributes and audit the results to ensure the attributes are performing as they should be, all without the need of a developer.
Equifax extensively use ILOG’s Rule Team Server web interface to expose rules to customers.Components of Equifax rules (there can be up to 2000 rules for a given credit policy):
Equifax business rules require a very rich structured business domain object model or fact model. This allows Equifax to build their own language and score-model to expose scorecards to customers.
What are the challenges with JRules 6.x?
What are the benefits?
Daryl Plummer, group vice president and Chief Gartner Fellow
In this lively presentation, Daryl Plummer highlighted the changing perspective around the way systems are built, deployed and used.
Daryl started by pointing out that when it comes to adopting a technology like SOA, you need to build a case for the business value. You also need to be aware that SOA is not something you choose to do, it’s something that will be forced upon you. Why? Because the frequency and level of change in the business world is continually increasing.
If we don’t plan for this change:
It’s not just about being quick - you need to plan in order to be agile. How does BPM help us with this? If the business processes are more dynamic, this will have a positive impact on these areas of the enterprise:
It’s a misnomer to talk about alignment between business and IT. It’s more a case of fusion. Another misunderstanding is to talk about SOA integration - it’s about interoperability. It’s about letting systems communicate with each other - not merging or integrating them.
So what exactly is a service? Something that abstracts the work. It lets us ask something and receive a result without having to worry about how the result was arrived at. Daryl claims that people are service-driven, using the example of how we use electricity. Once we find the socket, we just plug in our appliance and get on with it. We don’t care how the electricity is generated or which generator gives us the power.
SOA allows us to control how the services are used. Daryl uses the example of the travel plug that allows us to use a US hairdryer in the UK. This interface is the equivalent of an SOA.
There has been an evolution in the way applications are written. In the past the whole application was developed as a single unit. Now, we separate out the different parts. User interfaces are in portal or on the web. Databases have been pulled out into separate applications. Decision points have been pulled out and put in rules engines. The processes have been pulled out so business people can alter the process themselves, without having to try to communicate changes to the IT team. When it comes to the web, SOAP and WSDL allow us to link services together.
In order to make your business process-centric, you need to:
Daryl went on to explain the link between events and services. The service should be constructed to respond to an event. An event is a change in the system or the state. When an event happens, I’ll do something. I’ll design in a more declarative fashion. That fits the SOA model. I can handle information that’s coming from anywhere and continue to add processes to the sytem to evolve it.
Daryl added a note of caution when pulling everything together. SOA is IT-driven. BPM is business-led. You need a process-centric stack in the middle that will tie the two together, rather than assuming that this will naturally happen.
Where will this all lead? The final stage is the agile business structure where the structure of the business can lead to innovation.
For more information and links, check out James Taylor’s commentary on this session.
Moderator:
Tony Baer (TB), principal, onStrategies; formerly an analyst with Datamonitor/Computerwire
Panelists:
Barry Vandevier (BV), CTO, Travelocity
Sandeep Gupta (SG), Vice President, Strategic Software Development, Equifax
Chris French (CF), Partner, Deloitte Consulting
Sam Paper (SP), Senior Vice President, Client Management and Credit Technology, Strategy and Service Orientation, Bank of America
TB: What is your strategy on .NET?
SP: We’re pleased with the responsiveness of ILOG in bringing .NET products to market. Particularly the Microsoft integration. We look forward to seeing this in JRules.
TB: How is the economic environment effecting your product development?
BV: We’re currently assessing our view of spend. But we do need to continue to innovate. We’re still focussed on our strategy on services. Our global development team is also important to us. Whether or not there’s a recession we still have to do our core business.
SG: We are proceeding with caution. We’re seeing some strain in the retail sector. From an innovation point of view you need to be in the right place if the recession does hit. We will still need to meet our customer’s requirements tomorrow, hence we need to continue planning and spending.
CF: We still expect to grow over the next year, although we have seen a slowdown in the FSI industry.
SP: From the IT side, paradoxically there is more opportunity for IT investment to help streamline operations and make processes more efficient.
TB: On a related note, the dollar is not as strong as it has been. How has this affected your global picture?
BV: We find talent across the globe - albeit India or Argentina. Development and marketing in a global realm makes a lot of sense for us.
SG: On the supply side, we have not seen any major drop as a result of the change in exchange rate.
SP: We have a global model - even the work we’re doing with ILOG is coming out of Shanghai. You need to have flexibility from where you deliver your solutions.
SP: All of our BRMS development is here in the US. This has not had a major effect on us.
TB: There has always been a gap between the C* suite and IT. How do you deal with this?
SG: The divide is growing wider. It’s becoming more difficult for the C* suite to understand the strategic level: an example being which technologies will survive the current proliferation. IT wants to be oblivious to what the business imperatives are. Technical teams need to make sure they do take on the needs of the C* suite.
BV: IT is always pushed to develop faster. BRMS is a key element to help us achieve this. If we get to the points where we need to quickly change suppliers, we can do so with a BRMS. Better, faster, cheaper.
SP: A BRMS capability gives the business more transparency, flexibility.
TB: As a profession, are we getting too infatuated with open source?
BV: We’re big fans of open source but we do use commercial applications as well. It depends on the application -it’s a balance. We are also intersted in standards and make sure that we don’t just jump on the latest technologies.
SG: What has happened with open source is a phenomenon. But it does depend on the business use. Open source particularly benefits the new entrants into the market.
CF: This area is more driven by our clients needs.
SP: It’s a balance - we have to look at each case closely.
TB: Can we overdo process?
BV: If you’re not careful, you can go overboard. Particularly if you over-adopt SOX. You have to make sure you have a happy medium.
SG: As far as the BRMS is concerned, it depends where you are. Eg. government needs due diligence. If the process is heavier, you need more people. If you are leaner, you can get greater ROI from your workforce. Google is a great case in point. We need to make sure we have the right balance.
CF: One problem we have is how we rationalise and limit the redundancy where many systems are concerned. You have to make sure you don’t just layer on top of legacy systems as this will lead to problems in the future.
TB: How do you avoid the technical/political tug of war with the adoption of a BRMS?
CF: We had to look at what a rule was and where we should apply them. Rules are everywhere but you need to concentrate on the core rules. What is actually impacted? You need to get into the science of what rules are about and where they should be applied.
SP: We need to focus on our core applications to redeploy a BPM/SOA. We haven’t talked about our packaged applications.
Moderator:
Steve Nunez (SN), product reviews contributor, InfoWorld
Panel:
Maura Cole (MC), Business System Specialist, aigdirect.com
Darren Koch (DK), Senior Manager, Revenue Management, Hotwire
James Taylor (JT), author of “Smart (Enough) Systems“
The session started with questions from Steve:
SN: How do you work with linking your business processes to rules?
MC: We work with Excel to test the rules. This is a fully manual process, although we can move to production quickly. Rules are changed as part of a scheduled release.
DK: We tread the line between responsible/frenzied. There are no requirements beyond those in the heads of the analysts. Scripts cover the QA process. We can implement in as little as two hours. About half of that time is automated.
JT: There is the recognition that in an emergency things can be changed immediately. This is one of the big benefits of implementing rules.
SN: Do you have the ability to rollback if there’s a problem?
DK: We don’t have the kind of system eBay use. We normally just apply two rules at a time so we can pull these out if we need to.
SN: Do you have a governance process
MC: Yes, we have a team that are responsible for looking into this.
DK: We’re much lighter on this. I’ll approve changes and then pass these changes out to all engineers. Once this stage gets approved, the changes are pushed out to production. The original push for changes will come from the analysts.
SN: What is the process for passing rules down from business analysts?
MC: We don’t currently have the business analysts interacting directly with the rules. We’re interested in looking into the ILOG approach that can bring business analysts closer to the rules. We do currently let business analysts change the parameters of the rules - just not the logic.
DK: The IT department works on the BOM and keeping the site up. We originally started with a table that gets mapped to output.
SN: What is the biggest requirement for a BRMS?
DK: Speed of use. We’re constantly changing and trying new things. We make changes and we measure the effects.
JT: It’s interesting that some resources have to move. Business users need to add headcount - IT will loses some. This can cause organizational problems in dealing with this.
DK: We didn’t see it, but our organization is smaller.
MC: Our business analysts are not directly involved so it did not increase the resource requirements.
SN: What were the biggest challenges you face?
MC: Testing of the rules. Billing is complicated and these rules are difficult to change quickly. A lot of the rules are shared, and there’s a possibility that if you break something you can break something else further down the chain.
DK: We don’t have that problem as we don’t share rules across lines of business. We try and keep things in a linear process. All our rules are run realtime. For instance, when you book a flight, the rules are running while the bar moves across the screen.
MC: Performance is very important. A team checks that performance remains within company standards.
SN: Any unexpected benefits?
MC: When we put down the underwriting rules, no one in the business knew what the rules were. By exposing these rules, there’s new awareness of what’s going on. This transparency (not just to IT) is a good thing.
DK: We found something similar. eg. what is the process and how do things happen? We could go through the rules and look at the process, rather than having to rely on a software engineer.
JT: You will see IT and underwriters looking around the same screen - something that never would have happened in the past.
SN: Where is the IT function within the process?
DK: They concentrate on the BOM. They also vocalize the BOM.
Audience questions:
Question: When your business users starting writing rules, how did you test?
DK: We transitioned the testing. We had a script that sent thousands of simulated user searches through the rules. This helped us pinpoint problems.
JT: If business users are involved, there’s generally investment in automated testing. Tests that are meaningful to the business users, not just IT.
DK: We do have an error correction program. We never have the same mistake happen twice!
Question: Who were the sponsors for the deployment of rules?
MC: IT were the sponsors. Many IT analysts come from a business background so they were more aware of the business needs.
DK: For us, the push came from business users - an executive saw the value in the flexibility rules could offer and approached IT. The option was to buy or build. IT decided to buy.
JT: In my experience, both IT and business can be sponsors. IT tend to be IT-centric. This often adds another round to the implementation. The BOM needs to be redefined for the business perspective.
Question: How many rules did you start off with?
DK: We started by replicating a table with 10-50000 rows. This led to about 10 rules. Now we have 20-30 rules.
JT: Many of the best case studies have a very few number of rules.
Question: How do you manage the versioning if one rule is modified for another team?
DK: Our org is small - only 2-3 people change the rules. We keep it small and self-contained so that doesn’t really happen.
Question: How many people in the group change rules without changing the rest of the application?
Audience poll result: of those who responded, majority change rules without changing app.
Question: Is there anyway to extract the rules and see dependancies?
MC: Billing rules are embedded within use cases. These rules are pulled out to Excel spreadsheet and this can help spot dependancies.
JT: Another technique is to externalise the decisions from the use cases to cut down on the number of changes. The decisions change a lot more than the use cases.
Question: As you migrate the rules did you have any challenges?
DK: Security and access with our other systems. These systems are changed by engineers, not business users. The business users are sometimes overlooked and not told of these changes.
MC: We used a phased approach for migration. This worked for us.
