Joe McKendrick, ebizQ's SOA in Action Blogger, is a nationally published author and consultant
with deep knowledge and insights regarding trends and developments in
the technology industry. He is a contributing editor to a number of
national and international publications and Websites including
Database Trends & Applications, ZDNet, and Webservices.Org. He also
serves as analyst for Evans Data Corp., and is lead analyst for Evans'
Web services and enterprise development management issues surveys.
SOA in Action Blog
|
« ESBs Promise to Untangle 'Rat's Nests' | Main | Ten Ways to Improve Your SOA » March 21, 2007Ultimately, SOA is About the Data Service-oriented architecture and enterprise data management have a lot of common ground, but tend to be treated as two separate entities. There are some industry observers who even say a well-designed data model, based on current database and data management technology can already accomplish all the things SOA promises. However, SOA and EDM have a lot they can offer each other. And it's time that SOA efforts include ways to surface data resources. "Just because a database is buried deep behind a service interface doesn't mean we can ignore the basic principles of data management," wrote Adrian Apthorp in a recent blog entry. In his keynote at last November's SOA in Action conference, Gartner's Roy Schulte did a great job of describing the parallels between EDM and SOA. EDM, in fact, was conceived long before SOA, but employed the same principles of reuse of a common base of data elements -- a concept picked up by SOA years later. "The theory was if you could have all these applications tied into the database, you could have one copy of the data -- all the applications could share that data." However, Schulte observed, "most companies found that although they did implement relational database management system, and although they did share data across multiple applications, they still could not get to one copy of the data. They still had 20 copies of the employee and the product data. And maybe 40 or 50 copies of the customer data." Can SOA help bring all that data into a common domain, or will SOA fragment the way the data world has? The jury is still out on that, Schulte said. Arpthorp said he has seen little discussion of the role of EDM within the service fabric. And he asks a very key question as to how data will be handled in this context: "How do we know that data passed through an interface is handled correctly? ...We cannot rely on a sea of services that are going to perform every validation for us - much of this will still be left embedded in applications. After all how would our services perform if every validation required a service invocation?" Arpthorp outlined the three key issues in making an EDM/SOA convergence a reality: Synchronization (including translation) of content: "Ensuring that reference data or master data are up to date and distributed to where it's required when it's required." Synchronization (including translation) of definition: "As with any language, establishing a single dialect for the business and implementing it in its information systems is probably not a reality, especially when many system components are sourced from outside the enterprise and/or need to interoperate with customer and supplier services. Is Oracle's semantic model the same as SAP's?" Data (and service) ownership: "Until this fundamental principle of data management is established many of the advertised benefits of service orientation will remain elusive." Enterprises need ways to cost-effectively access data from any application, running on any system, from any data format. Data warehouse and EDM providers are beginning to offer Web services through which end-users can direct queries and access analytical applications. Such services handle the computation and sifting of data, versus traditional SQL commands. Services run against data can also be components of CRM or ERP applications, and may access data sources and do the analysis to determine a product's success in certain markets, a customer’s profitability, or abnormalities that may signal fraud. Posted by joemckendrick in SOA | Digg This | Add to del.icio.us Trackback Pings TrackBack URL for this entry:
|














