In this article we will examine a fairly common business process, customer address change, to outline a range of alternative approaches to business process management and improvement, from a low-tech, manual “quick fix” to a service-oriented architecture (SOA) approach.
The Scenario
Ann Smith calls into the Best Insurance customer service center, located in Austin, TX, to have her home address information changed. She has just moved from the suburbs of Chicago to Austin. Ann is concerned that delaying her address change may affect her insurance coverage, but she has not yet found a local agent to handle this for her.
Best Insurance, from which Ann purchased her policy, offers a range of products to its customers, including life, fire and auto insurance. Ann has two policies through Best Insurance – life and auto. Internally, Best Insurance is organized along product lines. While agents provide a single face to the customer, life and auto products are supplied by two different business units. As a result, there are two different systems storing customer information, including addresses, policy numbers, etc. Some of this data (such as the policy number) may be different, but data such as the customer home address should be identical. However, since they are stored on two different systems at the backend, there is redundant data.
From “Best” to not-so-good in one phone call
When Ann calls in to update her address, the customer service representative (CSR) asks Ann which types of policies she has. She says “life and auto.” The CSR then accesses the life policy system and, after asking for and getting Ann’s social security number (SSN), brings up Ann’s record and types in her new address. So far, this has been a simple transaction and Ann is feeling satisfied with Best’s customer service, but she’s not done yet.
The CSR then asks Ann for her SSN, again. This time, the CSR accesses the auto policy system. The CSR again types in Ann’s SSN to access her record, again asks her to repeat her new home address, and proceeds to update her auto policy information.
Ann now begins to wonder about the quality of Best Insurance’s customer service. Can you imagine how she would feel if she had four more products from Best?
Considering that all Ann’s insurance products are from the same company, why does she have to go through the address change process multiple times? Best Insurance has to figure out how to solve the customer address change need in the shortest time possible. The ideal would be to get Ann’s new address just once and, after appropriate validation, update all of her policy records at once.
The question is then, how to integrate?
The Solution
There are potentially many solutions to this challenge. Let’s consider some possibilities:
Manual Update Approach
When Ann calls into customer service and provides her SSN and new address, the CSR takes down this information on a piece of paper. Then the CSR proceeds to access and update the systems, one by one, which correspond to the policies that Ann holds. This is much better than the earlier scenario, because the CSR does not have to get Ann’s information over and over again. However, there are some potential problems with this solution. There are the possibilities of human error (and potential data integrity issues) that come with any repetitive, manual process steps. Another potential disadvantage is that the customer may need to be on the line or on hold for a relatively long time until all the systems are accessed and updated. Also, there may be legal compliance and/or security issues related to writing down personal information such as someone’s social security number.
Integrated User Interface Approach
One basic way to integrate the different systems would be to bring together these systems within a single user interface (UI). This would be similar to providing a single umbrella interface that contains individual portlets that access each policy system. Here, the CSR types in the SSN and new address onto the UI. Each time the CSR accesses the portlet corresponding to the policy system, the information is automatically sent over to the system. The advantage is that the CSR does not need to physically write down the information, and the automatic transmission will save retyping work, thereby reducing the possibility of human error. This process can be completely automated, but since the integration is only at the UI level, it requires passing of information between the UI forms. Enhancements to this basic approach may include simultaneous updates, API invocation, etc.
Integrated Application Approach
In the “integrated application” approach, the application code for the life and auto systems are actually combined by rewriting them as a single application. A major disadvantage to this approach is demonstrated if Best Insurance later acquires another company and decides to have their system integrated as well. This scenario would require another expensive, time-consuming rewrite of all applications for best integration (similarly, imagine what would need to happen if Best decided to sell or drop either the life or auto line of business). This approach would also involve reconciliation of the database structure (schema) among the systems that are being integrated. For all of these reasons, the “integrated application” approach will usually prove to be too expensive, time-consuming and ultimately impractical for most businesses.
Service Oriented Architecture (SOA) Approach
In a SOA approach, for two (or more) systems that require address updates, each system provides a service that allows external parties to update these addresses. Let’s say that the auto policy system provides a service called “auto_address_update,” and the life policy system provides a service called “life_address_update.” An external program could be created to first invoke the auto_address_update service and then the life_address_update service. Since the actual address update would be done automatically, it can be accomplished within a few seconds, if not under a second. The CSR would type Ann’s new address on a single screen, which would then trigger a process with two steps. The first step invokes the auto_address_update service and the second step invokes the life_address_update service. The CSR gets an immediate confirmation and the transaction is completed.
To take this one step further, the address update process may even be made available on the BestInsurance.com’s website, which would allow Ann do the address update herself.
There are several advantages to the service-based approach:
- The individual systems can still be maintained by different groups.
- None of the policy systems code has to be rewritten. They can all be reused.
- The database schema does not have to be consolidated. Only the mappings between the fields need to be documented and handled.
- If another system needs to be integrated, it becomes relatively easy, since all that system needs to provide is a similar address update service.
- Using a process-driven mechanism, the order-of-service invocation can be changed and controlled through conditional invocations. For instance, if the customer does not want to update one particular policy, that can be handled through external logic.
However, all these advantages do not come free. There is some work that needs to be done to create the appropriate services. As the number of services grows, there will be additional administration needs, including keeping track of the versions, ensuring that the catalog of services is available to those who want to access them, specifying and meeting the Service Level Agreements (SLAs) that have been agreed to, and so on.
One disadvantage of the SOA approach is that, since “servicification” adds a new layer of code, and the exchange happens over the internet, it may slow down the response time. However, with high-speed computers and rapid network data transfer rates becoming available, it’s probably a relatively small price to pay for the benefit of system reuse, ease of implementation, and flexibility.
SOA Implementation Challenges
As mentioned above, the services can be invoked in any order, and one can orchestrate these invocations to follow a business process. The business process itself can be modeled as a process map. The process map, in turn, has to be stored in a Business Process Management System (BPMS), so the BPMS can then pick up the process map and execute it.
We will not go into the details of the implementation challenges, but rather point out some highlights and critical steps:
All the legacy systems whose functions are to be invoked have to provide these services. Other information about the services that must be identified includes: the input it takes, the output it generates and any error conditions.
- Appropriate process maps have to be created.
- Appropriate user interfaces have to be created for the user to type in the data to the system and get a confirmation.
- A robust BPMS system has to be selected and installed.
- Database update error conditions have to be specified for handling. For instance, what happens if the auto_address_update service succeeds, but the life_address_update service fails?
- All the services have to be managed so that they satisfy certain SLAs.
- Metrics on what needs to be tracked must be specified and built.
An Incremental Approach to SOA is Best
The best way to address these challenges is probably with an incremental approach. The idea is to first work out the integration between just two systems (for instance auto and life). Then other systems can be added in. After gaining experience with that, other services may be added in. With added services comes the flexibility to add more complex business process. With more complex business processes comes the need to handle scalability and complex event processing. An incremental approach to SOA will ensure that business value is continuously delivered with each of the iterations.
