RSA - MDM Reference Data Functional Detailed Design v0 2

RSA – MDM REFERENCE DATA
FUNCTIONAL DETAILED
DESIGN V0.2
Abstract
This document describes the detailed design for the MDM Reference Data solution
RSA – MDM REFERENCE DATA Functional Detailed Design v0.2
Table of Contents
1 Document Overview..............................................................................................................................................3
1.1 Purpose.......................................................................................................................................................................... 3
1.2 Revision History ............................................................................................................................................................. 3
1.3 Document Approvers .................................................................................................................................................... 3
1.4 Document Reviewers..................................................................................................................................................... 3
1.5 Referenced Documents ................................................................................................................................................. 4
1.6 Acronyms ....................................................................................................................................................................... 5
2 Overview ...............................................................................................................................................................7
2.1 Data Insight Architecture............................................................................................................................................... 7
2.2 Scope ............................................................................................................................................................................. 9
2.3 AGENT.......................................................................................................................................................................... 10
2.4 RDM ............................................................................................................................................................................. 10
3 Interface Detailed Design ................................................................................................................................... 11
3.1 User Interfaces ............................................................................................................................................................ 11
3.2 Data Model .................................................................................................................................................................. 11
3.3 RDM SCREENS.............................................................................................................................................................. 13
3.4 Screen Examples .......................................................................................................................................................... 14
3.4.1 Process Screen ................................................................................................................................................. 14
3.4.2 View Screen(OOTB) .......................................................................................................................................... 15
3.4.3 Tasks Screen(OOTB) ......................................................................................................................................... 16
3.4.4 Authorize/Rollback Screen ............................................................................................................................... 16
3.5 Reference Data ............................................................................................................................................................ 18
3.5.1 Key Considerations........................................................................................................................................... 18
3.5.2 Process ............................................................................................................................................................. 19
3.5.3 Input File .......................................................................................................................................................... 21
3.5.4 Output File ....................................................................................................................................................... 21
4 RDM Integration Job .......................................................................................................................................... 22
5 MI Reporting ...................................................................................................................................................... 23
6 AuDIT Logging and Error Handling ..................................................................................................................... 23
6.1 Audit ............................................................................................................................................................................ 23
6.1.1 Audit Table ....................................................................................................................................................... 24
6.1.2 Audit Log File .................................................................................................................................................... 24
6.2 Errors ........................................................................................................................................................................... 24
6.2.1 Message Error Tables ....................................................................................................................................... 24
6.2.2 Error logs .......................................................................................................................................................... 25
7 Security ............................................................................................................................................................... 25
7.1 Access Controls ............................................................................................................................................................ 25
7.1.1 Network And Platform Secruity ....................................................................................................................... 25
7.1.2 Talend SQL Server ............................................................................................................................................ 25
7.1.3 Talend Log files................................................................................................................................................. 25
7.2 Data Security ............................................................................................................................................................... 25
8 Availability .......................................................................................................................................................... 26
9 Requirements Traceability Matrix...................................................................................................................... 27
3.4.1 & 3.5.1 ......................................................................................................................................................................... 29
3.2 & 3.5.2 ............................................................................................................................................................................ 29
Modified: 08/02/2018 01:11 1
Copyright ©2015 Accenture. All Rights Reserved.
3.5.2 30
Modified: 08/02/2018 01:11 2

1 DOCUMENT OVERVIEW
1.1 Purpose
The purpose of this document is to provide a detailed design to component level for the MDM Reference Data
solution. This document extends the MDM Solution Analysis Specification document which provides an
overarching description of the MDM solution and requirements.
1.2 Revision History

Date Version Description Author
June 2016 V0.1 Draft R. Ghai/ S. Khela

August 2016 V0.2 Updated comments from stake holders R. Ghai
and added RDM screens
1.3 Document Approvers
Name Role
Ian Kenealy Design Lead
Dom Attwell / Jide Okuwa Data Architect
Gillian Tomlinson CDO
Susan Binns Service Architecture
Tony Prikockis Product Owner
Alistair Goodall Security Lead
1.4 Document Reviewers
Name Role
David Green Business Analyst
Ian Elms Data Modelling Architect
Chris Darragh Data, Analytics & MDM Delivery Lead
Richard Walsh E2E Architecture
Jazz Khan / Paul Dobson Infrastructure
Jon Lillis Infrastructure
Jorge Orts Integration
Modified: 08/02/2018 01:11 3

Susan Middleton Integration

Dean Jackson Product Owner
Phil Surley Migration
Jonathan Moore Operations / Performance
Louise Edwards Operations / Performance
Paul Ellis Personal Intermediated MI Delivery
James Craigen Security
Marie Clampitt Data Office Lead
Seren Yashar Data Requirements
Sarah Simmons CRM Product Owner
Ian Warnett DC Product Owner
Jeroen Hendriks CRM Solution Lead
Damiano Pietroni Data Migration
John Bean Solution Integrity
Ben Tyte Solution Integrity
Ian Dawson CDW Lead
Ian Martin Service Architecture / Business Capacity Planner
Vincent Stenhouse Service Architecture / Storage Technical Service
Manager
1.5 Referenced Documents

The list of referenced documents are listed in the below table, including a link to the Accenture SharePoint.
The documents are also available in JIRA at the following link:
https://jira2.uk.rsa-ins.com/RedirectToDocuments.jspa?documentOperation=show-folder&documentKey=369
For assistance with access to JIRA, please reach out to Theo Muzangaza (theo.muzangaza@uk.rsagroup.com)
and/ or David Bodle (david.bodle@uk.rsagroup.com).
Name Accenture SharePoint Location

MDM Solution Analysis Specification https://ts.accenture.com/sites/RSA_Transformation/Delivery/Data%
20Analytics%20and%20MDM/MDM/Solution%20Analysis%20Definit
ion/RSA%20-
%20MDM%20Solution%20Analysis%20Specification%20v1.1.docx?
Web=1
Talend MDM Best Practice Guide https://ts.accenture.com/sites/RSA_Transformation/Delivery/Data%

