The overloaded paradigm matrix of heterogeneous understandings of “what SOA really is” demanded a consolidation – given a plethora of different guidelines, principles and best practices. Even if you look at the closed Thomas Erl universe of SOA books it is a daunting task for the busy architect to grasp the essence and derive well-defined corridors for his project.
Thus, a group of SOA representatives from vendors gathered with analysts and book authors in Rotterdam last week and worked on the core values and rules for Service Oriented solutions. On Friday 23rd of Oct. they presented their result of hard, sometimes tough collaboration work at the end of the SOA Symposium which is an aggregation of the principles on the basis of a hard earned consensus of some of the main SOA thought leaders: The SOA Manifesto (www.soa-manifesto.org).
The debate has started
As you could have anticipated, a heated debate has started in blogosphere already with flames rising high – some pro, many very loudly against the manifesto as well as against SOA in general. Opposing many of the complaints in the posts, I think it is good that the manifesto was written by both vendor representatives and independent thought leaders: Both could not get their individual beliefs published but they needed to find a compromise – and from what I observed they worked very hard on finding that compromise – so unlike many say, the manifesto is not a vendor’s view! It states clearly you cannot buy SOA through purchasing an ESB! On the other hand, it is not a hard core REST proponents view as well. What I like is that the result is still not lame. For me, the following aspects bring real value by their emphasis on aspects that distinguish a successful SOA initiative from a flawed one.
The SOA Manifesto emphasises
diverse social and cultural aspects that should be respected. This notion demands thorough management of change
diverse solutions based on the context. I personally believe this is key and that along this notion the term SOA will diversify in the next years. Similar to the “forces” in good old object design pattern, the context should determine designs, tools and the degree of virtualization! The decision should be justified along criteria such as requirements for agility, reuse and criticality and the organizational level for which the solution is built: You might not need in ESB in some integration optimization for a local department. On cross departmental / enterprise level it could be well justified
business value first
understanding the conflict between the interest of the project manager and the interest of the strategic goals of the overall enterprise (the problem is that the latter often has no stakeholder!)
a strong architectural standpoint – not tools – at the center of successful service orientation
loose coupling and separation of concerns (oddly the manifesto is never directly mentioning both, but they are the underlying principles that shine through the manifesto).
What I miss is an even stronger argument that Service Orientation implies organizational change – Service Orientation is the antidote against silo thinking! This is hinted at in “Recognize that SOA ultimately demands change on many levels.” – unfortunately the levels (technical and organizational) are not mentioned.
The SOA Manifesto is another important starting point
The SOA Manifesto has the potential to frame a constructive discussion on how to shape the future of enterprise computing: SOA (or whatever we will name the ongoing evolution from objects to components to services to whatever, maybe services that have event based interfaces and are used by more and more agile processes) will further evolve and architects will learn to understand when best to apply which degree of loose coupling – we don’t need SOA and loose coupling everywhere! I see Service Orientation as an architectural pattern that only applies when certain forces are prevailing. Thus I appreciate that the manifesto does not ask to “SOAficate” the whole IT. Some applications are to stay untouched with all their point to point connections and it should be recognized that loose coupling comes with a price tag.
A short discussion with the group
To delve a bit into the text and its making process, here are some thoughts that stem from discussions with my good friend Clemens Utschig-Utschig, as well as with Dirk Krafzig, Nicolai Josuttis, Dave Chappel – all ground braking book authors, Anne Thomas Manes – “SOA is dead – long live services” and some of the other authors. The conversation took place right after the presentation of the SOA Manifesto on Friday evening in the exhibition hall.
After reading the printed manifesto, I congratulated the group for the simple and easy to understand language and this compliment was well received, you could see that this was a major concern and goal. Yet, I said, for me the only sentence hard to grasp was the third value:
Intrinsic interoperability over custom integration
What actually is “intrinsic interoperability”?
I learned from our discussion that a service has intrinsic interoperability if it is easy to use, it’s semantic is clear and there is as little integration hassle (Adapters, Transformations etc.) as possible. Anne added that a REST based service has better intrinsic interoperability than a WSDL based service because the technology footprint is smaller. I would agree, but regard REST applicable in other context than WSDL, so an architectural decision should take non functional requirements into account as well.
To deeper understand intrinsic interoperability Clemens later emphasized the importance of a well established canonical data model that is used across services and further conventions that make the service easy to understand and use.
… and what is a service that needs custom integration?
Asked another way: What is a not so well-behaved service? Here, Anne dismissed extrinsic services that are not easily reusable: A typical example is a proprietary API, either of a packaged application or of a legacy system that is exposed through a Web Service layer. This design tightly couples consumers of services to implementation details and thus needs lots of further custom integration if a consumer needs that bit of functionality: Data must be mapped, implementation-level IDs must be resolved etc. Anne referred to such services on top of existing APIs as “lipstick on a pig”.
I like that metaphor as I regard a respective “right-click service” based on existing APIs as one of the most fundamental anti patterns in naïve “SOA” projects and as one of the main architectural root courses for failure of solutions in the long-term because it does nothing to prevent from a badly maintainable system landscape and lead to a tightly coupled design. This shows that with the sole application of WS-Standards nothing is achieved, you just have a new interface technology (WSDL, SOAP instead of CORBA, EJB, FTP or COBOL copy books) on top of the old, often, not always, messy systems. Such pseudo services, if directly exposed for public usage are the latest “Emperor’s New Clothes” – transparent “Ugly SOA” wardrobe on the still naked king.
A way to deal with API-Service is to understand them as “Private Services” – implementation details of Business Oriented “Public Services”, the latter focusing on the consumers and its needs, completely abstracting from underlying proprietary data schemes, programming languages, platforms etc. The trick is to never expose those details of Private Services, but translate them to the needs of the public interface behind a service facade. I think this “Public/Private Service Pattern” serves well the discussed value Intrinsic interoperability over custom integration.
And now: Best Wishes!
I wish for the SOA Manifesto to serve as a guiding foundation for many proposals and solutions in SOA space – similarly as the Agile Manifesto served beautifully well for many to start thinking Agile.
Further Reading
As well Thomas Erl, Anne Thomas Manes and the audience exorcised the over-hyped “Evil SOA” of false marketing promises as a further development of Anne’s famous blog entry “SOA is dead”. After the dramatic departure of Evil SOA, they embraced the “Good SOA”, which emphasizes the importance of thorough architectural efforts and governance.
Adventures in SOA and BPM 
