SAS® Insurance

Intelligence Solutions

Customization Guide

Edition 3.2 Release B 1.0

© 2006 SAS Institute Inc.

 Usage Agreement
Company means the legal entity represented by
its employees accepting the enclosed material.
SAS Institute Inc. and its subsidiaries do not
guarantee and shall not take any responsibility for
the success or failure of a project due to the use
of all or parts of the SAS® Insurance Intelligence
Solutions. It remains the sole responsibility of the
Company’s project manager and project team
members to utilize the SAS® Insurance
Intelligence Solutions material, to plan and to
manage project activities for a Company’s client.
SAS Institute Inc. and its subsidiaries shall not be
liable for failure of a project, any lost profits, or
other incidental, direct or indirect damages
resulting from such a project, through use of the
SAS® Insurance Intelligence Solutions and SAS®
Insurance Intelligence Solutions material.
SAS Institute Inc. and its subsidiaries do not
guarantee that the materials in this reference
manual are correct. If errors are found, SAS
Institute Inc.’s local subsidiaries should be notified
in writing.
SAS Institute Inc. or its subsidiaries do not offer
technical support for the SAS® Insurance Intelligence
Solutions or the use of the SAS® Insurance
Intelligence Solutions. The SAS® Insurance
Intelligence Solutions and any SAS® Insurance
Intelligence Solutions material are and will remain
the exclusive copyrighted property of SAS Institute
Inc. The Company is granted a non-transferable,
non-exclusive and gratuitous right to use the SAS®
Insurance Intelligence Solutions and SAS® Insurance
Intelligence Solutions material in any project where
Company is involved.
In the event the SAS® Insurance Intelligence
Solutions has become obsolete due to major product
developments, SAS Institute Inc.’s subsidiaries have
the right to request the Company to stop using the
SAS® Insurance Intelligence Solutions and SAS®
Insurance Intelligence Solutions material in future
projects. The Company agrees to adhere to this
request and discontinue using the SAS® Insurance
Intelligence Solutions and SAS® Insurance
Intelligence Solutions material.

The correct bibliographic citation for this manual is as follows:

SAS Institute Inc., SAS® Insurance Intelligence Solutions, Cary, NC: SAS Institute Inc., 2006.
12 pages.

SAS® Insurance Intelligence Solutions

Copyright 2006 by SAS Institute Inc., Cary, NC, USA.

All rights reserved. Printed in India. No part of this publication may be reproduced, stored in a retrieval
system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, or otherwise,
without the prior written permission of the publisher, SAS Institute Inc.

Restricted Rights Legend. Software and accompanying documentation are provided to the U.S.
government in a transaction subject to the Federal Acquisition Regulations with Restricted Rights. Use,
duplication, or disclosure of the software by the government is subject to restrictions as set forth in FAR
52.227-19 Commercial Computer Software-Restricted Rights (June 1987). The Contractor/Licensor is
SAS Institute Inc., located at SAS Campus Drive, Cary, North Carolina 27513.

SAS Institute Inc., SAS Campus Drive, Cary, North Carolina 27513.

1st printing, April 2006

SAS® and all other SAS Institute Inc. product or service names are registered trademarks or trademarks
of SAS Institute Inc. in the USA and other countries. ® indicates USA registration

ii SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.

 Contents

