IBM Industry Models for Insurance

Insurance Process and Service Models -

The Insurance Application Architecture (IAA)
General Information Manual
Contents
Executive Summary 3

The Foundation Models 10

The Process Models 13

The Service Models 16

The Product Models 21

  
   

  
 

2
Executive Summary
Insurance for On Demand Business
As the insurance industry continues to deal with a fast pace of change, insurers face stark new challenges. In today’s
marketplace, survival favors the agile; speed can be a critical differentiator; and the organizational status quo is often a
liability. Successful insurers are beginning to adapt to continuous, unpredictable and accelerating change. Many insurers
still struggle to manage a complex web of legacy silos, disparate systems, redundant functionality, excess capacity and
inconsistent service levels. Enthusiasm for IT spending and decentralization has exacerbated the problem, saddling firms
with overlapping – and often unproven – technologies. For many insurers, the results are all too familiar: disjointed operations,
redundant capabilities, inefficient cost structures and duplication of work across product, geography and business lines.

Most insurers still operate largely within a vertical business structure, whereby distribution occurs mainly by product silo
and operations are biased toward internally manufactured or developed products. Achieving material cost reductions in
this structure is difficult, and consumers generally see very little or no differentiation among insurers. Given their financial
challenges, insurers can no longer afford to have capabilities duplicated across product silos, with each product operating its
own processes, systems and specific channels. This duplication causes significantly greater complexity in insurer operations,
impacts costs and speed to market, and often increases operational risk.

In large enterprises, initiatives that attempt to optimize these processes in isolation, without first merging them, fail to fully
address their complexity and overlapping functions. Process optimization generally focuses on vertical integration and
often within single products or business units. To achieve a step change in performance, today’s highly complex insurance
operating models must be simplified. Moving from process transformation to enterprise transformation is the key that will
unlock significant benefits for insurers.

Technology is a fundamental change enabler, but IT decisions need to remain firmly rooted in the business needs of the
organization. To operate on demand, your organization will need to transform the way it operates by re-evaluating its business
processes as well as its technology infrastructure.

Business Transformation
Most insurance firms know they need to change, but question if the analytical tools available to them are up to the task.
Traditional, linear approaches, such as business process re-engineering, are useful for optimizing workflows and often yield
improved sub-processes, but they do little to highlight similar activities that are scattered across separate processes within
the enterprise. Successful insurers require a new way to view their business operations, one that will help them adapt and
thrive in an environment of continuous change. An insurance specific Component Business Model (CBM) helps by simplifying
the way insurers look at their operations. With CBM, executives can extract themselves from the process “rut” and get at the
real sources of value that drive their companies. They can identify the unique, standalone building blocks that comprise the
insurer as a whole. Viewing business activities as autonomously managed components that can be optimized individually
for greater value to the whole business enables decision makers to cut through historical boundaries that may have built up
along organizational, product, channel, customer, geographical and informational lines.

Application Transformation
The use of component-based business modeling, underpinned by industry models, such as the IBM Insurance Application
Architecture (IAA), enables insurers to define their target business architecture and transformation goals. This drives
application transformation and often the design and implementation of new application solutions. The IAA models, with a rich
set of industry application component definitions, are a key accelerator for the logical design and architecture of building new
functionality.

3
A common enterprise-wide description of the business concepts that define the business data entities controlled by the
application components is the crucial factor in a successful application solution. Without this common language, any attempt
to support an already challenging consistent and flexible architecture is made more difficult. The IAA models provide a
complete and unambiguous description of the business concepts, business activities, and business rules that must be
supported within the insurer.

The Insurance Application Architecture (IAA)

The Insurance Application Architecture (IAA) is a comprehensive set of insurance specific models that represents best
practices in insurance and is a natural extension to the Component Business Model. The IAA models provide the insurance
specific business content to accelerate the projects that result from moving to an On Demand Business and pick up the
definition of the components that take you there.

IAA describes the business of the insurer and is an efficient communication bridge between business and technology
communities. It is designed to be readily accessible to business users and by focusing on industry issues such as Sales
and Customer Services, Marketing and Analytics, Customer Relationship Management, Policy Administration, Product
Development, Insurance Claims and Risk and Compliance.

IAA comprises:
• Foundation Models: insurance terms and definitions for communication and standardization
• Information Models: insurance data content for an enterprise-wide view of information and data rationalization
• Process Models: insurance business processes content for areas such as business process modeling, simulation and
execution
• Service Models: business services content for component based development and services oriented architectures
• Product Models: a method for accelerating insurance product design
These models are described graphically on page 8.

