Those moving toward SOA seem a bit confused by the use of data within a SOA. While most consider data as…well, data, those in the know understand that data needs to be a strategic part of the SOA for SOA to succeed as a project, or as an overall architectural strategy.

The trouble comes in when attention is centered on the “S” in SOA, which stands for services. Those charged with building architectures and systems, who focus on the notion of a service as delivering functional behavior, neglect the need to manage the underlying data. In many cases, data quality and consistency issues quickly arise, and the agility that SOA should provide is limited by the need to alter services directly after the underlying data has changed.

Most in the SOA community understand that data services provide controlled interfaces to underlying data, but typically don’t understand the strategic value of data services to the SOA. Data services, if created and leveraged correctly within the context of a SOA, should provide a wide variety of features including data quality assurance, data governance, and, most importantly, the ability to support data abstractions.

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. Done right, this provides a huge strategic advantage to business and enterprise IT, including the ability to change the underlying databases without driving changes to the applications that leverage the data services. Volatility exists within a single domain, and thus provides agility. Agility is the core value of a SOA.

However, moving to data services is not an easy path. You need to consider the design, implementation, and the right enabling technology.

The best practices around data services design are about moving from the top down. I suggest that you understand the data model at a logical level first, focusing on the business entities such as Customer, Sales, Inventory, etc., and then on the best physical/virtual structure that binds into those entities. Once that occurs, then you can link that physical/virtual structure to the physical database or databases.

Moving from the logical to the physical provides a few major advantages:

• You’re not constricted by the limitations of the existing physical database, or databases.
• You’re focused on the business purpose first, and then on the technology implementation.
• The logical design is durable over a long period of time, where the physical design typically exists within many instances of the database structure, and is where the changes typically take place.

What’s surprising to me is the number of people working on SOAs who don’t understand the value of data services. Working from the data up to the services within SOA is clearly a best practice, and what I see repeatedly in the successful use of SOA. We’ve been at this for awhile now. We need to get a clue.