Some models of the insurance system

Wolfgang Keller's introduction to some Pattern, which is used by the insurance system. This is an epidemic translation of online popularity, but in the first look, there are a number of industrial vocabulary, specially made amendment, and by the way, it will become a Word document, although it is not clear. Some people have done this. Although the original text has been published for a long time, I think that domestic insurance software developers have difficulty in achieving these pattern. Some models of the insurance system

Author: Wolfgang Keller forward, liwenhua translated article taken from: UMLChina January 10, 2003

For many insurance companies, it is necessary to build a shortened product cycle, flexible, flexible insurance system is a challenge. Although this system has a huge market, many projects are carried out around these, but these projects seem to still have some confusing. In fact, this problem has no answer.

Insurance System Reference Model Overview

With the secret change of financial markets, competition is intensified, shorter product innovation cycles will help you lead you in this competitive financial service market. Service providers always want to expand to new product areas, so they are allowed to sell. They try to provide personalized products to provide better service for existing customers. At the same time, in order to reduce investment costs, there must be a flexible flexible system. The flexible flexible system can reach the above objectives under the affordable maintenance expenses. In order to achieve these goals, the financial industry uses many systems. These systems have a lot of similarity. This similarity is the so-called product drive method in the banking industry and the insurance industry. This approach is to draw from conventional manufacturing, but it has a significant difference from the traditional manufacturing industry. This difference is that you enter the system's insured service while producing an order (insurance policy). After all, financial products are invisible.

A similar situation in other industries

This paper collects some modes in the product-driven insurance system, which explains the basic laws and programs of the various parts of the driving insurance system operation. These patterns are designed very flexible and can be seen in many systems in insurance and financial industries. Perhaps you can find these patterns in other industries, however, this will not explain how you don't need actual project background knowledge in other fields, they can be applied to those areas. If someone has made similar patterns from other industries, we can compare them, match them.

"Product Tree" is a core model - this mode is trying to present the product with the structure of the tree - its prototype is from the manufacturing industry, but it has been applied to the insurance industry recently (about 10 years). The service provider wants to use a series of predefined elements to configure the product in the way they need, this idea can also be seen in the manufacturing and other industries. There are several ways to be a batch customization, and they are seriously relying on information technology to deliver mass-customized products [and 97]. There is a typical example of a typical example in the computer industry - Dell or Vobis can customize your computer. There is also the same example (Levy Strauss and others) in the fabric industry. Personal non-real products can also be found in the telecommunications industry. The bill plan can also be configured using techniques similar to product trees and product servers to make configurations from predefined construction blocks. This article does not use all mode language to degrade mode. In fact, there are many ways to model product modeling, and we only use one here.

Existing insurance reservation reference model

