≡ Menu

DIALOG Group RCI and Legacy Migration


Frank DiGiovanni of Group RCI (a vacation exchange and vacation rental company, part of Wyndham Worldwide) presented on their journey  – a legacy modernization using ILOG Rules. Frank  identified SOA, legacy migration from mainframe to SOA and how business rules complements these as his key topics. Group RCI’s core problem was threefold:

  • Members: had to call RCI for everything and web experience was poor
    Lots of searches returned no or very few results. This is a real problem as it makes members feel their timeshare had less value – nothing to swap it for.
  • Business: 90% of transactions were handled by guides in the call center and slow to create new products. Complex too because different rules for everything
  • IT: 30 year old legacy COBOL application with 3M+ lines of code that was hard to change and expensive to use to support web searches

Their first step was to enhance search to allow members to see how much opportunity there was to swap their timeshare for something new and how many properties were available to rent. Developed a web 2.0 interface supporting multi-dimensional search. Let members add and remove criteria, go from map to list, see availability and reviews etc. This solved the search problem for members. But the specifics of which properties you can swap and other details involve lots of rules. This meant they needed to marry rules-based processing with the multi-dimensional search. That way people could find exciting vacations easily and then the engine could manage the details of eligibility.

Doing this has challenges – hard to reinvent member experience, using SOA and support a web 2.0 interface. Challenges include:

  • Extracting 35 years of rules from 3M lines of COBOL with limited documentation
    This is, of course, absolutely typical of legacy applications – they are big, important, complex and poorly documented!
  • Reducing costs
  • Managing organizational change
    People get very used to the old system and its implications. For instance, “requirements” tend to become tied to the implementation and so lose their focus on the business need and become more about how to change the mainframe.
  • Helping people understand what a BRMS is and why SOA would be good
    These can be abstract concepts and explaining, and selling them, is hard but necessary
  • Politics
  • Choosing between big bang and phased migration
  • ROI, justification, complexity

Their goals, specifically those related to ILOG, were to create an SOA platform that can deliver an enhanced user experience across channels by combining enterprise search with business rules. Specifically:

  • Agility to change rules in production using a well governed process
  • Move service domains one at a time – most CPU intensive first
  • Document the new rules and add governance, versioning etc
  • Demonstrate results quickly to build funding and sponsorship support – prototypes sell projects
  • Generate real reuse

They use ILOG BRMS for member visibility and inventory segmentation (35 years of contractual obligations), pricing (more than 50M calculations daily), reservations, exchange fees, discounting, communication rules and more for both members and business partners. Using rules in this way builds customer trust because they never see a property in the search that they won’t be able to exchange or rent. The rule engine constantly interacts with the search so that all the business rules that are relevant are executed as the search is being conducted – not after the fact but as “part of” the search.

Revenue analysts, marketing and IT operations people enter rules. For the revenue analysts, lots of these rules come from analytics and data mining on demand and segmentation. All these rules get pushed into the rule engine. This then sits behind all the channels (web, B2B XML, co-branded, call-center) and interacts with operational datastores (updated systematically from the mainframe database) as well as the Endeca search engine. Interestingly they did the project in a series of steps and this meant they needed some heavy duty transformation and synchronization of data between the operational datastores and the mainframe database. The alternative would have been to do a “big bang” and that would not have worked.

After all this, asked for feedback. Customers really liked the new interface and their ability to find vacations. The business (not IT) can change rules in hours not months and have increased pricing and marketing opportunities through the rules. Operationally it is saving money thanks to reduced mainframe use.

Finally some best practices:

  • Partnering with vendors and business partners
    They were very happy with the support they got from ILOG
  • Make sure you base architecture is solid
    ILOG services really helped with this too
  • Prototype – fail fast!
  • Map rewards to business success
  • Use views, templates to make it easier for business users to manage rules

Interesting presentation – nice description of how to incrementally service- and rule-enable a mainframe application.