IFP MDM Preliminary Research

InfoPower MDM Solution Preliminary Research & Planning ** MDM Concepts and Market Overview **

Author: Patrick de C Customer: Internal

IFP Confidential

Document: Subject:

80652843.doc MDM Planning

Date: 2012-01-08 Version: V1.1 Page 1 of 67

Document HistoryDocument HistoryLast Updated Time: 2009-02-02 Version Number 1.0 Modification Modification Description Date 2009-02-02 Initial Version Author P de C Notes

AuthorizationThe document needs to be approved by the following people Name Title/Role

DistributionThe document is distributed to the following people Name Title/Role

Document: Subject:



Table of Content1. Introduction...........................................................................................................3 2. The MDM Concept...............................................................................................52.1 MDM Definition.........................................................................................................................5 2.2 Use Cases for MDM Solutions.................................................................................................6 2.2.1 Operational Use Case.......................................................................................................6 2.2.2 Analytical Use Case..........................................................................................................6 2.2.3 Collaborative Use Case.....................................................................................................6 2.2.4 Hybrid Use Case...............................................................................................................6 2.3 Architectural Styles of MDM Solutions.....................................................................................6

3. MDM Market State, Players and Opportunities................................................93.1 Requirements for MDM Solutions............................................................................................9 3.2 Current State and Evolution of the Market...............................................................................9 3.3 Main Players on the MDM Market and their positioning.........................................................11 3.4 MDM Solutions Architectures Examples................................................................................15 3.4.1 TibCo CIM Screenshot....................................................................................................15 3.4.2 DataFoundations OneData Architecture..........................................................................15 3.4.3 Sun MDM.........................................................................................................................16 3.4.4 Amalto Xtentis Architecture (all XML standard)...............................................................16 3.5 MDM Solutions Offers Key Exerts.......................................................................................17

4. SWOT Analysis for InfoPower MDM..................................................................19 5. Basic Requirements for InfoPower MDM...........................................................21 6. APPENDIX 1 Kalido MDM Example...............................................................256.1 Main Features of Kalido MDM................................................................................................25 6.2 Main Roles and Functionalities..............................................................................................25 6.3 Kalido MDM Strengths and Weaknesses ...........................................................................26 6.4 Kalido MDM Specific-Concepts..............................................................................................26 6.5 Kalido MDM Features through Screenshots..........................................................................28

1. IntroductionIn the past months, preliminary discussions have been held concerning the potential development of an InfoPower MDM solution. As a result of those discussions, research efforts were carried out to gain a better understanding of the MDM concepts and its market, but also to try and find out the relevant positioning for an InfoPower MDM solution.

Document: Subject:



This document is not only the result of a one-month research period, but also of experience gained while implementing Data Warehouse projects and MDM projects, in particular the on-going MDM project for Johnson & Johnson Medical China. Its goals are multiple: 1. 2. 3.4.

to align everyones understanding of MDM to share findings and current understandings of the MDM market to justify (or not) the adoption of an MDM initiative by InfoPower to start devising features requirements and design guidelines, as a first draft more importantly, to pave the way for future discussions and steps, should a decision be made to go ahead with the project.

5.

We will first start with a definition of MDM and the major concepts associated with it. Note that since the MDM market is still in its infancy those definitions are evolving quickly. The second part of this document will provide information about the MDM market, delving into the details of the strategies followed by the main actors in this field. We will use this market analysis and the conclusions derived from it to perform a SWOT analysis (note that the internal part of it is based on a subjective understanding of our situation and that the bulk of the analysis is very much a work-in-progress) to determine if building an MDM solution is feasible for InfoPower. The positive outcome of this analysis will lead us to a consideration of our potential positioning in this market. In light of all this, generic requirements for an InfoPower MDM solution will follow, with prioritization. A detailed description of the Kalido MDM solution is also provided for reference in Appendix 1, as an example of a leading MDM solution.

Document: Subject:



2. The MDM Concept

2.1 MDM DefinitionThe MDM concept can be broken down into its main constituents:

Master Data: These are NOT transactions, these are NOT metadata, but rather, these could be qualified as the contexts that structure transactions. For example, a $500 invoice is issued on a specific day by a department for a customer and references several products. A $100 expense is assigned to an Account (Chart of Account), and a Sales rep (Organization). Most common Master Data are Product, Customer, Chart of Account, Organization, and Supplier. One of the essential characteristics of Master Data is that it is replicated in many systems. Master Data Management: A way to provide consistent, comprehensive core information across an enterprise. At its simplest, the MDM is a registry to handle mappings between records duplicated in several transactional systems. At its highest level of complexity, it is a single system of record and system of entry where all master data is entered and maintained, before being dispatched to target systems. The major management features that MDM solutions provide are: Compliance (auditability and traceability for SARBOX and BASEL) Security through authentication and access controls Management of data enrichment and/or creation and maintenance of master data Management of integration with source and target systems (through mappings and links to web services) Data Quality Management through workflows and business rules Identity management being an important part of this. Master Data Lifecycle Management (through version control, historytracking and/or workflows) Management of multiple contexts or branches across the company

Note: Gartner separates the MDM market into two segments: Customer MDM (CDI) Products MDM (PIM) The differentiation comes from the fact that the Products MDM solutions are usually heavily focused on workflows and BPM so that the whole product lifecycle can be managed in a collaborative manner (for instance for New Products Introduction). CDI has more focus on cleansing and managing the integrity of customers which come from

Document: Subject:



different systems (ie. IBM in one system, International Business Machines in another, and I.B.M. in a third system). Initially, MDM actors were specializing in one of these two markets, but the trend is more and more to provide generic MDM capabilities, as suggested by the MDM market study.

2.2 Use Cases for MDM Solutions 2.2.1 Operational Use CaseMDM is focused on feeding transactional systems, usually in real or near real-time. This is usually delivered through SOA (Service Oriented Architectures). (example: near real-time customer data hubs and securities masters)

2.2.2 Analytical Use CaseMaster Data Management is focused on master data analysis or especially tailored to feeding a Data Warehouse. Examples: Financial reporting such as global spend analysis or chart of account consolidation, master data created for the Customer dimension in Data Warehouse

2.2.3 Collaborative Use CaseDefinition, creation, and synchronization of master reference data via workflow and checkin / check-out services; examples: product information management (PIM) data hubs and anti-money laundering (AML).

2.2.4 Hybrid Use CaseThis is a combination of two or all of the above types.

2.3 Architectural Styles of MDM SolutionsThere is no consensus in the Market about the naming conventions for those architectural styles. A mapping between the terms used by several vendors and market research companies has been established for information, with the hope to clarify a bit.

Document: Subject:



Following are some possible definitions for the MDM architectural styles (most of them according to Gartner):

Consolidation Style The consolidation style has a physically instantiated, "golden record" single view of master data stored in the central hub. This usually supports reporting; however, it can also be used for reference operationally. If used for reporting, then it may be referred to as a downstream "system of reference" for reporting needs. The golden record is constructed by standardizing, cleansing, matching, linking and merging master data from multiple sources, where they continue to be authored, and assigning a unique global identifier. However, this record is not guaranteed to be up to date. There is no explicit desire to clean the source data.

Registry Style This MDM approach holds a central registry of unique identities and a reference mapping to the participating applications that own entities. The application systems are still the master systems of record. This architecture style rapidly matches similar records across and within dispersed data sources, links them and maintains their cross-reference links back to sources.

Coexistence-Style (or Hybrid): The coexistence style physically instantiates a golden record in the central location of master data, and additionally harmonizes the master data across other even remote sources or data repositories. The golden record is constructed in the same manner as a registry or transaction style, and, as remote data sources themselves take on roles of authorship and validation, and evolve into multiple transactional or registry hubs. However, the key difference is the concept of a central system that publishes selected master data out to the subscribing spoke systems. This style

Document: Subject:



includes a set of workflow processes, based on middleware infrastructure, which has the effect of harmonizing the consistency of the master data across the various systems. MDM Hub (or Transaction-style architecture) The transaction-style hosts a central, physically instantiated, single version of the truth for master data. Upstream, transactional applications can read and write master data to the new system, and, potentially, all spoke systems subscribe to updates published from the central system in a form of harmonization. This style often evolves from the consolidation and coexistence styles. In a similar way, it physically instantiates a golden record single view of master data in the central database; however, the key difference is that the master data is authored in the center. The transaction style is the one most likely to be designed for an SOA environment, exposing a layer of business services that are consumed by new SOA applications and wrapped applications.

Example: Microsoft (ex-Stratature) MDM Repository Architecture

Document: Subject:



3. MDM Market State, Players and Opportunities

3.1 Requirements for MDM SolutionsSource: MDM Institute Third generation MDM Solidified Requirements SOA / Shared services architecture with evolution to process hubs Strong hierarchy management High-performance Identity management Data governance-ready framework Persisted, registry and hybrid architecture flexibility

Evolving Requirements for 4th generation MDM Multi-Entity MDM Process/policy hub architecture Unstructured information support Integrated data governance Enterprise search

3.2 Current State and Evolution of the MarketAccording to Gartner: MDM for customer master will hit $1Billion in S/W revenue by 2012 With PIM & other domains, it could be over $2 Billion.

According to Forrester: $344 Million total MDM S/W market size (not including services) in 2006 MDM anticipated growth to over $2.2 Billion by 2010

Overall, the MDM Software market should grow to around $2 Billion in 2012.

Document: Subject:



The aggregate enterprise MDM market (customer & product hubs, plus systems implementation services) totaled US$730 million at Year End 2007 and will reach US$2 billion by the end of 2012. Software sales are but one portion as MDM systems integration services reached US$510 million alone during 2007 and are projected to exceed US$1.3 billion per year by 2012.

Document: Subject:



IBM and its acquisition of an MDM vendor has been a major reason for the MDM market to go global so fast. Note that Asia-Pacific MDM sales are going to be multiplied by about 7 between 2008 and 2012. Markets like China or India are not tapped yet and might have great potentials.

3.3 Main Players on the MDM Market and their positioningThe following materials are derived from market information provided by Gartner as well as the MDM Institute. In some cases, the author of the present document might have added information. A lot of consolidation and evolutions are taking place within the MDM market; this overview of the major players can be deemed relevant as of 2008. The Key Facts column tries to provide the most relevant information concerning the Player. The Products positioning focuses on the Product aspects. It has been kept simple to focus on the most important aspects, but could be complemented with a detailed list of features. The Geographic Coverage does not focus on the players strategy or plans, but rather on the actual state of the geographic development as of 2008. Major players such as IBM or Oracle have been deemed to have a World focus, due to their size, but that may not depict well the current reality. Positioning Actor D&B Purisma Key Facts Leverages Duns & Bradstreets Customer base: MDM integrated to Duns & Bradstreet data services Leverages SAS infrastructure (quality tools and data integration) while keeping autonomous. Client strategy to start small with data quality tools, then evolve with full-fledged MDM. MDM strategic to IBM. Leading customer MDM in retail banking and insurance. Several products not well Product Customer MDM: mostly B2B for now, trying to sell more B2C Geographic Coverage Mostly in the US

SAS DataFlux MDM

Focus on customer master data, but evolutions planned

Mostly in North America, moving to Europe

IBM (InfoSphere MDM)

Data Domains: Party (Customer), account and product (but mostly for operational use

World

Document: Subject:



Actor Key Facts integrated make their strategy complex and confusing (eg. for workflows need to add a product). Initiate Systems Best-of-breed MDM player, with focus on Party data (customer, patient, citizen, organization). Strength in healthcare-related markets (providers, insurers and retail pharma). Leader in enabling data exchanges among multiple organizations. Focus on operational MDM, weak in analytical MDM. MDM strategic for Oracle.

Positioning Product case and simple). Not very flexible in terms of iterative and customized MDM Geographic Coverage

Specialist of CDI (customer MDM): mostly B2C, increasing in B2B. Flexible architectural styles (registry style or hub) and data models.

Mostly US, little in Europe

Oracle MDM