20Analytics%20and%20MDM/MDM/Talend/Best%20Practice%20Gu
ides
RSA GALAXY – Data, MI, MDM and Analytics - https://ts.accenture.com/sites/RSA_Transformation/Delivery/Data%

Discovery 20Analytics%20and%20MDM/Management/Discovery%20Phase%2
Solution Blueprint v5.6
Modified: 08/02/2018 01:11 4

0KT%20from%20Bernard/Blueprint%20Feb%2004%20v5.6.pptx?We
b=1
Data Architecture Glossary.docx https://ts.accenture.com/sites/RSA_Transformation/Delivery/

Data%20Analytics%20and%20MDM/MI%20and%20Reporting
/00%20Standards/Data%20Architecture%20Glossary.docx?W
eb=1
Canonical Customer Data Model https://ts.accenture.com/sites/RSA_Transformation/Delivery/
Data%20Analytics%20and%20MDM/Data%20Model/CDM/Cu
stomer
KDD for Vendor assessment https://ts.accenture.com/sites/RSA_Transformation/Delivery/
Data%20Analytics%20and%20MDM/MDM/Vendor%20Assess
ment/KDD%20UK%20Galaxy%20data%20management%20ve
ndor%20DCF%2004.02.16%20v1.1.pptx?Web=1
Requirements (from JIRA) – Provided on 11th https://ts.accenture.com/sites/RSA_Transformation/Delivery/
April 2016 Data%20Analytics%20and%20MDM/MDM/Requirements/MD
M%20FR%20And%20NFR%20draft%200.1%20(Satinder%20Co
mments).xlsx?Web=1
Critical Success Factors document https://ts.accenture.com/sites/RSA_Transformation/Delivery/
Data%20Analytics%20and%20MDM/MDM/Requirements/Suc
cess%20Factors/Critical%20Success%20Factors.docx?Web=1
Migration Solution Blueprint, HL https://ts.accenture.com/sites/RSA_Transformation/Delivery/
Requirements and architecture Data%20Analytics%20and%20MDM/MDM/Data%20Migration
/Galaxy%20Delivery%20-
%20Migration%20Solution%20Blueprint%20V2%2040.pptx?W
eb=1
RSA Galaxy - Data Analytics and MDM https://ts.accenture.com/sites/RSA_Transformation/Delivery/
Deliverables Map v1.1.pptx Data%20Analytics%20and%20MDM/Data%20Model/Delivera
bles%20Map/RSA%20Galaxy%20-
%20Data%20Analytics%20and%20MDM%20Deliverables%20
Map%20v1.1.pptx?Web=1
Security HLD https://ts.accenture.com/sites/RSA_Transformation/_layouts/15
/start.aspx#/Delivery/Forms/AllItems.aspx?RootFolder=%2fsites
%2fRSA%5fTransformation%2fDelivery%2fSecurity%2fSecurity
Arch
UK Security Implementation Standard - Data https://ts.accenture.com/sites/RSA_Transformation/_layouts/15
Classification v1.0.docx /start.aspx#/Delivery/Forms/AllItems.aspx?RootFolder=%2fsites
%2fRSA%5fTransformation%2fDelivery%2fSecurity%2fSecurity
Arch
1.6 Acronyms
Acronym Definition
Modified: 08/02/2018 01:11 5

AIP Accenture Insights Platform

API Application Programming Interface
CRM Customer Relationship Management
DC Duck Creek
DQ Data Quality
DSC Data Stewardship Console (Talend GUI)
ESB Enterprise Service Bus
ETL Extract, Transform, Load
GUI Graphical User Interface
MDM Master Data Management
NBS Nationwide Building Society
OOTB Out Of The Box
RDM Reference Data Management
UFE Unified Front End
BPM Business Process Management
Modified: 08/02/2018 01:11 6

2 OVERVIEW
This document is a technical design for the MDM Reference data solution. It will provide the development team
guidance on what is to be built to component level and include any business logic that must be implemented. It
is also useful reading for anyone developing or supporting the downstream applications which are part of the
e2e Galaxy initiative.
The inputs into this design are the RDM requirements and the MDM SAS (Solution Analysis Specification). This
design should be read alongside both of the afore mentioned documents
2.1 Data Insight Architecture

The end-to-end Galaxy target application architecture has been described in the diagram below so that the RDM
solution described in this design document can be placed into perspective against the overall landscape.
Capabilities
Batch and Real Time Extracts Advanced Analytics Partner Portal

Data Visualisation, Master Data Mgmt Real Time Decisioning Broadcast Decisioning
Reporting and Best Next Action Legacy Extracts
NBS Portal A Single Customer View Direct Mail
Dashboard Earnix Pricing Multi Product Holder Discount Legacy Reports
Customer Congruency Email
Emblem Portfolio Lookers Legacy Dashboards
Quote Outbound Telephony
Underwriting Customer Match / Merge Churners
Lexis Nexis Customer View across all
Policy SMS
Counter Fraud Data Quality Reporting Quote Followup More Th>n products
Transactions Mid
Marketing Reference Data Management
Non Policy Activity (CRM) EPOQ
Finance Operations Data Governance
D4P Dashboards
Premium Partner Extracts
Internal Extracts
Access Layer
NBS View Home D4P Extract
MI MDM Legacy
Home D4P Home D4P Motor D4P

RDM
Analytics
Warehouse
Data Vault AIS MI
CDW
Customers:
No integration PL Quote MI  350k - More Th>n Motor
with the Legacy  1.2m - More Th>n Pet & Home
Data Lake Customer MDM systems inside  20m - Holders of lapsed policies
the dotted & enquirers
Customers:  44m – From Experian Consumer
border. They
 Galaxy Home, migrated on renewal from DLG View
are shown for
context.
CSAT NPS
Operational Data Hub
FDS
Telephony
API API
Biztalk CAL SIL
Sources
Europa Experian 68 Feeds from ~20

