Resolve the top-level structure of the insurance system

Http://tech.ccidnet.com/pub/disp/Article? Columnid = 322 & ArticleID = 36322 & pageno = 1
In this article Article We will introduce the top-level subsystems that exist in most modern insurance systems based on the insurance value chain. An important part of the insurance system is the so-called product server. In typical cases, as a product server, it has a rule system for processing product rules.

Model 1: Insurance Value Chain

Example

You are assigned to design a structure for the new insurance office system. In the current system, you find one system branch by product type, such as life insurance, property insurance, and vehicle insurance. You find that there are a lot of overlapping functions in these existing systems, especially in the reporting and policy processing systems. You also find that the effort to add a new product is very tedious and lengthy, and it starts at the rate of adding two new products each year. The reason for this inefficiency lies in the chaotic product knowledge of system management policy and management declaration processing, and more other product knowledge still exists in other parts of the system.

Problem

For most commercial functions and business objects in an insurance office system, what is a good domain architecture?

Constraints

The system should be constructed in this way, and it must support your competitive strategy. We have discussed market constraints at work.

Solution

The domain structure is structured based on the value chain in insurance. Product-policy-reporting processing-sales and marketing-Customer Service, plus help systems, such as partner subsystems, insurance object subsystems, and inbound and outbound payment systems.

Structure

Figure 1 insurance system structure based on the insurance value chain

Similar to Porter's value chain model, this structure is adopted by the insurance industry.

Modeling the value chain through subsystems:

· Product development and definition subsystems: products must be defined before they are used by other subsystems. The product development and definition subsystem is responsible for providing product definitions for other systems. The product definition is explained in other parts of the system.

· Policy parameter subsystem: stores policy parameters and supports all use cases for commercial activities.

· Sales and Marketing subsystem: process customer-oriented product sales

· Customer service subsystem: helps you provide additional services you expect to your customers, which are out of the services specified by the complaint system.

To model all business functions, you need to help the sub-system as follows:

· Partner subsystem: stores information about all your partners.

· Sub-system of objects under warranty: stores information about objects under warranty and insurance.

· Payment subsystem: processes the cash flows of income and expenditure.

Generally, you will find that there are many other systems, such as general bookkeeping, management information systems and data warehouses, and human resources systems. These systems are not only for insurance systems, it exists in general, so we will not discuss it further here.

Conclusion

Instead of using the insurance value chain model to get a flexible and flexible system and shorten the market development time, you also need to use more models such as product servers and product instance parameters to help you achieve your goals.

In this mode, you can build a system that meets all product categories, but it cannot be deployed in one step. In most cases, you need to start from some product categories, and then gradually expand the system to migrate from the legacy system. In this case, you can avoid repeated investment and reduce development costs.

The above structure is designed for the internal service system. It does not affect your service attitude.

The above structure does not mean that the layers of communication can be reduced and the cost can be saved. To achieve this goal, you need to start the business process reorganization and adopt the workflow system.

Implementation

The insurance value chain is a domain framework model. To realize a real system, you need an application architecture. Currently, most domain systems are built through a tree-like hierarchy. Workflow systems are also frequently used. Generally, you cannot implement the entire system at once in one place, or a single virtual system at once. The current network bandwidth and performance are not satisfactory. Based on these considerations, You have to divide the system into two systems: inactive service and insurance sales.

Variant

You will often find differences in how the product system and the policy parameter system work together. The product server model to be discussed is different from the above two. Other frameworks such as UDP do not provide subsystem boundaries between the two subsystems, but policy parameters are used as product instances, the two systems are properly coupled.

Related Mode

Generally, product subsystems are implemented as product servers.

A policy parameter subsystem is usually implemented using a user-defined product framework, which can take full advantage of the advantages of the component mode and the type object mode. Generally, you can use policy parameters as product instances.

Known applications

