INSIS Plataforma PMS única

Presentación del tema: "INSIS Plataforma PMS única"— Transcripción de la presentación:

1 INSIS Plataforma PMS única

2 INSIS V10 Arquitectura Componentes INSIS Configurador
INSIS Componentes funcionales core INSIS Internal service bus INSIS SOA Adapter INSIS Rule retrieval service bus INSIS Motor de Workflow INSIS Front end 2

3 INSIS V10 Configurator INSIS V10 Configuration Module consist of 3 modules Product WF FE The RE although is a very important part of the configurator can not be considered as a separate module, because is used in all 3 modules

4 Principios del Configurador de INSIS
Construcción de los componentes de configuración Construcción de repositorios Reglas de herencia y de instanciación. Intefaz de usuario intuitiva con presentación gráfica. Independencia de la plataforma The redesign of INSIS Configurator will be based on the following principles: Platform independent – the V10 Configurator will not be tied to a particular database and development platform; Combining configuration elements (parameters, elementary rules) into reusable components containing complex insurance rules and conditions – the Configurator will allow building configuration components of different complexity that can be used across multiple products Rule inheritance and rule instantiation – the V10 Configurator will allow a single rule to be inherited in multiple products simplifying the definition and the maintenance of general rules and conditions. Changing of the general rule will apply to all places where it is referred to. Alternative option will be when an existing rule is instantiated (copied) into particular product and modified to match the business requirements. In this case, changing of the general rule will not apply to the instantiated one; Configuration components versioning – the configuration definition will allow multiple versions of the same rule (simple parameter or complex condition) to be defined and active in the same time; Intuitive user interface with graphical presentation of the definitions using convenient drag and drop facilities for rapid configuration.

5 INSIS V10 Product Configurator
The Configurator will allow building of product using components of different complexity , organized into a set of repositories Each repository can, contain a number of sub-repositories grouping the rules in a structured manner. The repositories will allow the definition of structured set of rules as standalone reusable components. The components can be used across multiple products. For example, taxation configuration can be defined as generic rule with all necessary parameters. Then this rule can be referred to in all the products keeping only one definition. When the legislation changes the only thing that need to be done is to change the generic rule and the change will apply to all the products The components can also be reused by instantiation where the entire definition of the rule is copied in the product and can be modified to adjust it to the needs. In this case, changing of the generic rule will not affect the instantiated copies Easy product configuration maintenance The configuration components that are stored in the repositories can be versioned for simultaneous usage of different conditions. For example, a rating rule can be modified due to a campaign, new sales channel, new market niche, etc. Then this new rating version will coexist with the basic rate but will be referred to depending on the policy conditions, time, sales channel, customer age, etc. For compatibility with the older INSIS versions, the V10 Configurator will be available with a deployment tool that will allow the configuration content to be exported and uploaded in the standard INSIS configuration tables. INSIS V10 will use the configuration content directly from the configurator using the Rule retrieval service bus. The bus will allow simultaneous usage of existing configuration and new V10 configuration in the same instance. For migration purposes, V10 Configurator will have option to upload configuration content from the existing configuration tables into the new configurator.

6 Módulo de Reglas Un componente importante en el configurador V10
Una herramienta para manipular la estructura de datos fija. Una mejora de la calculadora de tarifas.

7 RRTF - Rule Request Transformation Function
INSIS Rule Engine INSIS Service Bus Two types of configuration data requests will be served by the bus: -forward chain -backsword chain INSIS Rule Bus Rule Engine Backward Chain Rules Forward Chain Rules RRTF - Rule Request Transformation Function Rule repository 7

