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 a 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 an enabling standard leveraged within many SOAs, you can certainly build SOAs using other standards-based technology such as CORBA, COM, J2EE, etc. You may even build SOAs using technology that’s proprietary to you. Remember, SOA is an architecture. The technology you employ should be appropriate for your requirements, there is no one size fits all. Number Three: If you purchase an ESB, you have a SOA. Not really. ESBs are good technology, they allow you to move information in and between applications, and do so through Web service interfaces. However, they are one solution out of many, and you must first understand your own requirements and issues before buying one of these puppies. Thus, while they can certainly be part of some SOAs, 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 architectural approach. The degree in which they are able to scale is a function of the technology solution. 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 vendors. However, the fact is no one vendor has an end-to-end solution for all architectures, and requirements. Thus, typically if you pick a single “big stack” vendor solution, you’re only getting part of the architecture right. Unfortunately, it’s a bit more complicated than just picking up the phone and buying from the major vendor already in your company. However, based on what I’m seeing, many are purchasing technology that way. 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(s) 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, etc., etc., etc. Then, and only then talk technology, and don’t forget the proof of concept testing to validate the technology before writing the check. Software Development