6. SOA Does Not Require More Savvy Developers or Architects
Just the opposite...the whole point of SOA is to manage complexity better and make accommodating new functions easier. This means that developing in an SOA environment is much easier than in a pure-Java or .NET environment. It's all about agility, both in the sense of making it easier to add/change functions, and in getting from development through QA and into production faster. Again, much of the value of SOA lies in putting into infrastructure parts of applications that used to be developed and so the development part necessarily becomes less complex. You will still need a few specialists on the development team, including at least one SOA architect, and some senior developers that own different component services like the database - they will need to understand how to drive the performance of the service against the database - but the stock SOA developer doesn't need to understand how to do it. This is a big change and cost savings. Most good J2EE developers are intimately familiar with driving performance of their code against a database. It's among the first things that they learn. SOA obviates the need for all developers to know much more than how to leverage your firm's SOA tools against your services. I've even seen clients successfully retrain mainframe programmers for SOA process development that have no foundational OO language skills whatsoever. So, if your HR department is putting out requirements to job boards that include your old platform spiel plus your new SOA stuff, you're on the wrong track.

7. The Biggest Challenge in Moving to an SOA Is Not Technical
It's organizational. Realigning political boundaries and responsibilities and establishing a governance regime proves difficult for most development groups. If your group is organized around a set of siloed applications then you can envision the problem. There has been a lot of debate recently about how best to approach this. Should it be addressed top-down (CIO puts forth an SOA vision and tries to convince the business to pay for the retooling) or bottom-up (developers and architects interested in making things better create an SOA groundswell)?

In my experience it's both and neither. It's a runaway process of continuous improvement where the development team identifies some low-hanging fruit to attack with SOA, which provides good value to the business, thereby leading to an ever-lengthening leash to build more SOA aspects. The alternative to this approach almost never works: a meeting with the business in which you have to ask for the big investment in SOA tooling and training to be able to deliver what they think you already should be. If you get this far, the remaining trick is to generate an infrastructure that doesn't look piecemeal. Look to open-source (or already paid-for) tools and also consider proposing to address a problem of great business need with tools that can be reused for other SOA aspects.

8. It's Not ESB
ESB evolved as a combination of hype ("We're not a proprietary integration broker, we're the bridge to SOA…) and necessity ("If SOA mediation standards aren't there, how do I do real integration?"). Not to rehash the ESB/SOA debate here, but I lose more gusto for ESB every week as support for SOA mediation standards are announced. If I can do with SOA standards what ESB accomplishes but with fewer of them, I go with the pure SOA every time in the hope that as my enterprise evolves I can repurpose and realign at a much finer granularity. I bristle at the thought of waiting for the next release of someone's integration platform to get a rendering of a new standard. At the same time, I understand the need and presence of ESB in the real world. We just need to understand that it's not SOA.