08/29/08 :: [SOA] SOA Is a Failure [permalink]


This is what a lot of people would like you to believe (not everyone). They even started to lump sum integration with it. The reality is that most of these people don't understand SOA. They tried their usual remoting stunts with Web Services technologies and it did not go well: it was not really client/server and synchronous and not CRUDish at all. So some of them are jumping on the first floatation device they could grab: WOA. Anybody knows HTTP, so for them, it does not matter if you'll need an army of people to build all it can't do as long as there is no training required and license cost, and WOALa. The fine prints (like versioning, contracts, loose coupling...) well, you'll discover them at your leisure.

I work for a large financial institution and our SOA platform processes millions transactions daily. That's a lot of SOAP calls if you ask me. Recently, one of our most talented architect put in production a "connected system" that was only composed of services interacting with each other -including 3rd party services. Not a glitch. Over the last 3 months the usage has ramped up nicely and still not a glitch. Would you consider these two data points a failure? I certainly would not. These technologies are not perfect but they work.

Could we be better at SOA? sure, there is always room for improvement everywhere: operations, BPM, more connected systems, exposing more business logic and legacy data could all bring additional value, tons of value.  

Now I rarely disagree with people like Loraine Lawson or Eric Roch for instance. Like many, their posts are deeply rooted in experience and they don't care about launching the fad du jour. They try to look objectively about what works and what doesn't, why, in which context, and so on.  However, today, I would like to disagree slightly with Loraine. She argues that:

Integration, SOA, Whatever. It’s Always About the Business

She recommends to involve IT decision makers and brag about the results.  My experience is that the key people that you have to focus all your energy on are the developers, architects, business analysts, QAs and operations. If they don't get SOA, you won't have much to brag about. Sure I understand why she is saying this, SOA and Integration may cost a lot of money and you can't always hide the deployment of SOA infrastructure components within projects, but at the end of the day this is a pure IT problem.

The business cares about "solutions" (I think we agree there, she says: "the business may benefit when IT is most effective and efficient"). But, SOA is not a solution. SOA is an architecture. It is IT and IT's only responsibility to decide whether they want to do SOA and for what reasons. IMHO, we wasted years trying to convince the business to throw money at SOA and to a certain degree disappointed them when we missed the most critical success factor: get delivery and operations organizations knowledgeable and on board. How many of you are going to tell me that they saw their delivery organization dismissing SOA because it was changing too many things for them, it was creating too much risk and sometimes they even had too much to loose. If you want to fail your Service Oriented Architecture ignore delivery and operations and focus all your energy on "business architecture", go play golf with your CEO and CIO and get a big budget to buy expensive products.

Yes SOA can be successful, if you want, but not every path will lead you to success. There is no magic product or technology. Just like for anything, specially of that magnitude, you need to think hard about what you do and really understand who are the key stakeholders of SOA. It might be a surprise to you, but the business can't care less about SOA, they only care that you solve (all) their problems (in a timely manner and in a cost effective way).

Getting a SOA initiative on its feet is actually simpler than it may look:

1. Create a COE to make sure that skills reach a critical mass in your organization

2. Think Globally: Make sure you understand the big picture of where you want to be and what change is going to happen and how it is going to happen

3. Act Locally: Use your COE to help regular projects create services. The key here is to get your delivery teams excited about SOA. It might look like Just a Bunch of (Web) Services (JaBoS) at first but don't spend a lot of time governing where there are no obvious reuse opportunities. Make sure, also, that Service Construction does not disrupt project lifecycles, schedules and cost.

4. Make sure your services can be found (registry)

5. Iterate: make your services reusable when someone wants to reuse them.

6. Take every opportunity to get closer to (and refine) the big picture

7. Grow your CoE and move resources back into your delivery organization

8. Once you get results, brag about them...