| In January, 2009 I found myself participating in a service engineering workshop at the Dagstuhl Castle in Germany. The rooms you are given when staying at Dagstuhl are intentionally simple; no TV, no radio, and little to do other than listen to yourself think. Following each day's discussions, workshop participants therefore often gravitated toward a common area and began talking into the night. On one of those nights, Gregor Hohpe stated that we should put together a manifesto, just like what the agile community had done years before. After a modest round of e-mail exchanges with the likes of Olaf Zimmermann, Nicolai Josuttis and Cesare Pautasso, we did manage to put forth some preliminary thoughts and even some draft values. But we then decided it was too ambitious for that occasion, and refocused our attentions on the remainder of the workshop agenda. The idea of a manifesto lay dormant for several months, as the SOA community began wrapping its head around Anne Thomas Manes' "SOA is Dead: Long Live Services" proclamation that was posted soon after I returned from this trip. By that time, SOA had long suffered from lack of clarity and direction. Everyone and their brother seemed to have a different opinion or perception, although most agreed that the outcome of its adoption should be something labeled with "agility" and "loose coupling" and would, of course, maximize our synergies and forever change the way we do business. There was a concerted effort underway to attack this ambiguity. Various specialized books and papers had been published documenting not just the notions of SOA, but the actual details of the underlying paradigm of service orientation and the target state its application is expected to realize. When we began focusing on the method of service orientation, previously unanswered questions like "What exactly makes a software program service-oriented?" were finally being addressed head-on. Principles, patterns, and practices emerged all dealing with the hard issues around applying service orientation in the real world. Service-oriented architecture itself had even become better established as a distributed architectural model with distinct characteristics. The "SOA" acronym had meaning and it seemed that clarity was finally in sight. The only problem was there weren't enough of us looking. And that's when Anne stepped in with what I like to call her "community intervention." During the months that followed her blog post, I observed a clear division in the industry. Those that felt validated in their belief that SOA had been nothing more than a churn around the IT hype cycle, and those that read beyond the headline to realize that this was essentially a warning to us all. A warning that if we don't change course, SOA could in fact die - not due to a lack of substance or potential, but simply due to a seemingly endless proliferation of misinformation and confusion. It was this somewhat chaotic period that led me to revive the original idea of putting together a manifesto. The industry needed leadership and what better way of accomplishing this than getting together industry thought leaders to hash out a formal declaration of the vision and values behind SOA and service orientation. These thoughts crossed my mind during my involvement with the program committee for the 2nd International SOA Symposium. At the previous year's event in Amsterdam I had the opportunity to meet up with a variety of SOA experts, many of which were being invited to return this time around. It seemed natural to take advantage of this gathering and hence the "Towards an SOA Manifesto Working Group" (later to be renamed the "SOA Manifesto Working Group") was formed. I reached out to those I regarded most highly in the SOA community to establish a base membership that grew further as several members recommended others. In the end, there were twenty invitees, three of which (Jim Webber, Ian Robinson, Gregor Hohpe) did not join. The complexion of the final group was well balanced in that less than half the members were with product organizations, while the others primarily represented the practitioner demographic. Everyone agreed that it was essential to check affiliations at the door when entering the working group sessions, as this was to be a meeting of minds, not corporations. The initial challenge was in establishing a pragmatic process. We had three days of sessions planned with little realistic opportunity for prior discussion and a firm deadline of October 23 for the announcement of the manifesto during the closing conference keynotes. Nicolai Josuttis came up with the idea of having every member prepare a draft manifesto in advance. Herbjorn Wilhelmsen organized a series of short presentations to start the sessions and Anne Thomas Manes further refined the process on-site by suggesting that we defer actual debate until after all the presentations had completed. This approach worked well, as each working group member was given the opportunity to propose an individual manifesto. By the time we were done, we had over 50 value statements and 80 principles. That's when the gloves came off. The 48 hours that followed would see these submissions narrowed down to 6 value statements and 14 principles, as all proposed input was scrutinized, filtered, prioritized and then aggressively refined. There was much discussion around the scope of the manifesto and the level at which it should be written. It needed to convey a value system and related principles, while still being accessible to a range of IT professionals. For example, we had to constantly restrain ourselves from adding definitions for terms like "service-oriented architecture" and "service orientation" because that was simply not part of our mandate. We finally settled on a light preamble to provide some overarching context. When working through the principles, we needed constant reminding that this wasn't about the "design" principles of service orientation, but instead the "guiding" principles of realizing the core values of service orientation. Even then, we had to continually make a distinction between guiding principle and industry best practice. Many of the proposed principles were valid practices in their own right, but were deemed too specialized, too detailed, or simply out of scope for inclusion in the manifesto. In fact, it was sticking to the very concise and limiting scope of a manifesto that was perhaps our greatest challenge. As the sessions progressed, we found ourselves meeting in a variety of places to continue discussions long after the originally allocated time. The looming deadline on the last day especially elevated the intensity of the collaboration. There were all kinds of heated exchanges, and tempers ran high as we entered the very last round of debates about wording options for some of the values and principles. But then it all came together. The manifesto was finally completed minutes before we all had to take the stage for the official announcement. After the formalities, we gathered together one last time to sign copies of the printed manifesto document. There was a general consensus that our efforts over the past days exceeded our expectations. Yet, at the same time, there were no delusions of grandeur. We understood how the prior reign of ambiguity had fragmented the community. Introducing a formal declaration into such an environment is bound to not align with the ideals of everyone, especially those that benefit from an absence of common understanding. The significance and relevance of this manifesto will ultimately be determined by the community as a whole and the true business value it helps the community realize. - Thomas Erl, for the "SOA Manifesto Working Group" |