8. They underestimate the complexity of SOA.

You don't know what you don't know. Conceptually, SOA is simply the next evolution of what IT has been building over the years. It is not a hard concept to understand, but it is hard to implement correctly. The beauty of SOA and BPM is the simplicity it brings to the end users by integrating various back end systems so they look like one composite application to the user. The downside to SOA is that this greatly increases the complexity of building and managing software. Building SOA is a software engineering exercise. This is not drag-n-drop development effort and many developers will struggle to make the transition. SOA requires adherence to standards and best practices (governance) and needs talented individuals who understand complex concepts to be able to deliver.

There is so much to do to implement SOA that often security is an afterthought. It is critical that security requirements are gathered early so that the underlying architecture supports security from its inception. Otherwise, it is highly likely that major changes in architecture will need to occur if security is addressed later on.

Recommendation: No matter how conservative you are, expect to run into various technical road blocks along the way. Build in time as you will run into various integration issues, some caused by your code and some caused by the tools themselves. The vendor products are all far from being mature and there will be issues. Set realistic expectations and don't try to take on too much too soon. Start small, deliver value often, and build on it. Build security in from the inception; don't let it be an afterthought.

9. They fail to implement and adhere to SOA governance.

Governance is a dirty word to many people. Anything that sounds remotely close to government can't be good, right? Wrong! Call it SOA management and maybe people won't shiver as much.

Regardless, to achieve the benefits of SOA (reuse, flexibility, agility), the team must adhere to the architectural guidelines that the company adopts. This is what is called design-time governance. Without design-time governance you will likely wind up with JABOWS (just a bunch of Web services). If that occurs, you can throw the ROI out the window because you wind up building everything from scratch each time. When done right, SOA becomes more cost effective over time. Eventually the development effort will shift from building services to consuming services. Jason Bloomberg of Zapthink calls this the tipping point, when the SOA starts reaping the benefits of agility and flexibility.