Currently, 3 products: Oracle CDH (for manufacturing, high-tech, retail and distribution), Oracle Siebel UCM (for telco, media, utilities, large-scale retail, financial services and government), and Hyperion MDM (deprecated). Building a multi-domain MDM product called Fusion. Mostly relevant for Oracle-centric customers. SAP NetWeaver MDM Loyal customer base from SAP looking for integrated solutions. About 200 clients in Q1 2008. MDM is a key part of NetWeaver, and next 3 years will see MDM integrated with Netweaver applications. Mostly for SAP-centric companies. Not very well integrated in SAP vision for now. Comprehensive, flexible MDM platform that can support virtually any MDM implementation regardless of the subject area or preferred80652843.doc MDM Planning

CDH and UCM are mostly Customer MDM. Fusion MDM will be multi-domain. UCM has different tools (eg. for Data Quality) with poor integration.

World, but not available yet

MDM for products, customers, supplier and employee. Analytical MDM for customer/party. Operational MDM for supplier/product. Wide range of MDM requirements met. BO integration will be leveraged for Data Quality, profiling and reporting. Flexible, integrated, metadata-driven, rulesbased MDM platform. Multiple domains of data can be modeled,

World

Siperian MDM

Mostly US and Europe

Document: Subject:


Actor Key Facts architectural style. Good performance in life science industries (eg. JJ) and financial services. Strong customer loyalty, and good track record in product innovation. Perceived as pharma-centric. SOA oriented, so new functionality can be added through web services. Main weakness: user interface too programmer oriented Sun MDM

Positioning Product Geographic Coverage

eg. multiple types of party, product, location and reference data. Any kind of data can be modeled, but the tool comes with pre-built standard industry data models.

Based on SeeBeyond technology. Open Source (Mural community). Healthcare and government centric. Inability to invest due to poor company financials. Tibco CIM Operational and Collaborative MDM. New solution with few references. Started with Product Data, but expanding into customer, supplier and employee domains. Started in 2002. Multidomain MDM, with flexible data model and businessfriendly presentation of master data Early success in CPG industry (product and supplier data), now customers in government and other industries. Amalto Technologies Xtentis MDM I2 MDM French company with a few customers in France and the US. Developed a product based on open source technologies (XML DBMS) Recently gave rights to Teradata to use their source code. Seem to be moving

Mostly Customer master data (Sun Master Index and Sun Master Patient). Support for SOA. Flexible data model. Good probabilistic matching and data stewardship. No formal CDI solution. Architecture fitting well with real-time and SOA. Full lifecycle and process flows for multientity support.

Data Foundations OneData

Multi-domain MDM with flexible model. Can build own data model or use templates provided. SOA support. Sophisticated hierarchy management Virtual repository

US, Europe and India

Multi-domain MDM, mainly for operational use cases. No embedded data quality.

France, US

Document: Subject:



Actor Key Facts out of MDM and re-focusing their efforts on SCM Kalido MDM Business-model driven MDM, mostly for analytical use cases. Some clients extend their solutions to operational use cases. Microsoft MDM

Positioning Product Geographic Coverage

Multi-domain MDM, with visual business modeler. Process flow and workflow engine. Model flexible. Time variance support for change management. (Stratature): Multidomain MDM, initially focused on analytical use cases. Strong hierarchy management. Integration with Microsoft software (ie. MS Dynamics ERP and CRM)

World

Microsoft purchased Stratature in 2007, and is willing to re-launch it integrated within next version of MS Office and Sharepoint server in Q3 2009. Low TCO to be expected. Inherited from I2 MDM technology. Re-worked and v2.0 on the market in Q1 2008. Sold to Teradata customer base, as part of Data Warehouses. Analytical MDM, with operational implementations as well.

World

Teradata MDM

Multi-domain MDM, analytical and operational.

World

Document: Subject:



3.4 MDM Solutions Architectures ExamplesThese Architectures have been extracted from publicly available presentations and are shown to provide ideas and examples of existing and possible MDM solutions architectures.

3.4.1 TibCo CIM Screenshot

3.4.2 DataFoundations OneData Architecture

Document: Subject:



3.4.3 Sun MDM

3.4.4 Amalto Xtentis Architecture (all XML standard)

Document: Subject:



Xtentis Technical Architecture

3.5 MDM Solutions Offers Key ExertsOverall, several factors can be used to segment the MDM market: Geographic coverage: World or specific continents or even countries Specific MDM domain or multi-domain (the latter being the trend) Background of the company: best-of-breed MDM (Siperian, Orchestra, Intitiate, DataFoundations), DI or DQ background (SAS, WebMethods EOMing Orchestra, Cordys, I2), data provider background (D&B), software infrastructure and data management background (Oracle, Microsoft, IBM, SAP, Sun), DW/CPM background (Teradata, Kalido, Hyperion) Use cases supported: Operational, Analytical and/or Collaborative Architectural styles supported (being able to support all is one of the requirements for a comprehensive MDM solution) Primary Markets targeted: eg. retail, telco, pharma, insurance, government, CPG, etc.

Document: Subject:



Most best-of-breed MDM vendors only have presence in the US and Europe for now. Data integration or DQ vendors are mostly focused on customer MDM and the DI/DQ part of MDM. Their strategy is usually to first sell their DQ products, and then to evolve from there. Giant software infrastructure and data management players are for most of all currently refining their MDM strategies and performing important restructuring of their products. Oracle is building a single multi-domain MDM solution (merging its 3 MDM solutions into one they might keep two solutions running in parallel though), Microsoft prepares to issue its new MDM solution as part of their next Office/Sharepoint release (currently planned for Q3 2009), IBM is perceived as too complex with a confusing product strategy (the author is not informed of the steps they are taking to reduce that complexity should they be willing to), and SAP MDM is perceived as SAP-centric and still has a lot of work to do to make their MDM product fit within their Netweaver strategy. Companies with Data Warehouse / CPM background players are mostly selling Analytical MDM as part of their Data Warehouse strategy. Few companies are actually using Kalido DW products, and Teradata is reserved to a market with significant investment capacity in DW/BI. Finally, the author believes there are a few interesting best-of-breed players for us to look at: Siperian MDM, Orchestra Networks (which partners with WebMethods to provide SOA and workflows) and Extentis MDM. Microsoft MDM, once available, will be an important player to consider as well. Those players are still rather small but have built interesting MDM solutions in terms of positioning or technology. In particular, Siperian has developed a product which has earned awards in the MDM industry and is getting implemented in companies such as JJ Health Care, Pfizer and Astra Zeneca. About technology, Orchestra Networks and Extentis are taking innovative, fully SOA-compliant initiatives which may be worth taking a look at.

Document: Subject:



4.

SWOT Analysis for InfoPower MDM

To conclude this SWOT analysis, it seems there is a window of opportunity that InfoPower could take advantage of:

Most potentially serious MDM challengers on our markets (ie. pharma in China or Asia) are still struggling in the US or Europe and are not developing in Asia Pacific. MDM solutions on other continents are still in their early stages and may not be ready for rollout to the whole world, especially considering the significant investments they might represent. We have a strong presence in the pharmaceutical industry, and know of a strong demand for MDM there.

Document: Subject:



In terms of positioning, the following considerations should be observed:

We will position on market segment niches, according to perceived demand and our knowledge of the markets. The first niche that should be considered is the Pharmaceutical industry. InfoPower MDM solution will be multi-domain from its start. To account for future evolutions, our solution should be customizable. Users should be able to manage subjects and add new subjects through a metadata management interface. To enable fast implementation, data model templates for example for Pharma industry - will be deployable with a few mouse clicks. InfoPower MDM shall be SOA-compatible from the start. This probably means that it should be built on top of an SOA platform (eg. Open Source SOA). To take into account the Window of Opportunity, a first solution should be available and marketable by July 2009. InfoPower MDM shall be marketed as a low to mid-cost MDM alternative In terms of use cases, InfoPower MDM will be mostly focused on Analytical and Operational use cases. Limited workflow functionalities will be available in the first release. Through the inclusion of open-source workflow and BPM tools in InfoPower MDM, collaborative MDM will be possible after customization. As for which Architectural Styles will be available, decisions still have to be made in this area.