8 INSIS Workflow INSIS Service Bus Service Provider Service Provider
INSIS workflow module is used to organize the processing sequences of all business operations executed with the application. The operations are organized in processes each of them containing set of elementary steps, which may correspond to the system core functions (for automatic steps) or human tasks actions (for the interactive steps requiring operator intervention). The WE engine consist of 6 main functionalities : Flow control, Validations, Authorities, Assignments, Task Executions, Audit Log WF executes tasks from other modules and has the knowledge of the executing sequence of the business operation. This module has access to all of the Service Providers on the Service Bus; it is capable of invoking any function available on the bus - therefore, the Workflow acts as “task manager” upon the rest of the systems, including Front-End. During the task execution, the Workflow is able to generate events propagated to the Service Bus. Moreover, it is capable of generating Navigation Events, consumed particularly by the Front-End Service Provider. INSIS Workflow engine plays significant role in manipulation of Front-end behavior in terms of controlling the sequence of user screens appearing in a given business process. The system provides graphical Workflow Configurator (part of INSIS Configurator) to create the process definitions with their tasks and transitions between them; to define the association between the tasks and the system functions or user interface modules; to specify assignment rules defining qualification requirements for the human tasks. The configured processes are executed by INSIS Workflow Engine. The workflow engine uses the INSIS service bus to access the core INSIS functionality including FE or external systems functionality which is involved in the process execution. The module is used to organize all complex processing sequences. Those sequences may contain automatic or manual tasks executable in the INSIS core or external systems. WF Activation Event WF Service Request INSIS Workflow engine Process Flow Control Validation Authority of Users Assignment Task Execution Audit Log / Statistics

9 Introducción a: INSIS Front End Components
Actuales requerimientos y demandas del Mercado: Una Solución que “oculte” los detalles y las complejidades de desarrollar ambientes. Personalizar la interfaz de usuario para que coincida con las necesidades de cada compañía de seguros, proporcionando herramientas interactivas para la gestión y configuración. Lo más importante: NO requiere habilidades de programación Nowadays, software engineering experiences a shift towards reusing pre-built components (user interface screens, business modules) rather than tailoring specific UI screens for each software application. The main goal is to deliver the client a set of already built UI components and a tool which allows management and customization of these components, thus giving the client full control over the final user interface of their specific application. Advantages of this software shift are numerous, most important of those are the significantly reduced development time and possibility of highly-customized and specific UI screens. Insurance software engineering is no different. So, to point out current market requirements : Insurance companies need a solution that hides the technical details and complexity of development environment Customizable user interfaces to match each individual IC needs by providing interactive tools for management and configuration Most important should be the fact that no programming skills would be required

10 Introducción a: INSIS Front End Components
El Objetivo: Identificar los elementos básicos de los procesos de seguros Creación de bloques reutilizables de aquellos elementos Organizar bloques reutilizables en un repositorio central Dar el control a los clientes sobre el repositorio, proporcionando una herramienta para la gestión y personalización de los elementos en el repositorio El Resultado Entregamos un set estándar de componentes reusables al cliente. Las compañías de seguros crean su interfaz de usuario, adaptada a sus necesidades específicas. No hay programación involucrada y el conocimiento especializado no es necesario. Analyzing the requirements formed the goal of this solution : To identify the basic elements of the insurance processes To create reusable blocks from those elements which represent basic business transactions Organize those blocks into a central repository Give the clients control over the repository by providing a tool for managing and customizing the elements in the repository. This includes editing existing elements or creating new elements. What would the result be ? A set of reusable components and an environment which can accommodate them Ability to manipulate those components without any programming skills.

11 Introdución a los Componentes INSIS Front End
La Solución !!! –Componentes INSIS Front End Se construyeron “ladrillos” de seguros específicos, analizando el proceso de negocio. Se diseñó la arquitectura de INSIS Front End, para la definición y manipulación de estos “ladrillos” . Con ella se desarrollan estos “ladrillos” como Front End Components: Se los organizó en un repositorio central. Se definió y creó un ambiente para operar los Front End Se desarrolló un “INSIS Composer” (Orquestador) – una herramienta para la administración, agregación y personalización de los Front End Components At Fadata, we have developed Front End Architecture relying on Front End Components that are organized by business purpose and functionality. How did we do that ? First of all , we classified basic building blocks of insurance by analyzing business processes. Next, a dedicated Front-end architecture was designed. It allows creation and manipulation of those building blocks. Given the FE Architecture, we developed the building blocks as Front-end components. . The FE architecture forms an operating environment which can accommodate those FE Components. Front-end Components are classified and organized into Repository with searching criteria such as business purpose, sales channel, data operation (read/write), etc. And those FE Components are managed and customized with the help of INSIS Composer –powerful tool for FE manipulation. Features include creating UI screens using drag-n-drop functionality, intuitive means of UI screen customization , and so on. At the second part of this lecture we will demonstrate the composer.

