The IAA Business Model
The following is a diagram of the Business Model from the IBM Insurance Application Architecture (IAA).
LUNOS components behave according to this model.
The LUNOS Component Collections
LUNOS Components are separated into two collections:
The first collections consists of Generic Components and Foundation Components from the Business Model shown above. We refer to these as the LUNOS CORE Components.
The reason for this is that these components are generic to the insurance industry. This means that the logic within these components does not have to change from one insurance company to the next.
The second collection of components is made up of the Specific Components, which, together with some libraries in the web tier, make up the LUNOS EXT Components (those which can be extended, hence 'EXT'). It is in the EXT layer of components that an insurance company performs its customizations and extensions.
The CORE components and customized and extended EXT components, together, make up the application that will be used by the Insurance Company.
Silvermoon Components and Layers
List of Main Components
The following is a list of some LUNOS components with brief, non-definitive descriptions.
- Account and Fund:
Provides services related to accounting in a broad sense, including General Accounting, Insurance Agreement Accounting, accounting for units purchased by a customer in a unit linked insurance agreement and Intermediary Accounting.
- Activity, Condition & Place:
Provides services to manage all activities that have occurred, are occurring now, or are planned to occur in the future. It provides services to manage assessment results. It also provides services to define and manage a place, its structure and relationship to other places, and the risk characteristics associated with a place.
- Generic Agreement:
The Generic Agreement component is a generic component that provides the classes and services for administering agreements and agreement specifications.
It is reusable for different kind of agreements such as Intermediary agreements or Insurance agreements. It models the actual agreements and the specification of agreements (product specification). Built according to the Specification Framework the Agreement Component Implements the following patterns - Specification Actual, Composition (Agreement and Request), Role, Property, Rule , Calculation, Request Behavior.
The Claim component provides services to maintain and manage a claim, from its initial opening to its satisfactory settlement and closure.
The Communication component provides services to produce and define, based on associated rules, the structure and composition of every document necessary to the business. An important example of this is the policy document associated with a policy
- Contract Framework:
The Contract Framework defines a number of classes and services that are re-used in the definition and management of specific agreements. This extends the more generic mechanisms that live in the Specification Framework.
Two very important aspects of insurance functionality are implemented in the LUNOS Contract Framework. The first aspect is the management of agreement versions. The second aspect is the management of the life cycle of the agreement objects in the insurance company.
The management of agreement versions is re-usable for the different types of contracts that are managed in the context of an insurance company. This includes insurance policies, contracts for agents and brokers, reinsurance treaties, etc.
The management of the life cycle of the agreement objects in the insurance company allows the externalisation of the state chart of the agreements such that the flow of the lifecycle of these agreements can be configured externally to the policy admin application. This is done at the level of the Product Specification such that each product is given the responsibility to know the life cycle for its insurance policies. This translates in possible actions that can be triggered from the dynamic user interface.
- Financial Transaction:
The Financial Transaction component provides generic services to manage the definition of monetary amounts, the generation and processing of financial transactions and the reporting of financial transactions. These services are used in other components such as Billing and collection management and many others.
- Physical Object:
The Physical Object component provides services to manage information related to any physical object relevant to the financial services business. Physical objects can be linked to one or more parties, be involved in insurance agreements as insured object or be involved in a claim.
Silvermoon's implementation of the Rating component provides services to define and retrieve rating data. The rating component provides a central location for all of this type of data. Calculation algorithms are not provided in the rating component. Its scope includes the definition and management of actuarial statistics, indexes and rates, as for example, mortality tables.
Party provides services to manage information related to a specific person or organisation and the various means of contacting them. The person or organisation may play many roles in the context of a financial service agreement or claim, for example, the policyholder, beneficiary, annuitant, or claimant. The party may be directly related to the agreement or be a third-party, such as a re-insurance company, intermediary, or service provider.
This provides a customer with flexibility to insert new products and their corresponding rules and calculations in the policy administration application quickly and at minimal cost.
- Financial Services Agreement:
The Financial Services Agreement component provides services to cover all maintenance operations on financial services agreements, from proposal to termination.
The early stages in the life-cycle include recognition of a proposal, making an offer or quotation, and acceptance or rejection of the contract.
Later stages in the life-cycle include cover updates, automatic renewal, policy reinstatements, and premium increases. The termination of the banking or insurance agreement can occur in many ways including expiration, maturity, lapse.
The Financial Services Agreement component is delivered with a starter set of transactions and product definitions that can be modified by a customer to suit their own requirements. The customer will maintain all source code in this component relative to their operations.
The Intermediary component provides services to manage the agreement by which compensation is defined between the modeled organization and brokers or agents.
The Common component provides services for the management of these business objects - Business Model Object, Category, Category Scheme, Type. This component provides very generic mechanisms such that it is possible to allocate a Type to every business model object as well as the capability of managing category objects.
- Request & Authorization:
This is a mechanism that allows the configuration of authorization rules per type of request (transaction) that would be performed in the insurance administration. This mechanism needs to be used in combination with the customer's own authentication mechanism.
Product Definitions and the Generic Agreement Component
The Generic Agreement Component manages agreements according to definitions that have been plugged into it. These are the rules, calculations, life-cycles and so on that govern any particular agreement.
A Product is defined through a modeling process that produces a Product Specification Diagram (PSD) for that product. The PSD is translated into a technical format and the result is plugged into the Generic Agreement component.
As soon as a product specification is plugged in, the system using the Generic Agreement can process new agreements for that product. This is the particular mechanism that guarantees an insurer rapid product development and delivery.
Check out the section on Product Modeling for more information.
The Silvermoon LUNOS Enterprise Suite is based on IAA. By default, it is a Business Service Oriented Architected solution.
The emphasis on the word "Business" is to emphasize the new paradigm of providing a solution that is open for solving any future problem. LUNOS Enterprise Suite, Solutions and Components do so without compromising an organization's ability to deal with legacy challenges. It actually liberates them into a new flexible paradigm.
For architectural context in the following sections, here is IBM's SOA Solution Stack:
IBM's SOA Solution Stack.
In IBM's SOA Solution Stack:
- Each layer has a specific focus - e.g. the bottom one focuses on data.
- Services solve a lot of issues including integration complexity and process flexibility.
- SOA addresses the cost of duplication & complexity inherent in organization silos.
Silvermoon Solution Tiers
LUNOS maps closely to IBM's SOA solution stack.
LUNOS provides a layered architecture supporting the services required to run an enterprise-level insurance system. This is the generic tiered space. Each tier supports a different set of services.
The Production Line is where work happens. Different lines of business and geographies require some differences in support. LUNOS provides the application functionality through "Requests" or "Services" to support the Workflow.
The "Requests" or "Services" are made available to the Workflow in the Process Layer. Business controls are implemented here. When it receives a request, the Process Layer consults with the Product in the Product Tier to determine what information is required to execute the Request.
It communicates this information to the Workflow and passes information received to the Product. An insurer may extend Platform functionality with additional Requests. The Requests are generic (e.g. Quote for Insurance). Request Behaviors (Transaction Behavior) may be specific to the Product or Product Family.
The customer has access to Request Behavior code and uses existing patterns to customize the functionality.
The Product Tier houses the Product Specifications and the Generic Component Foundation. The separation of Product from Process is vital for Insurance companies to achieve the speed to market and flexibility they seek. It allows the implementation of standardized, reusable processes across Product Lines without forcing a "one size fits all" solution.
The Component Tier provides Generic Services as laid out in the IAA Interface Design Model. The set of normalized components defined in the IAA IDM has been implemented in LUNOS, with each component maintaining a specific data domain (as described below) and its assigned service responsibilities. The Components directly support Insurance Company requirements as depicted in the IAA Insurance Business Model.
The Data Tier provides the Data Structures to support the Objects defined in the IAA Business Model. An important design feature is that this Tier is protected by the previous 4 Tiers.
What this means is that by the time data enters the database it has faced a gauntlet of rules in the production line, process, product and component tiers. This data is therefore highly reliable and provides a robust platform for automation. Each Component has its own database which is optimized for the specific component domain. Based on the design principles, individual components can also be replaced at any time.