The search for boundaries and a definition for SOA

I sat in on the Architectural summit session at PDC yesterday on defining Service Oriented Architecture. While it was a good panel discussion with some lively arguing between the panelists about what really constitutes SOA, it was clear that this is another one of those areas that is going to take years and scores of real implementations to try to define what the boundaries are that constitute a SOA.

In fact, most of what they were talking about was not defining SOA at all, in my opinion, they were really just trying to define the S. Most of the discussion really was centered around what constitutes a service and a lot on contrasting the way you compose systems out of services as opposed to objects or components. But an architecture is a lot more than just saying how things are connected. You have to address all the fundamental aspects of scalability and performance, security, reliability, as well as satisfying the business requirements.

Granted it is a little difficult to get to that if you are tied up quibbling about the definition of what SOA is. And no, I won’t even take a shot at coming up with my own definition until I have actually tried to build some real systems using the fundamentals that most people agree are part of SOA.