The above architecture is described in more detail in several fields of the insurance industry, such as Phoenix architecture, IAA--IBM insurance application architecture or VAA (vaa95.

Despite the huge insurance market, there is little information about the insurance system, which is opposite to other market fields. For more information about the basic concepts and raw material products based on the value chain architecture, see innovative Gestaltung von versicherungsprodukten. The preceding known applications have a large number of documents describing similar domain architectures. The IBM-based IAAs is also a huge domain framework, but it has been registered and is not made public to the public.

Mode 2: Product Server

Suppose you want to build a product-driven insurance system that generally has a logistics system to handle proposals, manage policy parameters, and handle complaints. On the other hand, you also need to provide product definitions for personal computers for sale, such as internal supply or insurance broker support, and other systems.

Figure 2 clear product definitions are required for multiple systems

Problem

Where to define your product knowledge and how to publish it?

Constraints

In addition to the above mentioned, there are several factors to consider:

Platform independence: the logistic system generally runs on OS/390 machines, the sales PC generally runs Win95 or other personal operating systems, and the clients on the Internet may run Java applications, or the server side written using embedded HTML and a certain languageProgramApplication. Your product definition must be accessible on different platforms.

Interface Design: wide interfaces may lead to difficulties in maintenance and the software structure is too cohesive. Narrow interfaces are suitable for a large number of customers on different platforms.

Product knowledge encapsulation: on the one hand, you want to encapsulate all product knowledge. The advantage is that, for example, only one product definition can be interpreted in all the dialogs, and the new product definition can be automatically changed. The disadvantage is that the automated interface lacks aesthetics. This method is suitable for the Internal Service System dialog box, but not for the sales dialog box and multimedia product display on the salesman's laptop.

Demand differences: although the same product definition is required for both the internal service system and the sales system, they differ in the product definition perspective. For internal systems that store all policy parameters, you need both the old product definition and the actual product definition. For the sales system, you only need the product programs you actually sell. A product definition knows more products, including those that are not yet in development and sales programs, and must provide different views for these systems.

1 2Next page>

Solution

Encapsulate product knowledge in the product server. Encapsulate it in a portable product running system during running and provide a view using the appearance

Structure

You will find the following components in a typical product Server:

Product Editor: provides easy-to-use interfaces for users who define products. The product definition may be stable in the product model.

Fixed Product Definition: represents a fixed business object of your product. How to better organize these objects will be discussed in the product tree and compensation for Object events.

The first two components may also be organized in a common object-oriented tree hierarchy.

Figure 3 structure of the product Server

Commercial objects represent stable product definitions and are rarely transplanted. Therefore, we need more components.

Generator: responsible for generating portable products from the definition of stable productsCode.

Product runtime system: it can run on OS/390 and Windows platform, and is responsible for interpreting the code generated above. Some systems use ansi c as the system code for product runtime to ensure system portability.

If you want to provide a very narrow interface in the product runtime system, but do not want to deal with too many original interface operations, you may achieve:

Front-end components: provide different views for your product definition system

Figure 4 salesman laptop

The fact that the product server contains all components does not mean that all these components must run on a single machine, nor that the product Server is a server in the customer/server system mode.

Figure 4 shows the configuration of the sales system. The sales dialog box uses the product runtime system through front-end components. The rest of the so-called product servers, product editors, product business objects, and generators may run on different machines in different operating systems and technical architectures.

Conclusion

The insurance system uses product servers to provide excellent flexibility and platform independence. Compared to using only the activity object model, you can use the product server to assign different views to the same product definition in your sales system, website, and so on.

The disadvantage lies in the creation process. Compared with using the active object model and reflection, using the generator has some disadvantages. However, this disadvantage can be remedied by some fact in one aspect. When editing, you do not want your modifications to the product to be seen elsewhere. Insurance products must be tested, released, and versioned just like code. A system uses a simple active object model. For product development and testing, the model is general and fuzzy. production is inefficient and prone to difficulties.

Other conclusions:

Platform independence: Achieve platform independence by using a portable product runtime system

Good Interface Design: designing a very narrow interface for the product operation system may achieve a good interface design

Optimal Interface Design: contains the expertise of some products and covers their trends. This is an extraordinary Design

Requirement differences: different front-end components can be used in the system during product operation to ensure compatibility with requirements.

Implementation

By using the active object model in the tree structure, you can use the product editor as a common object-oriented application.

Related Mode

To implement the product editor, you should use the product tree, and the product tree is organized in the object event compensation mode. You also need to integrate the table system and rule system. The running system can adopt the virtual machine mode. Front-end components are used to provide different product views for product definitions.

To implement the product business model for the product editor, you can use the activity object model and launch.

Known applications

This idea of using product servers can be found in many insurance systems. You can see the section in VP/MS, for example, using the caf product definition. EA generali's two projects also contain the idea of the product server: KPS/s, a property insurance project being developed; Phoenix, a life insurance system to be completed.

Mode 3: rule system

Example

If you have implemented a product editor that allows you to define the product structure, you need a mechanism to export the node elements of the tree from one attribute to another, for example, evaluating policy parameters.

Problem

How do you implement features like authenticity check or policy evaluation on the product tree?

Motivation

Use by system administrators: If you want your system administrator to define a new product without code, you must provide an explanation language that can attribute the product, performance estimation is connected and table search can be implemented. If you start your job with this idea, you will soon find that this requires a newProgramming LanguageOnly. For further discussions about these, see programming-based customization on WWW (http://c2.com ). The discussion there is similar to hard coding for scripting: generally hard coding (especially in Smalltalk) is easier than trying to create another Smalltalk on smalltalk.

Cost: it is expensive to develop a rule system rashly. Training Smalltalk for some system administrators is generally less costly than developing a customizable programming language for them. In addition, we know that, as in Excel, implementing functions like the formula interpreter at an acceptable price is often accepted by the system administrator.

Traceability mechanism: If you want to establish a rule system, it is best to export all the properties required by the product definition. Otherwise, you have to program the implementation.

Flexibility: for compiling languages like C ++, it is necessary to edit, compile, and link the language. For the system administrator, an Excel form seems more flexible.

Test and debug a product: If you want to implement the same encoding property tracing mechanism as the script language in your product definition, you need some other programming language Environments and additional tools, for example, you can customize the debugger.

Solution

Establishes an attribute tracing mechanism similar to the semantic function in the parsing tree, or cell computing in the Excell form, which is explained at runtime.

Structure

See Figure 6: insurance product tree. Like compiling and building, you can use a programming language (such as lex/YACC) to program semantic functions, or you can define a complete set of tools in different scripting languages.

Note that this does not have much to do with rules-based systems, such as risk assessment systems in life insurance. In a rule-based system, you often see expert systems (such as those implemented using PROLOG ). The rule system mentioned here implements business rules on a fairly definite and predictable basis.

Conclusion

The conclusions are as diverse as the implementation approaches. How to Use them depends on your motivation. These aspects are very similar to programming languages. Here are some examples. In the system I know, these examples will happen or already happen:

Incomplete Rule Definition Language: in this case, you will need to partially encode the attributes for traceability and definition. The result is that compared with the flexibility and customization provided by the rule, you have paid too much.

Super-complete rule Definition Language: such a very complex language is prone to errors and expensive. Rather than using an explanatory programming language.

Related Mode

Related models are required to implement the product tree. The interpreter and virtual machine are often used to implement the rule system.

Known applications

UDP outlines how to use Smalltalk to implement a rule system. VP/MS uses a version that is very similar to a data table. Phoenix uses both hard encoding and rules.

"Imported from umlchina 』

(Edit responsibility Sunny )

<Previous Page1 2