IAA in practice typically supports over 80% of an insurer’s business requirements and is designed to be easily customized
and extended to cover any specific requirements. IAA assists an insurer in implementing a flexible, reusable, extensible and
easily customizable architecture, to enable the insurer to:
• Be more adaptive and to respond quickly to changing customer needs
• Focus on achieving competitive differentiation
• Identify and leverage best practice behaviors across the organization

The IAA models identify, describe and structure all of the business functions, data, and processes that you would expect to
find in any insurer in a way that accelerates IT projects. These models ensure that business requirements for major initiatives
are captured and expressed in a manner that can be understood and used by the IT organization and that are reflected in all
subsequent levels of the application development process.

By providing a set of pre-defined models, IAA enables the scoping, specification, design and deployment of information
solutions, which are:
• Faster, through use of generic model specifications and designs
• Cost effective, through reduced analysis costs and increased re-use of existing assets
• Better, through increased quality and consistency
• Lower risk, by building on good practice and by ensuring a strategic perspective

4
 IAA Value Propositions

Risk & Reporting

IAA provides processes and services for the enterprise risk management including the analysis of possible loss to the
insurance company, which allows a more prospective view of an insurer’s risk profile and capital needs. This is with highly
tailored analytic processes that recognizes each insurer’s unique structure, and with processes that recognizes the benefits
and risks of a diversified base of products, investments and geographic spread of business. IAA also covers the regulatory
financial reporting requirements for assets, liabilities, actuarial valuation, Profit & Loss and Solvency, which allows the
analysis of the financial institution’s arrangements and activities according to legal statutes, the directives of government and
regulatory institutions.

Solvency II
Insurance organizations should adopt a proactive approach to SII because the workload involved in ensuring SII compliance is significant.
There has never been a greater urgency for insurance organizations to act and prepare for SII, especially given the increasing scarcity of
actuarial, project and IT resources needed for the implementation of SII projects.

IBM Process and Service models have been enhanced to support Solvency II to QIS5 level and ORSA (Own Risk and Solvency Analysis),
with over 75 business processes and over 300 business activities.

Communication & Standardization

IAA provides extensible structures and rich business content for all stages of systems development or integration projects. It
can be easily customized to cover every single insurer’s needs while the pre-defined content provides an important acceler-
ating factor. IAA provides a strong base for defining corporate data and development standards. Its use enforces consistency
in data or services across projects and lines of business. IAA also facilitates the understanding between business and IT by
transforming the business content into IT artifacts while maintaining traceability of business requirements to IT systems.

Business Process Analysis

IAA defines best practice business processes for the insurance industry based on a large pool of requirements collected
and validated over many projects. The processes link to other business constructs, in particular to the business component
services that describe how IT can support the requirements expressed in those processes. With IAA an insurer can compare
its own business processes to best practice business processes, and can understand how to better support them from an IT
perspective.

Application Rationalization, Component Based Development and Services Oriented Architectures

It is common for an insurer to have a good deal of duplication in services (functionality) across different IT applications. The
negative impact on maintenance and extensibility is very clear. When business functionality needs to evolve, multiple systems
will be impacted, which results in significant duplication of effort. The ideal situation is to have a componentized solution
where all functionality is clearly identified and allocated to only one, component. To evolve from a situation with hundreds
of applications that are duplicating functionality to a component-based solution is by no means easy and requires a well
structured series of steps. IAA addresses this issue at the diagnostic and design levels. This supports the primary business
driver for component-based development which is to increase the flexibility of the systems and to decrease the disparity
between the required business functionality and what the existing systems provide.

5
An SOA enables more rapid and pragmatic response to business transformation, while enabling IT to rationalize, simplify and
enable new capabilities within the application portfolio while reducing complexity and cost. Services oriented architectures
are to application transformation what the Component Business Model (CBM) is to business transformation. For the insurance
industry, the transition between these levels is supported by the traceability features of the IBM Insurance Application
Architecture. These features articulate the services required to support a particular business component, thus providing a
seamless path from business transformation to application transformation.

Integration
The goal of integration is to make communication possible between systems that have not been designed to communicate.
SOA is a technology that can help in integration. SOA as a basis for integration and as a means of structuring large-scale
software architectures is rapidly becoming the backbone of the modern insurer. A key factor underpinning a successful
SOA is a common enterprise-wide description of the business concepts and processes. Models are required to provide the
specification for the structure and content of the services needed for integration. SOA without business content is just an
empty shell. IAA provides this business structure.

Product Flexibility
Survival in a highly competitive environment can be achieved through price competition (cost control) or by company
differentiation. Customer service supported by a customer-centric view is one differentiating factor; a second factor is
product differentiation. To keep pace with the competition, it is essential to innovate and to develop and release new financial
products quickly. IAA offers a set of specialized analysis techniques dedicated to the structuring of insurance products that
enable a more rapid release of products to the market. IAA contains a representative set of insurance products structured in
accordance with these analysis techniques. These product definitions can be used as templates to accelerate the modeling
of insurance products. IAA also includes a design framework for building flexible product engines and administration systems
to support both new and existing products.