Contents
Preface............................................................................................................................................................ v
Purpose ...................................................................................................................................................... v
Who Should Read This Document........................................................................................................... v
Contents of This Document...................................................................................................................... v
Conventions ............................................................................................................................................... v
Part I. Generic Customization Guidelines ............................................................................................ 1
1. Introduction ............................................................................................................................................... 2
2. Basics of Customization .......................................................................................................................... 3
2.1 Scope of Customizations.................................................................................................................... 3
2.2 Classification of Customizations ....................................................................................................... 4
2.3 Incremental Deployment and Upgrades............................................................................................ 4
2.4 Mechanism of Customizations........................................................................................................... 5
2.4.1. Steps of Customizations ................................................................................................................ 5
2.4.2. Customization Parameters............................................................................................................. 6
2.4.3. Tracking of Customizations............................................................................................................ 6
3. Guidelines .................................................................................................................................................. 7
3.1 Acquisition ETL ................................................................................................................................... 7
3.2 Data Model Customization.................................................................................................................. 7
3.2.1. Detail Data Store Customization.................................................................................................... 7
3.2.2. Star Schema Customization .......................................................................................................... 8
3.2.3. OLAP Cube Customization ............................................................................................................ 8
3.3 Data Delivery ETL Process Customization ....................................................................................... 9
3.4 Report Customization ......................................................................................................................... 9
3.5 Data Management Processes............................................................................................................. 9
Part II. Customization for Insurance Intelligence Solutions.............................................................. 11
1. IIS Customization Example .................................................................................................................... 12
1.1 DDS Customization ........................................................................................................................... 12
1.2 ETL Customization ............................................................................................................................ 12

Figures
Figure 1 Dependencies Considered for Customization.....................................................................3

SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc. iii
Customization Guide

iv SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.

 Preface

Preface
Purpose
This document describes the technical guidelines for customizing various areas of industry intelligence
solutions.

Who Should Read This Document

This document should be read by Data Architects, Warehouse Consultants, Data Exploitation
Specialists, Application Developers, Instructors, and Solution Specialists.

Contents of This Document

This document contains guidelines for customization of various areas of a typical intelligence solution
implementation. Part I of the document has generic guidelines that are applicable across all intelligence
solutions and Part II contains guidelines and/or other useful information as specifically applicable to
Insurance Intelligence Solutions, Edition 3.2.

Conventions
The typographic and usage conventions of this guide are as follows:

Item Usage

Italics Italicized font is used within text for the values of fields that are typed in/entered
or selected in the UI. Italicized font is also used for book titles, new terminology,
emphasis, and values of configuration options.

Bold Bold font is used within text for key names, key combinations, key sequences,
menu items, commands on menus, buttons, and various screen elements.
Monospace Monospace font is used within text for sample code and code listings, API and
language elements (such as function names and class names), file names, path
names, directory names, table names, column names, macro names and HTML
tags.
MonoItalics MonoItalics font is used within text to indicate variable placeholders in
angular brackets.

Note: Text in a gray box indicates a point of particular interest or that special notice should be
given to the text that follows.

SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc. v

Customization Guide

vi SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.

Part I. Generic Customization
Guidelines
Customization Guide

1. Introduction
The SAS® Industry Intelligence Solutions incorporate the latest industry-proven implementation of key
business topics. However, it is not able to exactly match an individual customer’s business requirements
totally—no standard model can. Some degree of customization is always required, for example, to reflect
the local markets or unique customer specifics. Therefore, every project involves some customization. This
document describes the guidelines for customizing various parts of typical industry intelligence solutions.
This part of the document is applicable across all intelligence solutions and addresses only technical
aspects of customization. It does not describe the process of solutions assessment that generates inputs
for customizations. This aspect is covered in the Intelligence Solutions Implementation Methodology.

2 SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.

 Part I. Generic Customization Guidelines
Basics of Customization

2. Basics of Customization
In general, it is recommended that customization be considered first, rather than development. It is better
to adapt the available IS material rather than start from scratch. Customization not only affects the data
models but also the Dependent Data management processing. Depending on the customer scenario, this
can be more work than customizing the data models. While doing the customizations, it is also necessary
to consider the difficulties that could arise for future upgrades to intelligence solutions due to a lot of
customization. It will always be a balancing act between the ease of future upgrades and the need for
customizations.

2.1 Scope of Customizations

The following diagram shows areas of a typical intelligence solution with dependencies that need to be
considered while working on customizations.

Detailed Data Store

SAS Solution marts Analytical Base Tables

Star Schema OLAP Cubes

Information Maps

Report Definitions

Copyright © 2003, SAS Institute Inc. All rights reserved.

Figure 1 Dependencies Considered for Customization

The arrows show the direction of the cascading effect of changes made in a particular component. This
cascading effect should be kept in mind while deciding on whether to build new structures or modify
existing ones.

