I'll get more info but its easy to imagine that services that provide
access to call detail records could be used by a variety of things
besides fraud detection.
Also if the design includes BPEL then it is by default more flexible
than hard coded interactions between services.
Dave
Sent from my iPhone
On Jan 16, 2009, at 3:42 PM, Nick Gall <[email protected]> wrote:
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".
-- Nick
