MDM REFERENCE BY BHAWANI NANDAN PRASAD

MDM

PREPARED BY – BHAWANI NANDAN PRASAD

PREPARED ON: JULY 9, 2013

MDM

2

TABLE OF CONTENTS

1.0 INTRODUCTION ....................................................................................................... 3

2.0 MISSION STATEMENT .............................................................................................. 3

3.0 PROJECT OBJECTIVES .............................................................................................. 3

4.0 PROJECT SCOPE & BOUNDARIES ............................................................................. 3

5.0 MDM APPROACH ....................................................................................................... 4

5.1 MASTER DATA MANAGEMENT – AN EMERGING NEED ................................................................... 5 5.2 MASTER DATA MANAGEMENT AND SERVICE ORIENTED ARCHITECTURES ..................................... 6 5.3 BUSINESS DRIVERS FOR MASTER DATA MANAGEMENT.................................................................. 7 5.4 MDM IS APPLICATION NEUTRAL INFRASTRUCTURE ............................................................................. 8 5.4 MASTER DATA INITIATIVES REQUIRE A STRATEGIC VISION ........................................................... 8 5.5 MASTER DATA MANAGEMENT INITIATIVES REQUIRE TACTICAL ALIGNMENT ...............................11 5.6 BALANCING BETWEEN STRATEGIC VISION AND TACTICAL ALIGNMENT........................................13

6.0 PROJECT PLAN AND MILESTONES ......................................................................... 14

7.0 PROPOSED TESTS AND CRITICAL SUCCESS CRITERIA .......................................... 15

8.0 PROJECT ASSUMPTIONS ........................................................................................ 16

8.1 HUMAN RESOURCE ASSUMPTIONS .....................................................................................................16 8.2 TECHNICAL AND FACILITIES ASSUMPTIONS ......................................................................................16 8.4 PRE-INSTALLATION MEETING .............................................................................................................17 8.5 ROLES AND RESPONSIBILITIES ..............................................................................................................19

9.0 APPROVAL .............................................................................................................. 19

APPENDIX A – NON DISCLOSURE AGREEMENT ON FILE ............................................. 21

APPENDIX B – TEST SPECIFICS SOFTWARE ................................................................ 21

B.1 SOFTWARE PRODUCTS ......................................................................................... 21

B.2 METADATA REPOSITORY DATABASE ..................................................................... 21

B.3 PREPARATORY QUESTIONS ................................................................................... 21

APPENDIX C – POC SCENARIO DETAILS ...................................................................... 23

APPENDIX D – CLIENT ENVIRONMENT AND SYSTEM REQUIREMENTS ...................... 28

SYSTEM REQUIREMENTS FOR INFOSPHERE MASTER DATA MANAGEMENT SERVER ON

REDHAT LINUX ............................................................................................................. 28

MDM

3

1.0 INTRODUCTION

This Proof of Concept (―POC‖) describes the services as part of the evaluation of the

IBM MDM solution.

2.0 Mission Statement

This document is intended to outline the process in which Bhawani will work with

INDUSTRY to test and validate IBM ―MDM Server‖ solution. This document provides

a POC project plan along with associated testing scenarios and success criteria.

3.0 Project Objectives

The objective of this POC is to:

Demonstrate IBM "MDM Server" product functionalities can satisfy

INDUSTRY‘s enterprise business requirements outlined.

ensure "MDM Server" product meet INDUSTRY's infrastructure compliance

requirements

facilitate infrastructure design & implementation of infosphere product suites as

bases for INDUSTRY to further commercialize these products

confirm "MDM Server" product are integrated with InfoSphere product suites

including Metadata Management, Quality Management and Data integration

ETL/CDC products

4.0 Project Scope & Boundaries

This project will focus on infrastructure, integration, and business scenarios that

Keystone does not cover;

1. Implement ―MDM Server" software to validate product compliance and product

compatibility with Infosphere product suites.

2. Design architecture alternatives for "MDM Server" and Infosphere product suites

in both short and long term horizon. Highlight pros & cons of alternatives and its

impact on cost and performance.

3. Confirm integration between "MDM Server" and Metadata Management toolsets

(Metadata Repository, Metadata Workbench and Business Glossary)

4. Confirm Integration between "MDM Server" and Data Quality toolsets

(Information Analyzer and QualityStage)

5. Demonstrate that "MDM Server" can support cross reference and consolidation

style of Master Data Management

6. ―MDM Server‖ can satisfy Master Data Management requirements for enterprise

projects

MDM

4

7. "MDM Server" can support global locations

5.0 MDM APPROACH

IBM has embraced the opportunity to break new ground to bring powerful Master Data solutions

to the marketplace. Combine this commitment to innovation with our longstanding dedication to

open standards, flexibility and Service Oriented Architecture (SOA) and you get a company that

understands the business value of Master Data Management (MDM) — and how you can use an

MDM strategy to help you drive accurate, trusted and actionable information over time across the

enterprise, to provide a real-time single version of the truth about customers, products and other

entities.

Bhawani have embraced MDM and are teaming with IBM to offer robust, leading-edge

solutions to help their clients drive strategic and financial value from managing complex,

voluminous data in an integrated manner. This white paper demonstrates the value of adopting an

MDM methodology and strategy. Organizations cannot deliver on key strategic initiatives

because master data on customers & products (and other domains) is fragmented across

applications. Companies need to build an accurate and complete understanding of key master data

entities across the enterprise, while delivering on short-term tactical projects (Customer Data

Integration or Product Information Management) with demonstrated business value. Customers

want to gain control of their data and manage a master version of the truth that is complete and

accurate. Together, IBM and Bhawani can help customers increase revenue, lower marketing and

sales costs, increase customer satisfaction, and reduce data errors.

MDM

5

5.1 MASTER DATA MANAGEMENT – AN EMERGING NEED If you can think back to the state of the IT world in the late 1980‘s and early 1990‘s, it was a

time, when there was no such thing as a Data Warehouse. Business Intelligence was an unheard

of phenomenon. There was only operational reporting, and most of it was being done from

Operational and Transactional Systems. Then came a evolutionary

