Today, it is clear that SOA brings high business value to the table, especially for insurance enterprises that have numerous deployed systems and technologies that require orchestration and communication (see the diagram below from Celent).
The value of SOA is achieved by bringing closer the different systems and exposing legacy systems to newly purchased systems and home-grown ones. Insurance companies involve complex transactions with high volumes of data and data attributes that include many conditions and rules which are defined for underwriting, premium calculations, commercial treaties and other purposes.
Source: Celent
The next generation of packages for insurance companies should take the technology and characteristics of insurance business into the next level of productivity. Service activation usually involves data transfer between different systems. In many cases the amount of data exported, transferred through the ESB (Enterprise Service Hub) and imported at the other end is massive; insurance rules are highly dependant on product / cover versions and many forms of insurance rules come in the format of coefficient tables (which is a format often derived from actuarial statistical analysis). Thus, standard SOA will cause for reduced performance and duplication of data models. Standard rule engines will require large amounts of data transfer and product versions will need to be set up manually as extra rules will complicate the model.
A possible solution for enabling better performance and higher productivity as implemented in the IDIT™ software insurance package is to place a central databus, easily accessible through XML, for the placement and retrieval of data. A simple method using OGNL (Object Graph Navigation Language) enables non-technical power users to write rules which use the data on the bus very easily (e.g. if Policy.totalPremium > 500). The Insurance-oriented rule engine is called so because it automatically stores the version context of all rules and rule-sets (while enabling reuse), based on its link to the insurance product. In addition, coefficient tables are placed on the databus and are accessed by the rule engine in a rule format as well. This way conditions, calculations and coefficient expressions, can be set and maintained in one place using one data model.
Once this infrastructure is set up, SOA can be used not only for ‘plumbing’ as performed in standard ESB platforms, but it can become the foundation for the gradual evolution of the older systems and logic onto the service BUS. This seems very challenging; how can this be performed?
Each time a service requires major modification or when a new service is required - it will be performed on the suggested platform (rule-engine & databus) pending ROI checks. This way, a gradual evolution of older logic and older technologies is facilitated onto the platform (only for older systems). In IDIT™'s case for instance, this platform also includes a large library of insurance-related services so the evolution can be made even more effectively, with greater momentum. This replaces the common practice that SOA ushered in – investing more in legacy systems since they can be ‘plumbed now’ into the architecture.
This enables a very cost-efficient and affordable, yet architecturally sound roadmap, not only to connect your existing systems and services together, but also, to have a foundation for new services that is up to date with the latest technologies and best practices.
An additional added value is centralizing back the data-model into a model which has greater cohesion and, through the databus, can become the single point for all data-model metadata that can ease further integration work with other enterprises or systems.
= = =
