I replied to the blog but upon reflection felt it was worth while adding a link here to see if anyone is inclined to comment further. I did.
To me, the aged ol' problem with SOA is not that there's anything wrong with it, but more, it really is nothing new. If anything, many people still fail to understand that SOA, like EDI or any "distance" API is really hard to implement and benefit from wide reuse. Heck, even a simple subroutine in a piece of code on the same system is hard to reuse and more often, is copied and modified. Welcome to "legacy" application support. SOA does not change that. IMHO.
If anyone tries to convince themselves that an SOA is not going to be a legacy problem a few months or years from now, perhaps they need to re-read the techno history books. The problem has never been how hard it is to write re-usable components, the problem always is, the legacy code needed to bring those components together. There's always something else someone wants to do with a component but you can't risk breaking it so you copy it instead. And/or as soon as you break this compatibility (which is a no-no), your break re-use.
So, is WOA any different? I think so as it really reminds me of the difference between solving the problem for the business or waiting forever for IT. You can have something that works right now or get in the back of the queue (read years) until I (maybe) write perfection. Businesses cannot wait, especially today.
At OpenSpan, we can quite literally turn any business user process into a Service and consume it from anywhere else - RIGHT NOW. It also helps IT, because they get time to do it right whilst not sacrificing what business needs - RIGHT NOW. Is that WOA?
1 comment:
From personal experience, I have recently come across a major financial project built where SOA was the business case for the project. No business rationale, no financial benefit, just a pure strategic desire to run a technology refresh and try a new TLA (three letter arcronym).
What ended up being delivered to the business was a mess of loosely coupled services, fragemented to the extreme. Frankly, calling them coupled in the first place is really stretching the truth and imagination. Service boundaries were all over the place, WCF timeouts lost in the morass of services talking to each other...you can imagine how well received an application like this would be in the business - and the sort of issues you might experience. Debugging the simplest of intra-service issues was like finding a needle in a haystack.
Now here's the nub of the problem; the application had no "orchestration" service. It doesn't need to be Biztalk, but it does need something to control the whole process end-to-end. So keep the service layers to the minumum, and abstract some logic to them, rather than run 60+ individual services, each with their own service layer.
The relevance of this to WOA? I'd agree it is the dichotomy that many in-house development teams will face. I want it now, I want it cheaply, and I want it contemporary. Sometimes pursuing new technology or methods for the sake of it can leave a business with a bad taste in its mouth.
Post a Comment