idea that Data for analytics and business intelligence must be separated from operational and

Transactional systems, and the concept of the Data Warehouse was born. Today, some 20 years

later BI is an established discipline, with many products and vendors, numerous design patterns

such as ETL technologies, Data Marts and Dimensional Databases and Data mining and reporting

technologies. Today, there is a similar methodology being created around Master Data

Management (MDM), which is a critical, emerging high growth market today. MDM

encapsulates a radical idea that Master Data must be fundamentally decoupled from Operational,

Transactional as well as Analytical Systems. The way transactional systems interact with master

data must be orchestrated through well-defined Master Data Services that inter-operate in a

typically

hetrogeneous environment, through a Service Bus in a Services Oriented Architecture (SOA).

This conceptualization of MDM goes well beyond merely consolidating master data into a

centralized hub, and providing some form of governance. It goes further beyond, providing some

form of bi-directional synchronization between this Master Data Hub and all other applications,

as well as providing the ability to do ‗new‘ things with cross enterprise data – such as maintaining

privacy preferences. The ideas of SOA and MDM, therefore, represent nothing short of an

Architectural revolution in the way systems are constructed and assembled. At the leading edge

of this emerging MDM market, is the customer domain. This is more commonly known as

Customer Data Integration (CDI), a capability that bridges the operational and analytical realms

of Enterprise Customer Information (CRM, Data Warehouse, ERP, etc.), and will be a key

component of the MDM adoption cycle of most enterprises. This market is moving out of its

early infancy stages, with most leading edge enterprises exploring what it is, what it means to

their IT environment, and how to get started on this journey of architectural transformation. There

are now many examples of companies who are rapidly progressing past their phase I

implementations of customer data integration.

MDM

6

5.2 MASTER DATA MANAGEMENT AND SERVICE ORIENTED ARCHITECTURES

At first sight, it might appear that Service oriented Architectures (SOA) and Master Data

Management (MDM) have little in common. After all, SOA deals with de-composing monolithic

applications of the past into a collection of reusable services, while MDM deals with better

management of Master Data. SOA is the most critical IT trend today. Most large enterprises

today are dealing with the question of how to transform their IT systems into a Service Oriented

Architecture. On this journey, they go through the early stages of organizational education,

exploration and evaluation of available technologies. Then they actually invest in some kind of

limited SOA Pilot. These Pilots are typically low to medium risk initiatives, and help them

validate their chosen technology sets. Then their journey meets a critical cross road – How do

they scale from low cost, low risk pilots into a larger business unit wide or even an enterprise

wide SOA initiative?

At this cross road, it becomes apparent that as long as their highly shared ―Master Data‖ assets

are scattered, amongst numerous applications, it is in-sufficient to wrap existing legacy

applications with a services layer, and call this resultant architecture SOA compliant. For

example a simple Re-usable service such as ―Create new Customer‖ or

―Update Product Information‖ must now synchronize those master data changes with multiple

operational and transactional systems (sometimes 100‘s of applications). It makes little sense to

end up with 100‘s of different instances of ―Create new Customer‖ services, with each one

operating within a restricted application domain. There is also the possibility that you can end up

with rather large application centric services that are too large and complex to satisfy every

MDM

7

consumer of the service. The problem of data replication, and resultant data conflicts remains

unresolved. For services to be truly ―Re-usable‖ enterprise class services, they must deal with the

problem of widespread replication of their Master Data. This recognition leads naturally to a

bottom up approach to SOA i.e. organizations must invest in de-coupling and consolidating their

critical Master Data assets from participating applications, by instantiating the concept of a

Master Data Hub. Master Data Management Solutions then become critical milestones

in the journey towards enterprise wide deployment of SOA.

5.3 BUSINESS DRIVERS FOR MASTER DATA MANAGEMENT

Although it is intuitively obvious that MDM initiative are strategic and may impact a number of

business areas and applications in an enterprise, in practice there are often no clear and easily

identified Business Drivers for an MDM initiative. A Business Unit or Process owner is not going

to ask the CIO, that he or she would like to invest in an MDM initiative, this year, or even the

next. However, there are a number of business drivers, or pain points within most large

enterprises, that are addressed better through MDM Solutions. Some examples, frequently heard

are ―I need a consistent, single view of my Customer‖ or ―My profitability reports don‘t match

up‖ or ―It takes too long to introduce a new product in this environment‖ and so on. The picture

shown below captures this idea. The Business need to better manage Master Data may arise in

many different contexts within an enterprise, Legacy Modernization, Service oriented

Architecture adoption and so on. While the Solution to each of these problems could be uniquely

constructed for that particular problem space, it is when these problems are taken together as a

MDM

8

set, that the need to better manage the shared Master Data Assets, becomes apparent as a

―common shared concern‖.

5.4 MDM IS APPLICATION NEUTRAL INFRASTRUCTURE

It is readily apparent from the discussion above that MDM initiatives are highly Strategic,

Enterprise level Infrastructure initiatives. An MDM initiative is quite different from an

Application implementation. MDM initiatives also embody a paradigm shift in the way Master

Data is managed within the enterprise. Where previously, the focus had always been on building

point solutions or localized applications, and Master Data simply existed as a necessary

pre-requisite within any given application domain, now, there are at least a handful of people

within the enterprise who are recognizing that the Master Data deserves some attention in its own

right. Where previously, the way Applications acquired and managed their master data, was

simply by building an interface (or even a set of interfaces) to some other application(s), from

where they could acquire the Master Data, now, there is an emerging concern for the Architecture

of the way Master Data is shared across application boundaries. Where previously there was little

concern for Data ownership and governance, now, there is a growing interest in establishing some

principles and practices, around Data ownership and governance. Where previously, Data

ownership rested within specific Application domains, now there is a growing recognition, that

the Enterprise‘s Master Data assets, flows through many business processes, ranging from Order

management, to Customer Relationship management, to Procurement, to Business intelligence.

Therefore the ownership and governance of Master Data cannot rest with the owners of any one

process or its corresponding application. Thus, there is an entirely new set of concerns around

data governance, data quality, data model and the data life cycle that is de-coupled from the