Data Rationalization
The importance of accurate and readily available data in an insurance company can never be emphasized enough.
Unfortunately, the same fundamental information is often captured in various places and different formats. This has negative
and quantifiable implications: a risk of poor data quality and an increased maintenance burden with increasing difficulty in
updating the systems to satisfy new business requirements. IAA, with its thousands of industry definitions and its formatting
of those definitions into a logical structure, can be used as an overall reference for data. The business drivers for data
rationalization are to reduce multiple data entries (saving costs) and to understand a broader view of key concepts, such as
a single view of the customer across the whole company. From a management point of view, this effort can be phased and
scoped by subject area; for example, a first step could be to understand how to clearly identify all the customer data within
the insurer.

Data Warehousing
The effort of implementing a data management infrastructure that allows efficient data extraction, transformation and
aggregation, and distributes accurate, complete and timely information to business users and decision makers is a major
challenge. The IAA data warehouse solution lets insurers exploit the potential of detailed information previously locked in
legacy systems and hence inaccessible to the business user. IAA features a consistent suite of business requirements
and enterprise analysis and design models for a data warehouse plus pre-defined data mart models, enabling insurers to
effectively develop solutions to:
• Improve business profitability analysis, including underwriting, claims performance, persistency, cross-selling
penetration, and fraud detection
• Build Management Information Systems (MIS) to track and analyze key performance indicators
• Develop risk management systems to support extensive risk modeling and data analysis, including asset and liability
management.
6
Customer Centricity
Since the cost of acquiring a new customer is much higher than the cost of retaining an existing customer, creating and
maintaining high customer satisfaction is critical to insurers’ profitability and competitiveness. This can only be achieved by
having a consolidated customer view for an in-depth understanding of those customers’ needs. In most companies, customer
information is scattered across disconnected systems, making it impossible to obtain a total picture of a customer. While all
the IAA models have been built around the idea of a customer-centric view of the business, the IAA warehouse models (the
formational side of IAA) best address that entire customer information picture with a number of analytical perspectives that
focus on customer segmentation, marketing, campaigns, and more.

Distribution and Partnerships

Developing new distribution channels is core to capturing a bigger market share. Providing a wider set of offerings
customized to customers’ needs through establishing alliances and partnerships is also essential. Open systems are the
critical success factor to reaching these goals and can be achieved through clearly defined system interfaces or integration
through messaging as supported by IAA.

Mergers & Acquisitions

The competitive pressures that continue to fuel mergers designed to achieve cost reduction through economies of scale
result in financial services groups that are larger and more dis-integrated than ever before. The technical consequence is the
need to integrate systems that are invariably built on different platforms in different locations and to provide a single internet
image to consumers. IAA, particularly through its IAA-XML messages, is a perfect fit to provide one single, common, and
integrated corporate reference point for those businesses, irrespective of current size and growth strategies.

Deploying the IAA Models

The IAA business models are tool independent, but are optimized for use in conjunction with IBM software products. IAA
used with IBM middleware helps move you quickly through requirements gathering, analysis and design, and deployment for
accelerated transformation to an effective On Demand Business.

Using IBM Information Management Software

The tight integration between the IBM Industry Data Models, Infosphere Data Architect and IBM InfoSphere Information
Server allows organizations to exploit industry-specific business and technical metadata to accelerate data integration
projects such as master data management initiatives or data warehouse development. For example, the Industry Data
Models and Infosphere Data Architect physical schemas can be shared across the entire IBM InfoSphere Information Server
platform, including InfoSpherem Business Glossary, InfoSphere Information Analyzer, InfoSphere FastTrack, InfoSphere
DataStage® and InfoSphere QualityStage®. In addition, business or glossary definitions from the Industry Data Models and
Infosphere Data Architect can be used to populate InfoSphere Business Glossary to share common definitions across the
enterprise.

7
Using DB2 Software
IBM DB2 Information Management Software products help banks leverage their existing IT assets so they can maximize the
value of their information with advanced Business Intelligence (BI) features for building and working with data warehouses
and data marts. IBM’s BI solutions enable companies to comb through vast quantities of data quickly, thoroughly and with
sharp analytical precision. BI capabilities are built into the DB2 engine, and BI applications have DB2 at their core. The IAA
business models provide banking-focused data content, which can be deployed on IBM DB2 Information Management
Software to address areas such as business intelligence. While the Industry Models help clients define and describe a unified
view of their analytical data that persists in a data warehouse, in order for the analytical solution to work, IBM Information
Server enables organizations to understand their existing data sources; to cleanse, correct and standardize information; and
to load the information into the data warehouse.

