Mike:

I could not agree more with the list you provided and the insight to go about it. I would however disagree just a tiny bit on explaining the value of SOA to the business. At the end of the day the business should not understand what SOA is. They can't care less. The business wants solutions and they expect IT will do its due diligence to deliver these solutions in a timely manner, at the lowest cost... SOA should be transparent to the business, they should just experience the benefits. IMHExperience, talking about SOA to the C level and the business is just a waste of time.

JJ-

There is something in SOA that worries me deeply. JJ Dubray touches upon it in his comment (2008-07-20) as well - somehow we take it for granted that successful introduction of SOA requires organisational change. To me that is a shortcoming of SOA in its current shape. An IT architecture strategy that requires the business to reorganise simply does not sound healthy to me.

Businesses are organised by operational or geographical responsibility, not along the lines of service ownership or usage. And frankly, that's how it should be. The dependencies that SOA introduces cross organisational borders and that is not healthy. There are reasons of budget, trust, and internal competition that all combine forces to make enterprise-wide SOA fail.

I have written about this earlier in a company whitepaper (available at www.mphasis.com > knowledge bank > white papers). My conclusion is that SOA is easier to do within a trust boundary, which is usally an organisational unit with a single operational responsibility and a single budget. This of course limits the potential reuse and hence the cost savings, as the scope is much more limited than enteprise-wide rollout. That is the price to pay.

Between these trust domains, one should strive to maintain a single view on the state of the enterprise (a data dependency which requires only very loose coupling) rather than a shared pool of services (a functional dependency requiring much tighter coupling).

To Jean-Jacques Dubray:

If SOA does not affect business, it is the dead-end for service-orientation (cul de sac). Just look into latest OASIS SOA RM and draft of SOA RA standards. SOA is not seen any more as an IT thing, it is enterprise thing, otherwise, do not bother with it.

Required business changes is not in the enterprise business model but in 1) relationship with IT; 2) ownership and accountability model. For the first, there should be a convergence between business and technology architectures. For the second, business organisation has to strictly follow the business model, not "18 century map of Germany" pattern. Every business activity must be considered from the point of contribution into the company revenue - no negative net business value (cheap project, extremely expensive changes).

Business must be in SOA even deeper than IT because all IT products have to provide business value, not a beauty of elegant code...

To Bert Hooyman:

I agree with "An IT architecture strategy that requires the business to reorganise simply does not sound healthy to me."

In SOA, IT architecture strategy has to follow business strategy, which in essence is service-oriented according to the enterprise business model. Unfortunately, this model gets masqueraded by inadequate operational ownership and accountability.

If you join OASIS SOA RM vision, you can easily find that reuse is mainly IT thing. If you build business services ( not interfaces like Web Service/WSDL to the business services ) and ask business can they reuse them, you will not find much reuse. At the same time, your services must as flexible and open for changes as possible. To reach this level, you have work ( design and build) not only to the business requirements but keeping the business model in mind as well - there are no unexpected business requirements, this must be in the boarders of the business model. Otherwise, it is a Federal Case for the enterprise.

However, if you start building real vertical end-to-end business service, you can find that it is a cross-domain thing. In this case, you can assume that the organisation has inaccurate “domain” division based on management structure, not on the business structure of business services, functions, features and processes.

Finally, SOA is a business-oriented consumer-centric architectural paradigm which covers both business and technology in the enterprise.

@JJ, @Bert, @Michael,

I was going to leave a detailed response but Michael did a great job of covering the important points for me. The only thing left for me to respond to is "selling SOA to the business". This concept is hotly debated. I believe it is critical in getting the business to buy in and drive the initiative (the business side of the initiative that is).

I did a presentation at Zapthink's Practical SOA event a few months back about how I sold SOA to the business. (Click this link and go to the 4th video - you must register on Zapthink...it's free) or look at these slides.

The key is not to discuss architecture, ESBs, web services. Instead talk about business drivers (eliminate waste, increase sales, improve customer satisfaction, increase speed to market, etc.). This is why BPM is the killer app. By reengineering business processes across boundaries you eliminate duplicate data, improve data quality, provide visibility into where things are in the flow, and offer operational reporting and metrics.

Mike,
following comment:
"This is why BPM is the killer app. By reengineering business processes across boundaries..." may be read like an IT might have an Application written in BPML (sounds similar to BPM, which can solve the problem.

Let me say that we have to be very accurate with such expressions - there are no such Application and cannot be. I would rephrase it (if you do not mind) as something like 'IT service such as Business Process Management can facilitate reengineering business processes across enterprise business divisional boundaries'

In some of my posts I am trying to say that business is already sold on SO but it uses different name - business model. SOA should not tell business to change, it is not the business to be changed but buisness management model ( ownership and accountability models) should be re-organised along business services.

Then the picture will become very clear and IT will be able to orient in it. Some business know this and simply disallow IT to get proper understanding. This is the pity thing.

You describe perfectly the reasons why the majority of government SOA projects are failing -- especially the pursuit of technology at the expense of solving business problems.

All the big contractors are getting rich while government agencies spend tax dollars trying to do SOA "on the cheap" with people who have little or no skill implementing SOA.

Actually, I do disagree. While the 10 items posted certainly contribute to why SOA projects fail, the list misses a critical item that I'd rate as number 1. Specifically the failure to take some inventory or accounting (call it what you will) of the business processes. SOA really is about business processes; before you start the SOA project, you better know the business process it impacts. Failure do that and the rest of the 10 items in the article become relatively meaningless.

Good point, which is why I keep harping how BPM can "facilitate reengineering business processes across enterprise business divisional boundaries" (I won't say killer app anymore per Michael P.).

If you look at the presentation that I included in my previous comment, you'll see that we started with an exercise in business process reengineering. The findings this exercise unearthed created numerous projects that could bring huge improvements to our business in revenue, cost savings, customer satisfaction and much more. It also provided us with a business vision of a future state which made it easy to align a SOA roadmap with.

When SOA became a buzz word, everyone started making SOA apps in cases where they don't even need it. Say if we are sure that a particular functionlity is not reused at all, what is the need of making it a service insstead of making it a direct DB call or somethig like that? When it was Webservice 1.0, the performance was rellay bad. But after Webservice 2.0, the performance has really improved.

Rebert
LEAPWAYS.COM