NBS Reverse Duck Creek Duck Creek Aggregator Perils & FloodRE (Home
UFE (address Earnix CCS MI Experian Consumer CRM internal & external Salesforce SAP
Congruency Billing P&Q Quotes Proximity only)
validation) View sources
Agency
(position on
diagram TBC)
Key:
Title: Data Insight Architecture for Galaxy Contributors:
Unchanged Component Changed Component Legacy
Scope: Galaxy RSA: Dom Attwell, Tony Prikockis, Ian Dawson
Level: Level 0 Accenture: Ian Elms, Chris Darragh, Sandeep Raju,
Version: 0.7 Required for Home Only New Component Subramanya Hanuman
A : Day 1 + 12 months Addition
Note: This diagram is currently under review with RSA architecture and subject to change until it has been
approved.
The diagram below describes the key layers of the MDM solution and the main building blocks within each of
the layers that are being delivered.
Modified: 08/02/2018 01:11 7

The RDM FDD’s will provide coverage of all the blocks listed in the block diagram. The coverage of work
described in this design document has been highlighted in the block diagram shown below:
This FDD will describe the design for storing reference data at a central location for the Galaxy Home Insurance
business.
Modified: 08/02/2018 01:11 8

2.2 Scope
This section defines the reference data categories which are in scope of Galaxy. The categories are divided into
Integration, MI, MDM and NBS scope. These have been signed off by Product owner.
Reference Data ID Category Scope Reference Data Category

1 Integration Gender
2 Integration HearAboutUs
3 Integration ReasonForCancellation
4 Integration ListedBuilding
5 Integration/MDM/NBS MaritalStatus
6 Integration PolicyTransactionReason
7 Integration PolicyTransactionType
8 Integration PolicyTransactionMigration
9 Integration PremiumPaymentMethod
10 Integration ProductBrand
11 Integration ProductName
12 Integration PropertyType
13 Integration Status Type
14 Integration Quote Type
15 Integration Channel
16 Integration/MDM/NBS Title
17 Integration CampaignCode
18 Integration PartnerBranchCode
19 Integration/MDM County
20 Integration Nations
21 Integration AffinityCustomerSegment
22 MI MTA Reasons
Modified: 08/02/2018 01:11 9

23 MI Flood/ sustenance postcode regions/codes

24 MI Referrer ID
25 MI Finalize Premium Reasons
26 MI Underwriting Referral reasons (Code)
27 MI AgencyName
28 MI Partner Trading periods
29 MI SchemeName
30 MI RSAOperational&ReportingHierarchies
31 MI RetentionCode
32 MI Agent
The current RDM solution has been designed in line with the in scope reference data categories as use cases, but
the capability allows for additional reference data categories to be introduced by RSA. The whole process of
adding and updating category/reference value has been described in section 3.4.1 and 3.5.2.
2.3 AGENT
Agent data will be mastered in RDM so that there is a single source of this information available for reporting
purposes across all systems in the estate.
Agent scope includes RSA agents only. Mastering of NBS agents in RDM is out of scope because due to data
privacy concerns NBS will not share information about its agents.
It will be considered just like any other category in RDM and will be created/updated by uploading fixed format
csv input file. The process is mentioned in section 3.4.1 and 3.5.2.
2.4 RDM
RDM solution provides following capabilities:
 Building capability for creating, updating and disabling reference data in Reference Data Model through
delimited csv file.
 Creating capability of using Talend customized Forms and Talend DSC by Data Office stewards to
approve/reject an operation on reference data, view reference data and dependencies using ootb
functionality and data governance process to manage consistency across all systems.
 Providing capability for MI solution to interact with RDM and pull reference data for reporting.
Modified: 08/02/2018 01:11 10

3 INTERFACE DETAILED DESIGN
3.1 User Interfaces

The Talend GUI’s are listed below. These offer out of the box functionality for data users, administrators and
developers.
Talend GUI Description
Talend Administration Centre This is a web browser based GUI. It allows an administrator to carry out
activities such as monitor jobs/ log files, conduct housekeeping, execute
jobs, stop/ start of jobs, restart servers, execute a backup strategy,
resource management and so on.
Talend Open Studio Client This is a client that runs on Windows. It allows developers to build MDM
jobs.
Data Steward Console The DSC is a web browser based GUI. It links to the MDM server and
allows data users to perform activities such data validation, merging,
survivorship, de-duplication, reporting and so on. It also allows users to
add, update and delete data. These features are out of the box.
Talend MDM UI This is a web browser based GUI. It allows users to trace data through
workflows, obtain status of jobs and provide reports and statistics.
It can also allow users to view, delete, update and create data records.
Data Quality Portal The DQ Portal is a web browser based GUI. It allows users to execute
reports for BI purposes. These reports can be configured to meet
business requirements.
3.2 Data Model

The Reference data model is presented in the ERD diagram shown below.
Modified: 08/02/2018 01:11 11

CATEGORY
PK Category_ID
Category
SYSTEM
Description
PK System_ID
Creation_DT
System_Name
Last_Update_DT
Creation_DT
Effective_Start_DT
Last_Update_DT
Effective_End_DT
Effective_Start_DT
Authorized_DT
Effective_End_DT
Active
Key
Approval_FL
Classification
CATEGORY_SYSTEM_RELN
Key
REFERENCE_VALUES
PK CAT_SYS_REL_ID
PK Ref_ID
Category_ID
CAT_VAL_ID
System_ID
CAT_SYS_REL_ID
Creation_DT
Ref_Values
Last_Update_DT
Creation_DT
Effective_Start_DT
Last_Update_DT
Effective_End_DT
Effective_Start_DT
Authorized_DT
Effective_End_DT
Publish_FL
Active
Active
Authorized_DT
Total_Levels
Parent_Ref_ID
Level_Num
CATEGORY_VALUES
PK CAT_VAL_ID
Category_ID
Value
Description
Creation_DT
Last_Update_DT
Effective_Start_DT
Effective_End_DT
Authorized_DT
Modified: 08/02/2018 01:11 12