Document: Subject:



5.

Basic Requirements for InfoPower MDM

Please note that the following list of requirements is still evolving. It is firmly believed that the InfoPower MDM solution should be planned and designed right from the start, with all features required by modern MDM solutions. All basic features should exist in the first solution available, but more or less developed (ie. some features might exist but in an embryo form).Requirement #1: A Flexible Data Model with Templates by Industry (Pharmaceutical to start)

Based on InfoPower experience with industry sectors, Data Model templates will be created. They should be deployable through a web management interface within a few clicks, and should be customizable. Possibility to create new models from scratch MDM key subjects like COA, Products, Customers, Suppliers, and relationship tables Time-sensitivity of records

Requirement #2: A Flexible and powerful Hierarchy Management

Flexibility to view data in hierarchical mode or flat mode Supports for 3 models of hierarchies: Rules-based hierarchies User-defined hierarchies Hierarchies imported from other tools Support for Multiple hierarchies (ie. merchandising hierarchy vs. internal product hierarchy) Support for Parent-child hierarchies, including ragged, unbalanced hierarchies (ie. Bill of Material) Features for search within hierarchy Drag and drop of hierarchy members

Requirement #3: An integrated and configurable web interface for users and Administration

Configurable Search and Browse features Possibility to switch between several record viewing modes (eg. tabular, classic, hierarchy mode, Search & Display) Dynamic Search functionality: users can choose the fields they want to use to search information

Requirement #4: Lifecycle Management through Version Control

Version Control For instance possibility to save a masters state on 2009-01-01 and 2009-02-01

Document: Subject:



Possibility to compare the 2 versions and show the changes (compare & merge)

Requirement #5: Tight Security

Roles Creation and user mapping Row-level authorization Column-level authorizations Subject-level authorizations Operations authorization (ie. read / write / admin) Authentication through LDAP system or internal repository

Requirement #6: Business Rules Management

Centralized interface to manage all Business Rules XML technology templates (ie. XSLT) for basic business rules such as regular expressions, enumerations and referencing other dimensions Basic Editor to create simple business rules Possibility to call external Web Services, executables or java programs for validation Possibility to override business rules when loading data and to validate in batch later Examples of business rules: for a category of products, price should be between 10 and 20 referential integrity minimum value, maximum value for a record minimum number of occurrences, maximum number of occurrences for a record If distributor type is Hospital, restrict a value to Level abc of product hierarchy can only have one parent If Field F1 is changed, start workflow W1 If Field F2 is changed, send an alert

Requirement #7: Auditing and traceability

All updates to the MDM application, including sessions information, should be logged by a comprehensive audit trail Data items should have a time-variance feature, enabling to view history of changes on that piece of information

Requirement #8: Support for Contextual Master Data

For instance, generic products are defined by HQ Each country might need to change their labels, name language or price Countries or regions should inherit the common products attributes and properties and override some of their properties / de-activate some, add labels,

Document: Subject:



Requirement #9: Support for Basic Workflow Functionality

Plan an Inbox for users to receive workflow-related messages

Requirement #10: Import and Export of Data

From/To CSV, TXT or XML

Requirement #11: SOA support

Exposure of data as inward and outward web services Inclusion of MDM processes in a whole BPM process (ie. for New Product Introduction flow processes)

Requirement #12: Bulk Operations

Bulk update of data Bulk change of access rights in data items

Requirement #13: WAP Access

For rollouts in the Pharmaceutical industry, the MDM solution should be searchable and updatable through handheld phones.

Requirement #14: Basic Data Cleansing and Reconciliation Functionalities

-

Probably available through Web Services (integrated ETL or Java classes) or via specific Java classes or ETL programs For instance: match and consolidate two customers who have differing elements but enough common elements to determine they are the same

Requirement #15: Reporting Functionalities

-

Ad-hoc querying functionalities Report generation and export in different formats Can be performed through the integration of an external BI tool

Document: Subject:



APPENDIX

Document: Subject:



6.6.1

