The Oracle Australia and New Zealand Middleware and Technology Blog.

Friday, April 3, 2009

Viewing SOA as a project instead of an architecture

Recently a lot has been written about SOA's failure to deliver results and ROI. Wherever you turn you will find blogs, articles and opinion pieces saying what amounts to "At last the snake oil is exposed. Flush and lets ...".

And that's thing thing isn't it? Lets what exactly?

Lets go cloud computing? Lets go Web 2.0? Lets go mash-ups? Or whatever. Thing is will any of these turn out any different to the perceived failure of SOA in 5 years time? Why would they? Most of these concepts borrow from SOA ideas which were based on ideas that came before that. I am reminded of Larry Ellison describing the IT industry as being "more fashion-driven than women's fashion."

It all goes back to the fundamental truth that I often write and speak about . SOA/Distributed-computing/Web 2.0/Mash-ups/Cloud-computing/yada-yada-yada all need an architecture rather than the "let's go buy some software, do our project and be heroes". In fact this attitude is what created the mess that SOA et. al. was born to fix.

This was succinctly put by Anne Thomas Manes recently in a blog about called Measuring SOA Success/Failure. Anne's headlines are often read (eg. SOA is dead) but the content of what she writes is often not digested. Here are a few salient quotes that should be heard loud and clear:
  • Most organizations that I've spoken with are using service-oriented middleware to do integration (SOI rather than SOA). Very few companies are actually re-architecting their systems...
  • I have seen a small number of spectacular success stories. These companies have realized huge savings, they are able to deliver new solutions in significantly less time than before. All these companies adopted SOA as part of a much larger IT transformation effort...
  • And just in case you miss my point, I still strongly encourage organizations to invest in SOA. But my primary recommendation is to focus on architecture rather than technology.
Here we see that most organisations use SOA to do point-to-point integration with Web Services. No wonder we see no value - all you achieve is add yet another technology to the mess.

The goal rather needs to be the rationalisation of IT. Effort needs to be applied to streamline the business process by reducing the complexity and the application and data layers. But this is difficult. It involves political fights as it cuts across fiefdoms. It involves the hard work of forward planning. Don't confuse what I'm saying to mean that you have to "boil the ocean" upon the embarking of the good ship SOA. Not at all. The SOA journey is taken as a number of steps but the before we leave the dock we need to know where we (the whole organisation) are going and why. Then each step can be taken in the right sequence - it can be taken in context with the other steps.

I am getting increasingly frustrated as each wave of IT technology is deemed to be a failure and the software products are invariably identified as the culprit. I am reminded of an old adage "a poor workman blames his tools". Doesn't matter how good the tools are - if you start building without a plan (architecture) don't cry if you make a mess.

2 comments:

Kate Carruthers said...

The big problem with SOA has been that it is often implemented as a point solution (often to solve integration issues) rather than as part of an effective enterprise architecture approach. Ramshackle approaches lead to ramshackle results & that is often what we've seen with SOA.

Jeff Salleh said...

I totally agree with the your thoughts and so to kate's comment. Most org end up doing SOI, and the challenge if to change that thought from SOI to SOA and I am really interested in how technologist can have tools/technique to influence SOI back to SOA.