domain of the individual applications, and placed in a shared space. This leaves the enterprise

with a dilemma called ―Who owns Master Data Management Initiatives‖? There is a whole set of

attendant questions, such as ―Who owns the Master Data itself‖? ―Who is going to get these

initiatives funded and started‖?

5.4 MASTER DATA INITIATIVES REQUIRE A STRATEGIC VISION

Further, when Master Data is de-coupled from the applications that use and consume it,

Application design itself undergoes a radical transformation. Instead of making Master Data part

MDM

9

of the Application itself, it must allow for the possibility that Master data may be available to the

application through externally provided services. Off the shelf products acquired from Vendors

must also allow for externally provided Master Data Services. Managing Referential Integrity

will be much more complex in this situation. All of these concerns represent a disruptive

paradigm shift in the organization.

Master Data Management Initiatives must therefore be constituted as Enterprise transformational

programs. They will impact most applications in the organization, including many concurrent in

flight projects. This implies that an Enterprise level Vision and Road Map must be established for

MDM initiatives. The governance of MDM initiatives must be coordinated at the Enterprise level.

Executive level governance structures must provide the right steering signals to align numerous

concurrent projects and programs with an Enterprise MDM initiative. Further, Master Data

Management must address all subject areas that are relevant to the business. Examples of

subject areas, or domains, include Customer, Product, Account, Location, Geography, Supplier,

Employee, and so on. Some subject areas may be more obvious and critical than others.

Nevertheless, an Enterprise level MDM Program will have many tracks, each dedicated to a

subject area. Each track may have a different Business sponsor, and even different Solution

patterns. The customer domain (and CDI) then is only one of the tracks in an Enterprise MDM

Program, although it frequently provides businesses with a starting point from which to focus on

MDM. CDI Market has gained momentum simply due the fact that in almost every business

vertical, getting to know the customer is a critical business imperative. Customer data is also

widely shared across numerous operational and analytical applications.

Enterprise wide MDM initiatives can gain benefit and momentum from early success with

Customer Data Integration. When CDI initiatives get initiated, without an appropriate Enterprise

level vision, they fail to yield any reusable design patterns, and may not yield the full business

value of MDM. In the first horizon of Master Data Management initiatives, enterprises begin by

consolidating master data from many different disparate environments. Since Master Data is

widely scattered, Data consolidation is the first milestone. Without Data consolidation, the

ubiquitous single version of the truth will remain elusive. Semantic dissonance and discrepancies

in definitions will remain. Enterprise Information Integration (EII) oriented approaches that allow

for real time integration of data will not resolve the pervasive issues of data quality. However

it can provide a short or medium term work around. This Data consolidation naturally leads to the

construction of persistent Reference Data Stores (also called Data Hubs). This Reference Master

Data Store will be a critical Application neutral infrastructural component. In the initial stages of

MDM initiatives these data hubs will co-exist with other legacy data stores, which may include

older versions of Master Data stores as well as Application specific Master data stores. Data

consolidation into the Reference Data Hub, will have to address all forms of data quality issues

and data conflicts. Such a Data Consolidation exercise requires the creation of Enterprise Master

Data models. Establishing an Enterprise level Master Data Model, allows an enterprise to address

issues of data definition conflicts and semantic dissonance, in a centralized manner. Data

concepts such as ―Party‖ or ―Customer‖ acquire different meanings and interpretations in

different business contexts especially over time. MDM initiatives thus become occasions to

fundamentally address the business terms and definitions in use and establish clear business

context and concepts, which can be shared across departmental boundaries. Such a Data

Modeling exercise must have a business context that transcends specific application contexts.

The tendency to avoid data modeling altogether, because the MDM solution is based on a

vendor‘s package (which has a packaged data model), must be avoided. While specific

Application Vendors may provide adequate ―Starter Models‖, these must be carefully evaluated

and customized. Since MDM infrastructures by their very nature are application-neutral,

Application specific data models must be avoided.

MDM

10

In the second horizon of Master Data management initiatives, the data in the Master Data Hubs

must be synchronized with all surrounding applications and master data stores that use some

portions of this master data. Since Master Data changes may originate in many different

application environments, this Synchronization must be bi-directional. Synchronization design

patterns such as real-time, batch or near real-time, must be established for each subject area,

sometimes at the attribute level. Issues of Data ownership and conflict resolution become critical

in this horizon. Data ownership requires that there is a single identified ―owner‖ for each business

attribute, in each subject area in the enterprise. Historically data ownership has always rested with

specific application owners by default. Enterprise wide data ownership is not a well understood

concept yet, in most enterprises. For example, it is somewhat intuitive that the SVP of Sales and

Marketing, could be a Data owner for ―Customer‖ Master Data. However he has to own and

govern customer Master data on behalf of the entire enterprise, not just on behalf of the Sales and

Marketing function. This represents a paradigm shift in data ownership and governance that is not

well understood and assimilated. New kinds of Enterprise wide roles and responsibilities and

attendant organization structures, now become important in the wake of Master Data

Management initiatives. This dynamic also underscores the importance of why it is critically

important to have an enterprise-wide governance body overseeing, creating dialog and providing

guidance around these issues.

In the third horizon of Master Data Management initiatives, Applications surrounding the Master

Data Hub, may get re-engineered, to access the Master data from the Hub, and get de-coupled

fundamentally from any master data stored locally to the application. This is a critical and radical

transition. This transition may be happen one application at a time, or may not happen at all in

some instances. Through these transitions, additional enhancements to the Data Hub data model

may be required. As customers consider their approach to this third horizon, they need to make

sure they are considering flexible MDM products and solutions that will help them evolve over

time. For example, a client may determine that they want to start off with a thin layer of customer

data in the CDI Hub, and then gradually increase the amount of data that is maintained in the

Hub. Additionally, accessing and managing that information in real time may become more

critical. Clients need a flexible, but scalable, product that can meet their current, as well as future,

needs.

It is clear from the above discussion that Master Data Management initiatives represent a

transformational journey for most organizations. They are not just another project. Therefore the

need to establish the MDM programs firmly in an overarching Architectural Vision, is critical for