APPENDIX 1 Kalido MDM ExampleMain Features of Kalido MDM Web-interface with Search, Browse (tabular view, classic view, hierarchical view), add new, Edit and Delete interfaces Web Management interface based on same web platform to define Master Data Structures (based on XML and XLST) and control the menu items shown by user role Auditability and traceability enforced through audit tables capturing all events, and time variance of selected records Records Validation: Validation enforced through regular expressions, data types (eg. predefined enumerations, reference to a specific item in another dimension, drilldown to enable drill down to another dimension, predefined ranges), minimum and maximum length, minimum and maximum occurrences, code auto-generation Security Control by roles with Read Access / Write Access and Control Access Workflows for collaborative data validation and approval Hierarchy Tree-based Search and Browsing Import features from csv files / XML Export features to flat files / XML Data Mapping functionalities inside the MDM application Version control through the setup of contexts

6.2

Main Roles and FunctionalitiesData Consumer Read only access to shared master data Anonymous access to public published output Search, browse, contact data owners Data Provider Edit content Match related master data items Authorize & submit for publication Administrator Setup Workflow

Document: Subject:



Design or import the Business Model Amend the Business Model

Data Acquisition File Loaders Import model and data from DIW API for EAI connection Publish and Export Published output in XML/XTM File export API for EAI broadcast Export for DIW load

6.3

Kalido MDM Strengths and Weaknesses

6.4

Kalido MDM Specific-Concepts

Kalido MDM uses the concepts of Catalogs, Categories, Hierarchies, Subjects and Templates. A Catalog is an area for storing homogenous data. Example: CONTINENTS A Hierarchy of catalogs can be defined to group data. CONTINENTS -> REGIONS -> COUNTRIES A category is a grouping of subjects with a common set of validation rules which are contained within a template (eg. Locations, Products, Customers). Subjects can be validated against the Categories Templates but may be inserted even if not validated against the category rules. Subjects are the instances of data within a category. Subjects need to conform to a category template (eg. a person, a product, a location, a customer). A template contains the rules of a category for records to be validated against. The template contains the category attributes and their associated definitions. The template is defined when creating a new category. For example:

Document: Subject:



Category: People Template: Name: text Tel: numeric Email: text Company: reference to another Category Manager: text (mandatory) Records are the information held within a subject. A record contains the values for attributes. Eg: Subject = J Smith Record: Name: J Smith Tel: +1 555 34598 Email: [email protected] Company: Alloway Trading Manager: (Unknown) Contexts are defined to hold different versions of the Master Data (Categories, Templates, File Feeds, Workflows, Subjects, Records, Catalogs, Export Feeds, and basic search are all context sensitive) Example: Publish product data every quarter, put Product data in one context and Customer data in another

Category

Subject

People

J Smith

Templates People V1 Tel Email Employer Numeric Text Link to Organisation

Contexts ! Organization v1 Tel Email Employer J Smith (V1) +1 555 34598 [email protected] Unileever

People V2 Tel Email Employer Manager Text Text Link to Organisation Text (Mandatory) Organization v2 Tel Email Employer Manager

J Smith (V2) +1 555 34598 [email protected] Unilever M Brown

Document: Subject:



6.51.

Kalido MDM Features through Screenshots

Browsing and Searching Features

Browse main page

Sub-menus

Search

Search Results

Document: Subject:



Advanced Search

Advanced Search Results

Document: Subject:



Browsing by Catalog Basic View

Browsing by Category

Document: Subject:



Subjects in the Category ISO Continent

Browse by Category Tabular View

Document: Subject:



Viewing Category Subjects in a list (Country Code, Capital And Region Parent defined as display attributes) 2. Create, Edit and Delete Features

Create New Product from Catalog View

Document: Subject:



Add New product (required attributes have a red *)

Edit Product

Document: Subject:



Edit Product Interface

Delete Data

Document: Subject:



Delete Confirmation

Add a New Category

Document: Subject:



Create a new catalog 3. Interface Customization Features

Configuration Options for Menus

Document: Subject:



Generic Configuration

Menu Set Customization

Document: Subject:



4.

Hierarchy Browsing

