Last year has been tumultuous in the world of SOA and we’re just at the beginning of rollercoaster ride. As organizations continue to re-examine the ever-shifting landscape of service design, service buses, service governance, and even just services, there are often mixed emotions. Many are confused as to the maturity and overall status of SOA in the IT industry, but there is definite sense of excitement around its touted potential to unite business and technology.
Many SOA initiatives were launched this last year, each with its own set of goals and expectations. Some failed miserably, while others failed just a little. For many, the determining factor in fulfilling their original objectives was drawing upon the experience of those who had already survived projects with less fortunate results. These individuals lived to tell their stories and warn others of what lies ahead along the path toward SOA.
In our line of work we get pulled into various projects at different stages of completion. We’ve seen good SOA go bad and bad SOA get even worse. Problems can be fixed and mistakes can be undone, but of course there is always an impact to getting things back on the right track. The best course of action is, obviously, avoiding problems and mistakes in the first place.
Understanding the pitfalls others have fallen victim to, puts you in a position from which you can form the extent of foresight required to chart a safer route down your own SOA roadmap. To help you get a head start, we have collected the eight most common SOA adoption pitfalls we've noticed last year.
#8 Not Keeping in Touch with the SOA Marketplace
There are few segments of the IT market as volatile and interesting as the SOA space. Any current SOA planning efforts need to take the state and direction of the marketplace into consideration. There are pieces of the platform worth investing in now and others worth waiting for.
A transition toward a Web services-based SOA opens up the arena of products and platforms that organizations can choose from. While the tendency will be to continue with what you know best, the option to look elsewhere is ever-present. As a result, it is anticipated that the SOA marketplace will become the most competitive ever.
Another factor that weighs into the technology marketplace from a Web services perspective is how product vendors relate to the WS-* specification development processes that are currently underway. Vendor diversification and the alignment of multi-vendor platforms with open standards and technologies are key components of SOA transition plans that are frequently overlooked, potentially leading to poor decision making and perhaps misplaced investments.
#7 Not Planning for Web Services Security
Organizations tend to start small when first building SOA with Web services. The extent to which Web services technology grows within a given environment is typically related to the comfort level developers and architects have with the overall technology framework. Once services begin to take on greater amounts of processing responsibility, the need for message-level security measures as well as security controls that apply to shared services begin to arise. The WS-Security framework establishes an accepted security model supported by a family of specifications that end up infiltrating service-oriented application and >enterprise architectures on many levels.
Even if your vendor platform does not yet provide adequate support for WS-Security, and even if your current SSL-based implementation is meeting immediate requirements, it is advisable to pay close attention to the changes that are ahead. Proceeding without taking WS-Security (and its emerging extensions) into account will inevitably lead to expensive retrofitting and redevelopment. This impact will be amplified when organizations begin to grow their service inventory and decide to only then apply the appropriate security measures.
#6 Not Planning for Governance
Many organizations are focusing on the technology impacts anticipated and introduced by SOA. With an emphasis on the Web services framework, companies are preparing themselves for the new generation platforms that promise to finally address some of the gaping quality of service holes.
An expected impact of SOA that will eventually go far beyond technology issues is the change required by an organization to control, manage, and evolve the ever-growing service inventory they will be building as a result of an on-going SOA transition. This is especially a concern for enterprise-wide transition efforts, as the increased frequency by which agnostic and reusable services are delivered will correspondingly increase the potential for those services to be shared and extended. This will, in turn, dramatically increase governance issues related to those services and the service portfolio as a whole.
SOA governance will impose organizational challenges that will affect the allocation of resources, the roles of IT professionals, internal standards, ownership, processes, and project delivery lifecycles. Not planning for this inevitability can derail any serious SOA transition effort. Though ranked at #6 for 2005, this particular pitfall will likely rise toward the top of this list in 2006.
#5 Not Understanding SOA Performance Requirements
Loose coupling comes at a price. When implemented with Web services, SOA introduces layers of data processing as well as the associated performance overhead imposed by these layers. When starting out small, it is easy to build service-oriented solutions that function and respond as expected. As the scope increases and more functionality is added, the volume of message-based communication predictably grows. This is when unprepared environments can begin experiencing significant processing latency.
Critical to building a successful service-oriented solution is understanding the performance requirements of your solution and the performance limitations of your infrastructure ahead of time. This means testing (and, if necessary, strengthening) the message processing capabilities of your environments, and paying close attention to service design so as to achieve an acceptable balance between transmission rates, transmission sizes, and other service characteristics that can negatively affect solution performance.
#4 Not Starting with an XML Foundation Architecture
In the world of today’s SOA, everything begins with Web services. That statement has become a mantra of sorts within some organizations, but it is not entirely true. In the world of today’s SOA, everything, in fact, begins with XML. It is the standard from which multiple supplementary standards have evolved to form a de facto data representation architecture. It is this core set of standards that has fueled the creation of the many Web services specifications that are now driving SOA.
So much attention is given to how data is transported between services that the manner in which this same data is structured and validated behind service lines is often neglected. This oversight can lead to an improper implementation of a persistent XML data representation layer. This layer is foundational to SOA and its weaknesses will have repercussions across any solutions built upon it.
#3 Not Creating a Transition Plan
The chances of a successful migration will be severely diminished without the use of a comprehensive transition plan. Because the extent to which service endpoints are positioned within an enterprise can lead to a redefinition of an environment’s infrastructure, the affects of a poorly executed migration can be significant.
Transition plans allow you to coordinate a controlled phasing in of service-orientation and SOA characteristics so that the migration can be planned on a technological, architectural, and organizational level.
Typical components of an SOA transition plan include an impact analysis (that predicts the extent of change SOA will impose on existing resources, processes, custom standards, and technology), transition architectures (that map out a series of planned hybrid stages toward a target SOA), and a speculative analysis (that takes into account the future growth of Web services and supporting technologies).
#2 Not Standardizing SOA
SOA, like any other architecture, requires the creation and enforcement of internal design standards for its benefits to be truly realized. For example, if one project builds a service-oriented solution in isolation from others, key aspects of its solution will not be in alignment with the neighboring applications it may be required to interoperate or share agnostic services with one day.
This can lead to many problems, including incompatible data representation, service contracts with irregular interface characteristics and semantics, and the use of non-complementary Web services extensions (or extensions being implemented in different ways).
SOA promotes a development environment that abstracts back-end processing so that it can execute and evolve independently within each application. However, standardization is still required to ensure consistency in design and interaction of services that encapsulate this back-end logic.
#1 Building SOA Like Traditional Distributed Architecture
The number one obstacle organizations have been facing when attempting to achieve SOA is building service-oriented solutions in the same manner in which traditional distributed solutions have been built, under the pretense that SOA is actually being achieved.
SOA is not CORBA + XML, nor is it ASP.NET + WSE. Service-orientation is not object-orientation, nor is it "close enough" so that building object-oriented component logic will always "fit right into" service-oriented solution environments. SOA is a distinct architectural model based on service-orientation, a distinct design paradigm. Understanding these distinctions are critical to building automation logic that is truly service-oriented and in alignment with where the SOA industry is moving on a global scale.
This article contains excerpts from "Service-Oriented Architecture: Concepts, Technology, and Design" by Thomas Erl (792 pages, Hardcover, ISBN: 0131858580, Prentice Hall/Pearson PTR, Copyright 2005). For more information, visit www.soabooks.com
About the author
Thomas Erl (terl@soasystems.com) is the world’s top-selling SOA author. His first book, "Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services", provides strategic guidance to establishing service-oriented integration architectures. His second title, "Service-Oriented Architecture: Concepts, Technology, and Design", is the first "how-to" guide to building SOA, and documents step-by-step processes for service-oriented analysis and service-oriented design, as well as comprehensive coverage of service-orientation principles. For more information, visit www.soabooks.com and www.thomaserl.com.
Thomas is also the founder of SOA Systems Inc., a research and consulting firm specializing in SOA consulting, planning, and training services. SOA Systems has made significant contributions to the SOA industry in the areas of service-orientation research and the development of a mainstream SOA methodology. For more information, visit www.soasystems.com.
Community comments
Why XML? Why vendor?
by James Richardson,
Re: Why XML? Why vendor?
by Stuart Charlton,
Re: Why XML? Why vendor?
by Stuart Charlton,
Re: Why XML? Why vendor?
by James Richardson,
Re: Why XML? Why vendor?
by Jeff Thomas,
Suprised by the lack of fret over #2 Standardize SOA
by Jim Murphy,
Re: Suprised by the lack of fret over #2 Standardize SOA
by Eric Roch,
Re: Why XML? Why vendor?
by Jim Murphy,
Why XML? Why vendor?
by James Richardson,
Your message is awaiting moderation. Thank you for participating in the discussion.
Despite being very popular and free, there are more performant and less verbose extensible data serialization formats. (e.g XER/PER)
Secondly - one needs to realise that the main purpose for the existence of vendors is to vend. Therefore they have a vested interest in making all the WS-* layers require their tools. However its totally possible to avoid a lot of complexity by simply not using vendor products, and doing "the simplest thing that could possibly work".
Jetty A Servlet XStream can get you off the ground very quickly - not a vendor tool in sight...
Re: Why XML? Why vendor?
by Stuart Charlton,
Your message is awaiting moderation. Thank you for participating in the discussion.
This is a very unfair characterization of vendors, and I would also say a somewhat idealistic stance.
Firstly, the XML verbosity argument is often irrelevant; the web is built on a very verbose markup language called HTML and seems to be doing just fine. There are many use cases that require a more compact form, but they tend to be the exception.
Secondly, Why XML? Let me pose an alternative question: Why is broken English the most widely communicable form of language, even though there are other more efficient languages like Esperanto?
There are plenty of contexts where an alternative to XML is applicable, such as JSON with AJAX. But one must recognize the serious economic tradeoff in making such an architectural decision. One shouldn't focus overly heavily on technological mechanisms when building an SOA; XML is not mandatory, but a whole lot more people will understand you than if you speak first century Aramaic.
Third, vending supposes there is "need" out there. One can argue whether that need is manufactured or is real. I would say it's likely a combination of both. Clearly, there are many use cases that WS-* covers that you can't point to in nearly another other standard, save rarely implemented CORBA services.
Some large customers happen to have tremendous clout with large vendors
Re: Why XML? Why vendor?
by Stuart Charlton,
Your message is awaiting moderation. Thank you for participating in the discussion.
Looks like I got truncated there.
Some large customers happen to have tremendous clout with large vendors. Large vendors have clout with standards bodies. Thus a reflexive process occurs, where communities of practice think alike and guide a standard down a particular path, which guides client perceptions, which guides vendors, etc.
Many clients want WS-*, even though URIs, HTTP and SSL would likely suffice for most use cases. They have their reasons - some legitimate, some not. But if they're willing to pay millions for an enterprise deal, it's hard for a vendor to at least be a "fast follower" of such standards, regardless of their actual success or value.
Re: Why XML? Why vendor?
by James Richardson,
Your message is awaiting moderation. Thank you for participating in the discussion.
I am merely challenging the assumption that either xml or vendor is absolutely required to have a SOA. It depends on what floats your boat.
While disagreeing, you simultaneously agree, by saying vendors are sometimes brought in "regardless of their success or value", and that xml is good "except in the extreme cases" - of which I can think of a lot.
The need for these things should be decided upon by a rational decision process, rather than assumption. (as is the case with everything)
Re: Why XML? Why vendor?
by Jeff Thomas,
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree that one can certainly have a valid SOA without XML. But it seems that many performance-oriented critics of SOAP/WS-* SOA are treating the proposition as if it were an application programming model and not an integration model.
Re: Why XML? Why vendor?
by Jim Murphy,
Your message is awaiting moderation. Thank you for participating in the discussion.
Let me add my 2 cents in support of vendors, since I represent one.
The point of spending the last decade pushing for the widest possible standards ever has been to get as many people as possible "on the bus" (not the ESB, the metaphorical "lets all go in the same direction bus"). The point of that is to offload common, crosscutting concerns that app developers have been baking into systems themselves. The "openness" of wire protocol, metadata and policy supports a high degree of automation and composability of various vendor products.
Obviously you need to be the judge of what automation and proucts you should compose but its a tremendous opportunity we have to raise the level of software development 1 notch.
Suprised by the lack of fret over #2 Standardize SOA
by Jim Murphy,
Your message is awaiting moderation. Thank you for participating in the discussion.
I often wonder what this means to people. Establishing a SOA council to adopt patterns and practices sounds like standardization. So does defining a common XML data model for an enterprise or even industry. But those efforts seem to be really hard to do. Try to get a bank to agree on the data model of a contact/person/organization/trading partner/entity etc. Then if and when you have standardized how do you evolve?
Does standardizing at a low level stifle future innovation? Once you have that in place is there ever a chance of moving ahead?
Re: Suprised by the lack of fret over #2 Standardize SOA
by Eric Roch,
Your message is awaiting moderation. Thank you for participating in the discussion.
XML can be a challenge but it?s difficult if not impossible to avoid using. Even if you don?t want to use XML your business partners will likely force you to. There are also great tools for authoring and storing (repository) XML and there are XML accelerators if performance becomes a problem.
See this post for more tips on XML and SOA.
blogs.ittoolbox.com/eai/business/archives/xml-s...