sustainable success with MDM initiatives.

MDM

11

USTOMER DATA INTEGRATION - A JOURNEY

5.5 MASTER DATA MANAGEMENT INITIATIVES REQUIRE TACTICAL ALIGNMENT

It is clear that Master Data Management results in improved data quality, semantic consistency

and can impact many business areas. For example, a typical CDI initiative can impact a variety of

areas related to the Customer. The real business value of MDM initiatives is the aggregate of the

business benefits in each impacted area. Building a comprehensive business case for MDM

requires understanding its potential business value across these varied business areas. No one

Business Executive is going to have MDM on the top of his or her agenda. Selling the concept

of MDM to the business requires constant evangelism and advocacy across a broad range of

business executives. The creation of a Centralized Master Data Hub cannot be an end in itself. It

has to be leveraged appropriately to deliver measurable business value. The business value of an

MDM initiative must be forecasted before the initiative begins, and assessed after it ends. When

business value is clearly demonstrated, subsequent iterations of the MDM Road map can be

funded more easily. The business value must be articulated clearly through a well developed

business case. The business case must be built on the basis of critical business measures that will

be impacted by the MDM initiative. MDM initiatives only deliver the ‗foundational

infrastructure‘ for potential business value. For example, the fact that we now have a single

customer view in the customer data hub, does not guarantee that the Cross Sell ratio will go up.

The single view of the customer has to be leveraged through ‗intelligent‘ cross sell business

strategies. Business executives must be educated on the fact that MDM initiatives deliver critical

infrastructure, which must be accompanied by business strategies and solutions. As an enabling

infrastructure, it is difficult to directly attribute business value to an MDM initiative. Selling the

concept of MDM and acquiring funding for an enterprise wide MDM initiative is going to be a

difficult task. It will always be easier to sell an enterprise on the concept of a focused and tactical

MDM

12

MDM initiative, with limited scope and budget, and to develop similarly focused follow-on

phases from that starting point. Pressing needs may exist within the enterprise that demands a

solution to specific business problems. Some examples are Sales (Cross Sell efficiencies),

Marketing (Marketing productivity), Compliance (Basel 2) or Servicing (Service Excellence).

The initial language of the problem, will almost never imply that the business is looking for an

MDM based solution. At first evaluation, each ‗pain area‘ may not look like they have anything

to do with an MDM Solution. In fact, it may even be possible to address the business

requirement, or pain area, without an MDM infrastructure. However, every significant business

initiative can be tied back to MDM in some way, since all business problems will involve the

need for Master Data. The concept of MDM must be creatively positioned within the domain of

the specific business pain area. Often there are in-flight, funded projects that are currently being

addressed through custom development, or off the shelf products. These efforts may not have

considered an MDM based approach at all. If an MDM Architectural vision is not aligned

tactically with ongoing funded initiatives, it may never get off the ground. By aligning an MDM

Road map with tactical initiatives, the enterprise can begin the MDM journey. Some central

agency must own the MDM architectural vision and arbitrate it across numerous in flight and

upcoming initiatives. Tactical business projects must be assessed for convergence with the MDM

architectural vision. The delivery of business value to a specific business area or function could

be constituted as a specific MDM iteration. For example, delivery of integrated Customer Master

data to the Sales function, and the attendant benefits could be a single iteration in the MDM Road

Map. The delivery of business value to a specific business area is easier to manage in a shorter

time frame. Shorter time to value builds confidence in the initiative.

Thus, the MDM vision for an enterprise must encompass the notion of ―MDM delivery iteration‖.

The business case and the solution footprint of each iteration must be carefully constructed in

order to build growing consensus for the initiative. This implies that there are no tactical MDM

projects – only MDM iterations that build upon an Architectural vision. By ensuring that each

MDM delivery iteration delivers on its business case we can establish a growing consensus within

the business for the MDM initiative. If the business case for MDM iteration, is buried in a larger

business initiative, MDM initiatives will never acquire their enterprise level focus and distinct

identity. Each MDM delivery iteration must be anchored with a specific business sponsor, who is

willing to demonstrate the business value of the specific MDM iteration. Not all MDM

deployments are the same. Therefore, MDM solutions need to provide capabilities to manage

multiple forms of MDM. This concept, Multiform MDM, requires support for multiple domains

(subject areas) and usage types. There are broadly three distinct usage types in MDM solutions.

There is Collaborative MDM design patterns that focus more on Master Data as content, and is

concerned with the workflows associated with content authoring. Operational MDM focuses on

transactional delivery of Master Data through large grained business oriented services.

Finally, Analytical MDM focuses on in-line analytical data consolidation and roll ups. It may be

tempting to align with an MDM vendor, who has an offering that is very strong within a specific

usage type, and most applicable to the initial needs. Without an over arching MDM vision, trade

offs between niche MDM (or CDI or PIM) vendors and enterprise MDM vendors cannot be

appropriately evaluated. There may be multiple MDM products involved in the overall MDM

strategy of an enterprise, but it is better to create a strategy that plans for an MDM product that

can successfully be applied to all domains and usage types.

MDM

13

5.6 BALANCING BETWEEN STRATEGIC VISION AND TACTICAL ALIGNMENT

Without a strategic MDM Vision, it is possible for most large enterprises to end up with multiple

MDM infrastructures, which are not appropriately integrated. The design of MDM solutions will

not be established to evolve through multiple MDM delivery iterations. Tactical MDM design

patterns that do not scale up to a coherent MDM architecture will be predictable. A strategic

MDM Vision that has the buy in with the key enterprise stakeholders, on both the Business and

IT organizations is critical to success along the MDM journey. A mechanism to co-ordinate the

project portfolio with the MDM initiatives is also critical to MDM success. At the same time,

without tactical alignment, the MDM journey will remain a vision without a sponsor. A big bang

approach without tactical short term value delivery will be difficult to get funded. The MDM

Vision must be reconciled with the current funded project work. A beach head project must be

identified that can become the ‗pilot‘ to get the MDM program started. The business value of

tactical MDM iterations must be clearly demonstrated. Without an appropriate balance between

