As we discussed in my last blog post, when building a SOA, data abstraction is the single most important approach and enabling technology when it comes to managing data within a SOA.

“Data abstraction is the key. It allows you to fix issues with the existing physical databases within the data service itself. Moreover, you can combine many different databases, and even unstructured information, into a single unified view of the data that is more representative of the business.”

Let’s walk further down this road. When using the approach of data abstraction, and data abstraction using data services, you’re able to emulate the desired data and data structure without having to recreate and restructure the physical databases, nor having to statically bind the services to the physical data. The core value of this is agility, but there are many other advantages as well, including:

• The ability to decouple the physical data from the services, thus allowing the SOA architect to make adjustments to the physical data, without driving changes to the services. Or, to the services, without driving changes to the data. Thus, you place volatility in the domain of the data abstraction layer which is adjusted through a configuration mechanism. When you consider design and ongoing productivity, this provides agility and value.
• The ability to design a data abstraction layer that will best serve the SOA, but will also leverage existing data stores. This means you can structure the data, distributed or not, so that the virtual data structure can meet the requirements of the new or existing services within the SOA. This typically means providing better logical groupings of the data (e.g., sales, inventory, customers, etc.), and the ability to eliminate data redundancy. For instance, the numerous times the concept of “customer” is defined across different systems, coming to a logical agreement for “customer” and linking all redundant data elements to the single instance of “customer” in the virtual database.
• The ability to provide data integration as a subsystem in support of the SOA. Since the data abstraction layer is made up of many distributed systems, databases, and data stores, it provides a natural point of integration for the SOA. In essence, dozens of distributed databases and applications are able to appear as a single logical database in service of the SOA. Thus, you reduce complexity, enhance agility, and allow the architects to deal with changes to the data, or services, using a configuration vs. a redevelopment approach.
• The ability to recast data as data services for use within the SOA. Thus, not only can you restructure the existing physical database using a new virtual structure, but you can also expose the new structure as data services that are exposed, leveraged, and managed within the SOA.

Clearly, the use of a common virtual database model using data abstraction is a core requirement to build a SOA that’s both agile and cost effective to operate in the long term. This does not eliminate the need for good design and advanced planning, but the end state architecture will provide a much better ROI when leveraging this technology.