RSSExpert analysis, advice and prognostications about Service Oriented Architecture and distributed computing.
Our bloggers: Mike Kavis is a veteran Chief Architect with over 23 years of IT experience including distributed computing, SOA, BPM, data warehouse, business intelligence, and enterprise architecture. Former applications developers Rich Levin has been implementing, advising on, and writing about information technology for over 20 years, covered computer technology for CBS Radio and hosts the popular "PC Talk" show. Nicholas Petreley is a former programmer and consultant, has worked for InfoWorld, Computerworld, LinuxWorld and Network Computing World, webzines, and serves as contributing editor for CIO, focusing on SOA as a primary area of coverage.
Top 10 Reasons Why People are Making SOA Fail
Keywords: soa, project management, failure
So now we know who to blame for failed SOA initiatives. It's the people, stupid! But just why do people make SOA fail? Let me count the ways.
1. They fail to explain SOA's business value.
One of the most common mistakes IT people make is that they approach SOA purely from a technology perspective. They spent a great deal of time and effort on architecture, governance and vendor assessments (which is good), but they forget that SOA needs to solve real business problems. So they spend a huge amount of time and money building out the architecture—only to find that when they are done, nobody in the business understands the benefits and are not interested in the technology.
Recommendation: Start with real business problems first. This is why BPM (business process management) is the "killer app" for SOA. BPM solves several business problems by improving and automating business processes. It provides visibility into operational performance, enhances agility by allowing the business to change their processes dynamically without IT involvement, eliminates waste—thus reducing costs—and much more. Start by showing the business how SOA will solve real business problems first. Then address the technology issues.
2. They underestimate the impact of organizational change.
As with any transformational initiative, resistance to change is a project killer. SOA brings massive amounts of change to an organization, especially if the organization does not have a well established enterprise architecture in place. Fear of the unknown is the greatest contributor of resistance to change. People need to understand WIIFM (what's in it for me) and why changing their ways is good for both them and the company. The challenge is people at different levels within the organization are affected in different ways. Each level of the business has concerns which need to be addressed which must be solved at an individual basis.
Recommendation: Create an organizational change management (OCM) plan. I would go one step further and hire an external OCM expert to help the leadership team of the SOA initiative deal with change. I am a big fan of John Kotter's eight-step methodology.
