Ibm based mdm poc

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)
complete objectives of POC. May be more than one
person.
Database
Administrator
(Customer)
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 )
testing.
Product Specialist
CDC
(BHAWANI )
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
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

MDM
26
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
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
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
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

Ibm based mdm poc

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (9)

Ähnlich wie Ibm based mdm poc

Ähnlich wie Ibm based mdm poc (20)

Mehr von Bhawani N Prasad

Mehr von Bhawani N Prasad (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Ibm based mdm poc