Top 10 Reasons Why People are Making SOA Fail
SOA is not something you buy, it is something you do. Research shows us that very few companies are doing it well. But the reasons for so many failures are usually people issues, not technology issues.
Recommendation: Develop an extensive training and resource plan and include it as part of the initial request for funds when delivering the business case for SOA. Try to reduce the number of times you need to ask for money and get as much as you can up front. Otherwise, management may view the SOA initiative as an endless drain on capital.
6. They have poor project management.
At the end of the day, it still boils down to a company's ability to manage projects. Project managers must manage scope, mitigate risks, keep everyone on schedule and provide the proper communications to people at all levels. Requirements gathering is critical and analysis paralysis must be avoided. If your organization struggles delivering normal projects, your chances of success with SOA will be twice as challenging.
Recommendation: Put your best project management resource(s) on this project. Or go out and get a rock star or two to help lead this initiative. Whoever you chose should have a track record for delivering huge, transformational initiatives. To make matters even more challenging, this person needs to be technical enough to understand SOA from a conceptual level.
7. They think of SOA as a project instead of an architecture.
Many companies are naive and think that implementing SOA is just another project. SOA is a software architecture and only achieves desired benefits when a company adheres to the core principals of service-orientation and ensures that deliverables are consistent with the architectural vision and road map. SOA requires specialization. A business service may be built through the efforts of an SOA architect, a developer, a data architect, a network architect, and a security specialist. Gone are the days where one person wears all the hats. There is also specialization within the layers of the stack. You have user interface designers, business process models, data services experts, business rules specialists, ESB experts, etc. All of these specialists may be working on the same services concurrently which requires high levels of collaboration.
Recommendation: The standard IT team structure is not effective for SOA. Think outside the box. I prefer a matrix organization and a collaborative war room environment. Tear down the cubes and set up an open space to allow for these specialists to work closely together. It also helps to have the business and testers in the room also. Put up white boards everywhere. Eliminate as many schedule meetings as possible and choose more collaborative techniques instead.