The field level detail is presented in the Reference data model spreadsheet presented below.
Reference Model
specsv0.2.xlsx
The data has been classified as ‘Confidential’ for all attributes in the data model. A definition of this classification
has been provided in section 7.2 of this document.
Note – Any Partner will be considered just like our native source systems and categories specific to partner will
be stored the same way as Galaxy categories in RDM.
3.3 RDM SCREENS

There will be a customized Bonita Form built in Talend to create, update and disable reference data in RDM. For
other operations like viewing reference data in a hierarchical way or approval/rejection of tasks, Talend OOTB
capability will be used by Data stewards and Managers. The responsibilities performed by each are mentioned
below:
 Super user/Manager
1. Will use DSC to approve/reject changes to reference data triggered by Data Stewards.
2. Will also manage the priorities of the tasks raised by Data Stewards based on created dates in
DSC. The Super user will be able to see all tasks/changes and their effective dates so that he/she
can prioritize task based on approaching effective date. Based on this super user will have a high
level overview of all open tasks and their deadlines.
 Data Stewards
1. Will create, disable and update reference data by uploading csv’s for multiple changes from a
customized Bonita Form. This will trigger an integration job to populate RDM tables and will
send email informing changes and category level file(s) to all-consuming systems like DC, CRM
and BizTalk etc.
2. Will use DSC to view RDM data and its dependencies in a hierarchical manner.
3. Using DSC to roll back the changes in RDM and informing all the source systems through email.
4. Authorize the change to all systems via email to all consuming systems mentioning the effective
start date for that change.
Modified: 08/02/2018 01:11 13

3.4 Screen Examples
3.4.1 Process Screen

This will be a customized Form which will be built in Bonita. Talend provides ootb capability to build
customized forms which can be used by Humans to interact with data. This screen will allow Data steward
to upload a fixed format csv file and fill some mandatory fields which will be used to track the task.
PROCESS
Category
Item System
Reference Value
Create
Action
Disable
Update
Input File Browse Upload
Name
Impacted CRM
Systems MDM
DC
Biztalk
Description of the fields mentioned in the form are:

1. Item – Either category, system or reference value can be selected for one category file upload. It
will signify whether there is an addition/modification of category, system or reference value.
2. Action – Either create, update or disable can be selected for one category file upload. It will signify
what operation is being performed on the item.
3. Input file – Data Steward will provide the path of input csv file in this field. Once the form is
submitted, the input file will be placed on the server from where the integration job will pick this
file and RDM tables will be populated.
4. Name – Data Steward will enter the name of Category, system or reference value which is being
added/modified.
5. Impacted Systems – One or multiple systems can be selected. The scope of CR or Business
Approval mentioned in section 3.5.2 will identify which systems are impacted from this change.
After the Steward clicks submit button, the integration job will be triggered to consume the uploaded
file in RDM
Modified: 08/02/2018 01:11 14

3.4.2 View Screen (OOTB)

This screen shows the Talend OOTB capability of viewing reference data in a hierarchical manner. This
functionality is part of Talend MDM UI.
Steps to view reference data hierarchy

o Login into MDM UI which is a web portal providing capability to business users to interact with
the data.
o In the Navigation pane, click Browse -> Hierarchy Explorer.
o We can view child – parent or parent – child relationship between entities.
o In the pivot field select the entity and if there is an existing view deployed for this entity, it will
automatically show up in the view field.
o Click on the pencil icon to select the fields of the entity which you want to see as part of
Hierarchy.
o Click on green add icon to add another entity which be part of hierarchy view with the previous
entity.
o Add the required fields for this entity which you want to see as part of hierarchy.
o Add other entities if you want to see n – level hierarchy.
Please note based on the relationship you have chosen, only entities following this relationship will be
available to select in pivot field.
Below screen shows relationship between category and canonical values.
Modified: 08/02/2018 01:11 15

3.4.3 Tasks Screen (OOTB)

This screen shows the Talend OOTB capability of seeing all the open/pending tasks. . This functionality is
part of Talend MDM UI. Integration job called after ‘Process’ screen will create a new task in DSC for
every file upload automatically.
Steps to view Open/Pending tasks
o Login into MDM UI which is a web portal providing capability to business users to interact with
the data.
o In the Navigation pane, click Govern -> Data Stewardship.
o Based on security/roles assigned, data steward or manager will only be seeing the tasks
assigned in Data Stewardship.
o For all the tasks, some basic information like status, owner and created_dt is displayed
automatically.
o To open a task and see field’s specific to the task, double click the task.
Below screen shows a task ‘Category_Create_Title’ created by ‘administrator’ user which is in ‘new’
status.
3.4.4 Authorize/Rollback Screen

This screen shows the customized capability to authorize or rollback tasks. This is a custom functionality
which will be created by integration job and will be part of Talend MDM UI
When Data Steward or Manager clicks on the task, specific details for that task opens up in a new tab.
Modified: 08/02/2018 01:11 16

Steps to Rollback a task

o Login into MDM UI and then navigate to DSC as mentioned above.
o Double click the task to open specific details of that task.
o The fields being displayed in the task will be defined in the integration job.
o If Data Steward wants to roll back the change, he/she will put true in the rollback field (as it is a
Boolean field) choosing default values from source record.
o When the steward hits save, a talend job will be triggered and all concerned operational
systems will be notified via email by this job.
Steps to authorize a task

o Login into MDM UI and then navigate to DSC as mentioned above.
o Double click the task to open specific details of that task.
o The fields being displayed in the task will be defined in the integration job.
o If Data steward wants to authorize, he/she will put the current date and select default values for
other fields from source record.
o When the steward hits save, a talend job will be triggered and all concerned operational systems
will be notified via email by this job.
The below screen shows how a Data Steward can authorize a change from DSC.
After hitting save, the DSC shows the task status as ‘Resolved’.
Modified: 08/02/2018 01:11 17

3.5 Reference Data
3.5.1 Key Considerations

 Approval_FL flag is maintained at Category level. This signifies whether the change triggered by data
steward requires approval from super user before being committed to RDM. For create/update of
reference data in RDM, this flag will be provided in input file itself as Y or N. If Approval_FL flag is set to
N, change will be committed in RDM else it will be send for approval to the super user. This will be done
by job itself mentioned in section 4 which will create and assign a task to super user in DSC.
 Publish_FL flag is maintained at an intersection table of Category and entity. This signifies whether the
