The data you want depends on your point of view.
You're a field technician needing to see the type of wiring going into this house. You're in the collections department and wonder why the people in this house haven't paid their bill. You're the customer wondering why the charges you're viewing on the website, do not reflect the fact that you haven't had telephone service for two weeks in this house.
It's all data on the same customer, but not everyone looking at it is looking for the same data.
Using a telephone company example, Ken Rugg, vice president and general manager for DataXtend, the data services product from Progress Software Corp., points to an issue with data services: "What's important to the guy coming out to fix your lines, who might be interested in fiber optics, and what's important to you as a customer viewing your current account balances, and what the billing system want to see about you: those are different models and different views."
This is a problem with the concept of providing a single view of the data in data services, he argues.
"In terms of having a single view, that becomes quite challenging," Rugg says. "Not only are the views different, but some portions of that view. If you think about who in the organization owns the information related to billing, the account balances may be owned by the financial side of the business. For instance the billing address where they mail the bill, and the service address where they send a truck if there's a problem may be owned by different parts of the organization. Managing that distributed ownership, taking the data services approach of using a virtual common data model can come into play."
Examples of the common data model come from the telecommunications industry because it has a standard, the Shared Information/Data (SID) specification, writes Philip Howard, director of research - technology, Bloor Research. SID is an industry specific version of the common data model that Progress is advocating.
Howard recently defined the common data model in an analysis piece – "The Importance of a Common Data Model" on IT-Director.org – as providing "a data model that spans an enterprise's applications and data sources. In other words it defines all the data relationships and meanings that exist within an organization."
In that article, Howard said the recently updated Progress DataXtend Semantic Integrator is the leading and apparently only product focused on the common data model.
"As far as I know, this is the only such product of its kind available from anyone," he writes. "This makes it a market leading product albeit that the market is in its infancy. Briefly, DataXtend allows you to import definitions for a common model, create the relevant mappings, govern the use of a common data model in SOA, and manage change."
The Progress product provides the kind of agility for managing data that SOA provides for business applications, said Jason Bloomberg, senior analyst with Zapthink LLC.
"The SOA challenge that DataXtend addresses is in building and supporting the data services layer, which abstracts the underlying data in order to provide flexibility to the business services above the layer," Bloomberg said. "In essence, DataXtend brings agility to an enterprise's data in a way that complements and supports the agility that SOA already provides to business processes."
Rugg said the Progress philosophy behind its approach to data services goes beyond providing data access and mediation for SOA applications by using the common data model for mediation.
He said it helps developers be more productive because they don't have "the n-squared problem of having to map everything to everything."
A data service layer based on a common data model provides functionality for data services that can be compared to an enterprise service bus (ESB), Rugg argues.
"Because you have an intermediate mediation layer it provides a great deal of flexibility when things do change," he explains. "It's analogous to what ESBs and SOA in general bring to integration by providing agility through loose coupling between your services at an interface level. A common data model approach gives you a similar benefit at the semantic level, the data formatting level."
The agility derives from the virtual nature of the common data model, which Rugg positions as more flexible than the master data management (MDM) approach.
"One of the challenges you'll find with a master data management approach is that in effect you've created another silo," Rugg says. "You've created another database, another materialization of the information model."
However, he does acknowledge that there are use cases where the MDM approach may be well suited.
"In some cases that's valuable," he said of MDM. "Sometimes you want to do that and create a projection that can support a new use case. Maybe you have a Web presence where you're trying to create a cached view to support customer self-serve or provide a higher bandwidth or support more responsiveness within a call center."
But there are also limitations to creating a single view of the customer that Rugg sees as a limitation of the silo approach.
"That doesn't mean that everyone wants the same view of the customer," he said. "They want to make sure they have the same customer and it's consistent, but that's not the same as being the same."
This goes back to the field tech wanting the wiring data for the phone customer, while accounts payable wants the billing status.
Rugg argues that the limited single view of the data approach leads to a misunderstanding about data services.
"There's confusion when people think of data services, they sometimes pigeon hole it into something more like an EII [enterprise information integration] scenario where you have distributed queries and everything's going through a layer of access between your accessing applications and your databases."
Progress is moving beyond EII and MDM approaches by providing virtualization for data services, he said. But it also allows for the single view of the data when an application requires it.
"Our view is that virtualization is at the logical, management, governance level but we may want to physically materialize another cache view to support low latency to the self-service website or create a materialize relational view to support an existing system where you don't want to convert over to take this new data services approach," he said.
This virtual approach provides the best of both worlds, Rugg said.
"You can really have your cake and eat it too, in terms of creating the responsiveness, creating the data that's available and in a format that is ready to be used, while at the same time getting the advantages of this common data model," he said.