I have firmly believed that a day would come when it would be you, my fellow integrators, telling me that one needs to data-orient first before benefiting from service-orientation. That day has indeed come!

Just recently, I created a quick one question survey and sent it off to a number of application and enterprise architects as well as IT managers at leading enterprises. The question was:

• What are the top three things on your mind as you architect or re-architect your infrastructures?

There was a common thread across the responses that I received:

• Service-orientation or an architectural approach to increase the speed and agility of how IT responds to a business’ requests,
• Doing more with less or something to that effect, and
• An easy way to leverage all relevant information, when it is needed and how it is needed

When I saw these responses, the pragmatic part of me started to build a list of questions in my head and I decided to call a number of these professionals and get the real scoop on their selections.

Here is what I heard…

* An enterprise architect at a global sporting goods manufacturing company, told me that the IT organization had just completed a three-year project to service-orient its infrastructure in order to help streamline operations. However, he told me, they were stuck and didn’t know how to move ahead as this new infrastructure, which included an ESB, could not support large files. Large files are used by the company to move their business critical order and product data once a day across their supply-chain management systems.

* An application architect at a leading financial services company had a problem with the quality of the data that was being delivered to his reports. As is their tradition, his company had just completed another round of acquisitions, and once again his reports were missing crucial customer data from the newly acquired company. Although the IT organization had service-oriented its infrastructure based on state-of-the-art technologies, it was a challenge to quickly understand what was in the new data sources and handle any inaccuracies and inconsistencies.

* Another enterprise architect from a large insurance company couldn’t hide his frustrations about the fact that every time something changed in the underlying data layer, the impact was huge. Every time a data source was changed or replaced, which was frequently, the integration logic in the consuming layers had to be rebuilt. He wanted a way to easily abstract the data layer from these frequent changes. According to him, the ideal solution would be for this layer to provide the necessary insulation and deliver all relevant data as reusable standards-based service.

* The enterprise architect at another large insurance company felt that there was no way to easily deliver an accurate, single-view of business entities such as “CUSTOMER,” “PROVIDER,” and “MEMBERSHIP” data, to their web portals. What they were able to achieve within their implementation was enabling the access of data across the diverse data sources and delivering the data as a Web service. But, when it came to doing complex transformations or ensuring that the quality of the data was as required, they had to resort to hand-coding or other sub-optimal means.

It is becoming increasingly clear that any effort to service-orient an infrastructure needs to start with a hard look at data integration. In his recent blog entitled “Understanding Data Services In Context Of SOA”, David Linthicum says that “Working from the data up to the services within SOA is clearly a best practice.” There seems to be a crystal-clear message here that “data integration” needs to be top of mind for anyone architecting their infrastructure for speed and agility.

So, if you are looking to service-orient your infrastructure, I would suggest that you data-orient first by doing a 5-point check to make sure that the foundation has the following capabilities:

• Easy access of all relevant data, including new or rapidly changing data sources
• Processing of data as batch, CDC or real-time, including handling large volumes of large data sets
• Proactive identification and resolution of data inaccuracies and inconsistencies
• Application of complex data transformations on the data
• Delivery of data, exactly when it is needed, as a standards-based data service

In my next blog, I will dig deeper into each of these requirements.