change triggered by data steward need to be published to BizTalk for translating messages between
source systems. There could be some categories specific to MI/partner which does not need to be
published to BizTalk. For create/update of reference data in RDM, this flag will be provided in the input
file itself as Y or N. If Publish_FL flag is set to Y for a category, data steward will notify all-consuming
systems including BizTalk else Biztalk will not be notified.
 An email group will be maintained having all consuming systems point of contacts who will be notified
about the changes.
 Consuming Systems will be CRM, DC, Earnix, BizTalk and MDM. BizTalk will be notified just like any other
source system about the change and they will implement/consume the changes only in downtime.
 The same input file format will be used to create, update and disable reference data. Data Steward will
be allowed to only import one category input file per upload.
 BizTalk will be provided all the active category files in case of any change in RDM but all other systems
like CRM, DC will be provided only delta changes. For e.g. if there are 30 categories in RDM and 10 more
categories get added and 5 existing category reference value changes, then Biztalk will be provided 40
category files but all other consuming systems will be provided 15 category files.
Modified: 08/02/2018 01:11 18
3.5.2 Process
1. Whenever any system wants to create/update reference data/category they will inform Data Office
about the change via email.
2. Data Office will raise a CR and will approve or reject it.
3. If the CR gets approved, then a nominated data steward will either create, update or disable the
reference data.
4. The data steward will upload a csv file with the new/updated reference categories/values through the
Bonita Form mentioned above which in turn will call a Talend integration job to insert/update data in
RDM.
5. Based on Approval_FL set in input file, the change will either be committed or marked for approval. If
the change is marked for approval, it will be committed in RDM only after the Super user approves the
change.
6. Steps related to different scenarios are mentioned below:
Create/Update (where Publish_FL=’Y’)

This scenario explains creating, updating and disabling reference data which needs to be published to
BizTalk for translation of messages between systems.
 Changes will be been done in RDM first through integration job. If Publish_FL flag is set as ‘Y’ in
input file, an email will be sent to all consuming systems including BizTalk describing the change,
category xml file and time window in which they have to implement those changes.
 After receiving confirmation via email from all the consuming systems, Data steward will
authorize the change through DSC as mentioned in section 3.4.4 which will notify all systems via
email about the effective start date of the reference category/value. All the systems will make
the change active based on the effective start date received by data steward.
Create/Update (where Publish_FL=’N’)

This scenario explains creating, updating partner specific/MI reference data which does not need to be
published to BizTalk.
 Changes will be been done in RDM first through integration job. If Publish_FL flag is set as ‘N’ in
input file, an email will be sent to consuming source systems which will be MDM and/or MI
describing the change. If Partner specific category/reference value is updated which MI does not
need to know then only MDM will be notified else MDM and MI will be notified in case MI
category/reference value changes in RDM.
 After receiving confirmation via email from all the consuming systems, Data steward will
authorize the change through DSC as mentioned in section 3.4.4 which will notify all systems via
email about the effective start date of the reference category/value. Informing MI and MDM
about authorization of the change will make sure that MI will only be able to access new
reference categories/values after effective start date.
Modified: 08/02/2018 01:11 19

Rollback
This scenario will occur if any of the consuming systems does not implement the changes within time
window given to them.
 Changes will be been done in RDM first through integration job. If Publish_FL flag is set as ‘Y’ in
input file, an email will be sent to all consuming systems including BizTalk describing the change,
category xml file and time window in which they have to implement those changes.
 If Data Steward does not receive confirmation from any of the consuming systems till a specific
date which will be before effective start date, data steward will not authorize the change and
hence will trigger rollback through DSC as mentioned in section 3.4.4 and all-consuming systems
will be notified about the rollback. It will be source systems responsibility to roll back the
changes.
Modified: 08/02/2018 01:11 20

Please find below process map:
Reference Data Model Create/ Update Process Flow

Downstream
System
Email Request Notify systems Systems respond Notify systems

Notify systems
Change to about the change confirming the about effective start
about the rollback
Reference Data and share xml file changes date for the change
No
Auto
Update
Flagged for
Reference Data
Approval?
RDM
Yes
Trigger
Yes
Yes
Trigger Rollback Authorize change

Manual review
and approve/ Approve?
reject
Email Change by
systems No
CR implemented?
No End No
approved?
Data Office
Yes
End
CR raised
Data Office
Updates
3.5.3 Input File

This section describes the fixed input file format which will be used to create, update and disable reference
categories/values.
title_input.csv
3.5.4 Output File

This section provides the file format which will be shared with BizTalk, DC, CRM etc. in case of updates/creates.
The xml file will be at category level having all the reference values and their mapping between source systems.
AgencyCountryCod Title.xml
e.xml
Modified: 08/02/2018 01:11 21

4 RDM INTEGRATION JOB

Below is the integration job which will read from a csv file and create/update the reference data in RDM. The
output of this job will be an xml file per category file. The diagram also illustrates the audit and error handling
flows/ components and a more detailed description of these is presented in a separate section of this design.
Errors
tFileInputDelimited tFileOutputDelimited
9
1 4 5 7
tDie and
tXMLMap tXMLMap tLogCharacteristics tStewardshipTaskOutput
2 3 6 8
tMDMOutput tMDMInput tMDMOutput
Create a physical log file
MDM Server
The table below describes the data flow and the components illustrated in the diagram above.
Flow # Component Description
tFileInputDelimited This component will read the csv file uploaded on server.
1 tXMLMap The csv file read by tFileInputDelimited is sent to the tXMLMap
component.
This component maps, transforms and route data. It maps the csv format
into the Data Model format in the MDM server. It will parse the fields,
Modified: 08/02/2018 01:11 22

