1 / 29

A Service -Oriented Approach to Unifying Data

A Service -Oriented Approach to Unifying Data. Nicholas Gall Senior Vice President & Principal Analyst Nick.Gall@metagroup.com. A Most Frequently Asked Question. Given that we want to evolve towards XML, Web services, and SOA,

malise
Download Presentation

A Service -Oriented Approach to Unifying Data

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. A Service-Oriented Approach to Unifying Data Nicholas Gall Senior Vice President & Principal Analyst Nick.Gall@metagroup.com

  2. A Most Frequently Asked Question • Given that we want to evolve towards XML, Web services, and SOA, • What are the best practices for unifying shared business data (aka reference and master data)? • Customer • Product/Material • Supplier/Vendor/Partner • Current answer: Relational Data+EAI+EII+ETL • Emerging answer: XML, Web Services, SOA • What’s the key difference?

  3. Modularity: The Key to Efficient Innovation • An on demand enterprise is one that is able to efficiently innovate its business processesand the IT systems that enable them • The key to efficient innovation is modularity • Modularity enables • Independent Comprehension • Independent Development • Independent Change • SOA minimizes coordination and maximizes consistency by modularizing change • Find what changes and encapsulate it • Applying SOA to Master Data will make it easier to coordinate changes by modularizing the data

  4. Mastering Reference Data Confusion (or is it “Referencing Master Data Confusion”?)

  5. Key Issue:How to Manage Ownership of Master Data? • Who owns the rights to query the data? • Who owns the rights to define the data? • Who owns the rights to create/delete the data? • Who owns the rights to change the data? How Widely Shared is Ownership? • App-wide • Process-wide • BU-wide • Enterprise-wide • Partner-wide • Industry-wide • World-wide Master Data Management (MDM) must evolve from ad hoc to architected

  6. The Hourglass Model Users Generic Complementors E x t e n s i b l e Simple Enablers Federated Providers Service-Oriented Architecture:An Internetwork Approach to Modularity • An SOA is an internetwork architecture that should be • Interoperable • Should not be tied to a particular platform architecture (J2EE or .Net) • Networked • Should do integration “on the fly” using a network of intermediaries • Generic • Should support a wide range of applications • Federated • Should overlay a wide range of software to minimize rip and replace • Simple • Should define standards using only “on the wire” identifiers, formats & protocols (IFaPs), NOT APIs • Extensible • Should be easily and dynamically adaptable to new uses and implementations

  7. The Hourglass Model for Intermodal Containerized Shipping Format Container Envelope Packet Message Oil Grain Consumer Electronics Intermodal Container Truck Ship Barge Warehouse … Train Freightliner CSX SS Minnow Ms. Ohio Wal-Mart Warehouse Southern Pacific Example:Applying SOA to Modularize Shipping For the transportation industry, horizontal integration, which emerged only in the 1950s, was made possible by the development of and agreement upon a standard freight container. When it was publicly demonstrated in 1956 that standard containers could move successfully on a land-sea intermodal journey, a commercial revolution was started. It was the container’s unique role as common denominator among modes that was revolutionary.

  8. Example:Applying SOA to Modularize MDM • An SOA for Customer MDM should be • Interoperable • Should not specify how apps represent customer data internally • Networked • Should do data routing, cleansing, and transformation “on the fly” using a network of intermediaries • Generic • Should define a customer metadata model that can be used across all applications • Federated • Should independently bind different aspects of the customer metadata model to application-specific customer data models • Should overlay existing middleware and applications to minimize rip and replace • Simple: • Should define customer metadata standards in terms of “on the wire” IFaPs, NOT APIs • Extensible • Should enable extension of the customer metadata model to new application-specific customer aspects “on the fly”

  9. TRANSFORMATION STEPS Next Steps to a Service-Oriented Approach to Unifying Data • Use the SOA “hourglass” criteria as a guide to better modularity • Design for change by focusing on services that are general purpose, federated, simple, and extensible • Focus on network concepts of interoperability • IFaPs “over the wire” not APIs “at the endpoints” • Use extensibility to incrementally get there from here • Minimize rip and replace caused by business or IT innovations • Modularize data to minimize the complexity of changing it

  10. Creating a Single Enterprise-Wide View of Your Customers A Joint BEA & Ascential Webinar

  11. So Where is the Master Customer Data? • Most organizations are doing some customer data consolidation • Data Warehouses • Enterprise Applications (System of Record) • So why doesn’t everyone have a complete view of their customers? • These approaches fail to meet the generic, federated, simple, and extensible requirements • What’s needed is an approach that leverages what you have, but focuses on these requirements

  12. Seeking a Single View of Customer CRM Duplicated, mismatched, and contradictory customer data Portal Call Center Application ? ERP Workflow Data Warehouse

  13. BEA & Ascential Joint SOMDA Solution Step 1: Understand Source Systems CRM Common Metadata Model Portal Call Center Source System Profiling Application ? ERP Workflow Data Warehouse

  14. BEA & Ascential Joint SOMDA Solution Step 2: Extract & Load Data to a Staging Database CRM Common Metadata Model Portal Call Center Application ? ERP Workflow Data Warehouse Extract & Load Staging

  15. BEA & Ascential Joint SOMDA Solution Step 3: Match & Link Records to Create a Customer Cross-Reference CRM Portal Call Center Application ? ERP Workflow Data Warehouse Staging Matching Service Survive Enrich Match Certify Standardize Load Transform Customer X-ref

  16. BEA & Ascential Joint SOMDA Solution Step 4: Create Application centric Data Services in Liquid Data CRM Portal Call Center Composite Data Services Application ERP Workflow Query, Transform, Cache & Secure Data Warehouse Staging Matching Service Survive Enrich Match Certify Standardize Load Transform Customer X-ref

  17. BEA & Ascential Joint SOMDA Solution BEA for application development, Ascential for x-ref keys and data analytics CRM BEA Portal Call Center Composite Data Services Application ERP Ascential Workflow Query, Transform, Cache & Secure Data Warehouse Staging Matching Service Survive Enrich Match Certify Standardize Load Transform Customer X-ref

  18. BEA & Ascential Joint SOMDA Solution BEA and Ascential are working on XMI based interchange of Meta Data CRM BEA Portal Call Center Composite Data Services Application ERP Ascential Workflow Query, Transform, Cache & Secure Data Warehouse Staging Matching Service Survive Enrich Match Certify Standardize Load Transform Meta Data Sync via XMI Customer X-ref

  19. The BEA Platform for Application Development

  20. Service-Oriented Architecture Real-Time Integration Services and Event Management DISCOVER PREPARE TRANSFORM and DELIVER Discover data content and structure Standardize, match, and correct data Transform, enrich, and deliver data ProfileStage™ QualityStage™ DataStage™ Parallel Execution Engine Meta Data Management Enterprise Connectivity The Ascential Solution for MDM Data Integration Ascential Enterprise Integration Suite™ Open, Service-Oriented Architecture Integrated Data Profiling & Data Quality Complex Data Transformation and Routing Reusable Components & Rules Unlimited Performance with Linear Scalability Enterprise Meta Data Management Anytime, Anywhere Connectivity Industry Standard Compliant (XML, EDI, JMS, JCA) Industry-Ready Integration Solutions Complementary To BPM, EAI, and EII Technologies

  21. Core Components of this Approach • Data Integration Service (ETL) • Matching Service • Data Integration (Composite Services)

  22. ETL Service Company Table Company x-ref CRM 1 CRM 2 ERP 1 DW 1 AT&T AT&T Wireless CRM 3 DW 2 Location Table Location x-ref 100 North 1st. Street CRM 1 ERP 1 CRM 1700 El Camino Real Ave CRM 2 • AT&T – One Hundred 1st Street • AT&T Corp – 1700 El Camino Real 3) AT&T Wireless – 250 Guadalupe Ave 250 Guadalupe Ave CRM 3 Matching Service Call Center 1) ATEndT– Unknown Staging Standardize Match Survive Customer X-ref ERP 1) AT&T Corp – 100 North 1st Review Table Data Warehouse ATEndT– Unknown 1) AT&T 2) AT&T Wireless Correct source

  23. Matching Service AT&T Inc. 100 North First CRM 1 CRM 2 ERP 1 DW 1 Matching Service Company Table Company x-ref CRM 1 CRM 2 ERP 1 DW 1 AT&T Standardize Match Return Match Keys AT&T Wireless CRM 3 DW 2 Location Table Location x-ref AT&T 100 North 1st. Street 100 North 1st. Street CRM 1 ERP 1 1700 El Camino Real Ave CRM 2 250 Guadalupe Ave CRM 3 Customer X-ref

  24. Liquid Data for Composite Data Services Liquid Data Functionality: • Services spanning multiple sources • Complex transforms for service definition • Caching and security policies • Modeling to organize services • Meta data management to ease service maintenance • Query optimization for performance • Validation rules for data consistency • WSDL generation: 4 clicks between query definition and WSDL generation Impact • Breakthrough productivity for creating and managing data services Client Applications Liquid Data Customer Payments Orders ERP CRM SQL

  25. Liquid Data Engine’s Internal WorkingCreates & executes an optimized path for each service request Result Request Check security & cache Cache results 5 1 Create optimized Execution plan Merge & Transform Data 2 4 Get data from underlying sources 3 Sub-query Sub-query Function Call

  26. Summary • A comprehensive master data approach is required • Understand and cross-reference source systems • Identify inbound records and relate to cross-reference • Liquid Data can then be used to create Composite Data Services • BEA and Ascential together can provide the necessary pieces

  27. Next Steps • Download the white paper: A Reference Architecture for Master Customer Data Management • For more information, go to: • http://www.ascential.com/mdmsoa/ • http://www.bea.com/mdmsoa/ • Contact your local BEA and Ascential representatives to get started

  28. Questions?

  29. Upcoming Webinars • August 31 - Centralizing Master Customer Data In Your Service Oriented Architecture, Nick Gall, Meta Group • September 2 - SOA Essentials: Modeling Legacy Applications as Web Services • September 8- Implementing Business Process Monitoring and Management Solutions • September 23 -Why a Message Broker is critical to your Enterprise Service Bus

More Related