12 Introduction to INSIS Front End Components
INSIS Visual Component INSIS FE Architecture relies on 3 types of building blocks : IVC (INSIS Visual Component), VFU (Visual Functional Unit) and FES (Front End Sequence). Each UI Screen represents combination of those building blocks. This is an example of an IVC. In this case, this is IVC People, which enables entering and altering data about a given person. 1

13 Introduction to INSIS Front End Components
INSIS Front End Architecture This is example of an VFU, in this case VFU People Profile. As you can see, there are three IVCs, located in three different visual areas.

14 INSIS Front End Sequence (FES)
Es el componente de más alta jerarquía en la arquitectura: FES El FES encapsula los VFUs (visual functional units) para crear una pantalla que soportan una operación de negocios completa ( Registración de una póliza, FNOL, etc) Resembles Complex VFU with the only difference - predefined order of VFUs’ appearance. However, a VFU only represents single business function. To be able to create a whole business process, we have introduced the highest hierarchy architectural level component – Front End Sequence – FES. FES does not have specialized logic or functional units, it just capsulate VFU to create a full business process. In a way, FES resembles Complex VFU with the only difference that there is predefined order VFUs’ appearance

15 Introduction to INSIS Front End Components
INSIS Front End Architecture INSIS FE Architecture relies on 3 types of building blocks : IVC (INSIS Visual Component), VFU (Visual Functional Unit) and FES (Front End Sequence). Each UI Screen represents combination of those building blocks. Last example is FES. As FES represents a business process with sequential steps, with each step representing VFU, there is no way to display a “real” picture of a FES. If needed, mention the example with film strip. FES – film strip, VFU is a 1

16 INSIS V10 Front End Module
IVC IVC IVC IVC IVC IVC IVC Front-End Module represents the graphic interface of a business process or function. This module operates over a repository of reusable building blocks that strictly follow established Front-end architecture. IVC – represents the business operation. Basis reusable unit; gives interface to a particular business function / functions. VFU – represents the business function. VFUs do not have concrete implementations; they consist of one or more IVCs, synchronized in their runtime behavior to form a complete business function. VFUs are entirely built with no programming FES – Static/Dynamic. The Front-end Sequence represents a whole business process. FES consists of two or more VFUs combined according to the business process’ requirement. The difference between Static and Dynamic FES is in the mechanism of invoking the VFUs and their order of appearance. In the Static FES, the number of the VFUs and their order of appearance are predefined at composing time, while the Dynamic FES works in combination with the Workflow module to acquire the particular VFU to load upon next in response to user navigation event. The FE module is able to communicate with the rest of the modules via the Service bus by generating different types of events. Those events include Action, Selection or Value Change event. However the most significant event is the Navigation Event. It is targeted to the INSIS Workflow module and its purpose is to invoke workflow processing which determines which is the next visual step in a guided business process. Hence, this navigation events are solely used by Dynamic FES to determine which is the next VFU to load upon user navigation. VFU VFU VFU VFU VFU Static FES Dynamic FES Host Environment Web Center Portal PDA Web Browser Action Event Value Change Event Selection Event Navigation Event INSIS Service Bus 16 16

17 INSIS V10 Architecture INSIS Service Bus External System Adapter
External cfg engine ADAPTER Front End External workflow engine INSIS configurator V10 the main objective is to make interaction among INSIS standard software (modules) and customized software uniform with clear boundaries that allows easy and straightforward replacement of any of them. The core operational modules communicate with each other through internal service bus that isolates the modules from each other. The modules receive the necessary configuration data using the rule retrieval service bus that isolates the modules from INSIS configurator. INSIS Policy administration module (PAM) INSIS Claim settlement module INSIS Billing and collection module INSIS Reinsurance module INSIS Commission module INSIS Accounting module INSIS Personal management module INSIS Object administration module INSIS Service Bus External system External System Adapter INSIS Rule Bus INSIS Modules INSIS Workflow engine Billing & Collection Policy Administration Claim Settlement External Rule engine Reinsurance Commissions External system ADAPTER

18 INSIS Destacados Solvency II Compliance Configurador Stand-alone
Módulos Independientes Reusabilidad de componentes. Nueva Arquitectura Front End Low TCO (Total Cost of Ownership) Arquitectura SOA, standard y uniforme. Aplica a todo tipo de requerimientos de usuarios. Aplicación madura y rica en funcionalidades.

19 Thank you for your attention!
FADATA AD