Tag Archives: SOA

3rd International SOA Symposium makes Berlin 2010’s capital of SOA

The SOA Symposium is the world’s largest SOA event, organized by bestselling book author Thomas Erl. In recent years, the event took place in Netherlands. This year Berlin is hosting the “3rd SOA Symposium and 2nd Cloud Symposium” on October 5 and 6 2010.

A look back at last year’s SOA Symposium
I attended the event last year as a speaker and was impressed by the depth and practical relevance of the presentations by Dirk Krafzig, Nicolai Josuttis, Joe McKendrick and others. Not too often the leading SOA thought leaders gather at one place so they seized the opportunity and created the SOA Manifesto.
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.

I am curious about the events Thomas plans for this year.

For me personally, it was a very succesful event: Torsten Winterberg, Clemens Utschig and myself presented on “Next Generation SOA” in a packed hall. As well I got introduced to a representative of a customer of HP, which led to a great opportunity to work in Amsterdam this spring.

Highlights of this year’s tracks
As a member of the SOA Symposium Group I am familiar with this year’s program and track structure – and I have to say that it looks very promising! I am happy that “BPM and SOA” is a very strong track investigating enterprise modeling aspects. The track “BPM, BPMN and Service-Orientation” will be the first track on a conference that will discuss project experience with the breakthrough version of the process modeling language BPMN 2.0 – which allows for directly executable process models.

BPMN 2.0 and current cloud solutions are examples of how SOA and BPM leave the agitated top of the hype curve and move to proven approaches that are applied in enterprise level efforts I start to see at large companies. Discussions change from trying to grasp hot topics such as ESB and SCA to sharing real life solutions to concrete project problems: More and more people are actually exposed to SOA challenges and need design guidelines and best practices. The track on SOA Patterns & Practices reflects this and has a great potential to deepen shared understanding of solutions since presenters are forced to talk in a well structured way about proven designs.

As well we made sure that the conference is not only relevant for technical people, SOA/BPM developers and architects. For C-Level executives and other business stakeholders who want to learn about and discuss latest and freshest trends there are specific tracks such as “Business of SOA”.

Here is the list of all tracks:

  • SOA Architecture & Design
  • SOA Governance
  • Business of SOA
  • BPM, BPMN and Service-Orientation
  • Modeling from Services to the Enterprise
  • Real World SOA Case Studies
  • Real World Cloud Computing Case Studies
  • Cloud Computing Architecture, Standards & Technologies
  • REST and Service-Orientation in Practice
  • SOA Patterns & Practices
  • Modern ESB and Middleware
  • Semantic Web
  • SOA & BPM
  • Business of Cloud Computing
  • Cloud Computing Governance, Policies & Security

Descriptions of the tracks at the call for papers section.

Looking forward meeting you in October!


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 (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