Using WebSphere Software

IBM WebSphere delivers application infrastructure and integration software that helps companies address key priorities in an
on demand world. IBM WebSphere software delivers the ability to integrate disparate applications and systems in a flexible
manner that speeds time to value and helps companies maximize the utilization of existing resources. The IAA models
provide standardized business services and models which can be deployed through IBM Rational software to address areas
such as model driven development and common services.

Using Rational Software

Rational software helps organizations create business value by improving their software development capability. Rational
software allows you to:
• Adopt iterative development practices that reduce project risk.
• Focus on architecture to develop more resilient systems.
• Effectively manage change and protect critical strategic assets.

The IAA models provide content in Rational software to accelerate and reduce the risk of model-driven development projects.

How this document is structured

The Foundation Models assist with standardization of terms.
The Process Models assist with process simplification and business process re-engineering.
The Service Models assist in the creation of a services oriented architecture environment.
The Product Models provide a method for accelerating insurance product design

8
 �������������������������������
������������������������

����������������������������������������
��������������������� �������������� �������������� �����������������
�����

���������������������� ��������������������������������������� ����������������������

�������������
����������������� ������������������� �������������������� ����������������
��������� ������������ ��������� �����

���������������� ���������������������� �����������������������

9
����������������������
�������� ������������ �����������
���������� ������������ ���������
������������ ��������������

�
� � � � � � � � � � � �
� � � � � � � � � � �

�������������� �����������
������� ����������
The Foundation Models
Communication and Standardization
Building systems for the insurance industry requires a wide range of skills: from understanding the fundamentals of the
business, to the fine-tuning of databases and component designs, many different people have to be involved. An important
success factor is good communication among these different types of resources.

Getting down to a common reference is a challenging goal. The IAA approach to this problem is to define models at different
levels, some of them purely business-oriented and some of them very technical from an IT point of view, but all enforcing a
semantic consistency and traceability between them

The IAA Foundation Models provide us with the tools to identify the important functions and business concepts that make up
a particular business issue. The models are deliberately designed to encourage the business and technical professional to
“step back” from the constrained detail of the current environment and to focus on describing the true and full scope of the
business issue being discussed. Providing a language that is common to all stakeholders and that describes key aspects of
the issue, enables fast and complete scoping of a business issue.

Business Terms
IAA provides a comprehensive list of insurance focused business terms to define its data. This makes communication with
the business easier, leading to better business buy-in of proposed technical solutions.

Clearly defined business terms improve the standardization within an insurer. IAA provides a catalogue of business terms
grouped in domains and mapped to the Business Model. Because they are grouped by logical business domain, the
business terms provide an easy entry point to the models. The business terms include aliases so that business people can
use the terms they are most comfortable with.

With data requirements defined, the next step is to create a conceptual view of the data within the insurer to satisfy those
requirements, free of any technological considerations.

A view of the IAA Business Terms

10
The IAA Business Model
A fundamental principle of IAA is the unambiguous definition of business concepts to ensure good communication across
different IT projects and between the business users and IT. This leads to systems that are adeptly architected and resilient
to changes in the business. Such systems have a longer life and lower maintenance costs.

The IAA Business Model provides this conceptual view of the enterprise data. Through its evolution since the early 1990’s, the
IAA Business Model has been the model of choice in a large number of development projects and has been put to the test
and enriched by many insurance companies worldwide. The strength of the IAA Business Model lies in its generic design
structures that guarantee its applicability in diverse situations.

The purpose of the Business Model is the clear understanding and communication of business concepts as a means to
accelerate project scoping. For example: what could be meant by “Customer” in a particular business context?

“Customer” concepts could include:

• Identifying a specific person or organization
• Knowing all customer addresses
• Knowing all products the customer has bought
• Knowing which market segments the customer belongs to
• Knowing about the customers recent transaction history
• Knowing about the customers complaint history

The meaning of “Customer” can imply some or all of these concepts depending on the business context. For example, in a
customer relationship management initiative “Customer” may be quite different to what “Customer” is to current call center
operations. The IAA Business Model can be used to define precisely what “Customer” means in either situation and to
clarify and reconcile these perspectives.

The IAA Business Model Structure

The IAA Business Model is available under two forms: UML as supported by CASE tools like Rational Rose and an Entity-
Relationship form as supported by CASE tools like ERwin and InfoSphere Data Architect. These two representations are
equivalent from a data point of view; the UML version adds the representation of the services to the data.
The Business Data Model is a conceptual business model representing the atomic information of the data warehouse, without
any design content. It is the Entity-Relationship version of the IAA Business Model.

The Business Object Model is structured as:

• A set of use cases, which describe service candidates
• A model of business concepts, which are used by these use cases

Business Activity Model

The functional requirements of an insurance company are expressed as business activities: elementary units of work that are
performed as part of the business operations. The IAA business activities are organized into business activity categories,
according to a functional view. It is possible to organize the activities differently, e.g., based on the line of business, or
according to organizational principles such as in the IBM Component Business Modeling approach.
The Activity Model allows rapid and complete scoping and comparison of the functional aspects of business issues and
should be used at the start of any project. By identifying which activities are involved in a particular topic or project, you can
quickly create a complete list of the business areas to be considered. If other related topics or projects are scoped in the
same way, they can be compared and contrasted using a common language to avoid duplication of effort in overlapping
initiatives.

11
Specific uses include:

• Understanding the responsibilities of business units and the dependencies among them
• Integrating similar functions across business areas, supporting reusability of solutions
• Aligning business processes and organizational structure to strategy and prioritizing business requirements in
functional terms
• Defining project scope clearly and avoiding duplication of effort with other projects
• Laying the foundation for the design of business workflows and application services/components

Benefits of the Activity Model

• Provides enterprise-wide definitions of business function, independent of organizational structure or line of business
• Forms part of a common language between business and IT
• Provides a rapid and accurate scoping tool for new initiatives
• Provides a predefined, readily customizable description of insurance functions

The next figure shows activity categories for Property & Casualty insurance.

12
The Process Models
Business Process Modeling
There are many business reasons for which an insurance company might want to model its processes:
• To improve the quality of service to its customers in order to retain them and attract new ones
• To understand which parts of its business are not core differentiators and could be outsourced
• To improve the integration with third parties, in particular distribution channels but also providers
• To meet regulatory compliance requirements in terms of process documentation
• To reduce operating costs and to increase the efficiency of the business

In any organization of significant size many business processes that have essentially the same purpose (and therefore should
be essentially the same process) are carried out in very different ways in various organization units of the enterprise. The
different process flows come about through a number of circumstances such as:
• Mergers and acquisitions
• Varying levels of automation across the enterprise
• Varying organizational structures and responsibilities across the enterprise
• New products or channels

This results in significant cost to the insurer, including:

• Inconsistent customer experience across channels
• Errors in serving the customer base (e.g. differing process for different products)
• Increased information technology costs in supporting the disparate processes
• Increased management costs due to increased complexity in audit and regulatory governance
• Increased staff training costs and reduced staffing flexibility
• Difficulty in introducing best practice in an enterprise-wide fashion
• Inability to guarantee compliance with policies and regulations

Insurers have found that by streamlining processes across organizational units, products, customers and even geographies,
they have achieved very real savings and improved their cost to income ratio measurably.

The IAA Process Models have been developed to address this, as well as to create logical models that capture business
requirements for development initiatives and help manage change. They have been created to serve as a business process
architecture, which is a vital tool for:
• Enabling cross enterprise business process simplification and rationalization
• Providing a fast-path to an enterprise-wide business process architecture
• Documenting complete business requirements
• Managing process change

Business process architectures provide the enterprise with a clear understanding of its business in the context of its many
processes. Clear, well-structured business process architectures have always been vital for ensuring efficiency and
effectiveness of business operations. The introduction of new technologies such as business process automation (workflow
management tools), centralized rules engines and active data warehouses has made business process architectures even
more important than in the past. Initiatives such as straight-through-processing (STP), achieving a zero latency enterprise,
and business activity monitoring, are greatly hampered improved with the use of effective enterprise-wide business process
architectures.

The IAA Process Models play a critical role in the definition of a services based architecture. Analyzing the processes that
support the operations of a financial institution identifies the service candidates that will best support those processes.

13
Process analysis provides essential information about the context of those services, capturing requirements governing the
applications that call services within the architecture, and the human roles within the organization that interact with those
applications.

With the IAA Process Models, an insurer can both compare its own business processes to best practice business processes,
and can also understand how to better support them from an IT perspective.

The IAA Analysis Process Model

The IAA Analysis Process Model (APM) is a set of logical models of that structure of insurance processes, where the
processes are defined to be independent of product, channel, organization structure or technology. By maintaining this
independence, the APM displays the fundamental “core” of business activities that are essential for the continued success
of the insurer. The APM is represented by flow diagrams of activity networks that graphically describe what is required to be
achieved by each process.

Like all the other models, the APM has been built with customization in mind. This means that it’s structure makes it easy to
reflect the specificities of every insurer when defining the to be processes across the enterprise.

For process simplification projects (achieving common processes across products and/or channels, harmonization of
processes from merged organizations) the steps outlined above are preceded by identifying strategies whereby the differing
process flows are selected according to how well they can be brought into synchronization. Understanding the strategies to
be achieved by an initiative is an essential pre-requisite to scoping processes and prioritizing process flow diagrams.