strategic vision and tactical alignment, MDM initiatives can suffer for want of adequate

sponsorship and visibility. Every MDM initiative during its life cycle will lean either towards the

strategic vision or the tactical alignment. Maintaining this balance is a key challenge with steering

MDM initiatives. This requires that Enterprises must have the appropriate ownership and

governance structures to achieve this alliance with MDM initiatives. Executive steering signals

must drive organizational behavior to accomplish this balance. Senior executives must be

sensitized to the nature of this balance. Enterprise Architecture has the broadest view of the IT

portfolio in the organization. Without such a broad view of the IT portfolio, MDM initiatives can

become narrowly focused. Enterprise Architecture must provide the leadership and guidance, to

establish an MDM road map.

This requires that there must be a strong Enterprise Architecture team, in the first place. The

Enterprise Architecture must educate and evangelize the concept of MDM and the nature of the

MDM journey with the senior IT and Business executives. Enterprise Architecture must guide

individual projects, product selection exercises, and technology choices to align them with the

MDM vision. A enterprise level program management function must align projects with the

MDM initiatives. Without a program management function governing and overseeing the current

in flight projects, there is a risk of individual projects making decisions that are not in alignment

with the overall MDM vision. Individual project design and architecture decisions made without

the overall MDM vision in mind can be counter-productive and cause inefficiencies. It is not

uncommon to have multiple MDM like initiatives sprout up, each with a narrow focus and little

convergence. The enterprise program management function, must work closely with Enterprise

Architecture to provide Architectural convergence across the portfolio of projects currently in

flight. Clear mechanisms for Architectural reviews, compliance assurance and exception

management must be established.

Sustainable success in the MDM journey is dependant on this balance between strategic vision

and tactical alignment. Enterprise Architecture and Enterprise Program Management are two

governance functions that are critical for enabling this balance. Tactically oriented MDM projects

must be brought under the fold of an Enterprise governance function. The Enterprise Architecture

and Enterprise Program Management Office roles must be strengthened and enabled to operate as

a team, in order to steer MDM initiatives for success.

BHAWANI is a 20-year global veteran and visionary pioneer in the IT industry, currently serving

seven of the Top Ten Fortune ® corporations in the U.S. alone. We believe organizations gain a

competitive edge by partnering with our business and domain experts. Some of the key

advantages that your organization will experience working with our MDM Practice include:

MDM

14

Extensive experience, credentials and expertise in the areas of ERP, BI, CRM, and SCM

technology space.

Alliances with major MDM/CDI vendors like i2 Technologies, IBM, Initiate Systems,

Kalido, Oracle, SAP, Siebel, Siperian, which we leverage to provide appropriate product

independent and best-in-class solutions for our clients.

A dedicated product group focusing as a team on your Data Profiling and Cleansing

requirements.

A Data Quality Improvement Methodology derived from extensive Six Sigma Process

Consulting engagements designed to optimize data quality investments; maximize the

impact of the data cleansing and process improvement effort; and to accelerate Value

Delivery.

6.0 PROJECT PLAN AND MILESTONES

POC Tasks - MDM Server Task/Deliverable Due Date Responsible Additional

Resource

SOW completion BHAWANI

Obtain Evaluation

Licenses for DMS Lab

MDM Server

Information Analyzer

Metadata Work Bench(MWB)

Business Glossary

DataStage / QualityStage

Change Data Capture (CDC)

Technical &

Architectural Review

Knowledge transfer

Current Lab Environment

Technical &

Architectural

Recommendation

Architectural Alternatives; Pros &

Cons; Performance & Cost impact

Document POC architectural

issues & recommendation for

commercialization

Software Install &

Configuration

Preparation for LAB readiness

MDM

15

Final list of software version,

releases & patches, complete list

of compatibility between all the

products

Install all software and validate

Determine POC test

cases & success criteria

Charting out detailed use cases

and success criteria

Confirm scope with stakeholders

Execute Data Load

Execute POC Testing

Compliance of ―MDM Server‖

Infrastructure with standard

Integration between MDM &

Metadata Repository (MDW &

Business Glossary)

Integration between MDM &

DataStage (QualityStage)

Support of 'cross reference' &

'consolidation' style of MDM

Facility Master Use Cases – see

Appendix for detail

Support of global locations

POC Results Review

Gather POC results

Document findings

present report out to stakeholders

7.0 PROPOSED TESTS AND CRITICAL SUCCESS CRITERIA

It should be understood that the Proof of Concept process is intended to demonstrate core

competency to resolve the business objectives relative to the Customer‘s identified business

requirements. As a limited engagement, expectations should be set such that all parties

understand that the Proof of Concept is not a full solution deployment.

The goal of the following tests is to confirm that the proposed solution: ―MDM Server‖ addresses

and solves the requirements of Customer as noted in Section 4- Project Scope & Boundaries.

Customer has identified and agreed that the following test results are to be used as success

criteria:

MDM

16

1) ―MDM Server‖ can be installed on Lab environment and is compliant with

INDUSTRY‘s standard. If there are non-compliant issues, BHAWANI

and DMS would assess its impact and research if resolutions or alternatives

are acceptable.

2) MDM Server‖ has to demonstrate its functionalities and deliver results to

meet business requirements as described in Appendix C - POC Business

Scenario Details.

3) MDM Server‖ has to be compatible with Infosphere product suitess and

necessray integration between products have to be demonstrated. If

critical business requirements cannot be met due to lack of integration,

BHAWANI and DMS would assess its impact and document workable

alternatives.

4) BHAWANI will conduct knowledge transfer sessions to help speed up

3Rivers and Data integration team‘s ability to further support and

commercialize this product.

NOTE: No BHAWANI software may be installed in a production environment, nor may any

BHAWANI personnel work on, connect to, or otherwise affect any production systems,

networks or databases.

NOTE: For specific testing environment details, additional scenario details, and additional

notes please refer to Appendix ‗B‘ Test Specifics/Customer Environment. A checkmark

indicates that each specific test has been verified by the customer as completed successfully.

8.0 PROJECT ASSUMPTIONS

8.1 HUMAN RESOURCE ASSUMPTIONS

