Ronan Bradley's FinanceTech Directions

My last blog item “SOA is not just data” reignited an important debate – whether the data model or the functional definition is the most important dimension of SOA – and which is a subset of the other! Of course both are always present in SOA and the reason debating the issue is important is that it is easy to focus exclusively on one or the other without careful consideration of where the balance between the two should lie for your problem domain – a mistake which may cause you to create the wrong architecture and select the wrong products to implement that architecture.

Responding to my piece, David Linthicum represented one perspective on the data/function debate when he wrote:

Truth-be-told, services can be anything really. They can abstract data, they can produce or consume data, even restrict access to data. However, considering the notion of reuse, the most ROI from the creation of services is the ability to provide true behavior or more simply put: application functions with data bound to those functions.

And used Calculate_Risk(); as an example of a function which is purely behavioral. Taking that example, Ipedo’s Tim Matthews explained the other perspective: that application functions are types of data abstractions:

First, data services [Tim’s term for data based services] can support application services (get me customer data, get me risk profile, get me consolidated sales figures, etc.). Second, many Web Services [Tim’s term for application function based services] really are just data services, allowing easy access to information.

In the past, these differences in perspective have been reinforced by artificial technology and product differences that forced you into deciding to go exclusively down the ETL route or the EAI route. These boundaries have broken down due to the XML and Web Services standards which allow both data and function to be addressed within the same framework and which allow products to be developed which can mix-and-match capabilities traditionally associated with only ETL or EAI. As Tim puts it:

I also think you'll see more and more use of EII within ESBs, where ESBs will call a Data Service that is mediated by an EII product.

However, my view is not that the data and function are now the same thing and hence you don’t need to make choices about which to focus on. Rather, the balance between focus on the data exposed through the service and focus on the functionality exposed through the service depends on the type of organization and type of integration you require. If you business tends towards business processes which are primarily multi-step coordinations across applications which are self contained and transmit little data between them – then the predominantly functional approach suits. However, if your business shares and exchanges large amounts of data between the applications – then that emphasis on data must be incorporated within your SOA.

What started this discussion was my observation about data being at the heart of SOA. What appears to be happening is that while people may start from a predominantly function based perspective on SOA, as organizations get further into SOA it is becomes increasingly obvious that the emphasis must move into the middle and balance function with data.

Again, this is different to traditional EAI which primarily solved coordination problems and which left data to ETL products. To use some terminology David coined in his EAI book, I believe that all of this supports my long held view that the SOA future will require a seamless combination of what used to be called Information oriented and service oriented integration – under the umbrella term of Service Oriented Architecture.