Tuesday, May 23, 2006

SOA In Practice

Now that we've got the theory, jargon, and general technical aspects of SOA out of the way, let's explore an example of usage. My hope is that this may spark some ideas for you in your organization.

Scenario Background: A regional Financial Services company was seeking to expand the average number of products purchased by existing customers. They knew the more business each customer conducts with them, the greater the impact to the bottom line, and the greater the retention rate. They launched a broad-spectrum marketing campaign, including print, radio, and television advertising. They even included Internet-based marketing in the form of Web advertising and e-mail campaigns. As a result, there was an influx of inquiry from both new and existing customers seeking to setup a variety of accounts. Applications came in from all channels (Web, paper, phone, even e-mail).

Challenge: The challenge for this company was in quickly processing these applications and creating the new accounts to meet high customer service expectations. As part of this, it was important to ensure that there were no duplicate accounts - these wreak havoc on their systems, especially invoicing and billing. Furthermore, since many of these were loan applications, they required credit scores which had to be obtained from a 3rd-party.

Before SOA: Prior to implementing SOA across the enterprise, each system and division had its own unique forms for new accounts, which were inconsistent. Often little differences would cause glitches (e.g., Male/Female vs. M/F, date formats, etc.). In addition, the 3rd-party providers for Credit Scores were different, depending on the department (e.g., Mortgages vs. Auto Loans). A constant challenge was in checking for duplicates, because the systems setup for this task often failed due to communication protocol errors. Checking for duplicates slowed the amount of time to process a new application.

Using SOA: With the newly implemented and fully tested SOA-based setup and associated Web Services, this company met their performance targets. Here were a few key benefits:
  • Forms - rather than have disparate forms, with inconsistencies, they created a central repository of forms and "snippets" of forms. They used Web Services to call these forms when creating a new application. If anything changes on these forms, rather than having to make the change in 50 different places, it is updated only once, and then pulled when needed.
  • Credit Scores - for consistency and speed, the firm made a decision to consolidate 3rd-party credit-score providers to a single company. They made sure the selected provider offered a secure, Web Services interface, with high availability, to which they could connect their loan application system and automatically capture the credit score. This reduced errors and increased efficiency.
  • Checking for Duplicates - they used Web Services to connect to their mainframe, which houses all customer Account Numbers. Rather than taking a great deal of time and resources writing code, figuring the format, establishing communication protocols, etc., they easily called a Service to identify duplicates. If no duplicates were identified, the system called another Service to setup the account number. By calling a central service, consistency and accuracy were preserved.

There are an infinite number of possibilities for leveraging a Service Oriented Architecture. However, Business Process Management and SOA, are particularly well-suited to one another. I'll explore this powerful combination tomorrow.

No comments: