Riding the Whirlwind

Strategic Interactive Marketing for the Insurance Industry

Key Points:

An Architecture helps to turn vision into reality. It provides a framework for identifying interfaces, and for creating a co-ordinated development plan

6.7 Develop an Overall Architecture

6.7.1 An Architecture provides a framework for creating a development plan that will realise the business mission and objectives. In the dynamic business and technological environment of the 90's, long term detailed plans are not appropriate. Never-the-less, it is important to avoid haphazard development as they can prove difficult to integrate.

6.7.2 Architectures, help to identify interfaces and help to place individual developments in context. They also help with the migration from legacy systems. An Architecture consists of models and frameworks and is described using diagrams and narrative.

6.7.3 Models are an abstraction of reality but at the same time they help to turn vision into reality. They are useful in identifying the essence of any business. These include its essential business processes, functions, data, and rules. In diagrammatic form they are useful for presenting overviews.

An Architecture consists of diagrammatic models and descriptive text. It needs to be accessible to all those involved.

- Shared Repository -

6.7.4 Computerised repositories are useful for holding and disseminating the details amongst all developers and users. They can contain rules for checking the consistency of the information; and can export computer code and declaratives to aid systems development. More recently repositories are being used in real-time for running the business. They may well provide product definitions and integrity checks, business rules and process event triggers, and marketing promotional triggers.

6.7.5 The following is a simple high level generic Architecture. It shows the major components for delivering interactive services. The new front-end delivery systems need building around a common core with varying presentation components. A middleware layer interfaces these new systems to back-end legacy systems and to product and customer databases.

A very high level generic model is provided as an illustration. It shows front-end delivery systems, back-end customer databases & legacy systems, and a middle "glue" layer.

A simple high level generic architecture for Strategic Interactive Marketing.

However, "off the shelf" frameworks are available for the insurance industry. Using supporting tools the framework is tailored to the company's own situation.

- "Off the shelf" Architectures -

6.7.7 "Off the shelf" architectures provide a supporting but generic business and systems environment. An Insurance architecture could provide most of the processes, functions, data models and definitions, rules and system code for one or more insurance products or lines. Additional facilities within the overall framework may include systems development methodologies, techniques and tools, along with training and project management. These provide support for tailoring the framework to the particular needs of the company.

6.7.8 Examples of architectures and frameworks are:

• CORBA-Insurance.
• IBM's Insurance Application Architecture (IAA) and Direct Insurance Process Models.
• Andersen Consulting's Eagle Project.

They are described in more detail in section 7.2.

Returning to the simple generic architecture presented on the previous page, the role of the key components are described:

A product metabase is a key component. It is a definitive description of a company's products and services including the processing rules. It is used by computer systems, staff and customers.

• descriptions of the core products and permissible options.
• business and compliance rules including standard endorsements.
• actuarial risk rates and product premium calculations.
• marketing criteria for promoting the products to customers, etc..

Product Metabases (Repositories) are used by computer systems, staff and customers. 

Given that many products are variations on a theme, then Object Technology (OT) seems ideal for implementing the Product Metabase. By using Temporal OT Databases (see Policy Database on the next page) the various changes to product definitions can be recorded over time. Staff and computer systems then see the options, rules, etc. that were previously applicable to a product.

The policy database based on Object Technology provides a robust means of capturing all the unique attributes of each contract.

- Each Policy Equals an Individual Contract -

6.7.10 Policy Database: Each policy represents an individual contract entered into at a specific point in time and governed by legislation and policy wording, as well as by specific endorsements, as defined at that time. Once a policy is sold then it is the policy data that represents the definitive statement of the customer's contract, not the product database. Using Object Technology the information from the Product Metabase is modified and encapsulated within the policy when it is created.

• Over time, policies change but with traditional databases the previous data is usually lost. A specific form of database, known as a Temporal Database, is designed to cater for this extra time dimension. It allows the preservation of the original data. This type of database should be particularly applicable to recording product information. See section 7.7.5 for more information on Temporal Databases.

Business Objects become the principal components rather than product systems.

• promotions, sales, service, claims, re-insurance, valuation, etc.
• Insurers already have a substantial investment in existing systems that handle the core administrative functions. There is a need to continue to exploit these investments yet at the same time draw them together to serve the customer in an integrated way.

Processes need to strike a balance between automation, flexible response, and ROI. Processes and staff capabilities need to be in harmony.

• Processes need to be defined from a customer perspective. Customers may be external or internal.
• Process modelling tools help both with the analytical calculations and in assisting organisational teamwork.

Processes Modelling tools help test the theory. An example using Process Charter.

Customer databases will hold "soft" & "hard" data.

• Hard data includes customer name, address, age, gender, medical details, policies held, premiums collected, claims, etc.

- Soft Data Like Aspirations -

• Soft data includes the purpose of the investment or insurance, aspirations, desires, likes and dislikes, preferences, etc.
• Much soft data will be textual in nature and may require analysis by natural language systems.

Communications databases record all customer interactions. Marketing rules trigger unique and targeted messages to customers when specific events occur.

A major UK bank is developing a central customer communications database.

• messages: date, time, promotional campaign, information sent, responses received.
• interactions: date, time, staff or agent involved, location, purpose, agreements or promises made, follow-up actions, assignees, target date, etc..
• rules: events to monitor and actions to take.

Marketing rules monitor for specific events and take action to build relationships.

Middleware has two key roles: it "glues" together legacy systems to the new distribution mediums; and it supports distributed component- based systems for greater flexibility and reliability.

• Object Technology (OT) is providing a reliable and flexible component based approach to new systems. OT particularly suits Web based systems.
• legacy systems and data can have object oriented (OO) "wrappers" that allows them to co-exist with the new OT systems.

- An ORB Links All the Components -

• an Object Request Broker (ORB) links all the application objects. It takes requests from demand objects and sends them to other service objects. For example:
  • an object running on a clerks PC sends a request to the Policy database for details of the last 6 months payment history.
• The ORB allows distribution of the various objects throughout a network, providing flexibility to meet changing demands and giving resilience through separating and duplicating resources. Using a wide-area network and an ORB, different companies in the value chain can interoperate in real-time and thus provide a seamless service to customers.

Distributed objects allow different companies in the value chain to interoperate in a way that is transparent to the customer.

- Linking to Suppliers -

• a customer is completing a home insurance claim form on a PC. The form is processed by a claims object obtained from his insurer. Because the claim is over £1,000 the object knows that a loss adjuster needs to be involved. It then requests another object to be sent to the customer's PC. This object displays in another part of the screen a diary and then connects itself to the system at the chosen loss adjuster company. Through a dialogue a visit is arranged. If the customer had an Internet telephone then instead of a diary on the screen it could substitute a voice link, or if he had a camera, then a video link. In fact, why not give him a choice!

An Object Request Broker (ORB) links the components together.

See section 7.7 for more information on OT.

A telecommunications infrastructure must provide security, reliability, responsiveness, support for a variety of end-user devices and different media formats, and links to a variety of locations, possibly via 3rd party networks.

• security: electronic firewalls to authenticate users and act as a defence from hackers etc., secure transmission of sensitive data and monetary transactions,
• reliability: monitoring and alarm systems, backup telecommunication lines, servers and power plant, recovery systems, technical assistance.
• responsiveness: sufficient bandwidth and server capacity.
• multi-media formats: text, forms, graphics (2D & 3D), audio, video, interactive commands, applications.
• end user devices: post, fax, pagers, PDAs, kiosks, telephones, I-TV, Web-TV, PCs with e-mail, WWW, etc..
• locations: customer's homes, workplaces, retail outlets, public areas, own branches, own FAs, IFAs, agents, partners. To communicate with some of these may require interoperability with other networks.