Here is an interesting example of an alleged (?) SOA-based system:
http://tech.groups.yahoo.com/group/silent-commerce/message/101 Gervas --- In [email protected], "Gervas Douglas" <[EMAIL PROTECTED]> wrote: > > Thanks, Anne. I am sure you have some interesting (optionally anonymous) > case studies that you would like to share with us ..... > > > > Gervas > > _____ > > From: [email protected] > [mailto:[EMAIL PROTECTED] On Behalf Of Anne > Thomas Manes > Sent: Monday, March 12, 2007 11:23 AM > To: [email protected] > Subject: Re: [service-orientated-architecture] Joe's Two Examples of SOA in > Action > > > > Great examples of cost-effective applications, and I've heard Sandy recite > them before, but I'd like to point out that both applications could also be > implemented using traditional development approaches. They are, in fact, > applications -- and I'm not convinced the they are especially service > orientated. > > In the first example, IBM has created a central notification system that > ensures that lots of applications that contain redundant capabilities are > notified of a changes that impacts all of them. If the system were truly > service orientated, it would no longer have redundant capabilities > implemented in all these applications. There would in fact be only one > system that maintains delivery date information. > > The second example is a simply case of automating a formerly manual process. > Implementing this automated process using pervasive protocols is an > obviously good decision. But where's the service-orientation here? > > Anne > > On 3/9/07, Gervas Douglas <gervas.douglas@ <mailto:[EMAIL PROTECTED]> > gmail.com> wrote: > > Some of you new to SOA have probably wondered what exactly it was > about, what the fuss was about, and what were the benefits. Joe here > quotes a couple of usage examples: > > <<A centralized delivery-date service. How many times have you been > given the wrong date on an order you were expecting? One retailer was > struggling with a fulfillment chain that comprised multiple systems - > each of which could update the promised delivery date for an order. > However, when someone changed a delivery date in one of the many > fulfillment applications, the information wasn't consistently updated > in the order-processing system. The result, naturally, was customer > confusion, and mangled delivery schedules. > > The solution was to implement a centralized delivery date service -- a > SOAP over HTTP service managed by an ESB. Now, when a delivery date is > changed, the fulfillment system sends a delivery-change notification > to this event-driven service through ESB, and as a result, the order > system database - and any other system that subscribes to this service > - is immediately updated. The total effort to create two centralized > services and build an ESB required four developers for four months, > Carter said. > > Charge dispute service. Have you ever disputed a credit card charge > and wondered why it sometimes took months to resolve? Maybe SOA could > speed things up. Carter cites the example of a financial services > organization had a manual-intensive process for handling disputed > charges from customers of its large retail partners. When a retail > customer disputed a transaction, the financial services organization > would manually print all transactions and send them through ground > mail to the customer to identify which transactions were being > challenged. The customer would then have to sign these papers and send > them back through ground mail to the financial services organization, > which would then package them and send selected documents to the > retail institution. After this paperwork was received, the retail > institution would decide whether the charge should be removed. This > process could take up to 20 days to complete and typically cost the > organizations involved between $400 and $700 per transaction. > > Carter reports that the financial services organization deployed a > service in front of its core transaction system that now enables > retail partners to transmit dispute claims to the financial services > organization on behalf of the partners' retail customers. To register > a dispute, customers now simply log into the retail institution's > Website and view a list of transactions that have posted to their > account. Customers can then select the transactions they wish to > dispute. The Website sends this request to the financial services > organization's transaction-dispute service. The authentication that > customers provide while logging on to the Web site enables the > financial services organization to eliminate the need for paper > documentation with a handwritten signature. > > Carter reports that the transaction-dispute process now averages a > total of three hours, reduced from 20 days, and costs only US $40 to > $70 per transaction, instead of the previous $400-$700 per > transaction, representing a 90 percent reduction in costs. "Automating > this process by creating a centralized service helped enable the > organization to realize estimated cost savings of more than $200 > million per year," she says.>> > > You can read Joe's blog at: > > http://www.soainact <http://www.soainaction.com/blog/2007/03/post_4.php> > ion.com/blog/2007/03/post_4.php > > If you, dear reader, have any interesting examples of SOA in Action, > perhaps you would like to share them with us. > > Gervas >
