As I go from conference to conference speaking on the development of SOAs I’m always surprise to hear how much people don’t understand about this concept. Perhaps it is the marketing engines around the many vendors grabbing land in this space, or perhaps it’s how SOAs are explained in the main stream IT press. No matter how you got it wrong, it’s time to get it right.
Number One: Service-Oriented Architectures are a new concept.
Not really. We’ve been attempting to create solutions and technology around the notion of sharing functional behavior, or services, since we have had more than one computer running in an organization. Indeed, RPCs were the first real attempt at providing this type of architecture, then IPCs, and on to more sophisticated technology such as distributed objects like COM and CORBA. Web services, albeit a newer standard approach, work much like “traditional” distributed objects. In other words, it’s an evolution not a revolution.
Number Two: You must use Web services to build a SOA.
Nope. While Web services are by far the preferred enabling standard in the construction and deployment of a SOA, you can certainly build SOAs using other standards-based technology such as CORBA, COM, and J2EE. You may even build SOAs using technology that’s proprietary to you. Remember, SOAs are all about the sharing and management of services, as well as processes/orchestrations that exist on top of those services. The technology you employ should be appropriate for your requirements.
Number Three: If you purchase an ESB, you have a SOA.
Not really. ESBs are very powerful technology, they allow you to move information in and between applications, and do so through Web service interfaces. However, they are not good at behavior-based integration, or sharing of actually application behavior, they are more information-oriented. Thus, while they can certainly be part of a SOA, they are not really a “SOA-in-a-Box” solution.
Number Four: SOAs are naturally highly scalable.
I’m sure most of you already knew this was a no. Indeed SOAs are an approach, the degree in which they are able to scale is a function of the technology solution and the instance of the architecture. For example, those that stand up services that are too fine grained may find that scalability is an issue as more of a load is placed on the architecture. There is no magic bullet when considering scalability. You have to first design the SOA correctly, understand the properties of all of the parts, and select the right enabling technology and development platforms. This issue is a book unto itself.
Number Five: SOAs are always justified.
In many cases you can make a business case for SOAs because they address two issues which save many organizations money, including; reuse of existing software (as services), and the ability to change the IT solution as the business needs change, or agility. You must do an assessment before you setoff to design and build a SOA, and do a business case based on your understanding of the benefits and the cost of the project. In most cases the cost is justified, meaning it will make the company money, but in some cases it’s not. Remember to factor in the soft savings as well, such as the agility a SOA brings to an enterprise, and the enterprises’ ability to adapt IT to new markets quickly.
Number Six: You have to use a single vendor when building a SOA.
Many point to compatibility issues when dealing with a number of vendor. However, the fact is no one vendors has an end-to-end solution for building and deploying most SOAs and you must select best of breed. You manage compatibility issues trough proof of concept testing early in the project. I call that “getting all of the liars in the same room.”
Number Seven: When building a SOA you select a type of technology and vendor, and work from there.
My God no. You understand your requirements, what problem you’re looking to solve first. Do a business case, and then design your system. This means doing a bunch of work including understanding the semantics, security issues, integrity, services that already exist, and services you’ll need to create. Then, how you orchestrate those services into solution, and how those solution can be changed to account for changes in the business. Then, and only then talk technology, and don’t forget the proof of concept testing to validate the technology before writing the check.
Number Eight: When you have a SOA you don’t need application integration technology.
Nope. While SOAs make application integration much easier, you’ll find that you still need core integration technology such as transformation, routing, process integration, adapters, etc. In fact this integration stack may become part of your SOA, but your SOA will not automatically include it. It has to be part of the architecture and planning.
