Even though there is such a hype & hoopla around SOA and every products & services vendor out there is preaching SOA, what I am finding is that it is in fact a very small world. Between a couple of people I know in this space it seems like we are able to pretty much map out the people, the organizations & jobs, the chances, the opportunities, the successes & failures the SO players have had. Every once in a while I catch up with some people and discover that we have similar observations on this space about people & organizations, their thought processes and the direction in which they are going.. largely misled:

• Category 1: SOA is such an Industry/Market Buzzword – We have to SO’A'ize.
  The blind need for every vendor to go SOA reflects the lack of clear knowledge.
• Category 2: SOA = EAI. Its just a new marketing buzzword for EAI. We’ve had COBRA (CORBA he he) and yada yada for a long time now.  Its just a new market buzzword.
  If SOA and EAI were the same thing I think someone would’ve called it out. There are subsets of similarity in goals that are being tried to achieve, but it would be more accurate to say EAI is / was a subset of what SOA should be.
• Category 3: SOA = WebServices. Web Services X & Web Services Y. Publish-Subscribe-Discover. We are done.
  If it was that simple then every restaurant in the world would have had the same kind of customer service and client experience. There are more dynamics involved here than this simplistic viewpoint.
• Category 4: SOA = BPEL BPEL BPEL – Let’s do BPEL in our IT organization. We are not cool if I dont do BPEL.
  Do I need to say anymore?  
• Category 5: SOA = We have this Multi-Million / Multi-Billion Dollar ERP system which was suppossed to solve all our problems. It never did that / It is doing what we need it do. Why should we believe that you have something to offer ? ERP vs SOA?
  Your ERP provides a set of functional business services, probably in conjunction with some of your custom applications. The orientation & alignment of these for maximum value is what Service Orientation brings to the table.
• Category 6: SOA = Unnecessary levels of abstraction & virtualization => Executional Overhead => Why do it at all?
  People dont understand the underlying reasons & benefits of virtualization. What can be leveraged? Who are the benefactors & what kind of benefits can they derive?
• Category 7: Our SOA products / product suite can solve all your problems.
  Now, how many times have you had a product vendor tell you that and then reality hits base when the rubber hits the road. The products have improved, and technologies have matured, but its still just a set of tools. If you wanted to build a house would you go to Black & Dekker or seek out the best Architects, Designers, Planners and Engineers & Managers to make it happen. Case in point.
• Category 8: Our IT organization / Enterprise Architects / System Architects are responsible for it & will drive SOA. – An SO initiative should not only involve but should “start” with the Business. It needs to start with the Business People; who justify & hold the purse strings, who the IT Management & IT people connect with at every level.
  -
• Category 9: SOA = Fixing our IT & solving all those bridge issues. – Yes & No.
  If there is no specific outcome or set of outcomes that your organization (Business Value Outcome) have in mind then it will probably be a pointless venture. Service ‘Orientation’ – What are you trying to orient towards today?
• Category 10: SOA = We dont need SOA. We need to solve our Data Quality / Master Data Management (MDM) / Business Intelligence / Data or Business Warehousing issues.
  A large majority of Data related issues arise from the silos in the organization (Business Silos as well as IT silos). Silos are the reality of an organization. They have been part of the human evolution for ages..and they will not go away.
  What do you need to do?
  Determine how silos influence each other, the overall structure / organization & the other way around. These influences are not limited to Data alone. Data is nothing but water in lots of buckets that gets passed around between people and/via technology / manually (active & passive modes). Those influences are cross ‘system’ & involved a lot of things.. Process, People, Technology..
  The key to solving your Data problems lies in your Processes & vice versa.  
• Category 11: SOA = I have all these consultants in here, I have all these SOA enabled middleware tools & products, we have been service orienting for 12/18 months now and we are just not happy. How do I get all of this to work for me? I dont want your high level strategy / roadmap that you give all your clients that end up as a bunch of documents that have no tangible impact. I want something that will have an impact on how I get these things done.
  These are the frustrations I get from the early adopters who were sold on SOA by a products vendor, IT bigwigs, Service Major (Think the Big5).
  I have 2 words: “Business Architecture” & “Business Governance”. Everyone is talking about it now, but they dont really understand what kind of ‘change vehicles’ are needed here.
• Category 12: BPM = I have to make all my processes kosher. I need to document and map each and everyone of them from start to finish in an “as is” state as well as “to be” state. I want to manage all my processes.
  The reality is processes are usually not well defined. Even after they are designed and defined there are micro-processes internal to them that act as constraints, essentially changing the ‘ideal’ view of that process towards a more ‘real’ view. These micro-process constraints are usually undocumented & neglected as a part of ‘major business processes’. Even though they are part of the core business processes, they have very low visibility in terms of the tangible business function, vocabulary & semantics.
  When the time comes to realize these processes, these constraints bring a less than real picture of BPM.
• Category 13: Executives are afraid of asking difficult questions. Dont’ give me the grand future vision. Let’s just document these things, get the tools and move forward.
  This is usually, when executives take the naive route and are going through the “first round” of their SOA / BPM initiative.
  Because, they did not pause to ask the difficult questions & neglected issues that could become stumbling blocks later on, they are digging themselves into a hole.
  It is when they have been through 1st & 2nd rounds of these initiatives & not achieved any tangible results that have a ‘real’ impact on their organization, that they start asking the difficult questions. At that time, they are extremely defensive, untrusting & will be the devils advocate to the n’th degree.
  I’d say, if they had asked their in house experts & consultants some of these questions earlier on, a lot of things would get addressed & better trust factors would’ve been built.