The Role of an EDW in an SOA


Published on

For more information, visit

Published in: Technology
  • Be the first to comment

  • Be the first to like this

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

No notes for slide
  • There are many parallels between data mart consolidation and SOA. One might say the Java and .Net architects are “normalizing” their code, much the same way we normalize a database design. With SOA we have inconsistent data definitions and processing for the same data elements in multiple applications. We also have considerable amounts of duplicate logic in the applications since they all need to handle such things as currency conversions, price discount schedules, etc. These duplicate independent modules also demand a minimum set of middleware and hardware infrastructure, gobbling up the IT budget on duplicate processes. Last, these independent processes require duplicate labor for maintenance, research, and enhancements. Since each application is independent, a simple business required change can take days or weeks of research to validate implications, get the right modules selected for enhancement, and then upgrade and test multiple application components. This sounds a lot like data marts where duplicate data demands excessive infrastructure, hardware, labor, and maintenance. So, like DMC, SOA is a long term objective to consolidate many applications into one integrated set of Web services modules. As time progresses, the TCO of the applications decreases and maintenance becomes both cheaper and easier. Like Data Mart consolidation, the value of the composite application increases as more and more applications are decomposed and combined. Just like adding subject areas to the data warehouse, adding a collection of SOA modules from a new application to the baseline SOA collection increases the value of the entire collection. It provides new business process capabilities by allowing old processes to integrate and interact with new ones. So, like blending “customer” and “product” and “sales” data, blending the “order entry” application with “sales automation” and “marketing automation” produces new views of the business, new capabilities.
  • The Role of an EDW in an SOA

    1. 1. The Role of an Enterprise Data Warehouse in a Service Oriented Architecture David Brand Senior Solution Architect Teradata Corporation
    2. 2. What Is SOA? <ul><li>Service-oriented architecture (SOA) provides methods for systems development and integration where systems group functionality around business processes. SOA allows different applications to exchange data with one another as they participate. </li></ul><ul><li>SOA aims at a loose coupling of services with operating systems, programming languages and other technologies that underlie applications. SOA separates functions into distinct units, or services, which developers make accessible over a network in order that users can combine and reuse them in the production of business applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. </li></ul><ul><li>Translation: </li></ul><ul><li>Define business processes in code </li></ul><ul><li>Make code modular and system independent </li></ul><ul><li>Place code modules in an accessible framework </li></ul><ul><li>Build once, use many </li></ul>
    3. 3. SOA and EDW Have Much in Common <ul><li>SOA Does for Applications what Data Mart Consolidation Did for Databases </li></ul>EDW Shared Subject Areas Application Process Code Data Marts duplicate code “versions” duplicate data “versions” app1 specific data app2 specific data app3 specific data shared Web services and middleware App1 App2 App3
    4. 4. Where Did SOA Come From? <ul><li>SOA is the natural evolution of object oriented programming </li></ul><ul><ul><li>Originally code was linear (BASIC, FORTRAN, etc...). We literally copied similar code from program to program </li></ul></ul><ul><ul><li>Programs got more complicated and turned into applications which were collections of programs </li></ul></ul><ul><ul><ul><li>Still had to copy code to share it </li></ul></ul></ul><ul><ul><li>Object Oriented Programming allowed programs within an app to share functions that did the same thing </li></ul></ul><ul><ul><ul><li>Call sales_revenue( product, date1, date2 ) </li></ul></ul></ul><ul><ul><li>SOA does the same thing at the next level </li></ul></ul><ul><ul><ul><li>Allows multiple applications to share functions that do the same thing </li></ul></ul></ul><ul><li>SOA is an application development and deployment framework </li></ul><ul><ul><li>Microsoft .NET is by far the most commonly used </li></ul></ul>
    5. 5. SOA Does Not Equal Federation <ul><li>Some people, especially consultants, have created the message that SOA=Federation </li></ul><ul><ul><li>Play the data where it lies </li></ul></ul><ul><ul><li>Create a virtual EDW </li></ul></ul><ul><li>To be fair, data management tasks can be performed by services </li></ul><ul><ul><li>Significant effort for something that already exists </li></ul></ul><ul><ul><li>Issues such as metadata management and data security can be nightmares across different organizations and applications </li></ul></ul><ul><li>Why is this perspective being pushed? </li></ul><ul><ul><li>It sounds good (“virtual EDW”) </li></ul></ul><ul><ul><li>It is very lucrative (lower infrastructure cost = higher consulting revenues) </li></ul></ul>
    6. 6. What Does Data Management Do for SOA? <ul><li>Data Quality </li></ul><ul><ul><li>Without centralized data management, you will frequently be combining data from multiple sources. </li></ul></ul><ul><ul><li>Which data is correct? </li></ul></ul><ul><ul><li>How does the data relate? </li></ul></ul><ul><li>Performance </li></ul><ul><ul><li>Dependent on/puts pressure on source systems. </li></ul></ul><ul><ul><li>Collation/distribution dependent on application servers. </li></ul></ul><ul><ul><li>Not scalable. </li></ul></ul><ul><li>Application Complexity </li></ul><ul><ul><li>Without a strong data management layer, all of the data management tasks (relationships, business rules, security, metadata management, etc...) have to be built into the SOA layer. </li></ul></ul><ul><ul><li>Places great pressure on application developers. </li></ul></ul><ul><ul><li>Tends to limit the complexity and usefulness to the business of the apps that are developed (lots of dashboards). </li></ul></ul>
    7. 7. Why Do You Need Data Management for SOA? <ul><li>Complex Queries Require Complex Programming </li></ul>Obj1 SOA LAYER Obj2 Obj3 Obj1 Collate Object SQL Result Set SQL Result Set SQL Result Set SQL Result Set Result Set USER Request Result Set USER Request Request Result Set Request Result Set Request Result Set
    8. 8. How Does an Enterprise Data Warehouse Enable SOA? <ul><li>Allows for storage and management of data from multiple systems in a single, scalable platform </li></ul><ul><ul><li>Enhances performance </li></ul></ul><ul><ul><ul><li>Removes dependency on individual source systems and application servers – “a chain is only as strong as its weakest link” </li></ul></ul></ul><ul><ul><ul><li>Assumes a scalable, powerful, integrated data management platform </li></ul></ul></ul><ul><ul><li>Removes issues of data quality </li></ul></ul><ul><ul><ul><li>Data relationships, business rules, etc... are maintained in the database where they are much easier to handle </li></ul></ul></ul><ul><ul><li>Removes issues of application complexity </li></ul></ul><ul><ul><ul><li>Function calls are much simpler </li></ul></ul></ul><ul><ul><ul><li>Dramatically speeds up application development time </li></ul></ul></ul><ul><ul><li>Can be done very cost effectively today versus historically </li></ul></ul><ul><ul><ul><li>Wide array of choices available both in terms of vendors and products </li></ul></ul></ul>
    9. 9. Contact Us <ul><li> </li></ul><ul><li> /company/Teradata </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul><ul><li> </li></ul>