BHAWANI will provide product specialist s for the duration of the setup and testing.

Customer will provide System Administrators, Database Administrators and other team members as needed

by BHAWANI for the installation, configuration, system and data access, and completion of all required

tests.

8.2 TECHNICAL AND FACILITIES ASSUMPTIONS

BHAWANI will provide the necessary product, product documentation and temporary license keys

for evaluation licenses for the Lab environment.

CUSTOMER will:

provide detailed system configuration information for all systems on which BHAWANI software

is to be installed including operating system versions, patch levels, database versions and patch

levels, and a listing of all additional applications installed;

MDM

17

share any testing plans (automated and manual) with the BHAWANI Systems Engineer onsite or

remote;

share their testing results with the BHAWANI Systems Engineer on site;

ensure that the agreed operating systems and databases will be installed on the test servers before

testing begins.

provide a working area with adequate office supplies, etc.

participate in a daily progress call, or meeting, between the BHAWANI team, the INDUSTRY

team and the senior INDUSTRY person responsible for the software purchase decision.

BHAWANI will:

Establish proof of concept team. The support staff includes:

o System Engineer(s)

o Account Manager

o Customer Support

o Product Management staff as needed

o Technical support staff as needed

Working with the Customer, the BHAWANI team will develop a schedule for executing the

proof.

The BHAWANI team will assist in designing and executing the prospects test scenarios.

Conduct daily status meetings with customer.

Customer Support will maintain a log of all problems or incidents reported and provide on-going

updates as required.

BHAWANI and the CUSTOMER will:

BHAWANI team working jointly with the customer project team will implement a prototype

system as the requisite functional proof of concept.

The Customer will notify the BHAWANI team to monitor any problems or incidents that occur

during the testing.

BHAWANI will use established procedures to receive, track and resolve problems or incidents

reported by the site.

A daily status meeting will review the progress and remaining tasks.

The proof will be declared completed upon a verbal agreement between the Customer, and the

BHAWANI team.

8.4 PRE-INSTALLATION MEETING

The purpose of the meeting is to fully qualify the client‘s technical environment for the proof and discuss

the installation process. This is typically scheduled as this document is presented.

There are four main objectives for this meeting:

Define the functionality that makes up the proof of concept.

MDM

18

Identify specific tasks necessary to implement the identified prototype, identify BHAWANI ‘s

consulting, involvement, discuss training requirements, assign client and BHAWANI Software‘s

responsibilities, create project plan.

Prepare the environment by providing the required facilities/equipment and ensure all prerequisite

software/hardware is available.

Schedule the proof.

Sign-off on test requirements and objectives as defined in this meeting.

Identify a focal point and primary liaison for the BHAWANI team.

Initiate BHAWANI resources access to test environment. ???

Identify staff resources for the proof of concept‘s duration.

MDM

19

8.5 ROLES AND RESPONSIBILITIES

ROLE RESPONSIBILITIES PERSON

Customer Signing

Authority

Acceptance of global scope of POC and project plan.

BHAWANI Signing

Authority

Acceptance of global scope of POC and project plan.

Project Manager

(Customer)

Provide Customer physical and technical resources to

complete objectives of POC. Facilitates scheduling

of technical resources, timeframes, POC technical

goals and objection handling.

Systems

Administrator

(Customer)

Provide Customer physical and technical resources to

complete objectives of POC. May be more than one

person.

Database

Administrator

(Customer)

Provide Customer physical and technical resources to

complete objectives of POC.

Installation, Configuration & Monitoring -

Knowledge Transfer Contact. May be more than one

person.

Project Coordinator

(BHAWANI )

Identification of customer requirements, primary

customer contact.

Technical Project

Manager

(BHAWANI )

Provide BHAWANI technical resources to complete

objectives of POC. Facilitates scheduling of

technical resources, timeframes,

Product Specialist –

MDM PIM

(BHAWANI )

Technical contact, providing onsite technical support

for Customer POC. Verifies evaluation plans, test

plans, provides technical knowledge transfers.

Installs and configures products, assists in physical

testing.

Product Specialist –

QualityStage

(BHAWANI )

Technical contact, providing onsite technical support

for Customer POC. Verifies evaluation plans, test

plans, provides technical knowledge transfers.

Installs and configures products, assists in physical

testing.

Product Specialist

CDC

(BHAWANI )

Technical contact, providing onsite technical support

for Customer POC. Verifies evaluation plans, test

plans, provides technical knowledge transfers.

Installs and configures products, assists in physical

testing.

Support Specialist Technical support contact to assist BHAWANI

product specialists with product support requirements

9.0 APPROVAL

The signatures below confirm that the POC business requirements and testing objectives covered

within this document are acceptable to both parties. The signing authority for Customer

acknowledges that pending successful completion of this Proof of Value Pilot, BHAWANI

Corporation and Customer will work in good faith towards the completion of a commercial

business transaction.

MDM

20

BHAWANI CORPORATION

By:

Name: [BHAWANI TSM name]

Title: Technical Sales Manager

Date: [date]

CUSTOMER

By:

Name:

Title:

Date:

MDM

21

APPENDIX A – NON DISCLOSURE AGREEMENT ON FILE

APPENDIX B – TEST SPECIFICS SOFTWARE

Detailed information on major systems components involved in the Customized demo/POC including:

Servers, Client Machines, Network, Databases, and Specific Test Scenarios

B.1 SOFTWARE PRODUCTS

BHAWANI Product /

Technology Platform Bits Version

Patch

Level

MDM Server Linux- Red Hat

Websphere Application Server Linux

Oracle Client

Information Analyzer

DataStage

QualityStage

Metadata Workbench

Business Glossary

Business Glossary Anywhere

Business Glossary Browser

Info Server CDC (Trans.

Server)

B.2 METADATA REPOSITORY DATABASE

Repository Database Brand Platform Bits Version Patch

Level

Oracle

B.3 PREPARATORY QUESTIONS

Question Answer

Any unusual security requirements for system access?

(fingerprinting, etc) No

Has appropriate software and/or reference data been ordered? NA

What type of group workspace is available for the project team?

Project room is preferred. Yes

