Ten reasons why people make SOA fail

Service oriented architecture, like so many IT initiatives is struggling to deliver on its promise. Increasingly, 'people' are being blamed. Here's why.

Share

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.

Then there is run-time governance. This is where you proactively manage the health of your production SOA environment. Run-time governance allows you to see what services are being consumed, enforce policies and SLAs, troubleshoot, analyse performance and manage all assets. Don't think that once you deploy that you are done. Managing a distributed environment is not a task to be taken lightly.

Recommendation: Treat governance as a fully funded initiative that runs alongside of your SOA implementation. There should be a dedicated team (which usually lives within Enterprise Architecture) with its own road map and long term vision. Don't try to implement governance overnight. This is a journey; it will take several years to reach a high level of maturity. As your governance matures, so does your SOA. Invest in a registry, repository and service management tools. You also need new testing tools to test governance.

10. They let the vendors drive the architecture.

Ron Schmelzer at Zapthink coined the term Vendor-Driven Architecture (VDA). Relying too much on vendors can be a disaster. The vendors' goal is to sell you as much stuff as possible. Your goal is to implement SOA successfully and to provide your company with maximum benefits at minimal cost. Do you see the conflict of interest?

Also, the vendors promise flawless integration if you purchase all of your tools within their stack. The reality is, they have purchased so many products from other companies that their stacks do not deliver any better integration than if you bought the tools from a variety of vendors.

Recommendation: Figure out what you need before you talk to the vendors. Perform a very thorough vendor evaluation process. When you narrow it down to a few vendors, have them come on site to perform a proof of concept for which you provide the requirements. Watch them execute on it before your very own eyes. This is where the vendors can no longer hide behind pretty PowerPoint slides; it can prevent you from making a colossal mistake. Do your homework.

Read blogs from practitioners, talk to consulting firms who use the tools, talk to other companies that have implemented SOA and talk to vendor references. Do not take any short cuts; you will have to live with the decisions you make.

Mike Kavis is a freelance IT Strategy and SOA consultant

"Recommended For You"

SOA security: Good enough and getting better Five business process and application trends for 2008