validate the fields, apply business logic/ transformation and map to the
data model structure.
2 tMDMOutput The tMDMOutput component writes to the MDM database.
3 tMDMInput The tMDMInput component reads from the MDM database.
4 tFileOuputDelimited The component will create xml output file at category level.
5 tXMLMap Audit and errors information from the MDM components are handled by
(Errors) the tXMLMap component where they output into the Audit/ Error tables
in the MDM database. The component maps the messages into the
format required by these tables.
6 tMDMOutput The tMDMOutput component writes to the MDM database.
Messages (audit logging) and errors are logged into the Audit tables in
the MDM database.
7 tDie and Process flow 7 & 8 are executed in parallel to 5 & 6.
tLogCharacteristics Audit and error information from the MDM components are handled by
the tDie and tLogCharacteristics component.
tDie is used where a tCatch is used in the component logging message.
The messages are output to physical log files.
8 Log file Folder containing the physical log file.
9 tStewardshipTaskOutput This component will create a task for every run in DSC so that Data
steward can authorize/rollback changes in RDM.
5 MI REPORTING
MI will be directly querying RDM database to fetch reference data. MI work stream will be responsible to pull
reference data whenever they need.
6 AUDIT LOGGING AND ERROR HANDLING

This section describes what error and audit message information should be captured for when Reference data is
created/updated by the RDM solution.
6.1 Audit
The MDM out of the box audit capability will capture creates and updates to the data in the RDM database. The
journal is available through the Talend GUI’s to review.
Additional audit logging of messages passing through the RDM component architecture is required for reporting
and tracking purposes. This will be captured in a customized audit table, created in the MDM database, and
physical log files.
Modified: 08/02/2018 01:11 23

6.1.1 Audit Table

The customized audit tables will capture information about which reference data is created/updated in RDM. A
description of the audit table to be used to capture this information is provided below.
The table will be created in the MDM Talend SQL Server database.
Table Name Columns Data Type Description

seq_num (PK) Integer Primary Key
dateTimeStamp DateTime date and time of reference data create/Update
component_Name Char name of MDM component
Message_Audit
rec_PK Key of the record created/updated
Request_Type Char Create/Update
Source Char Source application making the request
6.1.2 Audit Log File

Audit data will also be captured in physical log files. The log file will be a pipe (|) delimited flat text file where
each row will contain the same information as in the audit table described above and in the same order. The
first parameter (seq_num) will be a uniquely generated number to reference the data row and will not match
the equivalent record in the audit table.
6.2 Errors
Error handling for RDM components is provided out of the box and will be part of the error and alerting
framework.
The handling of errors at message level will require a customized solution, the errors will be captured in error
tables, physical log files and an alert sent through email.
6.2.1 Message Error Tables

Custom errors are initiated at component level and logged into custom tables in the RDM database.
The error table is defined in the table below:
Table Name Columns Data Type Description
seq_num (PK) Integer Primary Key
error_code Alphanumeric Error Code
error_message Char Error message
dateTimeStamp DateTime date and time of reference data create/update
Message_Error
component_Name Char name of MDM component
rec_PK Integer Key of the record created/updated
Request_Type Char Create/Update
Source Char Source application making the request
Modified: 08/02/2018 01:11 24

6.2.2 Error logs

All errors should be logged into a log file. The log file will be a pipe (|) delimited flat text file where each row will
contain the same information as in the error table described above and in the same order. The first parameter
(seq_num) will be a uniquely generated number to reference the data row and will not match the equivalent
record in the error table.
7 SECURITY
7.1 Access Controls

Access to RDM data and components will be restricted to designated users only. At the time of writing this
document, user roles and responsibilities are to be defined by the RSA Data Office and RSA business teams. The
access will be restricted to Data office and Operational teams. The following sub-sections describe where access
controls will be built into the solution.
7.1.1 Network and Platform Security

Access to Talend servers will be restricted to Administrators and Operational staff. Access through external
facing components will require VPN connectivity through the RSA firewall and use of the SSH protocol to secure
all transmissions.
7.1.2 Talend SQL Server

Access to the database server and the schema will be restricted to the database administrator and the server
administrator roles. All default login credentials will be changed when setting up these users.
7.1.3 Talend Log files

The physical log files will be located on the TAC and the MDM Servers (folder location to be provided in the low
level design document). Access to these logs will be restricted to server administers and Talend support staff.
The centralized operational tools will also have access to these logs, where this will be restricted to read-only
access to the folder where the logs reside.
7.2 Data Security

The data stored in the RDM solution has been classified as ‘Confidential’ based on the below definition.
Therefore it will be restricted to users with permission to view. The user roles are to be defined, but it is
expected there will be two groups of users within the Data Office/ Operational teams, they will be the
Managers/ Super Users and Data Stewards. They will be able to gain access the data after undergoing an
authentication and authorization process. This user roles and access security to be defined further in the Data
Office management FDD deliverable.
Modified: 08/02/2018 01:11 25

Level Label Description Relevance to RSA Galaxy
1 Public All publically available information available either externally Public displayed information such
or internally. (Always known as Public) as Support details, Web Content
2 Confidential Data used in normal business processes. The majority of an Customer and commercially
organization’s data would be included in this sensitive data stored within the
classification. Access to this data will require user Galaxy platform
authentication. (Previously and also known as Company
internal use only)
3 Highly Information, whose disclosure could seriously and adversely Financial data delegated to a
Confidential impact RSA. This would be a small subset of an Payment Provider
organization’s data and would include data and transactions
that fall under local regulatory guidelines, including
information security-related legislation.
8 AVAILABILITY
The backup and recovery requirements and approach (aligned to the RSA standards) are being managed by the
Galaxy Operations Architecture team.
At time of writing this design, the backup and recovery solution for the Galaxy estate has not been issued.
However the RDM solution has provided the following guidance.
Item Guidance
Availability  RDM to be available 24 x 7 x 365 (other than at agreed maintenance times and
Requirements subject to unplanned outages) so that it is able to support MI reporting.
NFR’s are still pending sign off at time of writing this requirements, however it is
anticipated that 99.8% is the availability including unplanned outages. This excludes
maintenance period.
For maintenance period, where possible this will be done while system is available
to avoid breaking contractual agreements. But where required, to be agreed before
it needs to be taken down.
 Round-Robin load balancing will be implemented (part of the Talend software
install).
 An Active-Active setup with a Main and DR centre to provide fail over support to