Many readers interested in patterns may have heard of IAA (IBM's Insurance Application Architecture), and how can I be related to it? In fact, IAA is worth the price. In addition to the second-hand resources that can be used, I have not directly exposed it directly, and there is no discussion of this dependency in detail. I am sorry for this, but this is not my fault. I can use only VAA (VAA95). VAA is an open model for the German insurance industry, I always refer to it as much as possible. The general dynamic driving of driver applications The factors that drive these patterns are clear, they include: 1. Flexibility in the market in the market: In Europe, in recent decades, the government has been strictly standardizing the insurance market. However, with the emergence of irregular factors in the global market and European market, insurance companies found that they were in a new competitive space. Banks, other financial services providers, insurance peers from neighboring countries, and other institutions, etc., these new competitors continue to emerge. Time has played a decisive role in the market. Those companies that have the ability to design new products faster and bring products to the market, and companies that provide personalized service products will have more competitive advantages than those who have introduced a new product to the market better. 2. New products and personalized products: Michael Porter analyzes several competition strategies (POR85), one is a price competition, one is quality competition, and one is a comprehensive service competition. If you want to open up a new market, or want to be a leader in the eyes of the customer's eyes, more products have more products in more customers will undoubtedly help you achieve your dreams. In the early stages of industrialization, all aspects of overhead conflicts with each other, and it is difficult to do this. However, with the current chance of modern computer technology, providing customer personalized products with lower overhead has become possible, and what is needed is to combine the standard element modules of the original product with customers. Who can provide customers with personalized products who have many competitive advantages. 3. Service points and save expenses: There are many strategies to enhance competitiveness. One of the strategies is to provide personal service. Many insurance systems are also purely implementing the old office system, a large number of official documents flow between multiple offices and sales representatives. Save the expenditure strategy is the middle steps that aiming at aimbing of the briefcases. The insurance system is deployed in a place closer to our customers, by using internet and personal computers, the laptop represented by the sales representative can be tightly integrated with the transaction center. 4. Development costs: The insurance industry provides pure intangible services, which are neither hardware that can not be touched. An insurance company can significantly reduce the expenditure of the data processing process, which is nothing from the manufacturer to reduce labor costs and production of raw materials. This means that it means competitive advantage. Therefore, when the insurance system is developed, it is also necessary to pursue development costs while providing more functions and flexibility. 5. The traditional structure of an insurance company corresponds to product packages and development expenses: Take the new insurance industry involved, the insurance company has a few more time, it is their need to support data processing technology. development of. The legacy system and organization of the insurance industry are generally built around the product classification. For example, you will see life insurance, health insurance and property insurance, which reflect the distribution of the company's organizational institutions and treatment processes. If you design the system according to this, there will be a large amount of functional redundancy, for example, the customer's application processing system and customer applications in property insurance apply is the same, and health insurance and life insurance are It is an insurance object that is human body. So developing systems around the product will lead to unnecessary development expenses.

From another aspect, if all the field experts are still old concepts, even if some products are very proficient, they are very unique to other products, then it is necessary to develop the system that can meet all products. It is also very difficult. There are often differences in reality, and different departments are not willing to work together to establish systems for all product categories. Mode The model here is quite strong inherent contact, which can be organized into some chapters to tell some chapters. Figure 1 indication of the set set

The mode given here is only part of many modes involved in the insurance area, and if they organize them, they will help better understand. So we arrange these patterns to the top structure of the insurance system: Most insurance systems involve how to deal with the structure of the top subsystem. In this section, the mode to be described is: insurance value chain, product server, and rule system for product server typical subsystems. Insurance Product Model: Here is some modes that make sense to model the product server products. This section describes the modes: product trees and object events. Policy: This part involves how to implement an insurance policy, here only one mode is provided: as a policy of the product instance. Distributed insurance system: In a typical insurance system, if we have a virtual supercomputer, this supercomputer is closely linked to every employee in the insurance organization, and the data access is not required. Limit and free, then you will find that some subsystems are unnecessary. Unfortunately, in reality, it is still necessary to develop these subsystems. Then, there will be some modes for distributed processing, such as an insurance sales system, or a table system.

Top structure of the insurance system

In this article, we will introduce the top subsystems that can be seen in most modern insurance systems. A very important product component in the insurance system is the so-called product server. Typically, as a product server, there is a rule system for processing product rules.

Insurance chain

Example You are assigned to design the structure for the new insurance office system. In the current system, you find a system branch based on product classification, such as Life Insurance, Property Insurance, Auto Insurance. You find that there are a large number of cross-repetitive functions in these existing systems, especially in the declaration processing system and policy processing system. You also found that it is necessary to add a new product to do very cumbersome and long, it is carried out at the rate of increasing two new products per year. Such inefficient reasons are derived from the system management policy part and the product knowledge of the management declaration processing section, and more other product knowledge is still in other parts of the system. The problem is a good domain framework for most of the business functions and business objects in an insurance office system. What is a good field architecture? The constraint system should be constructed, it must support your competitive strategy. We have discussed market constraints in our work. Solution in the field structure according to the value of the value of the value. Products - Policy - Declaration - Sales and Market - Customer Services, coupled with help systems, such as partner subsystems, insurance object subsystems, and enter and exit payment systems. structure

Fig. 2 is a structural diagram of an insurance system in accordance with the insurance value chain. Similar to the value chain model of Porter, this structure is adopted by the insurance industry.

Value chain modeling through subsystems: · Product development and definition subsystem: Products must be defined before other subsystems. Product development and definition subsystems are responsible for providing product definitions for other systems. Product definitions are explained by other parts of the system. · Policy subsystem: Responsible for storage policy, support all use cases of business activities.

Coroned subsystem: All insurance claims concentration, main business objects include events, claims, personnel institutions and others involved.

· Sales and market systems: Handling customers-oriented product sales · Customer service subsystem: help to provide your customers with extra services, these services are outside the service specified by the complaint system. To build all business features, you need to help subsystems as the same below: · Partner subsystem: Store information about all partners of your company. · Benevitated to be aimed: Store information about being protected and insured. · Payment subsystem: Treatment of cash flow in income and expenditure. Usually you will find a lot of systems, such as General Bookkeeping, manage information systems and data warehouses, human resource systems, etc., these systems are not for the insurance system, but we are generally existed, so we are no longer Further tell. Conclusion Not as long as the insurance value chain model can get a flexible flexible system and shortened market development time, you also need to use more similar product servers, product instance parameters such as to help you achieve goals. You can build a system that meets all product classes, but you can't get in place. In most cases you need to start from a part of the product class, then gradually expand your system to migrate from your legacy system. If so, you avoid duplication of investment, thereby reducing development costs. The above structure is designed for the inactive system. It does not separately affect your attitude on service. The above structure does not mean that the level of communication can be reduced, saving expenses. To reach this, you need to start the business process restructuring and use a workflow system. Implementing the insurance value chain is a domain architecture mode to implement a real system you need an application architecture. At present, most of the field systems are built by a tree hierarchy. Workflow systems are often used. Typically, you can't achieve the entire system at a place, or you have a virtual single system. The current network bandwidth and performance are not as well, based on these considerations, you have to divide the system into two systems in terms of parish and insurance. Variant You often find the difference in the combination of product systems and policy systems. The product server mode to be talked is different from the two described above, while the other like UDP, there is no subsystem boundary between the two subsystems, but the policy is used as the product instance, and it is adjusted two System related mode is generally, and the product subsystem is implemented as a product server. A baffle system usually implements user-defined product frameworks, which makes it possible to take advantage of component mode and Type Object mode. Usually, you can regard the policy as a product instance. It is known to apply the above architecture in several field frames, such as the Phoenix frame, IAA - IBM's insurance application frame or VAA (VAA95) has a more detailed description. Further reading Although the insurance market is huge, there is still very little information on the insurance system, and this is the opposite of other markets. Related concepts of basic concepts and raw materials based on value chain architecture can be found in "Innovative Gestaltung Von Versicherungsprodukten". The above known application has a large number of documents, describes similar domain frameworks. IAA from IBM is also a huge domain architecture, but it has been registered and does not open to the public.

Mode: Product Server

example

Suppose you want to build a product-driven insurance system, this system generally has a logistics system to handle the plan, manage policy, and process the claim. On the other hand, you also need to provide product definitions for individual computers for sales, such as internal supply or insurance brokerage support.

Figure 2 Multiple systems require a clear product definition

Where is the problem defined your product knowledge and how to release it? The constraints are also mentioned above, there are several factors that also need to consider: platform independence: logistics system is generally running on OS / 390 machine, selling PCs generally running Win95 or other personal operating systems, clients on the Internet may run Java Applications, or consist of an embedded HTML with a server-side programmap program written in a language. Your product definition must be accessible at different platforms. Interface design: Wide interface is easy to lead to maintenance difficulties and software structures are too consolidated. The narrow interface is suitable for a large number of customers in different platforms. Product Knowledge Package to Best User Interface Design: On the one hand, you want to encapsulate all product knowledge. The benefit is that, for example, all dialog box only explains a product definition, and can automatically change the new product definition. The disadvantage is that the automated interface is lacking. This approach is suitable for attendance system dialogs, but is not suitable for sales dialogs and multimedia product display on the salesperson laptop. Demand difference: Although the termination system and sales system need to use the same product definition, they differ from the perspective of product definitions. For inactive systems that store all policy, you need the actual product definition of old product definitions. For sales systems, you only need your actual sales product. A product definition knows more products, including those that have not yet appeared in development and sales programs, need to provide different views for these systems. The program is encapsulated in the product server. During operation, you can encapsulate it in a portable product running system and use the appearance to provide a view. You will find the following components in a typical product server: Product editor: Provides an easy-to-use interface to define the product. Product definitions may stabilize in the product model. Fixed product definition: Represents a fixed business object of your product. How to best organize these objects will be discussed in both product trees and object events. The first two components may also be organized in an ordinary object-oriented three-layer structure.

Figure 3 Structure of the product server

The business object represents a stable product definition, rarely being transplanted. So we need more components. Generator: Responsible for generating a portable code from a stable product definition. Product Runtime System: You can run on OS / 390 and on the Window platform, responsible for explaining the code generated above. Some systems use ANSI C to run time-run system coding to ensure the portability of the system. If you want to provide a very narrow interface in the product runtime system, don't want to handle too much original interface operation, maybe you can implement: front-end part: provide different views for your product definition system

Figure 4 Salesperson laptop

The so-called product server includes all components that do not mean that all of these components must be running on a single machine, nor means that the product server is server from the client / server system mode. To understand this, please see Figure 4: Configuration of the Sales System. The sales dialog uses a product runtime system through the front end part. The residual part of the so-called product server, product editor, product business object, generator may run in different machines and different operating systems and technology architectures. Conclusion Insurance systems use product servers to provide excellent flexibility and platform independence. Compared to only the active object model, use the product server can give different views in your sales system, website, etc. The disadvantage is that the creation process is created. Use the generator with certain disadvantages compared to the active object model and reflection. But this shortcoming can make up for a certain fact in one aspect. Usually you are editing, you don't want you to meet the product's changes to elsewhere. The insurance product also needs testing, release, version of the same as the code. A system uses a simple activity object model, product development, test, generally blurred, production is not efficient, easy to fall into trouble. Other conclusions are: Platform independence: By using a portable product runtime system to achieve a platform independent interface design: Design a very narrow interface for product operation system, a very narrow interface can achieve good interface design optimal user interface design : Contains specific knowledge of certain products and covers its trend. This is the extraordinary design demand difference: can be implemented by using different front-end components in the product runtime system to use the active object model in the tree hierarchium, which can be implemented as a normal object-oriented application. Related Matters To implement product editor, you should use the product tree, and the product tree uses object event compensation mode organization. You also need to integrate the table system and rule system. The runtime system can use the mode used to implement the virtual machine. The front end component is used to provide different product views for product definitions. To achieve a product business model for the product editor, an active object model and launch can be used. This idea that is known to use a product server can be found in many insurance systems. A portion can be seen in VP / MS, such as a product definition of CAF. The two projects implemented by Ea Generali also include the idea of ​​product servers: KPS / S, a development of property insurance projects; Phoenix, a life insurance system that is fast to complete. Mode: Rule system

For example, if you implement a product editor, this product editor allows you to define the product structure, then you need a mechanism to export another attribute from a property of the tree, such as an evaluation policy. Question How do you implement a realistic check or a policy evaluation of the product tree? Motivation system administrator use: If you plan to let your system administrator do not encode, define new products, you must provide a language that can connect product properties, performance estimates and can implement table lookup. If you start your work in accordance with this idea, you will find that this requires a new programming language. Further discussion on these can see "Customize" "by programming" "(http://c2.com) on WWW. The discussion with" hard-coded scripting programming language "is similar: general hardcodes (especially in smaltalk) Compared to try to build a SmallTalk on SmallTalk. Vasually. Consideration: Developing a rule system is expensive risk. To some system administrators training SmallTalk is generally less than to develop a customizable programming language. In addition, we know Like Excel, the functionality like the formula interpreter is also intended to accept the system administrator as an acceptable price. The completion of the retrospective mechanism: If you want to create a rule system, it is best to complete the product definition needs. All attributes are exported, otherwise you have to program the implementation. Flexibility: For compilation languages ​​like C , you want to edit / compile / link to complete, the system administrator is an Excel form seems to be flexible. Test and debug product : If you want to implement a script language in your product definition, you need some other programming locale, as well as additional tools, such as a custom debugger. Scheme establish a semantic function similar to the resolution tree Attribute traceability mechanism, or unit calculation in the Excell form, interpretation at runtime. Structure Referring to Figure 6: Insurance product tree. If you build, you can use some programming languages ​​(such as lex / yacc) to program a programming function, Or you can also define a complete set of tools in a variety of different scripting languages. Note that this is based on rule-based systems, such as the risk assessment system in life insurance, there is not much relationship. In rule-based systems, you often You can see the expert system (such as Prolog implement). We talk about the rules system to implement business rules in a fairly determined and expected basis. Conclusion, as a variety of ways, how to use it depending on you Motivation. These aspects are very similar to the programming language design. Some examples are given, in the system I know, these examples will happen: Incomplete rule definition language: In this case, you will need some code To complete the property traceability and definition, this result is that you pay too high for the flexibility and customizable of it. Ultra-complete rule definition language: This very complex language is easy to errors and quite expensive. It is better to use explanatory programming languages. Related mode requires related modes to implement product trees. Interpreters and virtual machines are often used to implement rule systems. Known Apply UDP a text out how to use SmallTalk to implement a rule system .vp / ms Used a version, this version is very like electronic data. PHOENIX mix uses hard coding and rules. Insurance system product model

This article includes some modes that are very useful in product server modeling insurance products. These modes are: product trees and object event compensation. Modeling products have a wide range of ways, and object event compensation is just one of them. See [SCH 96] You can get more information, and we have to explore more information from it in the future.

Mode: Product tree

Example You are determined to build a product server along the insurance value chain. Before design, you need to know how to model the insurance product. What is a good insurance product display? In addition to the conventional factors of driving insurance applications, the following factors also need to consider: Comparison of users with flexibility and versatility: You need to use the model that users understand, and engineering is very difficult to understand abstract data model. Reuse and flexibility: Good ways can be reused at the program module level. The ideal way is to form a module library during product development, which can be directly reused or combined to form new products, just like manufacturing industries. The program is built into a tree, just like a bicycle that usually makes it. Structure Figure 1 Insurance product tree (P15)

* The node of the tree is a product or product component; * Each node is descriptated; * Join the premium computing function as the export rule, the simulation compiler parsing the semantic function of the tree, or writes your own rule system (see Ralph Johnson UDP paper). Result Product Flexibility: Once you clarify the constituent element block, design and modeling new products, it will become easier and more. The user includes: the actual work of the development of the product server shows that some field experts who have some extra knowledge can model the product tree. Reuse: Once you define the product constitutes a block, you can reuse in both new or existing products. Realization of strict implementation This design also needs to make some additional design considerations. Product tree modeling does not mean that you can organize these product trees, nor you have the best product model design. Please refer to the subject event compensation to obtain some tips. Usually you will use the combination mode and the Type Object model to model the policy into a product instance. Combining the exported properties and these models can get the complete framework described in the work in Ralph Johnson and Jeff Okes. There are two very basic alternatives for designing the runtime system of the product 1. In the first way, it is assumed that the product editor works on the same database and models as an active implementation in a productive system. This will result in the active object model described by Ralph Johnson and Jeff Okes. 2. In the second way, it is assumed that the development space and product space are strictly separated, which is the product server mode. Variety often builds modules, then there will be certain properties to be shared. Consider the following two product elements: pension components and risk life insurance, you will find that the insured between the two is the properties of the relevant object. In a product collection, it is necessary to determine the attributes of two insured people in combination. This creates a DAG representation (direct non-cycle chart) instead of the tree type. The correlation mode mode is the key to implementing the system based on the insurance value chain. It has been discussed in front of this system planning. This method is known to use this method is very common in the insurance industry. For example, the VP / MS product definition system of CAF. Two systems developed by Ea Generali, such as the undergoing property insurance system KPS / S and the fast life insurance system Phoenix also contains the idea of ​​product servers. Other insurance companies are also or have already used this way.

Further reading

The idea of ​​imitating manufacturing components Dispersion manufacturing is to be discussed by Paul Schonsleben and Ruth Leuzinger at a certain level. Ralph Johnson and Jeff Okes discussed how to use the same system with object-oriented.

Mode: Object Event Compensation System Model

Example You have decided to build your insurance products into a product tree, so you start working, your companions work with you. When you combine two systems built by different people, you find that a single product tree example does not allow you to reorganize from the previous structural block. Problem uses a tree structure to model the insurance product, what good way? How to make good abstraction when modeling insurance products? Motivation quality and understandability: the existence of multiple programming languages, only one way to realize the insurance product tree will bring a poor structure structure, it is not easy to understand, resulting in maintenance difficulties. Similar situations in many areas, there is a fairly high-level abstract construction model example, such as object modeling, physical relationship modeling, etc. You need some rules or domain analysis model to reduce the scope of the solution, Some specifications are also needed to reduce modeling difficulty. Reuse: also requires modeling specifications. Your insurance product component is destroyed, the easier it is to be reused in other products. The program uses an object event compensation mode modeling insurance product. Each insurance product ensures one or more insurance objects. If the specific event related to that object occurs, the customer has the right to apply for a certain compensation. Structure Your product tree should be the following: Figure 2 Tree according to the object event compensation model organization

Each object has a recursive: an object may contain other objects, one product may contain other products, and so on. However, the basis of this tree structure is very stable. Result Productivity and Reuse: If each developer persists the same or similar model mode, you can achieve a common understanding of the product structure, which will achieve higher productivity and better reusability. Related mode object event compensation mode only describes the high-level product structure, which requires more detailed mode as a definition, semantic rules, how to check, and so on. To dig these modes, you need to refer to some product models created by different people or different companies. Since the product model is a confidential information of competition, we need a longer time to wait until it is open.

Further reading

There is no book on this topic that there is no article to introduce, but product providers like CAF provide training and related course materials.

Policy

This article mainly introduces how to implement insurance policy, this chapter has only one model, product instantiation policy.

Mode: Instantiation Policy

Alias ​​Mirror Parts List Example is very happy that you just completed your product editor. You use a combination mode to implement it and use a layered list box on the interface. You have typed product data in the leaf junction, and object event compensation has also joined some. Problem How to indicate the insurance product policy Motivation General Motivation: The maximum motivation is the motive for driving the insurance application design. The key is flexible. If you can't handle new products in logistics systems, the best product server is also useless. Therefore, the system that handles the policy should be as flexible like a product definition tool. The program creates a product policy instance, and is done with Type Object mode, then the policy can reflect the definition of the tree product. structure

Figure 1 As a guarantee of the product instance

Some product instances are saved in the policy factory as prototypes. Instantizes these prototypes with real data form a policy. Results · Flexibility: Like the most reflected system, you will get a very flexible and flexible system, which allows you to keep your same product definition. · Portability: You must take into account the portability of the system in advance. If you use this model to implement an active object model on a host, if the system does not have good portability, you may need to spend a lot of time to achieve the same system in the salesperson's laptop. · Performance: If you don't pay attention to performance, the same performance like most transmit systems may become very poor. If you have a 6-layer depth product tree, use a local database store, you need to work properly, you need to extract, for example, 100 database records can be done. To avoid this, you need to create a more intelligent database map. Variant actually, you can find two main mode varieties. Single database system: In this case, the product data definition system and the policy component are implemented in a single database. You can use the product editor to create a new product prototype in the policy factory. In this case, the policy factory is also a product pool of a product definition system. Insufficient lack of this way: excessively closely coupled to the production of product development and actual products. The advantage is that once you define the product, this product is immediately used in the product system (for testing and release, this is actually its shortcomings). In most cases, there is no way to use a single product to define data sources on a salesman's laptop. If you insist on this business object, you will fall into huge performance. Decoupling method: Central policy management system and insurance sales system share a product server: use the product server, put the policy factory (see Figure 2) as a client of the product runtime system, and remove the product definition dialog from Figure 2. Disadvantages of this method: more complex, not intuitive, and some redundancy. Advantages: Product Definition Systems are separated from the policy system, there is more room for more adjustment. You can build other clients, such as an insurance sales system. Figure 2 Single Database Product Definition and Policy Management System

Related Mode This mode is a combination and a recursive use of Type Object mode in a particular environment. Another call is an active object model, which is a variant of the transmit mode. You specify the type of product tree component for the product definition system for the first time using Type Object. The second use is a complex tree example (product tree instance) as an insurance policy (see Figure 1). Use a composite type to build a product tree and a policy tree. A concrete warranty tree is a product tree. It is known that the PVS of the generali Munich is the use of a single database on a host. Although the UDP system did not express which variant used, it looks more like using a single database. The PHOENIX project in Generali also uses a variant of a single database. We have not seen the decoupling implementation, but it is very likely that it will implement it in an item behind us. Further reading the specific discussion of object-oriented design considerations in the construction of product trees, you can refer to Ralph Johnson and Jeff Okes articles, they give this topic deep-level pattern. This article uses the interpreter to calculate the export attribute to give a deep discussion. Distributed Insurance System In a typical insurance system, under a hypothesis, you may find that some subsystems are not necessary. This hypothesis is that we have a virtual supercomputer, which does not have a network bandwidth limit, which enables everyone in the insurance organization without delayed access without delaying and no fees. Unfortunately, such a system does not exist. Now we will search for a mode of handling distributed applications, such as insurance sales systems and table systems.

Mode: Insurance Sales System

Example You have a flexible logistics system that you want a laptop office system that makes your sales representatives help you better sell products defined through the product server. How to construct a sales system on the laptop of the sales representative? In addition to the above-mentioned general motivation, you should also pay attention to some of the special motives below: System Publish: The ideal insurance system should have a distributed virtual framework, this framework is provided to a graphical user interface of the salesperson, and the salesperson will gently press the finger. You can get the necessary information. This system is not too expensive because we have different performance on network I / O in memory access, file and database I / O. After all, there is no free unlimited bandwidth. Low investment contrast personal market performance: Today you may be able to buy a system for selling standard financial products at a lower price. But this is not what you want. What you need is the performance of the personal market rather than standard products, you need to get them faster. This is discussed in detail above the general motivation mentioned above. Flexibility: Shorten product innovation cycle requires a very flexible system. Reuse and single source: In order to ensure the cost limit, avoid the redundancy problem brought by multiple sources, you need a single code base and to maximize reuse at the front-end office system and logistics office system. Innovation: Say "I can", you can't attract your customers. You need a place to insert innovative components in your application. Program first, put all things needed to sell products and provide services on the ladle of the salesperson. The more you are ready. These functions are then divided into any insurance company's universal shell, a partner subsystem, a sales record, a contact subsystem, and the core sales part of the insurance policy into a policy. If you like, you can add a multimedia sales part. Connect the system to the central processing system unit to handle the insurance and exchange customer data. structure

Figure 3 Structure of an insurance sales system application

The various components in the system have the following responsibilities: Universal Shell provides PC-oriented object-oriented schemes such as MVC frameworks, all of the basic components needed to hold the framework. It also provides your data copy, universal application driver. General Application Drivers make it easy to insert new applications. Partner Subsystem: Allows the sales representative to collect information about your customers, our customers 'financial conditions, and customers' hobbies. All measures are smoothed, and can be selected from the current group. A partner subsystem is generally much more functions than the logist office system for the salesperson. Sales Record: Allows you to track your partners from you or other companies have purchased products. Personality depends on the quality of the difference analysis components you want to provide. Contact Subsystem: This component is used to track your appointment, plan customization, and so on. Sales: Provide dialog box allows you to calculate your insurance policy with your customers in a certain format. These dialogs are product-oriented, typical is to use the product server. Differential analysis: a typical personalized component. It can collect customer information and make a comparison with the total needs of customers, it is best to list the products that customers may purchase from you. Innovation parts: Anything that can help you sell product parts, such as multimedia product information, will benefit your analysis. Examples already know the implementation method of using the shell, now you contact a seller, start a project, then you can put your product and innovative ideas into the housing. Conclusion The performance of the network: offline system is in performance, the disadvantage is that all enterprises are not allowed. You need to sell your products rather than imagine the maximum function on POS. · Function: Mode describes the system you see today, without describing the system you will see in the future - we will see more features to POS. This is a real model rather than just looking for future. Low investment contrast personal market performance: This mode takes into account the personal market performance (product and innovation components) that strict in relatively low investment. This mode also reserved space as a plug-in innovation. · Flexibility: In the sale of each product part, the product server provides a short product innovation cycle. · Reuse and single source: This model can be used by a series of methods to reuse: First, when you don't intend to override a separate partner or contact your application, you can use this mode. Second, a product server can be used. Another good idea to improve reuse is the concept of component hierarchy and business object hierarchy. Related Mode A sales system often uses product server runtime components, as well as table systems and rule systems. It is known to have several examples of several custom products to support this mode. For example, NSE developed the FINAS system (www.caf.de), CAF development SILVA system (www.caf.de). Some personalized products such as the Kubis or Interunfall of EA-GENERALI are similar. Mode: Table System

Example insurance systems, especially those who treat products, require a number of forms. These tables are used to provide legal sets of keywords, providing automatic insurance policy, such as from region to related interest rate mapping. Question How do you provide flexible and meet the needs of performance, enabling a smooth access to data that is read-only, and can provide data organizations in the table, providing to domain experts to update. Motivation performance comparison redundancy features: If you want to achieve another database system than relational database performance, you just have less features, you are a redundancy of the manufacturing system. Instead, provide a local read-only database, which has a very good access speed, considering the later maintenance cost, such component repetition is completely worthwhile. Investment and consideration of data distribution: In a central database, you have no data repetition issues at all. And if you have another database using the file, use the main memory when online, use local storage when offline, so that there is a problem with data repetition. So you need to weigh the data distribution convenience and data access efficiency. The distribution of tests and new products: Defining products are like writing code. In an insurance application, the data in the table is defined data, so it must be treated like the code: they need to be versioned, need to test and release process code. If you want this feature in a central database system, you have to create some additional processes anyway. Historical data needs: The insurance system is very dependent on historical data. Due to the existence of internal audit, you need to reproduce any historical state. Worse, once the policy changes, you must be able to reproduce any current and historical data related to the insurance contract at any time. This is the so-called two-dimensional history. In fact, no database can support this feature naturally. Solution uses a table system, the table is the unique data extraction layer of this system. These tables reside in the main memory of the runtime. Structure For customers, a table system provides a series of tables to store intermediate extraction data. Figure 4 Insurance application contains a table of legal sets

For a table system, you need some basic components.

· A table editor for administrators enter legitimate data. · Need to distribute to all customers' forms. They are usually saved in text files or other file system formats. · When the customer system starts, you need to load all the tables to memory. If the customer system does not have enough memory to reprint all forms, it can only read the desired form using the cache mechanism and swap mechanism. Conclusion Performance: The access speed of the table system is far better than the database system (the former is the nanosecond level, the latter is a small grade) redundancy and cost: Install a corrected database in your main memory, have to develop as data distribution , Test, edit the developer. A table system is not cheap. Table system can be found on the variant market, such a table system either handle historical data or cannot be processed. Related Mode Related Multi-Historical Data Mode Set: Historical Mapping Mode and 2D Historical Mode. To really implement a system, the details given are not enough. Our own phoenix framework contains an implementation, but a design is not a model, and we know only another realization, but it is very difficult. It is known to apply Table / 23 to the European insurance market host and customer system use a wide range of products. VP / MS contains a table system that serves as a component of the product server (but does not contain historical data). Both products are used in multiple insurance systems. VAA contains a form of table system specification that is used in insurance business.

Often used mode and strategy

The models that are often used in this article are listed below: the active object model does not need to be programmed to use the activity object model. Similarly to this is that the meta system or reflection business process reorganization you will often combine a new insurance system and business process restructuring. The mode representation of the BPR is shown in the BEE97 combination mode combination mode is the mode to be used when modeling product trees. In order to achieve a rule system, you need to create your own interpretation, this time the most commonly used the interpreter mode reflecting mode describes the component in the form of a mode. To achieve the flexibility of the product, you need to use the activity object model. The Type Object Type Object mode can be used to connect to the policy and product, and the method is based on the construction of the product policy. The recursive structure of the product tree is compounded. Virtual Machine If you create a product server, you may need to explain your product definition. At this point you can use a virtual machine from running products (product instances are policies) to decouple product definition (programming) The overall partial combination mode is a variant of the overall partial mode. Therefore, from this sense, whenever combined mode is used, it is in the use of the overall partial mode. thank

I would like to thank my PLOP tutor Richard Helm, thank him for giving me a lot of useful tips and suggestions.

Attachment: Subject Description:

1. Some format finishing

2. The original translation leaked a few words, and added.

3. Adjust some of the original translation, such as:

Policy: Policy (for the original translation is the policy or policy parameters)

Claim: Claim (the original translation is a complaint)

Interface: Interface (for the original interface)