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.