SOA Manifesto

I spent today at the SOA Symposium in Rotterdam, taking part in a working group that tried to define a manifesto for SOA. Here's the result.

I'll spend some time elaborating on the content tomorrow, but up front, I'd like to state my reasons for participating in this effort. I'm not exactly known to be a web services fan, so I had numerous people ask me why I'd take part in something like this. To my view, this is not at all a conflict — I see SOA as a high-level approach than can be realized with multiple sets of technologies. While I believe that RESTful HTTP is actually the best option out there, I concede that people might think differently about this. But there are some high-level goals that are independent of the architectural style and being used.

So I believe that SOA is a good idea, I also believe that web services based on SOAP/WSDL/WS-* suck, and I believe that REST is a perfect match for SOA. Of course this statement would be entirely meaningless if you defined SOA as the architecture of web services. I don't.

The reason for the manifesto being somewhat vague, in my opinion, is a good one – describe the values that are common to those who aim to improve upon the typical company's IT landscape, regardless of the actual technical architecture.

Comments

On October 23, 2009 10:05 PM, blog.whatfettle.com

said:

I’m sure you all had fun, but it’s the total vagueness which renders this manifesto circular, meaningless nonsense. From where I’m sitting, orientation around “services” and letterboxes into applications seems to be dead anyway. Roll on the era of data integration.

On October 23, 2009 11:00 PM, Dhananjay Nene said:

SOA is a great idea irrespective of whether one brings REST into the discussion. However “REST is a perfect match for SOA” is confusing. (I had documented a very contrasting view some time back here - http://blog.dhananjaynene.com/2009/10/service-oriented-rest-architecture-is-an-oxymoron/ ). However notwithstanding that as well, there are some serious practical difficulties with the said manifesto. A quick reaction to just some of its parts :

a. Business value over technical strategy, Strategic goals over project-specific benefits

This should be a part of any general business manifesto (it will apply to all architectures and all other issues unrelated to architectures as well). There is nothing SOA specific about it at all. Its just a big motherhood statement.

b.Intrinsic interoperability over custom integration. Shared services over specific-purpose implementations

Aren’t the biggest reasons why this is hard to achieve, the first two items (business value and strategic goals). Typically shorter term iterative and incremental development which may involve custom integration and specific purpose implementations are argued to be better consistent with business value and strategic goals.

c. Evolutionary refinement over pursuit of initial perfection

This is a great statement but seems a little misplaced in the context of the remainder.

Similarly on guiding principles :

i) Respect the social and power structure of the organization. and ii) Recognize that SOA ultimately demands change on many levels.

Isn’t it uncommon to find that the ultimately demanded change actually points back to he social and power structure ?

iii) The scope of SOA adoption can vary. Keep efforts manageable and within meaningful boundaries.

Isn’t it that the very attempts to seek strategic goals over project specific benefits ends up impacting the manageability of efforts and the meaningfulness of boundaries negatively ?

Unlike the agile manifesto, I thought this particular manifesto makes too many generalised statements and perhaps hasn’t clearly worked through some of the potential inconsistencies in the document itself. Shall certainly be looking forward to your elaboration.

On October 23, 2009 11:40 PM, Mike Parsons said:

Why is it again that we need a Manifesto? Sounds like a way for consultants to rationalize their billing rates.

On October 25, 2009 6:10 AM, Anonymous said:

This manifesto is applicable for building distributed systems and/or applications and for architecture in general. I like this.