Based on this diagram, the following areas are currently identified as candidates for customization:

• Acquisition ETL
• Data model customization
o Detail data store
o Star schema
o OLAP Cubes
• Data delivery ETL process customization

SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc. 3

Customization Guide

• Reporting customization
o Information maps
o Report Definitions
• Data management processes

Guidelines for each of these areas are mentioned later in the document.

2.2 Classification of Customizations

Customizations can be classified as one of the following:

• “Simple” changes: No effect on data structure, logic, or process in the data warehouse, for
example, character column length increase, label or format for a column, extra descriptive fields
not referenced by supplied applications.
• “Moderate” changes: Localized effect, clear simple effect on logic or process, for example, extra
data columns for a few specific tables, an extra level to a dimension hierarchy (but not adding a
new dimension).
• “Complex” changes: Widespread effect, potential complex impact on logic or process, for
example, new entity or table required, new dimension for star schema.

It is to be noted that the degree of complexity is partly based upon how much manual effort is required,
and how many components are affected.

Avoid making ‘complex’ changes wherever possible. These add to the cost and make future upgrades
more difficult.

2.3 Incremental Deployment and Upgrades

Intelligence solutions typically consist of more than one solution area. Various possible deployment
scenarios are:

• Deployment of DDS and first solution area

• Deployment of a solution area when one or more solution areas are already in production
• Upgrade to a new edition or release of intelligence solutions

In all these cases, the new deployment may have objects that are overlapping with previously existing
solution areas. In view of the customizations done, careful considerations are needed while making
such an incremental deployment and/or upgrade. SAS9 Metadata import plug-in is supplied along with
the Intelligence Solutions software. This plug-in does an import of metadata in an interactive manner
through a wizard while presenting users with various decisions to be made. This plug-in will highlight
any objects that are present in already deployed solution areas and new deployments, after which the
user needs to make a decision. The log of customizations mentioned above will act as an important
input while deciding how to perform the upgrade while preserving the customizations. The efforts that
will be required to do incremental deployment and upgrades will proportionately increase based on the
number of customizations and complexity (in terms of the classification mentioned above) of the
customizations. So a right balance is required between efforts needed for incremental
deployment/upgrade and the need for customization.

Note: It is important that the customizations are done as per the guidelines with particular attention
to make sure that customizations that are not recommended (such as deletion of fields) are not
done. Doing such changes may make it very difficult or even impossible to do incremental
deployment or upgrades of intelligence solutions.

4 SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.

 Part I. Generic Customization Guidelines
Basics of Customization

2.4 Mechanism of Customizations

2.4.1. Steps of Customizations
It is suggested that the customization effort be carried out by going through a step-by-step approach
described below.

Step 1. Identify Customization Requirements

a. Start from the target data mart – ABT or Star schema.
b. Identify gaps between requirements and the IIS pre-defined data mart. For example,
additional variables required in the ABT or in the star schema.
c. Note: While identifying gaps, it is important to review the detailed description or derivation of
variables to ensure that they meet requirements.
d. No updates or deletions should be made to pre-defined data structures.
e. For each additional variable required in the target data mart, determine if the required data is
available in the DDS. In this manner, identify gaps in the DDS.
f. Note: In certain cases, there may be no apparent gap in the DDS. However if aggregated or
derived variables are available in source systems or existing data warehouses, the variables
may be directly added to the DDS tables, in order to avoid business rules or aggregations
being duplicated in IIS.
g. Outputs from Step: Target data mart gap analysis, DDS gap analysis.

Step 2. Identify DDS Customizations

a. Based on the DDS gap analysis, specific additions to the DDS are identified in this step.
b. First identify columns to add to the existing tables.
c. In case all gaps are not satisfied with the existing tables, identify additional tables and
columns for those tables. Also identify relationships with existing tables.
d. No updates or deletions should be made to pre-defined data structures.
e. Outputs from Step: List of DDS additions.

Step 3. Identify Customizations to Global Parameters

a. In case the identified customizations include codes or values that need to be used as
conditions in the ETL jobs, the same should be defined as global parameters in the
parameter file. This avoids hard-coding of values in the ETL jobs and thereby enhances the
maintainability of the ETL jobs.
b. Outputs from Step: List of additional parameters and initial values.

