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
