DOA your SOA?

I like a lot of the stuff that Dave Linthicum writes but I don't agree with his latest post on why people should start with the data when doing SOA.

First off lets be clear, data is important its one of a few really important things in SOA

1. Services
2. Capabilities
3. Real World Effects
4. Data

Now I've deliberately but them in that order because that is the order I think is important. I've said before about SOA v POA and how I think you know that you are doing SOA. The key point on this is that a stack based view of

But the fact is you need to start with the data first, than work up to services, than the agile layer (process, orchestration, or composite). If you follow those basic steps you'll find that the solution is much easier to drive.

just doesn't work for me. It first of all implies a technology centric view of SOA that I don't agree with and secondly places services as just an intermediary between process and data, with the goal surely being to do more and more in the "agile" layer (although those of us who have done large BPM and composite projects probably aren't sure about the agile bit). This stack based view isn't going to progress IT, it might help with a single project but surely the goal of SOA is more than that?

To me this plays into the technology centric change view of much SOA advice out there. To me data is important but it is only important where it works this means understanding the services first.

Now if Dave is talking about having done the business services how he'd look to realise them with technology and that he'd have a single business governance piece over the service dealing with the data, process and other elements then I'm with him. But starting with data for your architecture.

To me that means you have a Data Oriented Architecture, and I can't see anyone selling to the business that the next project is going to be DOA and the goal is the whole IT estate to be DOA within 5 years.

So start with the business services, understand the business capabilities, understand the real world effects and then understand what data is being exchanged and managed to deliver that. Data is important, very important, but if you are taking a business view of modelling SOA then its just one of the technical artefacts, not the major purpose for existence.

Technorati Tags: SOA, Service Architecture