An actor represents a stake holder in a process. IAA defines a set of actors, such as customer, medical expert or agent.
Actors are specified in swim-lanes at each level of detail. Swim-lanes split the process depending on who is responsible
for handling each process part. The high-level business processes are decomposed into sub-processes and further
decomposed down to an activity level. This decomposition is expressed as a flow of activities and sub-processes in process
flow diagrams.

The decomposition can be nested in several levels and only stops at the activity level. More than 1000 re-usable activities are
combined into hundreds of business processes in various process flows.

How the APM is used

Optimizing and re-engineering processes

The APM provides a generic core of best practice insurance process definitions and diagrams. Thus it offers a fast start for
process re-engineering projects by providing an existing structure upon which to map the “as-is” environment, and create the
“to-be” solution. The APM eliminates the need to start with a blank sheet of paper.

Rationalizing and simplifying product (and other) processes

Because the APM is designed to be independent of product, channel, organization structure, etc.. it is an ideal “target
architecture” for process simplification and rationalization projects.

Analyzing application impacts and gaps

Being generic, the APM is easily mapped to the functionality of application packages. It is a straightforward exercise
to compare the functionality of the package to the insurers existing or future process requirements documented by the
customized APM, (in order to identify how well an application supports those requirements). It is also possible to compare
the functionality of one application system to another to identify reusable solution alternatives for those process requirements.

14
Supporting a Services Oriented Architecture
Analysis of the processes that support the operations of an insurer identifies the service candidates that will best support
those processes. Process analysis provides essential information about the context of those services, capturing requirements
governing the applications that call services within the architecture, and the human roles within the organization that interact
with those applications.

APM Process Catalog

Channel Management Intermediary Management
Claims Management Communication Management
CRM Customer Acquisition
Enterprise Resource Management Financial Reporting and Regulatory Compliance
Human Resources Management Enterprise Risk Management
Financial Transactions Investment Management
Reinsurance Management Marketing and Promotion Management
Product Portfolio Management Provider Management
Reinsurance Management Underwriting

Benefits of the APM

• Jump start analysis with content rich processes

• Provide an enterprise wide view of processes by promoting a common process language and eliminating redundancy
in process variations
• Provide a path to automation through linkages to IT services

In addition to the analysis level business processes, IAA provides a path to create design level processes that can be
deployed in run-time as process choreography.

An example of the Record Claim process in WBM

15
The Service Models
Services Oriented Architectures, Integration and Component Based Development
Integration issues are a major concern for insurers. Existing infrastructure must be retained, yet in order to meet the demands
of today’s business issues, a consistent architecture is required that maximizes reuse and supports the development of new
initiatives.

Services oriented architecture (SOA), as a basis for integration and as a means of structuring large-scale software
architectures, are rapidly becoming the backbone of the modern insurer. SOA can increase the speed of business changes,
improve business efficiency and performance, and protect the privacy and security of critical information assets. It enables
IT to align more tightly with business strategies in a cost effective manner and in a secure and managed integration
environment.

A key factor underpinning a successful SOA is a common enterprise-wide description of the business concepts and
processes that are of interest to an insurer. Without this common language any attempt to support a consistent and flexible
architecture may fail.

The IAA Service Models provide this common language. The models support a complete and unambiguous description of
the business services required to support the insurer. The IAA Service Models enable the efficient and accurate gathering of
requirement and guarantees the consistency of definitions with a single integration effort or across multiple projects.

The IAA Service Models are fully consistent with the IAA Process Models, describing the underlying services that support the
automation of these processes. Using the IAA Service Models, business concepts can be traced from analysis level through
design level refinements to actual component and message definitions that provide a quick start for the specification of a
common services bus within the organization.

The business processes, activities, and use cases defined in IAA represent the functional requirements of the insurance
company’s systems. The next step in the IAA approach is to take these requirements and describe how they can be covered
by a set of services.

The Enterprise Component Blueprint

Portfolio assessment consists in describing the existing applications across the whole enterprise according to a framework of
services. Only by going through such an activity can you effectively assess the amount of duplication of functionality across
several legacy systems. Here are a few examples of very common duplication: management of customer-related information,
execution of business rules, handling of funds, rating, policy management across lines of business, and so on.

To be able to perform such an activity, you need an enterprise-wide list of service definitions. This is typically quite difficult to
create on your own but you can use an existing industry reference instead of having to create this yourself. Such an industry
reference is the IAA Enterprise Component Blueprint (ECB), which defines a normalized set of functional services to support
the insurance business.

