I saw an interesting article on Zapthink today called Who's Killing SOA (you need to register to see the article). In this article they discussed the different groups of individuals who are causing some implementations of SOA to fail. Here is a quick summary.
Integration platform vendors. Some of the vendors are pretenders and have put some wrappers around their products and call it SOA.
My take. Do your homework, spend some time on a well thought out RFP, and have the finalists come on site and do a proof of concept to prove that their stuff lives up to their Power Points and marketing brochures.
Enterprise architects. Not all architects "get" SOA. Some think it is something you buy in a shrink wrapped box and install. Others think it's a bunch of web services. Some EAs are technical enough and business savvy enough, but they just don't get the concepts.
My take. Train them immediately. If they still don't get it, get them off the project before your project is doomed for failure. The EAs are key to a successful SOA implementation. Not only do they design and implement SOA, they are your evangelists for the rest of the developers who are watching the project to see if it gains traction in the organization. You need highly motivated individuals who believe in the promise of SOA. If you don't have EAs like this, don't even bother.
My take. If you are relying solely on analysts you are dead meat. Talk to other EAs, read blogs, leverage your network, talk to companies that have successfully implemented SOA. Analysts are just one source of information and most are bias.
CIOs. On this one I will quote the story.
You'd think that every CIO would be all over SOA. After all SOA can reduce integration cost, increase business visibility and agility, increase asset reuse, and ease regulatory compliance. What's not to love? For any organization that faces any or all of these problems, SOA is a no-brainer. And yet, the CIO is rarely the SOA champion for the IT organization.
The reasons for this lack of insight are many and varied. Many CIOs are nontechnical, and as a result don't understand, and often fear, architecture of any kind. Others are so driven by quarterly results that a long-term, iterative initiative like enterprise SOA is out of the question. Still others insist on project-based IT funding to meet the needs of individual lines of business, a funding mechanism virtually guaranteed to slow down any initiative that seeks to reuse assets across the IT organization the way that SOA encourages.
Fortunately, you can recognize clueful CIOs because they understand the business value SOA can provide, they are willing to fund initial SOA iterations, and as the IT organization delivers value with those early projects, the CIO authorizes more of the same. Unfortunately, however, such executives are few and far between.
My take. If your CIO is not on board you better have strong sponsorship from the business. Somebody high up needs to be passionate about this project and drive it through the organization. Make sure you capture key metrics that prove out the value proposition. Track service reuse. Continuously sell the value of SOA to those in doubt. Here is a good summary of benefits from fellow blogger Eric Roch.
Large consulting firms. SOA experience is hard to come buy. Most companies need to leverage the expertise of consulting firms to help implement SOA. Unfortunately, the skills shortage also impacts the consulting companies as they are rapidly ramping up with resources to meet the demand in the market place.
My Take. Invest some time into interviewing the technical leads of these firms. Do several reference checks. If you have purchased tools, ask for references for companies that have the same tools. Check with your vendor to poll their organization to provide feedback on the consulting firm. The vendor wants you to be successful too.
My Take. Tie your SOA initiative to business objectives. In my case, we sold SOA as the infrastructure necessary to leverage the business's investment in BPM.
I thought the Zapthink article provided a great view into the players who could derail your SOA project. I would add one more group and that is your IT department. Many IT departments have seen many silver bullet solutions come and go and can be pessimistic about all of the hype about SOA. In addition, many IT shops do not have a great history of implementing large culture changing initiatives.
My Take. Attack your SOA implementation in small manageable chunks. Create 2-4 month deliverables, spend time on change management, evangelize, advertise wins, and squash any resistance.
At the end of the article, Zapthink asked a handful of questions. I will post my thoughts on these questions tomorrow. Stay tuned!
The ZapThink Questions
Do you feel that SOA is truly in jeopardy?
Which forces do you feel are most responsible for the dangerous situation SOA finds itself in?
And most importantly, how can we work together to overcome the challenges, and craft SOA into the mature, ubiquitous approach we all desire?
