The Agile Manifesto has become a leading reference for agile software developers mainly for two reasons: it was written by thought leaders, and it's written in a very short and accessible format. The format highlights the core values of agile software development by stating what matters more out of two good things and then goes on to provides principles that explain and expand upon those core values. SOA has matured in recent years and recently a group of SOA practitioners/writers/authors saw fit to create a SOA Manifesto using the format of the Agile Manifesto in an attempt to similarly help the SOA community of developers and users. The SOA Manifesto was recently worked out at the 2nd International SOA Symposium in Rotterdam. Prior to meeting in Rotterdam the authors prepared their own draft manifestos based on their own insights and that of their peers.
As reported elsewhere the discussions at times were quite intense, as could be imagined with something as important and yet often ill defined as SOA. However, consensus was reached, though as with any working group not everyone got everything that they wanted. Although the discussions in Rotterdam were intense at times, in the end the group came to a surprisingly high level of consensus. The manifesto was first announced at the SOA Symposium and this announcement was recorded:
In the short time after the manifesto was published there have already been quite a few comments, some positive and some negative. In order to follow the original Agile Manifesto style, the SOA Manifesto is short and to the point. However, this may also lead to a weakness in the presentation. To describe a lot of information in few words will inevitably lead to statements that are open to different interpretations. For example one can interpret the statement “Intrinsic interoperability” as being a strong suggestion to buy an ESB and base all the interoperability on its standardized capabilities and formats. However, it would seem that during the discussions in Rotterdam the members of the group rather seemed to be thinking about designing interoperability into the services from the very start. The latter interpretation of this statement also plays nicely with the principle that states that products cannot give you an SOA.
If the SOA Manifesto is to become widely accepted the SOA community must first agree upon how these statements should be interpreted. If not, the discussions will never come to an end and the SOA Manifesto will not be able to contribute to filling the empty void of the SOA community: a shared understanding of the core values of SOA. As such it is important that all of the Manifesto is read in its entirely and the authors perhaps follow up with an in depth discussion of what they were trying to achieve. Without this happening in quite short order, it is possible that the Manifesto could become sidelined by much more vocal discussions around it that are perhaps based on misunderstandings.
Note, content co-authored by Herbjörn Wilhelmsen.
