IAB is short for Insurance in A Box. It is an open source development of core insurance processes that will work with any insurance product definitions. It takes a meta-programming approach and the solution is based around a product factory.
It is intended that IAB will form a baseline platform for the insurance industry, globally.
It has flexible licensing for those third-parties who wish a use it as the basis for a commercial product that they resell. The open source license is sufficient for Insurers to use the solution free of charge in-house for their own commercial activities. Under the terms of the license, to protect an Insurer's IP, the Insurer is permitted to make modifications to the source free from the obligation of feeding enhancements back into the open source base. See detailed licensing for more information.
|
Table of Contents
|
The Product Factory
For a decade or so the insurance industry has based it's electronic capability around a product factory. The product factory allows an insurer's products to be defined in, and tested from, a central repository, meaning everyone works with a common definition. There is a singular and rigorous approach to its definition, routed in powerful XML technologies.
The Product Factory concept is very powerful often the opportunity to harness its definitions are often missed.
IAB's goal is to bring those products alive over all kinds of electronic channel with minimal IT intervention, using meta-programming techniques and an agile approach.
IAB means that if you have a product definition already defined in something like Polaris ProductWriter, then from a simple touch of an IAB button, an application is created that offers the core insurance processes for that specific product. No specific code or database structure is required to support the specifics of any product. And the application it produces can be white-labelled within minutes!
IAB creates a web application from a product definition; an application that supports the core processes of new business; mid-term adjustment; renewal; and cancellation. The application that IAB generates follows standard design patterns and is easily enhanced if and where necessary. An IAB application will be 80-95% of the solution straight out of the box and is driven by the same definition that drives the rating engine; consequently many layers of software are simply removed.
IAB itself is open-source meaning that there is always access to the application generators, as well as the industry standard code it produces.
IAB also brings rigour to the methodology of production creation. Sure, those product factories mean a common definition, but we also like to help automate the process of product definition construction. IAB utilises a product library. Library fragments are used to create precise product definitions. There are over fifty separate coverages in the library already and the product definitions of most insurers can easily be assembled from those fragments.
There's even an easy way to specify which parts of the fragments you don't want included. In short the product library leads to rapid and consistent product definitions, where coverages can be adapted and re-used in subsequent product definitions.
Web 2.0
Web 2.0 is not simply about cosmetics, it is about how we reuse and connect to many varied sources of information. The applications that emerge from IAB are to be seen as fully participating and contributing the the principles of Web 2.0. Web 2.0 implies that the WWW becomes the operating system, requiring tooling / glue to join web based resources into an application. We use Ruby as our choice of glue.
Web 2.0 resources will be a mix of public available resources like google maps and blikis, to closed in-house services that are offered in a way that is entirely consistent with the web resource approach.
This was the dream of the service oriented architectures (SOA) that emerged at the start of the decade, but Web 2.0 and facilities like REST makes that vision a simple and practical reality today.
IAB Components
The IAB product comprises two distinct elements: the UI Pipeline and the IAB Server.
The UI pipeline component addresses the automatic creation of multi device and multi language white-labelled e-channels, but allows the line of business to make changes before the channel is published to the general public. It is a Ruby on Rails generator. Typically this is used to generate a Rails app for a chosen insurance product - an app that will be able to communicate with the IAB Server with no code change and no requirement to create product specific persistent stores.
The IAB Server implements the core standard insurance processes in a product neutral way, allowing the product factory definitions to shape each process in a product specific way, without the involvement of IT.
The IAB Server handles synchronous and asynchronous communication out of the box, and comes with a number of enabled channels including browser; email and XML.
Here's a video that explains the UI Pipeline component of IAB - a Ruby on Rails Generator that creates Rails views and helpers from XMLSchema definitions of insurance products:-
IAB is a multi-channel insurance application
IAB implements the standard insurance processes of New Business; MTA; Renewal; and Cancellation. It does this for any product that can be described using an XSD. It allows the creation of a web presence without creating a single line of code. The out of the box system follows the Ruby on Rails pattern and can be edited and enhanced.
IAB is founded on the principle of taking insurance product definitions in the form of XMLSchemas and using the definitions to automatically bring an e-channel to life for that definition. Practically for this to work there needs to be a rating engine that can be expressed in terms of rules based on objects and properties that are derived from an XMLSchema.
ProductWriter from Polaris in the UK is an example of such a rating engine. ProductWriter is simply a rules engine with some insurance specific intrinsic objects and properties. XMLSchemas are used to create a ProductWriter dictionary of objects and properties, based on types and elements from the XMLSchema. Rules are expressed in terms of objects and properties.
Polaris make up to 30 commercial lines schemas available to help gain a head start. Equally ACORD schemas and bespoke schemas can be used.
The rating engine works by taking an instance (containing customer answers) of the product schema and firing at the rating engine. The rating engine will respond in XML (again adhering to a response schema) with the quote and a breakdown (or maybe a decline or referral).
IAB is designed to:-
- Present a set of questions to a customer (derived from those in the product definition XML Schema) using any number of interaction channels. Our primary one is Rails of course.
- Take the answers and create an XML instance document that adheres to the product definition XMLSchema
- Pass the document to the appropriate insurance process (NB, MTA, etc) using the applicable communication pattern (sync, async)
- Provide an instance of the appropriate process to handle the request. Each core process accesses libraries of complex business logic to fulfil the request.
- Provide processes with access to services that fulfill communication with backend systems (e.g. Policy Administration, Finance, and of course the rating engine
IAB has not only rich and sophisticated UIs but under the covers….
The real complexity is in the underlying business logic and processes
At project inception in April 2006 we decided that there had to be a better way to build insurance systems for the market. Our consultants have collectively over 300 man years of insurance business knowledge and expertise from their work with the worlds big name consultancies. From Product Factory; to Reinsurance; to White Labelling, they've seen and heard it all.
Take MTAs, there are literally hundreds of subtle features required to implement MTAs, where Policy Versioning is key to many of these processes, only one of which is the support for concurrent MTAs on the same policy.
Our technicians have used meta programming techniques to build a new kind of insurance system from the ground up leveraging definitions from Polaris and ACORD. Emerging tools and techniques mean that solutions can be built in a fraction of the time.
Our competitors have spent over 300 man years programming their solutions in traditional J2EE and .NET stacks. IAB is just as functionally rich and has taken less than 30 man years. This is why we can offer its core free of charge, subject to support and consultancy; and why we actively encourage our customers to help us enhance and make the solution better! IAB is the basis for customer and partner collaboration, and is at the heart of our mentoring and exchange programme.
IAB is a Ruby on Rails Application
IAB is a Ruby on Rails application, but instead of a traditional relational database at the back end, it uses the Oracle Berkeley DB XML, so that data can represented [to our application] in the way our application thinks about it. The Berkeley DB is based on a BTree structure and allows for a wrapper, or layer to be placed atop of the core software, allowing for more appropriate data representations to the application. So think of the wrapper as something generic that is doing our application data to repository mapping.
IAB is engineered so that the same code base handles all the insurance products an organization wishes to sell
The application is driven by an XML Schema (XSD). The XSD describes the structure of the insurance product and the XSD, directly, or indirectly through generation, allows the code base to remain agnostic to the structure of the product it is administering. Throughout most of the application the quote and policy data remains in it's XML form and is persisted using Sleepycat. The generators described below are used to generate rails code and DSL modules that reflect the XSD meta data into the runtime application. This avoids constant reference to the XSD and allows the meta data therein to be utilised more effectively by Ruby. It also leads to a more human readable code base.
IAB introduces additional Rails Generators
The generators are known as the Pipeline. They take the XSD and generate rhtml files; pure Ruby files that adhere to IAB DSL; and a class hierarchy that reflects the structure of the XSD. This is used to marshall data into an XML doc from an rhtml client.
IAB includes a server written in Ruby that implements the business processes
All of the discussion so far has been around a Rails application that can be generated from an insurance product definition. The purpose of the app is to solicit data from customers, provide quotes; and convert to policies. The app is merely a gateway to a generic backend Ruby system that handles only XML requests. The requests can come from the Rails app, but equally they could arrive directly via hubs like iMarket in the UK.
The backend implements the core business processes in a channel agnostic way and provides for sync and async processing of requests.
It can handle New Business; MTA; Cancellations; and Renewal requests from multiple channels. The only prerequisite is that the channels deliver XML to the backend server.
The backend server has the ability to utilise a service broker to marshall requests to helper services. The service could provide gateways to logic on Finance and Policy Administration systems