Ibm based mdm poc


Published on


Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Ibm based mdm poc

  2. 2. 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
  3. 3. 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
  4. 4. 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.
  5. 5. 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.
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. 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.
  10. 10. 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.
  11. 11. 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
  12. 12. 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.
  13. 13. 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:
  14. 14. 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
  15. 15. 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:
  16. 16. 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;
  17. 17. 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.
  18. 18. 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.
  19. 19. 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.
  20. 20. MDM 20 BHAWANI CORPORATION By: Name: [BHAWANI TSM name] Title: Technical Sales Manager Date: [date] CUSTOMER By: Name: Title: Date:
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. 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:
  25. 25. 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
  26. 26. 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
  27. 27. 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
  28. 28. 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)
  29. 29. 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, 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 Enterprise Edition, or later (See the documentation)  Oracle 11g Rel 1 (Version 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