The SOA Manifesto: Business Value and Architecture First

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 (








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


    6 responses to “The SOA Manifesto: Business Value and Architecture First

    1. Pingback: SOA Manifesto revisited | SOA Governance - Service Oriented Architecture - SOA Business - SOA Design - SOA Services - SOA Software - SOA Solutions - SOA Security - SOA Web Service

    2. Pingback: SOA Manifesto: business focussed and agile

    3. Nice write-up. I also critiqued this manifesto, not for its goals, but felt the value statements were not on-point:

      • Thanks, Jordan, you have great points on your entry, I just linked it in the Further Reading section.

        Still, I embrace the value 2 “Strategic goals over project-specific benefits”, because it emphasisis that a decision has to be made on how much strategic aspects influence my SOA solution:

        For example, will I need to register my services in a registry? From local project point of view maybe this is just not necessary, but when you want your services to be discovered and reused, you might want to go the extra mile, depending on you strategy. Just a side note: The aspects on the right side of the values are not disregarded, so project concerns are seen important.



    4. “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.”

      Ahh reading language like this a glimmer of light begins to dawn in my poor befuddled developers brain. The people who keep handing me these over architectured, bloated performance killing SOA specifications actually think in such overblown bloated language.

      Excuse me while I get back to my “overloaded paradigm matrix” . Lol.

      • Mark, thanks for your comment! I see your point and thought about it myself whether this sentence is too bloated. But, I liked it then ;-).

        But I agree that SOA based specs are too right from the SOA ivory tower and, yes, we could see a lot of performance vs. loose coupling issues in our projects. You summarized a concern that is a challenge for SOA projects. I hope we all will find ways for agile, lean, clear ways to design specs for SOA based software.

        Cheers, Hajo

    Leave a Reply

    Fill in your details below or click an icon to log in: Logo

    You are commenting using your account. Log Out /  Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out /  Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out /  Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out /  Change )

    Connecting to %s