Insurance policy parameters

Http://tech.ccidnet.com/pub/article/c291_a36325_p1.html Introduction to insurance policy parameters (1)

Author: by Wolfgang Keller, translated by liwenhua at 15:47:42

This article mainly introduces how to implement insurance policy parameters, and analyzes the modes of the insurance sales system and table system in detail. Mode 1: instantiate policy parameters Alias Image parts list Example We are glad that you have just completed your product editor. You use the combination mode to implement it, and use a hierarchical list box on the interface. You have already typed product data at the leaf node, and added some compensation for Object events. Problem How to express insurance product policy parameters Motivation General motivation: The biggest motivation is to drive the design of insurance applications. The key is flexibility. If you cannot process new products in the logistics system, the best product server is useless. Therefore, systems that process policy parameters should be as flexible as product-defined tools. Solution Create a product policy parameter instance and use the type object mode. Then, policy parameters can reflect the tree-type product definition. Structure Figure 1 as the policy parameter of the product instance Some product instances are stored as prototypes in the Policy parameter factory. The policy parameters are formed by instantiating these prototypes with real data. Result · Flexibility: like the most reflective system, you will get a very flexible system that keeps you synchronized with product definitions. · Portability: you must consider the portability of the system in advance. If you use this model to implement the active object model on a host, if the system is not portable, you may need to spend a considerable amount of time on the salesman's laptop to implement the same system. · Performance: If you do not pay attention to performance frequently, the performance may become poor just like that of most launch systems. If you have a 6-layer in-depth product tree and store it in a local database, you need to extract 100 database records for normal operation. To avoid this situation, you need to build a more intelligent database ing. Variant In fact, you can find two major pattern variants. Single Database System: in this case, product data definition systems and policy parameter components are implemented in a single database. You can use the product editor to create a product prototype in the Policy parameter factory. In this case, the policy parameter factory is also the data pool of the product definition system. Disadvantages of this method: Over-tightly coupled with product development and production. The advantage is that once you define a product, this product can be used in the product system immediately (for testing and release, this is actually its disadvantage ). In most cases, there is no way to use a single product to define a data source on a salesperson's laptop. If you naively stick to this business object, you will be in huge performance troubles. Decoupling Method: the central policy parameter management system and the insurance sales system share a product server: use the product server and use the policy parameter Factory (see figure 2) as the client of the system during product operation, the product definition dialog box is removed from Figure 2. Disadvantages of this method: the implementation is more complex, not intuitive, and redundant. Advantage: The product definition system is separated from the policy parameter system, so there is more room for performance adjustment. You can create other clients, such as the insurance sales system. Figure 2 single database product definition and Policy parameter Management System Related Mode This mode is used recursively in a specific environment in combination and type object mode. Another method is the active object model, which is a variant of the launch mode. In the product definition system, it is the first time you use type object to specify the type for the product tree component. The second use is to prototype a complex tree instance (product tree instance) as an insurance policy parameter (see figure 1 ). Build a product tree and a policy parameter tree using a composite type. A specific policy parameter tree is a product tree. Known applications The PVS of generali Munich is to use a single database on a host. Although the UDP system does not specify which variants are used, it looks more like a single database. The Phoenix Project in generali also uses a single database variant. We have not yet seen the implementation of decoupling, but it is very likely that we will implement it in a later project. Further reading For a detailed discussion about the object-oriented design considerations for building the product tree, refer toArticleThey provided a deep-seated model for this topic. This article provides a deep discussion on how to use the interpreter to calculate export attributes. Distributed Insurance System In a typical insurance system, under a certain assumption, you may find that some subsystems are not necessary. This assumption is that we have a virtual supercomputer that has no limits on network bandwidth. It allows everyone in the insurance organization to access the computer without delay and requires no fees. Unfortunately, such a system does not exist. Now, we will search for patterns that can process distributed applications, such as insurance sales systems and table systems. Mode 2: insurance sales system Example You have a flexible logistics office system, and you want a front-end office system on your laptop so that your sales representatives can help you better sell products defined by product servers. Problem How to construct the structure of the sales system on the sales representative's laptop? Motivation In addition to the above general motives, pay attention to the following special motives: System release: the ideal insurance system should have a Distributed Virtual framework that provides the salesperson with a graphical user interface. The salesperson can obtain the company's necessary information by pressing his fingers. This system cannot be too expensive, because we have different performance on memory access, files and database I/O, and network I/O. After all, there is no free unlimited bandwidth. Low investment compared with individual market performance: Today you may be able to buy systems that sell 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 the standard products. What you need is to get them faster. The general motive mentioned above discusses this in detail. Flexibility: shortening the product innovation cycle requires a flexible system. Reuse and single-source: To ensure the cost limit and avoid redundancy caused by multiple sources, you need a singleCodeLibrary, and achieve maximum reuse in the front-end office system and the logistics office system. In terms of innovation: "I can also", you cannot attract your customers. You need to insert innovative components into your applications. 1 2Next page> Introduction to insurance policy parameters (2) Author: by Wolfgang Keller, translated by liwenhua at 15:47:42 Solution First, put all the products and services to be sold on the salesman's laptop. The more you prepare, the better. These functions are then distributed to the General Shell of any company, a partner subsystem, a sales record, a contact subsystem, and core sales components that convert insurance into policy parameters. You can add a multimedia sales component if you like. Connect the system offline to the Central Processing System Unit to process insurance and exchange Customer Data. Structure Figure 3 structure of an insurance sales system application Each component in the system has the following responsibilities: The general shell provides a PC-based object-oriented solution, such as the MVC framework and all the basic components required by the framework. It also provides data replication, a universal application driver. The general application driver allows you to easily Insert new applications. Partner subsystem: Allows sales representatives to collect information about your customers, their financial status, and their interests and interests. All measures are to smooth sales and allow selective actions from the current group. A partner subsystem generally provides many more functions for salespeople than the logistics office system. · Sales records: allows you to track the products your partners have bought from you or other companies. The degree of personalization depends on the quality of the divergence analysis component you want to provide. · Contact subsystem: this component is used to track your appointment and schedule customization. · Sales: a dialog box is provided to allow you to calculate the insurance policy with your customers in a certain format. These dialogs are product-oriented, typically using product servers. · Divergence analysis: a typical personalized component. It can collect customer information and compare the existing products of the customer with the total demand. It is best to list the products that the customer may purchase from you. · Innovative components: Any product components that can help you sell, such as multimedia product information, will benefit your analysis. Example Now you know how to implement shell. Now you are contacting a seller to start a project, so you can put your products and innovative ideas into the shell. Conclusion Performance across networks: the advantage of the offline system is that it cannot access all data of the enterprise. You need to sell your product, not the biggest function you imagine on POS. · Function: the mode describes the system you see in POs today, but does not describe the system you will see in the future-we will see more functions move to POS. This is a real model, not just an outlook for the future. Low investment compared to individual market performance: This model takes into account the performance of individual markets (products and innovative components) that are expected to be achieved with a relatively low investment ). This mode also reserves space for plug-in innovation. · Flexibility: The product server provides a brief product innovation cycle when each product component is sold. · Reuse and single-source: Reuse can be achieved through a series of methods: This mode can be used when you are not planning to rewrite a single partner or contact an application system. Second, you can use the product server. Another good idea for improving reuse is to use the component concept at the component level and Business Object level. Related Mode A sales system often uses the running components of the product server, as well as the table system and rule system. Known applications Several examples of customized products support this mode. For example, the finas System (www.nse.de) developed by neuron-specific processing unit (nse.de) and the Silva System (www.caf.de) developed by caf ). Some personalized products, such as Ea-generali's Kubis or interunfall adiplus, are similar. Mode 3: Table System Example Insurance systems, especially those that process products, require many forms. These tables are used to provide a valid set of keywords, such as region-to-related interest rate ing for automatic insurance policies. Problem How do you provide a flexible and performance-oriented system that enables smooth access to the majority of read-only data and the ability to organize the data in tables and provide updates to field experts at any time. Motivation Performance compared with redundancy: If you want to implement another database system with better performance than relational databases, but with fewer features, you are creating system redundancy. On the contrary, it provides a local read-only database, which has a very good access speed. Considering the cost of later maintenance, such repeated components are completely worthwhile. Data Distribution investment and cost: in a central database, you have no data duplication problems at all. If you have another database that uses files, the system uses primary storage online and local storage offline, there will be data duplication. Therefore, you need to weigh data distribution convenience and data access efficiency. Distribution of tests and new products: Define a product just like writing code. In an insurance application, data in the table is defined data, so it must be treated like code: they need to be versioned and the process code needs to be tested and released. If you want to provide this feature in a central database system, you have to create additional processes in any case. Historical data needs: The insurance system relies heavily on historical data. Because of the internal review process, you must be able to reproduce any historical status. Worse, once policy parameters change, you must be able to reproduce any current and historical data related to insurance contracts at any time. This is the so-called two-dimensional history. In fact, no database can naturally support this function. Solution Using a table system, a table is the only data extraction layer of the system. These tables reside in the primary storage at runtime. Structure For customers, a table system provides a series of tables to store intermediate data extraction. Figure 4 insurance applications contain tables with valid title sets For a table system, you need some basic components. · A Table editor for administrators to enter valid data. · Tables to be distributed to all customers. They are usually stored in text files or other file system formats. · When the customer system starts, all the tables need to be loaded into the memory. If the customer system does not have enough memory to repost all the tables, it can use the cache mechanism and swap mechanism to read only the required tables. Conclusion Performance: the access speed of the table system is far better than that of the database system (the former is in the nanosecond level, and the latter is in the subtle level) Redundancy and cost: Install a corrected database in your primary storage and have to be developed for data distribution, testing, editing, and development.Program. A table system is not cheap. Variant A table system can be found on the market. Such a table system can either process historical data or cannot process it. Related Mode For more information about historical data models, see Fowler's Analysis Mode Set: Historical ing mode and two-dimensional historical mode. To truly implement a system, the current details are not enough. Our own Phoenix framework contains an implementation, but one design is not a pattern, and we do know the only other implementation, but it is very difficult. Known applications Table/23 is a widely used product of hosts and customer systems in the European insurance market. VP/MS contains a table system, which acts as a component of the product server (but does not contain historical data ). Both products are used in multiple insurance systems. VAA contains its own table system specification, which is used in insurance business. "Imported from umlchina 』 (Edit responsibility Sunny ) <Previous Page1 2