Occasional use of a whiteboard will be required during the

week. Will one be available? Yes

Are there any issues regarding BHAWANI IT Specialists

accessing corporate data? No, non disclosure on file

Do you have access to the Internet for e-mails and file

transfers? Yes

What needs to be arranged for building security? Are

background checks required? What lead times are required? Will arrange

MDM

22

Question Answer

What needs to be arranged for building security with regards to

the entry and exit of PC‘s, CD/DVD‘s, memory devices? NA

What is the dress code at the location where the BHAWANI

IT Specialists will be working? Business Casual

What are normal working hours? Is special permission required

to arrive early or leave late? Is the team prepared to adjust

working hours?

Will arrange 7/24 badges

Will projection capabilities be provided for final presentation of

results? Yes

Will the system admin be available on the first day of the POC

to assist with the installation? Yes

Will the BHAWANI IT Specialist have administrative rights

to the client PC? No

MDM

23

APPENDIX C – POC SCENARIO DETAILS Infrastructure

▪ Install and configure MDM Server along with other inforSphere product suites into a Lab environment

Integration:

▪ Demonstrate integration options and features between MDM Server with other InfoSphere Product suites

▪ Demonstrate data model and data can be loaded from multiple source data into MDM Server (if Keystone is

already doing this, we could just use flat files)

MDM Functionalities to meet business requirements

▪ Provide functionality to assign default values and to transform source values with business rules to match

defined standards or convert to one generic format to harmonize the data in the MDM golden repository

▪ Multiple source data can have a GUID assigned and cross referencing can be established

▪ Provide functionality with business rules to enable:

Detection of data as duplicate or defect and be suspended for manual intervention with workflow

Assignment of default value

Validation with referenced standard data and be mapped in

convert to one generic format

similar data can be detected and merged into one gold record

▪ Support the automated processing of data sets match/merge and also allow manual intervention for suspended

data. Possibility of ―dark merges‖ and user controlled record merging

▪ Allow flexible data grouping (different from the hierarchy that keystone requires)

▪ Show simple collaboration with workflow (keystone is testing this already)

▪ Support the consolidation style of persisting one golden record and maintain the local system keys to

synchronize data bi-directional

▪ Master data publish & distribution scenarios based on manual or system triggered events

▪ Support of global Unicode character sets; and feeding data between MS SQL based systems and Oracle based

systems.

▪ Able to retrieve a snapshot of structure and content as of point in time

▪ Full audit trail

▪ Report features, and repository queries

The following items are out of scope:

▪ Integration with actual source or target systems is out of scope. The source data will be provided as files

(keystone is testing end-to-end data loading)

▪ Scalability and performance is out of POC scope, however architecture design for high throughput is in scope

POC Use Case 1: Validate Longitude/Latitude

Set threads hold of value of Long/Latitude to determine if it is defect or duplicate to screen out or merge record;

(business rule can be viewed in attribute detail)

POC Use Case 2: Reference Country code with ISO standard

MDM

24

Source data Country code will be mapped to reference table in ISO standard country code to validate and

mapped in.

POC Use Case 3: Grouping of data

Master data can be grouped flexibly

POC Use Case 4: Consolidate Master Data - Cleanse, Match, and Merge

Scenario Description:

a. Data will be loaded from different source files providing one to many records at the time. Key

identifier for source system can be determined by the ―source system‖ and ―unique identifier‖ in the

following ―Data Attributes & Business Rules‖ section

b. A limited set of fields will be parsed and values will be replaced with standard values or for empty

fields with default values.

c. Addresses get validated and missing information, like zip code, will be added to the data.

Agreed; IA is the right product for this. We only need to add zip code from a reference table

(Project already bought industry address data)

d. A global key gets generated.

e. Data will be loaded into MDM where records will be automatically merged, if a golden

record already exists in the MDM repository. The MDM record will be persisted and the

local key will be written to the MDM key mapping for the golden record. We will need to

discuss with ELF project further, something like source system unique identifier

f. New records without a match in MDM will be added to a workflow, providing the users on MDM

validations, automatic assignments, notification, and record matching based on multiple fields. This

can be done.

g. Records can be merged by the users on MDM, where field by field the golden record can be composed

and the local key of the source systems will be persisted. Yes, conflict resolution based on preference

can be established. In a production instance, keeping a local copy of the fragmented data from

different source systems can potentially lead to data explosion. We need to refine this requirement. For

a specific attribute if there are two data sources with different values, is there a preference?

h. Syndication Process can be triggered manually by a user for a selected set of data and will

automatically be processed upon change of records, sending only the changed records This can be

done.

i. Changing the golden record and change related source records, if applicable. To be discussed with

ELF project. We need to examine how many related records for a golden record. Are there any data

implications?

POC Use Case 5: Publish master data to consumer, synchronize data bi-directional

Master data can be pulled from target systems or pushed to target. Pushing of data can be either triggered by event such as

change of records or manually done by a user. This POC will test out event triggering data push by viewing composed

output records.

Conceptual Data Model:

MDM

25

Data Attributes & Business Rules

Fields for this POC: Global Unique ID (GUID), Source system unique identifier, Lat/Long, Country

Code

Item Field Definition Rules FACILITY

Facility Name Chevron assigned common name

Content will be in American English

Managed, must be unique.

Can change over time

Facility Description Text that provides additional information

about the Facility

American English

A long text field

Unmanaged open text

Facility GUID System generated id

System of record is ELF (not human readable)

Globally unique forever

Multiple facilities cannot occupy the same space on earth in 3 dimensions to gain uniqueness.

Facility Source system Status

Active/Inactive indicator of the Facility

System of Record: Source System

Post Close Obligation issues

White pages needs to know if people can work at this Facility

Facility Source Identifier for the system of record

provided in human readable format Values come from a managed set

Facility Type Facility type

Values come from a managed set

Each value corresponds to the conceptual model definitions

A Facility can only have one type

Facility Function Brief description of functional use

A Facility can have one or more functions

Values come from a managed set

Each value corresponds to the conceptual model definitions

Values are less than four words

MDM

26

Item Field Definition Rules