The ECB contains over 250 unique service definitions, such as Request risk assessment. In practice, the functionality
described by this service will be implemented in multiple legacy systems, often in conflicting ways. This is a strong inhibitor
to business agility as evolving this capability means that you need to update several systems, which creates additional work
and increases the risk of errors and inconsistencies.

Performing such a portfolio assessment is the only way to really understand how to reconcile the business and I.T. priorities.
The result is a duplication map that describes all the functional overlaps between the existing legacy applications.
16
The ECB gives a business view of how the financial services business could be supported by a fully componentized software
solution. It describes a set of business components and defines them by the services they provide.

����������
��������������������� ������������ ������������
��������

������������ ����������
��� ����� ����������������������������
���� ����������

�������������
������������� ����� ��������������� �������� ������������
�������������

�������� ���������
������ ��������� ����������������� ����
����������
�����
���������

The Enterprise Component Blueprint

The Interface Design Model (IDM)

The Interface Design Model (IDM) (the design level of the BOM and ECB) allows the insurer to specify a services oriented
architecture that meets the requirements defined in the models described above. This task is normally performed by a
technical team within the insurer that make design level decisions based on concerns such as the technology environment.

The IDM was developed to:

• Assist modelers in designing reusable services that meet the insurers stated requirements,
• Define business components that support these services
• Define standard interface definitions that describe the communication between software systems in the insurer

Business Service Groupings

The IDM is structured as a component model, describing units of software that satisfy specific business requirements. The
actual requirements that are supported by a component are described as interfaces, which group related services. The
internals of a component within IDM are derived from the class models of the BOM, providing the detailed class definitions
and relationships, which describe how the component operates.

17
The components of the IDM designed to meet specific business needs are:
Enterprise Risk Account and Fund
Activity Condition Place Claim
Common Communication
Contract and Specification Dispute Resolution
Financial Transaction Generic Agreement
Finance Service Agreement Intermediary
Marketing Activity Party
Physical Object Provider
Rating Reinsurance
Underwriting Rule
Tax

Business Service Interactions

The IDM describes the collaboration between services to meet a business goal. For example the service retrieve customer
information may call other finer-grained services to perform the required task. e.g. get names and contact points.

Collaborations between services are essential to a successful SOA as they prevent the definition of monolithic services that
would be less reusable across multiple projects.

Uses of the IDM

• Assists in the design for a services oriented architecture
• Provides component definitions for software development
• Provides messages definitions for integration development

Benefits of the IDM

• Allows you to construct services within a formalized model
• Provides traceability back to business requirements
• Structured to maximize reuse of business services
• Enables consistency of definitions
• Provides a ready built model so you can focus on business issues rather than building a model from scratch

Defining IDM services based on Business Model use cases

18
Deploying the IAA Service Models
The IDM remains a technology independent view of an SOA and requires transformation into the specifics of a given
technology, for example Web Services or XML messaging. However, some of this translation can be done automatically
through he use of the IAA Service Model Generators.

Generators could be developed for other technologies as well since the IDM content is defined to be completely independent
from any technology and the technology-specific choices are only made during the generation process.

Why Components?
Monolithic applications or package solutions deliver in general a set of functions to meet a particular purpose that is based
on a generic set of requirements. During the implementation of these packaged solutions, companies tailor the functionality
by adding extra functions as required and by deleting or modifying functions that do not match the business requirements.
Inherent to this approach is the fact that most packages usually set rigid limits on the scope of additions and modifications.

A component-based approach does not generally provide a ready-to-use set of business functions that packages do. Instead, it
provides major functional components from which a fully customized solution can be built or with which packaged solutions can
be evaluated for fit within an organizations’ system architecture. With a consistent set of inter-operable components, it is possible
to provide a solution that is better tailored to the needs of the business without having to build from scratch.

Recently developed packaged applications define more and more their interfaces in a component style, which makes them
much more suited to component-based and service-based architectures.

Components to implement the services

There are two implementation strategies for the SOA enterprise-wide services: Integration (to the legacy systems or package
solutions) or components. In almost every case, the solution is a mixture of both approaches.

When opting for implementing components to support the implementation of services, you need to define an enterprise
component architecture: how do the components relate to each other, are there dependencies, how do they collaborate, can
they be deployed independently?

The Interface Design Model proposes an enterprise-wide set of components for the insurance business. These components
are defined to support an enterprise wide set of SOA services. These two layers are kept completely synchronized and
traceability is enforced. In Model-driven terms, the IDM is a Platform-Independent Model (PIM). From there, it is possible to
apply some automated transformations to make it target a specific technology.

Java Design Model (JDM)

The Java Design Model (JDM) represents such a Platform-Specific Model that targets the definition of J2EE enterprise-
wide components. From the JDM, it is possible to generate J2EE-compliant Enterprise Java® Beans (EJB) interfaces for
the components as well a full set of Data Transfer Objects. These assets greatly facilitate the definition of enterprise-wide
components for the insurance industry.