The Hierarchy Browsing mode can be chosen to show the Catalogs hierarchy. View details of subject in right pane

To display Search pane

Catalog hierarchy browsing

Search window to filter the hierarchy

Document: Subject:



Hierarchy Tree filtered view

View details of the subject highlighted in left pane

Document: Subject:



Drag and drop subjects

Right-click menu

Document: Subject:



5.

Data Validation

Define Attributes that will create the Category Template

Data validated against Category template.

Document: Subject:



Note that data can be inserted overriding validation rules. Then one can launch the validation process and edit the data.

Click Edit

View Category Template

Edit Category Template .

Document: Subject:



6.

Workflows

Define a workflow

Create New Worlflow

Document: Subject:



New workflow definition window

Document: Subject:



Add State transition

Add Another State

Document: Subject:



Add Timeout for how long the item should stay in a state

Define Events

Document: Subject:



Add Notification to a State

Viewing Workflow (2 records require action in this workflow)

Document: Subject:



View Items in workflow then click on record to edit it

Click on Submit for Approval to send item to next step of workflow

Document: Subject:



Next user connects

And can take actions required by the workflow State

Document: Subject:



Raise an Issue while editing any subject to require another user to perform an operation (an issue can be Raised, In progress, Rejected, Resolved)

Document: Subject:



Issue displayed

Issue resolved

Document: Subject:



7.

Bulk Processing

Select Items to add to a Basket

Basket count updated. Click on Default Basket

Document: Subject:



Basket Selections Shown

Select what bulk operation to perform with these subjects Add to current Context Delete Catalog Recatalog Amend ownership Set security

Document: Subject:



Edit fields Approve Authorize Reject Submit for approval Remove some subjects from the Basket Remove all subjects from the Basket Print.

8.

Auditability and Change History

After turning on audit, the Display History tab is shown

Document: Subject:



View Change History In addition, for auditability purposes, 4 tables are provided in the database: Sessiont: records events where connections are made to the database Event: records events where updates are made to the database Thingt: holds the database records that have been updated by events. Textt: holds all the name values for named database records

thingt

Text table 9. Data Loading in Kalido MDM

2 steps: Create a file feed that defines the fields to be loaded, the category to be loaded against, the catalog where data can be viewed and the properties of the source data Start the task of loading the data

Document: Subject:



Click on new Feed

Create a new feed definition in 7 steps

Document: Subject:



Select a subject category

Select a Catalog section

Document: Subject:



Select a prototype file to serve as an example to all files to be loaded as part of this feed

Define column mappings

File Load

Document: Subject:



XML File Feed

Native XML import file format 10. Mapping in Kalido MDM Mapping is the automatic process of referencing subjects in one category (the Source category) to another (the Target Category). A reference attribute must be modeled between the two categories. Mapping runs as a task. A manual process can then be used to map any unresolved differences (no match or multiple matches found). Example: MDM application has a Category called Italian Packed Product that has a Reference Attribute to the Category Packed Product. Some Italian Packed Products have been loaded and many of the code values are the same as the codes of the International Packed Products. There is a Packed Product called Chocolate Stick with code CS and an Italian Packed Product called Bastone Del Cioccolato also with code CS. The Source System did not provide the reference values between the local and global products.

Document: Subject:



Click new mapping button

Select Italian Packed Product

Document: Subject:



Mapping Criteria Match By: Field Comparison, Prior Match or Lookup table

Mapping finished, details displayed Click Map Records button

Document: Subject:



2 matches possible here. Click on Edit

Document: Subject:



Select the target subject that the source subject should be mapped to

Forcing validation against templates 11. Publishing a Context (Versioning) in Kalido MDM

All the information held within a context is output to an XML and topic map file. The output files can be used by other systems.

Document: Subject:



3 steps for publications: Check for invalid records and ensures that all records have been authorized Create the read-only published context Produce the output file

Create a Publication 12. Exporting data to a file

Click New File Export

Document: Subject:



Document: Subject:



Document: Subject:



Document: Subject:



IFP MDM Preliminary Research

Documents

Transcript of IFP MDM Preliminary Research