Anatomy of a Flexible Insurance Administration System
Revolutionizing Insurance Administration into Flexible Systems
Complexity in Insurance Administration Systems
Insurance Administration Systems are inherently complex, often due to the myriad of different products they must support. In many cases, logic for specific products is hard coded in the application’s rules and processes.
When these products require updates or modifications, the application logic must also be altered, leading to complexities in the system and ultimately to a higher probability of bugs. Consider a traditional life insurance system, with the following hard-coded logic:
The Challenge of Supporting New Products
In conventional systems, introducing product variations often complicates existing structures and branching logic. The simple example above shows how introducing new statements in such ‘if-then-else’ logic can disrupt previously stable scenarios, creating a significant challenge. The more complex the product portfolio, the more difficult it becomes to maintain a clean and efficient codebase.
Paradigm Shift: Structuring a more dynamic Insurance Administration System
With Product Modelling as the underlying philosophy of the Silvermoon LUNOS platform, we can effectively structure Insurance Administration Systems in a dynamic way.
This approach involves extracting product characteristics from business processes and allocating them to a dedicated product model, thereby fundamentally reorganizing dependencies and reducing system coupling.
The diagram below illustrates obtaining the maximum end age for the insurance policy (represented in LUNOS as an Agreement object).
Decoupling Logic from Processes
In the diagram above, the LUNOS-based system shows a process in which the yellow blocks depict process steps. One of the process steps is about obtaining the maximum end age that needs to be used for the Policy (an Agreement object) that is being processed. The process ‘asks’ the Agreement object what its maximum end age is but the Agreement ‘doesn’t know’. It ‘doesn’t know’ about rules and calculations and therefore delegates this to its product for answering such questions.
The following breakdown summarizes the respective responsibilities:
- Process: The process needs to know what needs to be done, as opposed to ‘how to’ do it. It also knows which Agreement (or policy) it is operating on.
- Product: The product knows the logic for any rules and calculations.
- Agreement: The Agreement object knows its data and what product it was created from. It delegates evaluating rules and performing calculations to the product. In other words, the Agreement object sends its data to the Product for the evaluation of rules and calculations.
This separation of concerns allows each component—Process, Agreement, and Product—to focus on its respective core responsibilities, making the system more modular and adaptable.
The LUNOS Advantage: Runtime Product Additions
Apart from reducing the coupling in a system, one of the most groundbreaking advantages of the LUNOS platform is the ability to add new products at runtime—something that was previously unimaginable.
By externalizing the Product from the Agreement and Process, LUNOS provides a more flexible, future-proof solution that can adapt to new product requirements without the need for extensive reprogramming.
Implementing the Product Object Functionality
While the concept is simple, executing it in software requires careful design choices. In other words, there are choices to be made in terms of how one can design the functionality of the Product object.
One approach often followed, is to sum up the variations the system will need for supporting an insurance company’s different products. These variations can then be defined as parameters held in the Product object. When an agreement is going through a process step, the system will run the product’s parameters through code that interprets these parameters and display the desired behaviour that corresponds to the actual product definitions. The problem with this approach is that it is impossible to predict which variations will be required in future. This leads to modifications of the system as shown in the introduction.
LUNOS however, follows a more dynamic approach through the technique of ‘Product Modelling’. Product Modelling introduces a new product definition as a new object, as data. The Product object not only includes components representing the coverages or benefits a policy can offer, but also encompasses the rules and calculations relevant to the policies of this Product. The Product Modelling technique allows the business to express its products in terms of a Domain Specific Language (DSL) constructed specifically for this purpose.
This approach ensures the system is not limited to a finite set of capabilities, originally envisioned by its designers. Instead, it enables you to represent new Products you couldn’t even have imagined before.
The resulting Product Models are now stored in the system as data, avoiding the need for extensive code modifications. As a result, the system remains flexible and not confined to a limited set of capabilities.
Additionally, “Product Modelling” utilizes diagrams to visually compose and illustrate the characteristics of insurance products, making it easier for all stakeholders to understand and discuss product definitions.
Why It Matters
Actuaries will appreciate the ability to design and implement new products without the constraints of pre-defined system limitations, allowing for innovation in product offerings.
For CIOs and System Application Architects, the implications are clear: a reduction in system complexity and an increase in agility when responding to market demands.
Feel free to connect with us or send your questions to: sales@silvermoongroup.com