mitigate against component/ server failures.
 Enforce high availability by introducing redundancy and load balancing across
multiple servers (2x TAC servers, 2x MDM servers, 3x Execution servers for each
Active centre).
Backup & Recovery  Weekly full backup (NFR05A.001)
Requirements  Daily differential backups (due to frequency of the data updates and to ensure if
there is any data (user input or physical) corruption, we can roll back to a recovery
point in time - no more than 24 hours as per NFR05A.004).
Modified: 08/02/2018 01:11 26

 Scheduled backups for checkpoint style recovery during migration end to end
processing.
 Additional considerations for ETL parallel environment.
Recovery  Backup process to be designed in such a way as to allow point in time recovery and
the ability to synchronize data in line with all other Galaxy MI components (The roll
forward from the weekly backup can recover data to any point up to the final
incremental backup that was taken).
 The recovery Solution (which will be part of a separate design) to consider both
Operational and Disaster Recovery scenarios as the target recovery methodology
may be different.
 Recovery processing will need to align services with other application servers in the
Load Balanced group.
 Recovery processing will need to align services with other application servers in the
parallel processing environment.
 Component usage to drive backup schedule & minimise SLA impact

 Operational Architecture team have advised that the MDM backups to take place
between 21:00-23:00.
Usage Profile Note: As part of the RDM team’s review comments, the Ops Arch team have been
requested to schedule the backup to commence at 3am daily.
These timings are specified in the Backup and Recovery HLD which will also require
approval from RSA business stakeholders.
9 REQUIREMENTS TRACEABILITY MATRIX
Requirement Requirement Section Require Comments

