+1 with Nick
________________________________ From: Nick Gall <[email protected]> To: [email protected] Sent: Friday, January 16, 2009 8:42:51 PM Subject: Re: [service-orientated-architecture] Re: IBM's Carter on Selling SOA to the CEO On Fri, Jan 16, 2009 at 2:05 PM, David Chappell <david.chappell@ oracle.com> wrote: > [DC] - In my blog posting from Earth Day of last year, > http://blogs. oracle.com/ davidchappell/ 2008/04/roi_ by_the_ton_ > going_green_ wit.html > > I highlighte a case study about Verizon Wireless going green by rewriting > their fraud detection application using SOA, EDA, and Web 2.0, and as a > result eliminating 6 tons of hardware from their datacenter. > > The old application, which was based on J2EE, replicated the entire data > warehouse of call detail records for use by the fraud detection application. > It also had a lot of procedural custom code that was hand written by 5 FTE > over 2 years, some stuff that was ported from Forte to J2EE, and 100s of > JSPs feeding (circa 1995) html 3.0 pages with data. > > The new implementation is 0.5% of its original size. They replaced 100's of > JSPs and EJBs with 1 JSP and 1 SWF file for UI and BPEL processes which > access call detail records from the backend systems directly (via service > level interfaces). They also went from 5 FTE over the course of 2 years > down to 1 consultant who wrote several BPEL processes over the course of 1 > year. Why is this an example of SOA? Is ANY use of BPEL and "service level interfaces" (as Dave calls them) an example of SOA? Is ANY use of BPEL and things called "services", which is deemed a success by its implementors, an example of SOA? The reason I ask these questions is that I see a LOT of "SOA" case studies that sound to me just like good old fashioned integration case studies or even good old fashioned EAI studies. So why isn't any "successful" integration project that throws the term "service" around an SOA project? Or perhaps it is to some people. Gartner's definition of SOA (modular, distributable, described, sharable, and loosely-coupled) requires more than just successful integration and the use of the label "service". The resulting system must deliver services that are both sharable and loosely-coupled (able sustain change with minimal impact on existing dependencies) . I didn't see anything in Dave's description that indicated that the resulting fraud detection system was any more changeable or sharable than the old one. Sure it was smaller, cheaper, etc. But perhaps it was incredibly brittle and needlessly specialized (ie not sharable) as well. I can't tell from the description. And that's my problem with most "SOA" case studies. Almost all are reported immediately after they are deployed. So I have no reason to believe that they will generate more shared use down the road or that the service interfaces will be evolvable over the long run. And if they lack these qualities, they're not good examples of SOA -- at least according to some definitions -- they're merely good examples of integration using services. Unless good integration using services is all you mean by "SOA". -- Nick