Other IDs Source System Identifier for the source system provided

in human readable format Each source system has a unique ID assigned by

the Repository

Other IDs Unique Identifier Identifier from the source system Must be unique key in the source system

Facility Employee Primary Workspace

Eligibility Flag Flag that identifies whether or not the Facility can

be a Chevron primary workspace

Facility Group

GUID Globally unique identifier assigned to the

Facility Group Uses the same repository as Facility GUID to

maintain uniqueness within this repository.

Facility Group

Name Chevron-assigned common name of the

Facility Group

Content will be in American English

Managed, must be unique.

Can change over time

Facility Group

Description Text that provides additional information

about the Facility Group

American English

A long text field

Unmanaged open text

MDM

27

Item Field Definition Rules ADDRESS

Address City/Township FIPS PUB 55-3 in USA

American English name

Will select a standard where available or develop reference data where there is a business need but no standard exists

Must be unique in defined ISO country or country subdivision

City can be blank or NULL

Address Lat/Long Geodetic coordinates of the Facility

Lat/Long pair is required

Both Lat & Long have precision to within 3 meters (10 feet)

Western & Southern Hemispheres specified as negative values

Lat/Long acquired from the appropriate service or when not available use the Southwestern-most (lower left) point of primary entry point or entry structure

Address Height Specifically the height (altitude) of the

Facility

Height is an optional element

The height will be measured in meters as ± from the surface defined by the Datum

Address Datum Datum of the geodetic coordinates of the

Facility

Datum for the Lat/Long/Height pair above

Datum is an optional element. If datum is not specified, it assumed to be EPSG::6030.

If specified, it must be the EPSG code of the referenced Datum in the form EPSG::####.

Address Mailing Detail Address where mail is received for a

Facility

Exists only if different from physical address

Exists only for facility

A mailing label; In format both adequate & appropriate to be used for mail delivery

Item Field Definition Rules ADDRESS

Address Street Street Name

Includes entire street name & number

Can include apartment number, mail stops, office suites

Can be multiple lines

Primary use of the field is to assist in navigating to the Facility

Validated using the appropriate service when possible

Street Name can be blank or NULL

Address Postal Code Postal Code Standard of the Country in which the Facility exists

Postal Code can be blank or NULL

Address Country ISO 3166-1 Numeric value is always stored

Country will be blank if the Facility is outside the boundary of all ISO-defined countries

Address State/Province ISO3166-2

Numeric value is always stored

State/Province will be blank if the Facility is outside the boundary of all ISO-defined countries OR if the Facility is in a country that does not have ISO-defined subdivision 2

Address County INCITS 31:200x, (Formerly FIPS 6-4) in USA

First level subdivision under ISO3166-2, not necessarily an ISO standard

Will select a standard where available or develop reference data where there is a business need but no standard exists

County can be blank or NULL

MDM

28

APPENDIX D – CLIENT ENVIRONMENT AND SYSTEM REQUIREMENTS

Functionality

New Proof of Concept Environment to

install MDM & WebSphere Appl Server Lab Server

Operating System

Linux

Red Hat Release

Kernel Version

Hardware

CPU

Hardware platform

Processor type

Processors

RAM

InfoSphere Products on

Production/

Development Servers

provided for compatibility check for future

change management consideration with

established current environments

WebSphere Application

Server

WebSphere Application Version

Java version

Datastage

QualityStage

Information Analyzer

Metadata Workbench

Business Glossory

System Requirements for InfoSphere Master Data Management Server on RedHat Linux

Application Server Requirements

Operating Systems

Red Hat Enterprise Linux, Version 5 with Update 1

Hardware Requirements (see note

above)

x86 or x86-64 system, or POWER processor system, with at least 2 - 4 processor cores (based on

CPU speed)

MDM

29

Note: Itanium based systems are not supported

RAM: 6 GB

Disk space: 50 GB

Application Server

WebSphere® Application Server Network Deployment, Oracle® WebLogic Server 10g Release 3

Java™ Development Kit

BHAWANI Developer Kit for AIX, Java™ Technology Edition which is shipped with WebSphere

Application Server

Java Development Kit that is shipped with Oracle WebLogic Server

Database client (including Java

Database Connectivity (JDBC)

Drivers)

BHAWANI DB2® Client, version 9.7 and 9.5, including the DB2 Universal JDBC Driver, or

later

Oracle Client, version 11g Rel 1, including the Oracle JDBC driver 11.1.0.6, or later

Important: Although the database server can use Oracle 10g, the database client must use Oracle

11g

HTTP Server

BHAWANI HTTP Server, Version 2.0 or later

Note: The WebSphere Application Server plug-in must match the version of WebSphere

Application Server that you use for InfoSphere MDM Server.

Apache HTTP Server, Version 2.0 or later

Perl

Recommended: Install a private version of Perl for the InfoSphere MDM Server user. For more information,

see the information center. If you install a private version, ActiveState ActivePerl, Version 5.8 or later (Version

5.10 is preferred), is recommended.

Web Browser

To run the FirstSteps or Launchpad installation programs, use either of these browsers:

Mozilla 1.7 or later

Firefox 2.0 or later

Database Server Requirements

Operating Systems

Red Hat Enterprise Linux, Version 5 with Update 1

Hardware Requirements (see note

above)

x86 or x86-64 system, or POWER processor system, with at least 2 - 4 processor cores (based on

CPU speed)

Note: Itanium based systems are not supported

RAM: 8 GB

Disk space: 100-200 GB, in a RAID configuration

Database Server

BHAWANI DB2 Enterprise Server Edition Version 9.5 for Linux, UNIX®, and Windows® (See

the documentation)

BHAWANI DB2 Enterprise Server Edition Version 9.7 for Linux, UNIX, and Windows (See the

documentation)

Oracle 10g Rev 2 (Version 10.2.0.2) Enterprise Edition, or later (See the documentation)

Oracle 11g Rel 1 (Version 11.1.0.6) Enterprise Edition, or later (See the documentation)

Web Browser

To run the FirstSteps or Launchpad installation programs, use either of these browsers:

Mozilla 1.7 or later

Firefox 2.0 or later