Thoughts on the SOA Manifesto
By clemens.utschig on Oct 25, 2009
During the 2nd international SOA Symposium in Rotterdam, I was invited to participate in a working group to define what would become known as the SOA Manifesto. Certainly a big honor to be part of this group, but with the little time we had - a lot work would lay ahead.
Reflecting on the last days - it was an experience, a lot of heated up discussions, extremely strong & powerful arguments, the 'fresh air breaks [Kudos Steve]', and what was most impressive, an immediate common understanding of what service orientation and SOA is about - the business, everything else is second.
On a side note: All the people involved in this have spent massive amounts of time with customers, and helped implementing strategic, sustainable SOAs all over the world. Hence the last thing one can expect is to read terms likeESB / one can buy SOA / and what not in there. If you waited for that you will be disappointed.
The whole manifesto can be found at http://www.soa-manifesto.org/.
Here is the value system we came up with, which stands at the center of our beliefs when it comes to SOA.
Business value over technical strategy
Strategic goals over project-specific benefits
Intrinsic interoperability over custom integration
Shared services over specific-purpose implementations
Flexibility over optimization
Evolutionary refinement over pursuit of initial perfection
That is, while we value the items on the right, we value the items on the left more.
I plan to add commentary over time, but here is the first set.
a) Generating sustainable business value: The notion of service is derived from capability, which should be directly linkable to a business requirement. Implementing fancy technology is cool, and solid technical strategy important. But if one stands against the other, pick what generates business value
b) Strategic goals: While for many initiatives a quick win is key to get them started, commonly referred to as guerrilla SOA - we should never loose the focus on the strategy and the long term goals set to make it happen. A tactical quick win results way to often in throw away code.
c) Intrinsic interoperability: I remember Anne and me having interesting arguments over this one, likely English not being my mother tongue helped this. The key is to create services that allow for integration by their very nature. This can be accomplished through exposed protocols that everyone can understand, yet driven much further by a common data format. At that point reassembling does not require changes to the underlying communication architecture, and only new services are added.
d) Shared services: While we value (custom) specific purpose implementation, the creation of shared (that is [re]usable) services takes precedence. We know that this is a journey, and it introduces a need for governance, service ownership and a thought through concept of versioning.
e) Flexibility: While we value the need and push for optimization, flexibility comes first, but is a carefully weighted trade-off. With loose-coupling on the implementation / communication protocols - speed in fact might go down, while the ability to recompose / switch implementation will go up.
f) Evolutionary refinement : Too many people strive for initial perfection, very much waterfall centric rather than allowing for continuous refinement. This value compared with adapting / refining based on real world usage is targeted towards start small (yet wisely) rather than with a big bang.
Now what do these values mean for you? They, including the guiding principles, should help you to make the hard decisions and serve as reminder, guiding path throughout the implementation.
Stefan has added a much longer list of thoughts and commentary, which you can read here.
We look forward to comments and thoughts. If you want to become a signatory, you can do this here.