Typ
Feature # Description ment
e
Met?
As a MDM Tech * Customer Titles 2.2 Met This section defines all the reference
User, I want to (mr/mrs/ms/lord/la data categories which are in scope of
the Master Data dy etc Galaxy and will be stored at a central
Management to * Customer Address location. RDM will be the first point of
be the source of & Post code (e.g. entry/change of new/existing
reference data PAF) reference data which will then be
for operational * Flood/ sustenance notified to all downstream systems.
systems for postcode Consuming systems will manually
Feat nominated regions/codes create/update reference data in their
1124
ure reference data * Occupation systems.
table attribute, (Accountant,
So that the Lawyer, Doctor
MDM service is a * RSA operational
single source for And Reporting
specific Hierachies
reference data * Campaign codes
tables * Transaction Codes
& description (e.g.
Modified: 08/02/2018 01:11 27

MTA, Renewal,
Lapse,
* Cancellation codes
e.g.
* Partner trading
periods
* Referrer ID
As a Data Office * e.g. Partner agent 3.4.1 Met RDM defines capability to
Steward, I want details create/update reference data for
to To have the Partner/MI through a customized
ability for RSA Screen. The file per category has to be
Data Stewards to uploaded one by one.
manage partner
reference data in
RDM via a bulk
import process,
So that any
1810 reference data
Story
tables sourced
form partners
can be
automatically
uploaded into
MDMeither as
part of a
scheduled
workflow or
once approved
by data stewards
As a Data Office * Mass data update 3.5.2 Partially This will be a manual process. Every
Steward, I want * Batch upload met time reference data is created/updated
to Update (daily) in RDM, nominated data steward will
existing inform all impacted downstream
reference data systems including BizTalk giving them
on the fly & giving them specific time window to
build mapping make the changes. Once the changes
relationships to are done and confirmed by all systems,
the relevant data steward will authorize the change
enterprise notifying systems to make that change
systems, So that effective.
1811
Story when reference
data changes the
updates can be
made at any
time without the
need for a
systems release,
so that the new
table can be
scheduled to
take effect from
a specified date
Modified: 08/02/2018 01:11 28

As a Data Office * It is assumed any Met The Data steward will be given option
Steward, I want subscriber to new of choosing Impacted systems while
to Create new reference categories 3.4.1 & uploading the input file. Only the
reference data will need to be 3.5.1 chosen systems by Steward will be
categories configured to notified about the change.
where there is receive the
no downstream reference data
impact, So that
new reference
Story 1812 data tables can
be created by a
data stewards in
circumstances
where there’s no
inter-
dependency
with
downstream
systems
As a Data Office Met The data model stores canonical value
Steward, I want for each reference data which can be
to capture 3.2 & 3.5.2 used to find inter dependencies
canonical between systems to impact the
reference data change. Data model specs mentions
and any about the column supporting this.
mapping
associated to the
relevant
Story 1158.1813
enterprise
systems, So that
when creating a
changes request,
I can clearly
articulate inter-
dependencies on
downstream
systems
As a Data Office 3.2 Met Data model supports multi hierarchy
Steward, I want reference data. The entity reference
to to have the values can store n- level hierarchies.
ability to build
relationships
and hierarchies
1814
Story on reference
data , So that I
can provide
multi-
dimensional
insight
As a Data Office 3.2 Met We are maintaining versioning of

Steward, I want reference data with effective start and
to have a full end dates to meet this requirement.
1815 audit trail
Story
capability across
all reference
data
management
Modified: 08/02/2018 01:11 29
activity, So that I
can track
changes in
reference data
and can report
on transactions
based the
reference data
effective at given
point in time
As a Data Office 3.2 Met We are maintaining versioning with
Steward, I want effective start and end dates to meet
to set reference this requirement.
data to be
effective from a
given start & end
1816 date, So that I
Story
can report on
transactions
based the
reference data
effective at given
point in time
As a Data Office Not met PAF is not in scope of RDM.

Steward, I want
to automate an
overnight Batch
to update e.g.
Specific
reference data
such as Postal
Feat
1817 address files
ure
(PAF), So that I
can
automatically
update
reference data
tables that
require frequent
refresh
As a Data Office Partially RDM will inform consuming systems
Steward, I want Met including BizTalk by sending fixed
to RDM to 3.5.2 format xml file per category to update
publish any in their config manually. RDM cannot
changes out to make config changes in other systems.
relevant
enterprise
systems
Feat
1818 whenever they
ure
have been
approved, So
that changes
made to RDM
reference data
can be
automatically
uploaded in
Modified: 08/02/2018 01:11 30
downstream
systems avoiding
the need for
multiple
updates.
As a Data Office 3.5.2 Met The data governance process will

Steward, I want ensure that all the systems are aligned
to coordinate before any change becomes effective
approvals of across the enterprise.
changes to
1819
Story reference data
using a workflow
process , So that
I can trigger real
time updates
As a Data Office 2.2 Met This category is in scope of RDM.

Steward, I want
to master
transactions
codes and
description (e.g.
1793
Story MTA, MTC,
LAPSES etc.), So
that all
transactions fall
into definitive
categories
As a Data Office 2.2 Met This category is in scope of RDM.

Steward, I want
to master
cancellation
codes and
1794
Story descriptions, So
that we have a
definitive list of
reasons for
cancellation
As a MDM Tech 2.2 Met This category is in scope of RDM.

User, I want to a
reference table
listing all
Campaign codes
adopted during
the life time of
1758 the
Story
product/scheme
/agency, So that
I can track and
monitor the
efficacy of
campaign codes
and ensure that
any fulfillment
Modified: 08/02/2018 01:11 31

promised to the
customer is
honored
As a MDM Tech * e.g. PAF look up Not met Not in scope

User, I want to a * Each system
single customer should look up the
address look up PAF file in real time
facility , So that I (CRM, DC, CCS) - this
have a requirement has a
consistent dependency on
1759
Story approach to other systems.
applying
addresses held
in the quote and
policy DC system
and other
systems (CRM,
Web,UFE)
As a MDM Tech E.g. Dr, Mr, Miss, 2.2 Met We are capturing title reference
User, I want to a Mrs, Ms, Lord, Lady, category
definitive list of Rev,
customer titles
acceptable in DC
, So that all
1761 analytics
Story
involving
customer title
are based on a
standard RSA
customer title
list
As a MDM Tech Fixed Depth 3.2 Met Data model supports fixed depth
User, I want to Hierarchy hierarchy.
The ability to
support a data
hierarchy with a
1762 fixed number of
Story
levels, So that
RSA can define
filtering criteria
at any level of a
hierarchy
As a MDM Tech Multi-Parent Not Met Multi – parent hierarchy is not

User, I want to Hierarchy delivered in Galaxy scope.
The ability to
support a data
1763 hierarchy with
Story
one or more
parents for a
given node, So
that RSA can
attach / detach
Modified: 08/02/2018 01:11 32

nodes to/from
multiple parents
As a MDM Tech Single Parent 3.2 Data Met Data model supports single parent
User, I want to Hierarchy Model hierarchy.
Single Parent
Hierarchy, So
1765 that I have the
Story
ability to support
a data hierarchy
with exactly one
parent for any
given node.
Modified: 08/02/2018 01:11 33


RSA - MDM Reference Data Functional Detailed Design v0 2

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

RSA - MDM Reference Data Functional Detailed Design v0 2

Încărcat de

Drepturi de autor:

Formate disponibile

RSA – MDM REFERENCE DATA

RSA – MDM REFERENCE DATA Functional Detailed Design v0.2

Modified: 08/02/2018 01:11 2

1.2 Revision History

June 2016 V0.1 Draft R. Ghai/ S. Khela

1.3 Document Approvers

1.4 Document Reviewers

Modified: 08/02/2018 01:11 3

Susan Middleton Integration

1.5 Referenced Documents

Name Accenture SharePoint Location

Talend MDM Best Practice Guide https://ts.accenture.com/sites/RSA_Transformation/Delivery/Data%

RSA GALAXY – Data, MI, MDM and Analytics - https://ts.accenture.com/sites/RSA_Transformation/Delivery/Data%

Modified: 08/02/2018 01:11 4

Data Architecture Glossary.docx https://ts.accenture.com/sites/RSA_Transformation/Delivery/

Modified: 08/02/2018 01:11 5

AIP Accenture Insights Platform

Modified: 08/02/2018 01:11 6

2.1 Data Insight Architecture

Batch and Real Time Extracts Advanced Analytics Partner Portal

Home D4P Home D4P Motor D4P

Europa Experian 68 Feeds from ~20

Modified: 08/02/2018 01:11 7

Modified: 08/02/2018 01:11 8

Reference Data ID Category Scope Reference Data Category

Modified: 08/02/2018 01:11 9

23 MI Flood/ sustenance postcode regions/codes

Modified: 08/02/2018 01:11 10

3 INTERFACE DETAILED DESIGN

3.1 User Interfaces

3.2 Data Model

Modified: 08/02/2018 01:11 11

Modified: 08/02/2018 01:11 12

3.3 RDM SCREENS

Modified: 08/02/2018 01:11 13

3.4 Screen Examples

3.4.1 Process Screen

Input File Browse Upload

Description of the fields mentioned in the form are:

Modified: 08/02/2018 01:11 14

3.4.2 View Screen (OOTB)

Steps to view reference data hierarchy

Below screen shows relationship between category and canonical values.

Modified: 08/02/2018 01:11 15

3.4.3 Tasks Screen (OOTB)

3.4.4 Authorize/Rollback Screen

Modified: 08/02/2018 01:11 16

Steps to Rollback a task

Steps to authorize a task

Modified: 08/02/2018 01:11 17

3.5 Reference Data

3.5.1 Key Considerations

Create/Update (where Publish_FL=’Y’)

Create/Update (where Publish_FL=’N’)

Modified: 08/02/2018 01:11 19

Modified: 08/02/2018 01:11 20

Please find below process map:

Reference Data Model Create/ Update Process Flow

Email Request Notify systems Systems respond Notify systems

Trigger Rollback Authorize change

3.5.3 Input File

3.5.4 Output File

Modified: 08/02/2018 01:11 21

4 RDM INTEGRATION JOB