Step 4. Identify ETL Customizations

a. Recommended method - Additions
i. For all additions, define new ETL jobs.
ii. Note: In case additions as defined in Step 1, point f are made to the DDS, new jobs
will be required for those additions.
iii. Additions will need to be joined with the existing target data mart to get the required
target data mart.
iv. Add this new job as part of the existing jobs that populate the target table.
v. It is highly recommended that a separate naming convention be used for all such
custom written jobs.

SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc. 5

Customization Guide

b. Recommended method – Modifications due to change in business rule

i. In case there is a requirement to change the business rule then also add a new job.
ii. Use a different naming convention for these new jobs.
iii. Do not use the provided job as part of the regular ETL run, use the new job instead.
c. Outputs from Step: List of ETL job additions/customizations.

Step 5. Implement Identified Customizations

Note: Any changes made to the pre-defined xIS environment should be logged and the log
should be maintained on a regular basis. Details of this log are mentioned in subsequent section.

2.4.2. Customization Parameters

To control the behavior of intelligence solutions, a set of customization parameters are used in the
software. Values of these parameters are set through SAS Macro variables. Using these parameters
should be the first preference to address a customization need because this method will involve no
code change. List of such parameters used in a particular intelligence solution is mentioned in DDS
usage guide and in usage guides for individual solution areas within that intelligence solution.

2.4.3. Tracking of Customizations

Ongoing maintenance/support requires a log of all customizations (with reasons and customer
authorization for each). Also, identify tables or columns added for a particular customer outside of
the base model. This can be done with a naming convention (for example, a standard prefix). This is
a key deliverable at the end of the initial deployment so that the 'upgrade' team knows what was
done previously and why. An Excel file, (CustomizationLog.xls), is provided with this package. The
table shown below is a sample of the customization log.
No. Area Customized Date Identified Customization Decision Effort Assigned Progress Date
Item proposed by By to closed

6 SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.

 Part I. Generic Customization Guidelines
Guidelines

3. Guidelines
3.1 Acquisition ETL
An important step in implementation of intelligence solutions is to design and develop ETL processes to
get the data from operational (source) systems and to populate the DDS. This layer of data processing
is referred to as Acquisition ETL. Design and development of acquisition ETL will be a completely
project specific activity because of following reasons:

• It is dependent on Source Systems and the business rules they incorporate.

• Even if the site uses a commercial off-the-shelf package for some system, it may have local
customization itself.
• Data quality and cleansing requirements also impact this ETL.

3.2 Data Model Customization

3.2.1. Detail Data Store Customization
The detail data store is the normalized data store that comprises the first level of detail in the
Enterprise Warehouse with full history up to an agreed age, for example, five years.

The customization to the DDS is expected due to:

• Local language or value format requirements.

• Additional fields required in the tables due to additional business requirements.
• Additional entity/table required due to additional business requirement or to a larger extent
due to addition of a new area of business.

The following guidelines are recommended for SAS® Intelligence Solutions DDS customization. They
are classified into two categories.

Permissible Changes
• The column labels can be changed without any impact.
• The length of the fields can be expanded when data is expected to be longer. This will not
have impact on existing data but processes that refer to this particular column will need to
be changed.
• Fields can be added to the tables. However, using these fields in the already implemented
downstream processing would require customization of processes. It is recommended that
a naming convention be used for any new tables added so that they can be easily
identified later.
• New tables can be added to the DDS. However, remember that using these tables in the
already implemented downstream processing would require customization of processes. It
is recommended that new processes be added rather than modifying existing ones for
addition of a totally new business area outside the scope of the given Intelligence Solution.
It is recommended that a naming convention be used for any new tables added so that
they can be easily identified later.
• Language code (language_cd) is expected to be country specific and hence can be
customized.
• The currencies used are expected to be country specific and hence can be specified for
most of the amount values using the currency_cd column. However, we do not
recommend usage of mixed currencies for different tables within the DDS as that could
cause confusion during reporting.

SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc. 7

Customization Guide

Changes NOT Recommended

• It is strongly recommended that you do not reduce the length in case of impact on
downstream processing.
• Avoid changing column names as they have significant impact on already implemented
downstream processing.
• Changing data types for columns can also have a significant impact on already
implemented downstream processing. Hence, it is not recommended.
• It is strongly recommended that you do not delete any fields. In case the fields are of no
use, they can hold missing values.

3.2.2. Star Schema Customization

The customization of star schema is expected due to:

• Adding a descriptive column to dimension

• Changing the grain of dimension
• Changing the grain of fact

The following guidelines are recommended for star schema customization. They are classified into
two categories.

Permissible Changes
• The column labels can be changed without any impact.
• Fields can be added to the tables. However, using these fields in the already implemented
downstream processing would require customization of processes. It is recommended that
a naming convention be used for any new tables added so that they can be easily
identified later.
Changes NOT Recommended
• It is strongly recommended that you do not reduce the length in case of impact on
downstream processing.
• Avoid changing column names as they have significant impact on already implemented
downstream processing.
• Changing data types for columns can also have a significant impact on already
implemented downstream processing. Hence, it is not recommended.
• It is strongly recommended that you do not delete any fields. In case the fields are of no
use, they can hold missing values.

NOTE: Any customization in star schema mentioned above will need corresponding changes in
data delivery ETL processes.

3.2.3. OLAP Cube Customization

To cater to a set of pre-defined reports, a set of cubes are supplied along with the solution. Do an
assessment of reporting requirements to arrive at a decision whether to do a “minor” (few columns)
addition to an existing cube or to build new cubes to cater to new requirements. Similarly do an
assessment of available data to make a decision about removal of columns as well. It is strongly
recommended that supplied standard cubes not be modified. Instead build a new cube to cater to
additional requirements. An exception to this could be when space requirements for a new cube are
very large. In such cases modification to existing cubes may be the only option because of space
constraints.

8 SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.

 Part I. Generic Customization Guidelines
Guidelines

The processes to create cubes are supplied assuming full history would be loaded into the cubes. If
less history is required then these processes need to be modified to add a filtering condition.

3.3 Data Delivery ETL Process Customization

Data delivery ETL processes should not need to change as much as data acquisition ETL. Processes
are provided for all dependent storage. Any customization will be mainly due to data model changes as
described in previous sections and at more detailed level by business rule customization such as new
or changed derivations. A major area of customization and design work for data delivery ETL processes
is related to operational specifics. See the section on data management processes for details.

3.4 Report Customization

A set of pre-defined reports and information maps needed for the same may be supplied along with the
solutions. It is recommended that the supplied information maps not be modified because such a
modification may affect all report definitions dependent on a particular information map. Instead create
new information maps to cater to additional reporting requirements. Supplied reporting definitions can
be modified with appropriate logging of the customizations as explained in the previous sections.

3.5 Data Management Processes

Design of management processes covers aspects such as:

• On what server a process executes

• Backup and recovery
• Data aging and archiving
• Process scheduling

Some aging/retention/archiving tools are provided in the form of SAS macros. Process dependency is
supplied in the form of a document. These dependencies need to be implemented into a scheduling tool
such as LSF Scheduler.

SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc. 9

Customization Guide

10 SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.

Part II. Customization for
Insurance Intelligence
Solutions
Customization Guide

1. IIS Customization Example

1.1 DDS Customization
During the detailed requirements gathering phase, it was identified that an additional table called
POLICY_AMTS would be required, which would hang off the GENERAL_INSURANCE_POLICY table. In a
scenario like this, the new table should be “X_POLICY_AMTS”. The prefix “X_” would segregate this
table from the standard IIS tables and remove the possibility of a table name conflict in the future.

1.2 ETL Customization

The implementation team found that the way the earned premium needs to be calculated for certain
lines of business (LOBs) is different from the way it is calculated in IIS. In such a situation, a new job
named “X_CALC_EARNED_PREM” should be written by the implementation team. This, too, will avoid
any conflicts in the job names in the future.

12 SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.