It is four months since the SOA manifesto was announced; InfoQ interviewed the original author’s and in some cases pulled in their comments on the manifesto from the web to get insight into the motivations and the process behind the initiative. The questions were designed to get a broad understanding of the manifesto, as well as provide insight into some of the interactions behind the scenes, the goals of the participants, individually and as a whole, and provide transparency to the mechanics involved in putting together an initiative like this. We split the discussion into areas of philosophy (of certain aspects of the manifesto), process (behind how it was created) and lastly goals of the manifesto (which has been the focus of much of the media).
The philosophy
InfoQ: Who is the target audience of the manifesto? Is it a developer? An enterprise/systems architect? A business decision maker who expects to make informed decisions based a form of mapping of these values and principles to business services?
Mark Little: I think if the manifesto is to deliver value then it needs to be aimed at everyone of the stakeholders you've mentioned. Unless they all understand what SOA is and is not, then successful SOA deployments are not going to be as common as they could be. Typically when we see reported failures of SOA it's because one or more stakeholders misunderstand what's possible or expected from them. For example, if you go into using/utilizing SOA expecting that technology is the solution then you will fail. The manifesto is a concerted effort to make sure that all stakeholders understand this.
Herbjörn Wilhelmsen: I think that one of the major points in the manifesto is that SOA cannot be done by IT or technologists alone. Business and IT must collaborate in order to pull it off and this insight is reflected both in the value statements and the principles. Therefore the target audience is both business and IT.
Steven Ross-Talbot: The target audience is primarily those who are engaged in framing and delivering solutions; the enterprise/solutions architect; the developer; the business stakeholders and decision makers. The latter are perhaps secondary to the manifesto as it is the former who carry the message and get agreement. In the real world it is often the Enterprise Architect who, having received some direction from the business stakeholders, prepares an initial business case. That business case may well draw on the Manifesto or reference it directly.
Clemens Utschig: The audience is the stakeholder that wants to leverage service orientation in the context of his organization, rather than just a project. Especially the principles are multi-facetted, some fall into practitioner/implementation role, while others are dedicated to the organization as a whole (e.g. Respect the structure / power of the organization). A decision maker will find itself likely more in the value part, to understand the choices he has to make and the implications of them.
Ali Arsanjani: Every stakeholder and role within the enterprise should be aware of the possibilities provided by this paradigm and the value that can be achieved as a result of the application of its principles. There will be different roles and each will be focused on a different aspect of Service-orientation; as the different instruments in an orchestra, but they need to know how to play the piece under the guidance of the conductor. A considerable amount of companies are seriously considering adoption, since they have held on until the paradigm reaches and goes beyond the “trough of disillusionment”; so they can adopt paradigms and associated technologies that have been tried and tested. We can say that SOA and service-orientation have been tried and tested and are gaining a more pervasive quality in Enterprise Architecture and individual solution architecture efforts.
Dave Chappell: The SOA manifesto is directed at each of those stakeholders you mention, and then some. In addition to developers, enterprise architects, and business people, there are also project leaders, operations people, and all others involved in the entire lifecycle of a SOA project from inception through deployment that should understand the principles and priorities put forth in the manifesto
InfoQ: The opening statement of manifesto has come under a lot of scrutiny as a result of the recursive definition.
Service orientation is a paradigm that frames what you do. Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation.
As a result some of the seriousness of the manifesto is lost on the skeptic. This statement warrants an explanation/justification of the ideology behind the statement.
Mark Little: The aim behind the statement was to be concise about what SOA is, for the reasons I've mentioned already. Yes it may seem tautological, but that is because those who have looked at this have failed to understand that being explicit and obvious to them may not appear to be the case for those who are either new to this paradigm or have failed to understand what SOA is about. It is also important to understand (and remember) that service orientation has been around for years (decades) and therefore predates SOA. You can develop with services in CORBA, for instance (the core capabilities in CORBA are called the Core Services) yet no one would say that the default development approach in CORBA is SOA.
Herbjörn Wilhelmsen: Yes, we were chided by this seemingly obvious and recursive statement. I do however thing that there is an important point buried under those nice words. I can understand that the meaning escapes some readers. Anyway, my understanding of this is that SOA is something that you DO, that requires hard work and design skills. In other words: Money can’t buy me SOA. (Also see: http://soa.dzone.com/articles/herbjorn-wilhelmsen-interview )
Steven Ross-Talbot: I have been in a number of sales situations and workshops with clients and I get asked the question “how can I sell SOA?” So there is confusion. It often happens in technology as people try to sell technology and not benefits so it is not all that surprising. However you clearly cannot buy a SOA. But you can buy SOA-based technology that assists in the creation of a SOA. SO is important as it sits above any concept of SOA and drives the use of SOA-based technology. Getting these terms right might seem somewhat anal but in reality getting names and terms right is pretty much what computational science and informatics is all about. I think it was both the late Sir Roger Needham and Robin Milner who have in the past decried the poor use and definition of names that are used to describe solutions. And names are fundamentally what computing is based upon. Given that these two Turning award recipients are anal about naming and the use of names we would do well to heed their cry and this is why getting it right for SO and SOA is so very very important.
Thomas Erl: (from the annotated manifesto) [...] from the beginning it was understood that this was to be a manifesto about two distinct yet closely related topics: the service-oriented architectural model and service orientation, the paradigm through which the architecture is defined. […] The service orientation paradigm is best viewed as a method or an approach for realizing a specific target state that is further defined by a set of strategic goals and benefits. When we apply service orientation, we shape software programs and technology architecture in support of realizing this target state. This is what qualifies technology architecture as being service-oriented.
Anne Thomas Mannes: (from her blog post.) A number of people have chided us for stating the obvious in the first paragraph, but our contention is that many people miss this most obvious point. Many people think that SOA happens simply by using a particular type of technology or product (e.g., WS-* or an ESB). But SOA is not about technology. SOA is entirely about design. You can't achieve service-oriented systems unless you apply the service orientation paradigm during system design.
Ali Arsanjani: The idea behind this statement is to distinguish and differentiate between the “product” and “the principles” that are behind the particular style of architecture. Thus, even though you may not necessarily build an SOA for every single project in your organization may not necessarily follow the architectural style of SOA; nevertheless, you are able to apply the principles behind service-orientation on any project. This is part of the value-add of Service-orientation that transcends market hype and buzzwords that are in vogue for a short time. The service-oriented paradigm is the state of the art in software engineering; what SE has picked up from the lessons learned from applying service-oriented architectures and building systems on that basis.
Dave Chappell: That statement is not intended to be a definition, but more of a clarification. Service Orientation is something you do. It is the act of building services that are intended to be combined together with other such services in order to build a Service Oriented Architecture. We had lots of discussion around the popular misconception that SOA was something you could buy. This statement was intended to clarify. Perhaps in rev 2 we could prepend it with “SOA is not something you buy, it’s something you do….”
InfoQ: Since, a comparison to the agile manifesto is inevitable, one of the characteristics of which is that the values and principles are minimalistic with little or no overlap between the values and principles. The SOA manifesto on the other hand appears to be more on the subjective end of the spectrum. Could you comment on the suitability of the service oriented architecture domain for a manifesto similar to the agile manifesto?
Mark Little: Yes, there is overlap. I hope that will be clarified as the manifesto evolves. But does that mean that an agile-like manifesto approach is inappropriate for SOA? No, I don't think so. I believe that the core aims behind what brought us all together to write the manifesto are right. Outside of standards bodies such as OASIS, we've never had so many people from so many different organizations come together to try to define SOA and commit time and effort to answering the question of "What is SOA?" in a way that is supposed to be understandable by many different people.
Herbjörn Wilhelmsen: Actually there is plenty of overlap between the value statements and the principles in the Agile Manifesto. The SOA Manifesto, just like its agile predecessor, uses the principles to expand and explain the value statements. In fact one of the authors of the Agile Manifesto claims that the value statements was what inspired the Agile Alliance to write the principles (see Agile Principles, Patterns and Practices by Robert C. Martin). One of the main reasons for the success of the Agile Manifesto is the format of its value statements as it shows what direction to take when you need to make those hard choices (see http://www.ddj.com/architect/184414755 ). Choosing between two good things is hard! But these nice and compact value statements need some more explanation – hence the principles.
Steven Ross-Talbot: There is overlap. I for one have started to put a table of value statements against principles together and I know some of my fellow authors are doing the same. I would expect to see more clarity on this fairly soon.
As to subjectiveness, yes there is some but it is very hard to get the degree of precision right in such a short amount of text which is why all of us have been blogging on the subject in an effort to add clarity. However we will all have our own unique views so do not expect it to all be the same all of the time. What will make it interesting is that all of us are probably right and so the real story is the collective thoughts being consolidated over time. At least it is a start.
Did we need a Manifesto for SOA? We needed something with enough key people prepared to commit time and energy to re-fueling and re-aligning SOA and SO. A Manifesto from a collection of individuals with some profile is probably the best way to achieve this.
Ali Arsanjani: In a sense, a manifesto is usually used to portray a value-system for something nascent and evolving. The industry has never formally converged around the definitions and value statements on SOA and SO. This is an opportunity to declare the common set of values for service-orientation in general and SOA in particular. Thus the question on suitability is, IMHO, a misplaced one: of course you should declare key values of a paradigm that is communicated to people who may consider its adoption. With such a declaration of values, we will have greater clarity of vision and insight into what the value of SOA and SO really is, and what are the principles behind them. Note that in both manifestos, the principles are an expansion, and elaboration of the values. They may have different types of details, but they follow the same general direction.
The process
InfoQ: From Thomas Erl’s statement about the manifesto:
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.
With such an overarching goal, we’re interested in the process used to defining the scope and how these choices were narrowed. What would be interesting for readers are examples of some principles/values that were proposed that did not make the cut. This contrast will give an idea of some of the kinds of issues that some of the thought leaders are thinking about and also serve as examples of what was considered in scope and what was not.
Mark Little: Unfortunately I was participating remotely so have less to say about this aspect. Before the meeting we all produced our own manifestos that were submitted to the group. On the day(s) the group went over these individual submissions and others. For myself, I spent a lot of time on the phone with my friend Steve Ross-Talbot, going over the proposals, the issues etc. and feeding in my own suggestions.
Herbjörn Wilhelmsen: The initial statements and principles seemed to be very different. But, as we worked through them we found that surprisingly many of them were kind of similar – at least when the different authors explained and discussed further. To me it seemed as if many of the perceived differences came from the fact that the different authors used different words. Sometimes different words had the same meaning; sometimes the same word had different meanings. As we progressed through the values and principles we sometimes even rewrote the principles in order to not use some particular wording and expressions that people put different meanings into – or that is associated with too many meanings. Loose coupling is one such expression. You won’t find it in the manifesto. Other than that there was one clear trend that I spotted: We couldn’t go into details. Had we put some details in there we would have had to put an enormous amount of detail to get a good balance between all important details – and if we did that there is no way that we could have produced a short crisp manifesto or finished it on time!
Steven Ross-Talbot: We had to steer clear of design principles as, for the most part; these are dealt with in other forums. What was hard was coming to the meeting with principles that were pitched at the right level. For example, here are some that did not make it:
An SOA MUST exhibit polymorphism and late-binding i.e. pick the right instance at runtime. Services MUST be modular and normalized, i.e. no overlapping business logic. Change does not happen because of SOA adoption. It MUST be designed in from the start. Change has multiple dimensions SOA + BPM should not only provide agility but SHOULD maximize strategic performance metrics.
And here are two that clearly did make it:
- Service Orientation is something that we do not something that we buy.
- SOA adoption is business requirement and NOT technology driven. Business requirements MUST be derivable from business goals.
They can all (including the ones that did not make it) be tied into the high level principles in some way. I think it would be great if we all did some further work tying the design-based principles back to the Manifesto principles. It would certainly add additional clarity for many.
Thomas Erl: (from his annotated manifesto, his definition of the subset being considered) so far, the manifesto has established an overall vision as well as a set of core values associated with the vision. The remainder of the declaration is comprised of a set of principles that are provided as guidance for adhering to the values and realizing the vision. […] It's important to keep in mind that these are guiding principles specific to this manifesto. There is a separate set of established design principles that comprise the service orientation design paradigm and there are many more documented practices and patterns specific to service orientation and service-oriented architecture.
Clemens Utschig: The hardest part was the discussion over design principle vs. principle in general. A value I had on my table was "guiding enterprise governance over departmental freedom" - and some of this was folded into "Strategic goals over project-specific benefits".
Ali Arsanjani: Many of the statements around principles, for example, were initially highly technical in nature. We felt that as we had to cover both a business and a technical audience of stakeholders that we needed to speak to the business level primarily. A lot of the enunciation was a renunciation of the technical principles toned down to appeal to and resonate with non-technical folks as well.
Dave Chappell: Many of us came into it with similar statements. Some of us came in with statements that were more like best practices, such as this
“The practice of SOA is to leverage investment in existing application assets by creating service level interfaces, combined together in a loosely-coupled fashion with other such services, and new service logic, to build new composite applications that automate a business function.”
This turned out to be way too literal a perspective, based on the group consensus. Once we all became more clear that we were initially staying away from design principles and best practices, then it became more of a task of convincing each other what the most important core values were, and deciding on the wording. We set up a process for this where each contributor had their time on the floor to present their argument, and everyone contributed in open discussion to refine the wording.
Here’s one that didn’t make it exactly as I submitted it –
“Achieve Organizational Readiness through people, process, standards, and best practices.”
But this wound up manifesting itself in the following –
“Respect the social and power structure of the organization”,
“Establish a uniform set of enterprise standards and policies based on industry, de facto, and community standards.”,
“Recognize that SOA ultimately demands change on many levels.”
InfoQ: Agreeing to carve out a manifesto, with so many thought leaders in a room, can be challenging. Enterprise architects face similar problems regularly on how to get consensus in an enterprise over abstract architectural guidelines. Every participant will have had impressions on how certain things really worked in the process and how certain aspects could be improved. Could you share some of these experiences to help readers successfully orchestrate something similar in enterprises?
Mark Little: My remote impression was that the process was very similar to those that I have experienced in standards: there were proposals and discussions around them and when there were disagreements they were resolved on a consensus basis. The difference here though as that there was a strong feeling that people were not contributing to try to protect their company's investments in technology, which is obviously the case in standards bodies a lot of the time: here participants were working to produce something that would benefit the industry as a whole and if their own company didn't fit within that, then that would be dealt with subsequently.
Herbjörn Wilhelmsen: Go into an immense level of detail. Do not accept that anyone uses words that you didn’t choose by yourself. Make sure that you do not have any deadline. This way you are guaranteed to FAIL! To improve your odds just negate these things. Also I would like to point out that guidelines should be just that, guidelines. Do not try to solve all problems (especially not that you do not have today) and do not cripple creativity by being overly critical in the early stages.
Steven Ross-Talbot: I think there were 2 key things that helped us all work together. We restricted the numbers of authors (which helped reduce the time to get to a consensus and reduce conflicts). We required all authors to bring their own (which ensured focus on day one). I also think that several of the authors had worked in diverse standardization groups before so we were used to the sort of diverse stakeholder management needed to bring about consensus. It was remarkably painless with much debate and little argument. Certainly far better than many standards meetings I have attended or chaired.
Stefan Tilkov: (from his blog post, his perception of the process) we've been working to achieve certain goals, using an approach commonly called "SOA". If you believe we could have been able to come up with and agree on a detailed definition of what SOA is, you have probably never participated in any discussion of this kind – it's entirely pointless and doomed to fail. […] From a personal perspective, I consider the fact that the group managed to agree that the core values of SOA don't comprise centralized governance structures, machine-readable contracts, application-specific interfaces, orchestration, composition, let alone ESBs, SOAP, WSDL or WS-*, really great.
Ali Arsanjani: One of the key points was to get on the same page first: what is everyone thinking and why. Then try and have each person contribute to a list or values, work in a time-boxed manner in narrowing down the list, and re-enunciating the terms in a way that each person felt would minimize misinterpretation. Elaboration of principles from values brought in anecdotes and impromptu references to actual projects done that got the point across very clearly. Make no mistake, there was active debate as we wrestled through issues stemming from different backgrounds, but very soon, we found our experiences shared a common theme. Essential to the process was trying to state the value or principle so that it would be least misinterpreted. I think a key success factor was that we were not there to represent companies, but as experts in the field, were there to share our war stories and distill values and principles from them that would hopefully benefit others; so they would not have to share the same scars.
Dave Chappell: We were all there voluntarily, and we were given an upfront assignment to walk in with our own manifesto as a starting point. Another thing that worked in our favor was that even though there was much heated debate, we were usually in violent agreement with each other after we got past our own pet peeves. The takeaway from this is when working in groups; you must understand what the other person’s perspective is. [We must c]ompromise on language and wording, but never on your principles. An example of that was the debate around a proposed principle that stated “SOA should be completely technology agnostic”. My view is that anyone who considers building an architecture based on SOA principles and does not consider the impact of tooling and technology has gone too far in the abstract and is wasting their employer’s time. Where we arrived is somewhere in the middle, which is really what both of us were thinking all along – “Products and standards alone will neither give you SOA nor apply the service orientation paradigm for you”, and “SOA can be realized through a variety of technologies and standards.”
InfoQ: There are different emerging styles of service orientation i.e. ROA, WOA and the traditional SOA, What was the representation of these styles in the group. What were the considerations and how did each of them influence the manifesto?
Mark Little: With such a diverse group of people I believe that all of the different approaches to SOA were well represented. There were no special considerations for any particular implementation approach though.
Herbjörn Wilhelmsen: I think that the principle that everybody in the group agreed upon answers that question really well: SOA can be realized through a variety of technologies and standards.
Stefan Tilkov: The only REST advocates in the group, AFAICT, were Anne Thomas Manes and I. I thought for quite a while before joining the group in the first place, as I did not want to take part in anything that places value on what I consider to be the mostly misguided effort called WS-*. I personally prefer to define SOA as a high-level concept that's perfectly compatible with many technologies. I wanted to help ensure that those who view REST and RESTful HTTP (I don't care much for the terms "ROA" or "WOA") as the best approach to achieve high-level SOA goals can stand behind the manifesto. I think we succeeded in that respect - in fact I got the feeling that this was one of several issues where the group exchanged detailed specifics for the opportunity to get agreement.
Steven Ross-Talbot: All were represented. No specific considerations to any were made as we took a higher more abstract and neutral approach to accommodate any style of SOA that could possibly be written down.
Ali Arsanjani: The level of maturity of the group in actual project experiences was made clear early as it was made clear that we were not getting hung on common misconceptions such as SOA is tied to a specific style of implementation or realization. That no matter how you choose to realize your SOA there are architectural decisions that have to be made within the same overall framework or context of service-orientation; and that Web services, REST, WOA were all fair game.
Dave Chappell: We had enough diversity in the group and enough understanding of ROA and WOA where each of these approaches was considered. In all discussions we kept it up to a higher level around service orientation and not necessarily aligning ourselves or discounting any underlying implementation choices whether ROA, WOA, or WS-*, or CORBA for that matter.
InfoQ: [For the representatives of tool vendor] could you provide an account of the process, in relation to balancing the values and principles with reality of available product offerings?
Mark Little: Well as I said previously, I think a lot of people really approached this manifesto from an idealist perspective, even if the realities today do not match. If we really believe that the perfect technology component to producing successful SOA is available today from any or all vendors then I think we're not listening to users enough, many of whom are disillusioned with tooling. There are some really good tools out there to help with some aspects of SOA, but the whole picture (the whole software development lifecycle) isn't available yet from any vendor as far as I'm concerned. If you look at the manifesto and then look at something like Savara (www.jboss.org/Savara) you'll see how we're trying to fix those gaps in a way that can be applied across a range of different vendor platforms. This is something that has influenced the manifesto and vice versa.
Steven Ross-Talbot: I am not a product vendor but I will still have my two cents worth. For me one of the key principles that we agreed upon was: “Verify that SERVICES satisfy business requirements and goals.”
This principle has direct relevance to the successful delivery of SOA-based solutions. What we want, as a Systems Integrators, is tools that help us more effectively manage the Software Development Lifecycle (SDLC). In particular we want to ask questions of designs and understand how they meet requirements. So tooling that can help us to do this is really important as it will save huge amount of time and money in getting a solution delivered. Hence we have backed www.jboss.org/savara and will work diligently on applying it to other SOA platform such as Websphere, Oracle Fusion, Webmethods, .NET and so on.
Anne Thomas Mannes: (from her blog post.) We haggled quite a bit about this principle. It started out as a very simple assertion to "embrace diversity". As any large organization knows, it's extremely difficult, if not impossible, to maintain a completely homogeneous environment. Heterogeneity is a fact of life. And yet many organizations persist in trying to align their systems with a single vendor strategy.
Ali Arsanjani: One of the things I have learned from service-orientation is to separate the concerns of architecture from its realization. Deferring these decisions means that SOA enables us to embrace a heterogeneous environment of diversity of vendors.
Dave Chappell: We all left our vendor hats at the door before entering the room. All we were left with is our experience of working with clients and customers who have been building out projects based on service orientation. We all agreed that SOA is about service orientation at the business service level and that you can’t buy SOA from a vendor, and that SOA should be technology agnostic. Your efforts in designing services, should focus on the business value that they provide. However, as I have stated, anyone who completely ignores the impact of the underlying technology is spending too much time in the abstract. That’s where principles such as “Establish a uniform set of enterprise standards and policies based on industry, de facto, and community standards” are rooted from.
The goals
InfoQ: Since some of the values and principles are abstract, could you share concrete examples of how some of these principles could be used to solve real world problems?
Mark Little: This is a really important thing for everyone to understand. SOA is much more than a given implementation technology. Many people, and vendors, believe that Web Services are the implementation technology for SOA and therefore if you're developing with WS-* you are inherently "doing SOA". Unfortunately that is not the case. It's just as easy to write applications that are not SOA with Web Services as it is to build using SOA principles on CORBA, or DCE. I believe that the fallacy that SOA = Web Services has contributed a lot to some of the problems and confusion we've seen with SOA. We have customers of our SOA solutions who are developing SOA-based applications with FTP, which we all know predates CORBA let alone Web Services. And as for standards, unfortunately there are many examples of WS-* standards and specifications that do not fit into what would be considered good SOA, for instance WS-RF and to a lesser degree WS-Addressing.
Herbjörn Wilhelmsen: One of my favorite value statements are “Intrinsic interoperability over custom integration”. It could be stated also in another form: In SOA integration is a first class citizen. It means that you need to take important integrations into account when you are planning and designing your service. You need to ensure that the information in your service is compatible with (that is at least possible to translate into the data models of) other important software and / or business areas. This can save you a lot of trouble and massive amounts of money later on. But there is a fine line that you do not want to cross: You do not need interoperability with everything and everyone. Knowing who and what you need to be interoperable with is the key to success. Knowing that you should investigate this is a basic prerequisite for success.
Steven Ross-Talbot: “Verify that SERVICES satisfy business requirements and goals.” At Cognizant and Redhat this has led to the development of formalisms to support computed verification of solutions expressed as designs or architectural models that are formally tested against requirements to ensure that they satisfy them. The net result has been a huge drop in the time and costs associated with requirements gathering and architectural modeling prior to coding. In some cases the savings have been over 50% and have found design flaws early which in turn have led to more robust and high quality services downstream. In some cases the entire saving of the SDLC has been more than 20%.
The principle is simple but the impact, when taken to the next level of use (automated testing of architectural models) is really quite profound. Prior to SO and SOA we had no means of capturing service descriptions and their behaviors but the advent of first WS-CDL and then BPEL and now BPMN2 makes this a reality. It is unlikely that this would have happened had it not been for the wide spread investment in SO and SOA.
Clemens Utschig: One of the interesting ones coming to mind is "Establish a uniform set of enterprise standards and policies based on industry, de facto, and community standards." - which is our way of saying you need thought through governance, anarchy will buy you chaos, and that's the last thing you need when you try to implement an SOA across your organization. It's not about which types of standards you are using, but rather to have a set that you are enforcing. I have seen many project failing - largely because of this quintessential governance.
Secondly, "Maximize service usage by considering the current and future scope of utilization". Services will not come perfect in round one, or take forever to implement. Practitioners should be laying down future proof service architectures very early in the cycle, and proof that those scale, however constant monitoring, and continuous refinement (through lifecycle governance) often makes the difference between a few services and a very successful SOA implementation.
Paul Brown: (from his blog.) There are at least two major forces that conspire to lose the business value focus. One arises from the complexities of executing projects involving multiple systems and organizations. The other arises from the distinction between enterprise architecture and individual projects. Both must be guarded against in order to realize the value of service orientation. […] At the end of the day, the first SOA Manifesto value statement stands as a reminder to maintain focus on delivering business value, not to the exclusion of technical strategy but rather in appropriate balance with it.
Ali Arsanjani: One of the questions I get is why we value the items on the left more? Another is how can we value the items of the left, when the context is unclear? One of my favorite ones is: flexibility over optimization. How can you sacrifice optimization and fast performance and instead provide some futuristic flexibility? This is a battle that wages under the guns of urgency in getting projects out the door. Under the urgency of the moment, enterprise architecture and governance concerns are often thrown out, and tactical solution fulfillment is the main focus. On the other hand, one of the primary gains of SOA and SO is flexibility; an increase in business agility through an increase in technical flexibility. Tactical solutions will always be there. But if we always sacrifice strategic capabilities and goals in favor of tactical / momentary considerations, we will rarely reap the benefits of longer term planning such as enterprise architecture considerations.
Dave Chappell: Consider this principle: “The scope of SOA adoption can vary. Keep efforts manageable and within meaningful boundaries.”
This might seem like a no-brainer; of course one would want to keep efforts manageable. But what this is really referring to is to try not to boil the ocean all at once. One of the benefits of service orientation is that services can build on one another, and can be reused from one project to the next. Don’t get caught up in analysis paralysis out of the starting gate. You can start small and build upon each project as long as you have a strategic vision of where you are trying to get to as an organization, and well defined goals to keep you headed in the right direction.
InfoQ: Just as important as the preamble sets the context for SOA as referenced in the manifesto, it seems important to define SOA in the first place.
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.
Since definition of SOA as such is so subjective, the manifesto becomes that much more open to interpretation. Why was it not part of the mandate?
Mark Little: There simply wasn't time and there are some good definitions in the standards arena anyway, e.g., OASIS SOA-RM.
Herbjörn Wilhelmsen: My personal feeling about this is that we would not have succeeded had we tried to agree on such a definition.
Steven Ross-Talbot: Time largely. There are many definitions out there. If we think of SOA as a type of thing and not an instance it does suggest that SOA as a type can be defined in terms of some key attributes which when present, in an instance under examination can, be said to be an instance of a SOA. There are many attributes to SOA and many variations of those attributes. Loose coupling is one and the presence of service contracts is another but what that means in terms of the practicalities can vary widely. I do not want to give a definition here as I think I would need to spend more time to make it succinct and practical.
Stefan Tilkov: (from his blog post.) I can understand why people have become frustrated with SOA, and I can accept that some prefer to avoid the term altogether. Fine, But if you want to label something SOA, I strongly believe that these are all reasonable values and principles, even though some that you might have wanted to see in there didn't make it (the same is true for me). […] I've been talking about three possible and common interpretations of SOA in the past: 1) As a high level approach; 2) as a badly-defined architectural style behind DCOM, CORBA, and SOAP/WSDL, or 3) as the architecture behind WS-*. […] The manifesto firmly connects SOA to option 1. I couldn't be [happier] about it.
Ali Arsanjani: I have sat in different venues, from company meetings to client meetings to standards meetings where the same term, SOA was defined, redefined and then redefined a few weeks later. As our understanding grows, so does the way we choose to communicate key issues. So the question is, do we spend the time in trying to provide abstract definitions or shall we focus on what brings value and the principles that will lead to the implementation of those values? We opted collectively for the latter.
Dave Chappell: It was largely due to time constraints and also that there are other definitions out there such as OASIS SOA-RM. We never would have got to the manifesto if we set out to define SOA. Perhaps we could revisit that in the next meetup.
InfoQ: [For the representatives of tool vendors in the signatories] what are the takeaways from the manifesto? Signing the manifesto means providing the choices in terms of the values and principles in their product offerings. (Without really disclosing IP) Are there any interesting comments or observations on the influence of the manifesto on future product direction and strategy?
Mark Little: I think that vendors should look closely at the manifesto as well as how it was developed: collaboratively with people from across a range of different stakeholders. Tooling and other technological aspects of SOA should really be developed in a similar manner. Being an open source company, Red Hat products are developed in the open where everyone can get involved. That involvement can range from contributing code to contributing use cases. So in a way I think open source is an excellent arena for this kind of collaborate approach to improving SOA tooling and infrastructure. That's why from a Red Hat perspective projects such as Savara and Overlord (www.jboss.org/Overlord) are our frontline in improving everything we do around SOA. We'll take the SOA Manifesto on board and hopefully things we learn by contributing with community members such as Cognizant will help us evolve it and feed back to the Manifesto.
Herbjörn Wilhelmsen: I’m not a tool vendor, but here is my take on it: The world of SOA is ruled by skills and competence. No tool can replace either of them. In some cases tools come in very handy, but remember: Money can’t buy you SOA.
Steven Ross-Talbot: Again let me have my 2-cents worth even though I am not a vendor. For me the takeaways for vendors (and I say this as a practitioner) are better tooling. Ensuring that some of the principles are encoded in some way into tools to enable better governance that leverages service contracts to help manage change would be very helpful. Tools for validation and verification would also assist. Better dependency capture and documentation. There are a lot of things that tool vendors could and should do. The problem is will they listen. As a big SI company we hope so. The advent of the open source joint project with Redhat (Savara) is perhaps one way to ensure that we practitioners get what we need and not what is thrust upon us. Better collaboration with practitioners and open ears to listen would be very very helpful indeed.
Clemens Utschig: One big part that falls on us as vendors - is to help enforce principles and best practices in the toolsets we provide today, likely more than ever. On the other side SOA is so much more than just technology, and patterns - so the angle of methodology, already pointed out by Mark and Steve comes to more importance every day. And so does the collaboration aspect between stakeholders, and the management of them. The role of EA and being able to measure architecture against business goals, in combination with SOA and BPM will be with us likely for years to come.
Anne Thomas Mannes: (from the blog post) […] to some degree, I'm surprised that we were able to get the ESB vendors to agree to this value statement [Intrinsic interoperability over custom integration]. If you build services that support intrinsic interoperability, you really don't need an ESB. Of course you might use an ESB as a service container (not just as a mediator), in which case you can use the ESB to expose an intrinsically interoperable service. I'll just point out, though, that RESTful services are more intrinsically interoperable than other types of services.
Ali Arsanjani: The Manifesto does not constrain any product offerings: it widens our horizons as an industry in terms of how we can leverage and gain greater value from various diverse products and services, but most importantly to align them in the direction set by the principles to achieve the values.
Dave Chappell:The SOA Manifesto itself is agnostic to tools and vendor offerings. It is focused on those who are building applications using service oriented principles, which is a layer above the vendor offerings. Vendor offerings such as middleware and tooling can help with productivity, help to standardize on technology, prevent you from reinventing the wheel over and over again from one project to the next. An ESB for example, can be an underlying technology that enables your service intrinsically interoperable. This is true whether intrinsic interoperability to you means a common use of WS-*, REST, or any other emerging convention. Oracle Service Bus, for example, can expose RESTful service interfaces for backend services that were implemented using some other technology. In an ideal world all services are written from scratch and they can follow any interoperability convention that you agree upon. However, we live in a world of IT diversity, and vendor tools and middleware are just part of what you use when you implement the details of service orientated applications. But don’t let any of that get in the way of the bigger problem at hand, which is defining the business services in a way that are going to meet the needs of the business in a way that is flexible and capable of adapting to change. This is what service orientation is really about.
Attribution: The title image was generated by Wordle