Service-oriented architecture has proven to be a boon in the computing world. At its core, SOA provides enterprise patterns for systems development and integration where legacy systems are viewed as discrete business capabilities and packaged as standards-based services interfaces. SOA also typically describes an IT infrastructure that allows different applications to exchange data with one another as they participate within business processes.

Over the past few years, SOA has grown almost exponentially in popularity, becoming one way for companies to knit together applications and processes in a flexible, reusable and cost-effective way. SOA separates functions into distinct units, or services, which developers make accessible to users over a network, ideally allowing them to combine and reuse them in the creation of business applications. These services communicate with each other by passing data from one service to another or by coordinating an activity between two or more services.

However, like virtually any technology, business process or computing approach, there are misconceptions surrounding it - what it is, how it is used, its benefits and risks and who should be using it.

Myth #1: SOA and Web Services are the Same

To begin with, there is rampant misunderstanding around what SOA actually is. Some people will claim that SOA is simply the same as Web services and even use the terms interchangeably. The truth is, Web services, such as SOAP over HTTP, represent a standard means of defining an interface and fit the architectural pattern that SOA defines. The importance of these standards cannot be overstated, as they are instrumental in allowing systems of different types to communicate with each other without the need for a proprietary protocol.

Conversely, SOAs are based on underlying, guiding architectural principles, combined with so-called “best practices,” which ultimately allow the functionality of a Web service application to be asserted in an open fashion. SOAs and Web services are not interchangeable. Certainly, Web services can be used to build SOAs; in fact, they are the de facto standard for deploying SOA. Yet, SOAs do not necessarily depend on Web services standards, since SOA can also be implemented using CORBA, JMS, MQ and other interface/messaging standards alone or in parallel. The reality is that Web services can be viewed more as an interaction pattern within an SOA, typically describing an interaction between clients and a server over HTTP as opposed to SOA itself.
 
Ultimately, an SOA can be Web services-based or even based on SMTP email as an interface standard. However, by defining Web services as being equivalent to SOA you may lose visibility into many other types of SOA-based interfaces and capabilities that allow the kind of loosely coupled, autonomous, reusable components that define a real SOA.

Myth #2: You Can “Buy” SOA

One of the primary myths regarding SOA is the idea that it’s something that can be purchased, that SOA is an actual product that can be acquired for a business. Many organizations attempt to buy SOA in the form of relatively expensive infrastructure components, with products stacked against specific class capabilities such as directory, discovery or messaging. After acquiring these items they will declare that they now have SOA. However, this is far from the case. The true benefit is not the infrastructure that the SOA rests on but on the services that can be elicited from the infrastructure. Too many companies mistakenly focus their attention on creating a technology infrastructure and consider that a successful SOA implementation, rather than understanding that creating a platform for the delivery of valuable and functional services is the first step, needing to be accomplished in parallel with the identification, definition, design and development of the services that will ride on the SOA infrastructure.
 
While it’s true that you may eventually need to buy a repository to manage the services, a registry for other applications to find them and a mechanism for service consumers and providers to exchange business information, you may well be able to get started on SOA and achieve strong business benefits without buying anything new.

Myth #3: SOA Reuse Is Simple

While the reuse of software can be achieved on a small scale, it is exceedingly difficult to make it happen on the enterprise level - in that regard, SOA is no different. It can be extremely counterproductive to “force” the reuse issue, and trying to create services for each individual application or repository in an enterprise can lead to serious issues around maintenance and compatibility.

Ultimately, it’s best not to attempt to design only for reusability within the SOA development process. The optimal choice is to let SOA-style services suggest themselves based on requirements at the enterprise level. Given that point, it’s important to note that after you’ve modified an interface a couple of times to facilitate reuse, the “service” starts to present itself.

Myth #4: Acquiring a SOA Is Expensive

Many people are under the impression that launching an SOA is a costly endeavor. No doubt, there is a sizeable capital outlay necessary to create an SOA, but often that initial outlay is focused only on the infrastructure components identified previously. Many organizations believe that to create a SOA, you need a complete SOA stack made up of directory services, discovery services, message services and media mediation services, along with a portal for visualization and display. But you can achieve many of the core benefits of SOA without purchasing many of these components. You can achieve many of the benefits of SOA (standards-based services interfaces supporting information exchange) without any of the traditional core SOA infrastructure components.
 
As organizations’ SOA mature and begin requiring infrastructure components to expand their capabilities, there are many low or no-cost options available. Today, in fact, there are numerous open source technologies that provide the platform capabilities for an efficient and scalable SOA. And for the most part, these open source technologies are robust enough to power an SOA for an entire enterprise.

Myth #5: SOA Solves All Integration Problems

The misconception that SOAs solve all integration problems is a common one. The reality is that an SOA will only solve integration problems that are the result of tightly coupled systems; a number of issues, such as those related to semantic integration, will still remain after the SOA has been put into play. Also, many of the issues around integration have more to do with internal politics, personality and turf than any technological barriers to implementation. The best SOA capability in the world will not address these nontechnical issues.

Myth #6: SOA Is New

There is a notion that SOA is a relatively new phenomenon. The concept of looking at an entire IT infrastructure in terms of the capabilities (i.e., services) that it provides instead of a series of discrete applications on specific hardware is anything but new. Twenty years ago, organizations were creating modular COBOL applications based on standard service-based interfaces (COBOL copybooks). A COBOL copybook features a hierarchical data structure that looks remarkably like XML and quite a bit like WSDL, if you really think about it. Move ahead 10 years to the message-oriented middleware days, and you will again see SOA enterprise patterns emerging (called by another names of course). The truth is that SOA as an enterprise integration pattern has been around for at least the last two decades. Yes, the technology standards have changed and the languages and middleware have changed, but the fundamental integration patterns remain the same. Everything old is indeed new again.

Myth #7: Once It’s Done, It’s Done

In most large organizations today, management has bought into the SOA concept as a means to leverage existing legacy capabilities while providing a proven path for the future. Once the necessary technical SOA infrastructure is in place and the implementation is complete, your problems are over.

Wrong. An SOA implementation demands commitment, tenacity and constant review for it to be truly successful. SOA is not an answer to a specific question, but a path and methodology through which future questions can be answered. Additionally, adhering to SOA approaches and standards requires a regimen of discipline and strong governance. And support of the concept must come not only from top management but also from middle management and even the employees using the system. SOA is not a quick fix, and it’s not an approach that you can put into play and step away from.

SOA is not a panacea for every IT or business problem in the enterprise, nor is it quick and easy to adopt and implement. Still, SOA holds significant benefits for enterprises willing to approach it methodically and carefully - as well as the ones that take the time to understand exactly what it is and what it isn’t.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access