2009/1/17 Nick Gall <[email protected]>: > On Sat, Jan 17, 2009 at 4:59 AM, Steve Jones <[email protected]> wrote: >> 2009/1/16 Nick Gall <[email protected]>: >> >>> On Fri, Jan 16, 2009 at 2:05 PM, David Chappell >>> >>> <[email protected]> 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". >> >> Just a little point of order here. There are those (Mr Baker for >> instance) who have regularly claimed that just using HTTP makes it Web >> Oriented/REST. > > I won't speak for Mark, but I never claimed that just using HTTP makes > it WOA/REST. If that were true then every HTTP-based WS-* interface > would be WOA/REST and I hope it is blindingly obvious that I don't > believe that.
I deliberately didn't accuse you, but it was to make the point that over-claiming isn't unusual. > >> If this project thought about its services, modelled its services and >> then co-ordinated them using BPEL then that to me can count as SOA, a >> million times more realistically than quoting HTTP usage figures as >> proof of REST. > > There's a critical gap between "Can count as SOA" and "does count as > SOA". Sort of the necessary vs sufficient divide. I'm looking for > those who consider themselves SOA experts to provide their opinions as > to what is required to fill the gap. Doesn't Dave count? > >> The key phrase is "using services" at the highest level that is what >> is important an architecture that is ORIENTED towards services. This >> isn't old school EAI which was oriented towards either APIs or >> messages. > > So to fill the gap between "could be SOA" and "is SOA" in a case study > is merely the additional requirement that "we are using services at > the highest level"? Even if those services are as poorly designed as > imaginable, ie they are needlessly specific services and they are > virtually impossible to change once deployed, we still have SOA? SOA doesn't mean that it can't be crap in the same was a WOA doesn't mean it can't be crap. You can have the best service design in the world but pick the wrong technology to implement it then its going to be a rubbish SOA. If the services are poorly designed and not representative of the business or problem context then it would (for me) not be SOA. If they are however well designed and representative of the business then it is (IMO) SOA. The SOD (Service Oriented Delivery) could be complete bobbins but the Architecture would still be SOA. > > That seems a woefully low threshold to me. And a large factor in the > current backlash again SOA. Every set of ancient EDI supply chain > services (PO, Invoice, Shipping Notice) would qualify as SOA, even > though organizations have bemoaned EDI's brittleness and fragmentation > for years. Nope because most of those (as you say) are based around message exchanges around data objects which are not representative of the business service context. > > IMO, if a so-called "SOA case study" doesn't substantially improve > sustainable business flexibility (enabled by service sharability and > adaptability) then its not worthy of the name. (That's how I fill the > gap between "could be" and "is". And I hold WOA to the same > requirement.) But virtually none of the case studies I've read (other > than the WOA ones) demonstrates how the "SOA-based" system responded > to changing business needs over time. Which WOA ones? I've not seen (m)any outside of Google/Amazon/SFDC. I'd argue that there are lots of SOA case studies from the vendors that demonstrate technical flexibility (changing BPEL in the process oriented parts of a service oriented architecture is miles easier than doing the same in Java/Ruby/C/VB/etc) and there are significant ones that have delivered business flexibility. Again I don't normally do this but... http://www.capgemini.com/resources/success-stories/by_solution/serviceoriented_architecture/ For instance http://www.capgemini.com/resources/success-stories/atoc/ which went live in 2005 used a definite service oriented architecture, certainly led to more flexibility, re-purposed a legacy system which was extended with modern technology and gave a massive increase in business flexibility. Steve > > -- Nick >
