Welcome event

• CGI has a number of different apps - it's not just Ratabase!
• CGI is BIG! ~26 000 employees and growing

Introduction:

• Begins with Clients introducing themselves & how they use Ratabase. We (LNW) run the Ratabase calculator on Unix with a DB2 backend and IBM WebSphere app server interfacing to the calculator via JNI
• Some use Ratabase for Underwriting Rules (probably a bad idea, but meh...)
• Mike (of Chubb) is interested in decoupling & using SOA (so, might want to talk to him, since we do that at LNW)
• Geico people say they're on v5.0 (so, might want to talk to them about migration)
• Liberty International uses it with Specialty Lines (there's other parts of Liberty that use it? <sarcasm>who'd have guessed?</sarcasm>)
• <something> going to .NET
• Traveller's looking for WC Anniversary Rating advice (sounds like they need to talk to Deb...we've already dealt with this problem space)
• Erie Insurance implies that the Report Tool can be used to verify the TRN files in multiple environments (might prove useful if we have sync problems between any of our 5 environments).
• And ends with various awards being handed out

Panel discussion:

• Notes taken but not really coherent. Mostly questions about the direction of rating stuff in the insurance industry (so I didn't follow too well, and stopped even trying to take notes half way through).

Distribution ("What to Pack"): Santa Rita room, 13:00

• You need a Workflow!
• Starts in Product Builder (sounds like distribution isn't such a big deal for us because it's just Deb doing Ratabase right now)
• SHOULD use Product Builder's data statuses
• Can't (yet) do distribution by date
• "Status is just a checklist" - it doesn't affect operations
  • 'Ready to File' locks data down to read-only
  • 'Filed' is not reversible! (except when it is)
• Date changes can be done on 'User Filed' items (date change utility)
• v5.0 allows more test distributions: distribute while recalled so can test recalled changes
• General Distribution: redistribute everything
  • Sounds like what I think we do now
  • Maybe for fixes we could go with Specific Element
• What type of distribution are we doing?
  • Production or Test?(T*.trn == Test)
  • Loader is stricter with Production target
• "Distribution Drawer" in Product Builder stores distribution definitions
  • We should keep a log of distributed data
• Production TRN distribution: D*.trn
• With general distribution, don't have to worry about missing file loads
• Drawer allows recreation of a TRN
  • Unless filings have been shredded
  • Or dates changed - GETADDR error
  • Also, it creates a new sequence number (to allow rbdload to load the file)
• Owner-sharer relationships can be tricky
  • Don't want owner distributed? Out of luck if sharer used it & gets distributed.
• v5.0:
  • Distribution files have changed
    • Can run reports on production databases to get build info
    • Adds TRN file sequence/version number to database!
    • We can read the sequence number & output version automatically!
• Filings shredded in Product Builder but distributed will only be removed by using RBDelete – loading/reloading will not remove them.
• Archive utility also exists to pull things off production databases too
• When dealing with Owner-Sharer relationships, Product Builder actually does duplicate the data, but it also keeps track of what the relationships WOULD BE
  • Sharing data doesn't actually exist in the production DB, it's just relationships based on OID's
• Shredding may be needed to break sharing relationships (for us this "future" is when we move to User Filing)
• Date Changes need to be done after shredding & recreation
  • because dates are used in the object mapping (if OID changes)
  • dates are also used to pick filings
  • TRN Loader matches on OID || all other fields
• If the table structure changes, Originators (owners) need to be put in first
• Auditing is only done on user filed data
  • So we don't have any auditing support now?!
• Recall Distribution must be done after recall & before any future distributions
• Different regions wont get caught with sequence errors on load (sequence numbers don't have to be increasing across regions, just within a region)

Interactive Discussion

• Characteristics of good Ratabase programmer/analyst/whatever (people that work with Ratabase/Product Builder)
  • Team Player: needs to bridge IT & biz users
  • Problem solver
  • Analytical (LM PM VP said the economics majors worked out better than others)
  • Attention to detail!
  • Some use Actuarial to do Ratabase because they make the rate changes anyway (I think we technically do this, at least if you look at the titles & reporting structures)
  • Some use Consumer Affairs because of their understanding of the regulations and mediation of dealings with regulators
  • But you don't need a CPCU
    • Need to understand the Product though
    • Maybe only really need some biz knowledgeable users; not everyone needs to know it to code it.
    • Really need people who understand Formulas & Math
  • Must play well with others ("Participants are all in Partnerships")
  • Some projects helped by strong leads/PM
  • Colocating can be very helpful too
  • Can't separate IT & Biz that much; Ratabase is in between both worlds

Client Product Forum

• Apparently they have this conference call every quarter to discuss how people feel about Ratabase
• Kind of a User Group for Ratabase
• Gives CGI feedback for future plans/support options
• v.5.0: Need to upgrade from v.4.2
• v.5.01: Need to upgrade from v.5.0
  • Better Testing
  • Added XML API
  • Allows arbitrary NoMatch entries (indices in Item blocks don't need to be pre-allocated)
  • FTP into site to get the Full distro (direct from v.4.2 to v.5.01)
• v.6.0 is in progress
  • .NET native app!
  • can now sort columns of data by clicking on the column
  • Filing groups
  • Can now view formulas graphically (WPF maybe?)
  • Will be able to re-rate within calls (so we could conceivably do 1 call with multiple passes)
  • XML data API expanded to encompass Data Validation
• Listening to what other people say, it sounds like a lot of companies have bad practices:
  • Passing data through Ratabase
  • Not tracking changes
  • Making Ratabase take on roles it wasn't designed for:
    • workflow
    • rules
  • Why would one have thousands & thousands of tables!?
• Maybe we should adopt a naming practice for input fields
  • Assuming they're actually different than the ones marked as Input in the database (no, you aren't supposed to be mucking around inside the database to figure things out...)
• Liberty Mutual Personal Markets needs >15 digit numbers (trillions)
• XML test cases for testing tool might be good

Now playing: Veda Hille – the riot life – lucklucky