The advantages of the approach are a full consistency between the levels (from business and process definitions to services
and components), an enterprise-wide approach that reduces duplication of functionality and reduces maintenance costs,
and an external validation element that reduces the risk of overseeing some business requirements or to embark on a
dubious design.

19
IBM Process and Service Models are delivered in either proprietary Industry Models tooling or standard IBM tooling
(InfoSphere, WebSphere, Rational). The model delivered for the standard tooling environment also support any BPMN or
SoaML tooling. You can choose to implement using either environment but you cannot switch between them. The business
content of the models is the same in both tooling environment. This table details the specific component names by tooling
environment:

Industry Models Tooling Standard Tooling Environment

Business Terms Business Terms Business Terms (InfoSphere Business Glossary)
Project Scoping IBM Component Business Model IBM Component Business Model
Process Analysis Business Activity Model Analysis Process Model (BPMN)
Analysis Process Model
Process Design Business Process Model Orchestration Process Model (BPMN)
Service Analysis Business Model Business Object Model (SoaML)
Enterprise Component Blueprint
Service Design Interface Design Model Service Design Model (SoaML)
Java Design Model Interface Design Model (SoaML)
Design Model Datatypes Model (SoaML)

20
The Product Models

Product Flexibility
Survival in a highly competitive environment can be achieved through price competition (cost control) or by company
differentiation. Customer service supported by a customer-centric view is one differentiating factor; a second important factor
is product differentiation. Therefore, to keep pace with the competition, it is essential to innovate and to develop and release
new financial products quickly.

One of the strengths of IAA is the way it analyses financial services products. The IAA Product Modeling Guide provides a
set of techniques for analyzing and defining insurance products in a very structured way. It provides a graphical notation
(Product Specification Diagrams) semantic as well as hints and tips for modeling insurance products based on accumulated
project experience.

IAA Product Model

The IAA Product Models contain a representative set of insurance products structured in accordance with these analysis
techniques. These product definitions can be used as templates to accelerate the modeling of insurance products.

• For life insurance: annuities (immediate, deferred, single or joint life), term and whole life, unit linked, and all of their
components (waiver of premium, accidental death, loans, etc.) as well as all of their life-cycle transactions (total and
partial surrender, fund switch, premium holiday, …)
• For property and casualty: auto (including liability, own car damage, break of glass, fire, theft, car replacement…), home
(with a full set of options and coverages) and travel (with all the options) a fully fledged methodological example of how
to customize the product templates.
• For health insurance: family health indemnity plan with all its features and life-cycle events.
• For commercial insurance: a construction pollution liability insurance product
• For group insurance: a health product and a pensions product
• For specifying intermediary agreements: an agent product

The next figure shows a simplified example of a Product Specification Diagram for automobile insurance.

21
Product modeling can be done in a purely analytical way (to rationalize a product portfolio, for example) but it realizes its
full potential when the analysis is coupled to the Specification Framework, which is the generic framework that supports the
design and development of systems for product definition and agreement administration.

IAA Specification Framework

The IAA Specification Framework is a design framework for building flexible product engines and administration systems to
support those products (as well as existing ones). Its underlying principles of re-use of product definitions and externalization
of product rules can dramatically reduce the time to market of new products

The IDM focuses on the definition of the interfaces but does not completely detail how these interfaces are implemented.
In that respect, it is an external design model. An internal design level focuses on the implementation of the interfaces and
provides a set of class and low level collaborations in order to support the implementation of interfaces.The Specification
Framework is a UML model that provides the design of a technical framework allowing a dynamic definition of products and
agreements. The Specification Framework should be used as a design model by anyone who wants to develop a flexible
product system that can support the creation and the maintenance of related agreements, i.e., policies.

The Specification Framework has been implemented successfully on different platforms and for different lines of business:
health insurance, commercial lines, homeowner and even for an agent-compensation system (in that case, the product is the
specification of the intermediary contracts and the agreements the intermediary contract themselves).

22
 IBM Industry Models
www.ibm.com/software/data/ips/products/
industrymodels
Produced in Ireland.
All Rights Reserved
ibm.com
IBM the IBM logo and DB2 are a registered
trademarks of International Business
Machines Corporation.
Other company, product and service names
may be trademarks, or service marks of
others.
References in this publication to IBM
products, programs or services do not imply
that IBM intends to make these available
in all countries in which IBM operates. Any
reference to an IBM product, program or
service is not intended to imply that only IBM’s
product, program or service may be used.
Any functionally equivalent product, program
or service may be used instead.
This publication is for general guidance only.
© Copyright IBM Corporation 2012

23