11 min read

As a part of informative conversation, we have Adil — IT Manager for Home Insurance Systems, Elena — Chief Architect, Jennifer — Project Manager for Auto Insurance Systems, Mark — Project Manager for Home Insurance Systems and Service Manager for Customer Information Service, Mike — IT Manager for Insurance Products, Raj — Technical Lead and Member of SOA Center of Excellence, Ramesh — Solution Architect for Annuity Systems, Spencer — Member of Enterprise Architecture Team and finally Alexandra — Spencer’s wife as the key characters.

Every organization’s journey to SOA adoption must begin somewhere. Some organizations may take a very top-down approach based upon direction from the Chief Information Officer (CIO) or other senior IT leader, while other organizations may begin with a grass-roots effort from within the IT organization, often times during a single project.

Beginning the SOA Journey

Spencer walked in through the main doors of Advasco, a leading financial conglomerate, on Monday morning knowing it was going to be a busy day. He was part of the Enterprise Architecture team at Advasco, and immediately headed for his weekly meeting with his boss, Elena, the Chief Architect. “Come on in, Spencer,” she said. “As you know, we’ve been given a big challenge over the next few months.”

Late last week, the head of the sales and marketing for the insurance division announced that they needed to improve the way they interacted with their customers. Advasco began as a typical financial services company, but had recently expanded into the insurance area through acquisition. They began by acquiring a company that provided homeowner’s policies in several Midwest states. Over the next few years, Advasco had acquired several other regional insurance companies. This resulted in an increase in the number of insurance products that it offered, as well as turning Advasco into a nationwide provider. Unfortunately, Advasco was struggling to increase the number of insurance products per customer. Analysis of the situation had determined that while the sales staff of the original organizations had been combined, each of the different insurance products relied on different applications for customer management. As a result, it was far more difficult for the sales agents to know what insurance products any given customer had. After discussing it with Mike, the IT manager supporting insurance products, IT was given the task of providing the sales agents and marketing staff for the insurance division with a single view of the customer.

Elena then said to him, “I had a meeting with Mike to discuss their new initiative to provide a single view of the customer to the sales agents and marketing staff. While he has some great developers in his area, he asked me if Enterprise Architecture could provide some architectural guidance to their effort. Given the excellent integration work you did when Advasco acquired our first company in the insurance area, I think you’d do a great job on this effort.”

“It certainly sounds like an exciting project,” said Spencer, “I’d love to help out. Just last week, I met with my own insurance agent and saw first hand the frustration he had in trying to see the different insurance products that I have for my family.”

“I’m glad to hear that,” said Elena, “I’d like you to meet with Mike today and start coming up with an architecture for the effort. I know you’ve been reading about SOA. Perhaps this effort can serve as a good pilot for some of the techniques.”

Spencer agreed. He left Elena’s office and went to his desk to set up a meeting with Mike. This was going to be an exciting effort. This initiative was highly visible within the organization, since Advasco’s customer approval rating had been taking a beating over the past two years.

In addition, Elena knew that Spencer had been researching SOA. In his reading, he felt that SOA had great potential to change the way that Advasco built applications. This effort would provide an opportunity to try out some of the technologies associated with it.

Later that afternoon, Spencer met with Mike to go through the existing applications. Mike said, “Unfortunately, the situation is a mess. Right now, the application that handles our auto insurance business is completely independent from the application that handles our home insurance business. The same thing is true for the life insurance business. They each have their own databases, requiring our agents to enter all of the customer information in multiple times. It creates a nightmare for our billing department, especially when trying to compute discounts for multiple policy holders. These applications have all been built using different technologies, including COBOL, VB.NET, and Java.”

Spencer said, “Well, let’s take a managed approach to this effort. Which are the two insurance lines where we most frequently see repeat customers?”

Mike replied, “The most common case is for a customer to hold both an auto insurance policy and a homeowner’s policy. It’s an easy way to get a multiple policy discount.”

“Well, why don’t we start with those two systems and see what we can do. I’ve been reading about SOA and I think it could provide the right approach for this effort.”

“I’ll trust you on this one Spencer. Elena spoke very highly of you in our meeting last week. As long as you don’t think adopting new approaches will impact the timelines, I’m okay with it. The insurance sales and marketing group is under a ton of pressure to get our customer approval rating back up where it should be as quickly as possible.”

The next day, Spencer met with the managers responsible for the auto insurance systems and the home insurance systems. Spencer kicked off the meeting, “We’re here to discuss how we can make things better for our sales staff. Right now, they have to deal with two separate applications. As a result, sometimes they don’t know when they’re dealing with someone who is already a customer. Other times, we wind up with inconsistent records across the two systems, or have problems keeping records up-to-date when a customer moves.”

Tim, the manager for the auto insurance systems immediately jumped into the conversation, “If we could get the home insurance system to use our customer database, our problems would go away.”

Adil, the manager for the home insurance systems, responded to Tim, “We’ve spent the last 15 years evolving our application and database. It would be much more expensive for us to try to move all our data into your system.”

Spencer could sense the tension in the room. Both of these managers had invested many years in their systems, and neither one wanted to relinquish any amount of control. “I don’t think consolidating the data will work with the timelines we’ve been given. What I’d like to do is to create a new customer information service that will provide an abstraction layer in front of both of your databases. You’ll both need to modify your applications to use the service rather than going directly to the database, but the service will ensure that both systems remain in sync. In addition, you’ll have access to additional information about the customers in each other’s systems that you can now incorporate into your applications. Then, at a later time, we can pursue consolidating the databases into a single one. With the service in place, you won’t need to make any changes to the front end of your applications when that occurs.”

Adil said, “How are you going to make this work? My system leverages a Java front-end talking to our mainframe, while Tim’s system is based completely on Microsoft technologies?”

Spencer responded, “I think this a great opportunity to leverage web services technology. It claims to provide interoperability across these platforms, let’s give it a try.”

Tim said, “Who’s going to write this service?”

Spencer suggested, “Since we need to incorporate information from both of your systems, I suggest that we form a team with a developer from each of your groups to design and build the new service.”

Adil and Tim agreed, and told Spencer that they would let him know what developers they would contribute to the effort.

Spencer went back to his desk and knew that he had a real challenge on his hands. While the managers involved had committed developers to the effort, he also sensed that there was some hesitancy about the effort. They knew that changes were needed, but it was clear that neither one wanted to give up the control they currently had over their systems. He was hoping that the right developers would get assigned. He knew that many of them had complained about the redundancy that existed across the various applications, but the scope and timeline of their projects prevented them from doing anything about it. This effort was beginning with the right scope, so as long they met timelines, there was a good chance to make it happen.

Over the next few weeks, Spencer’s team, including the developers from Adil and Tim’s organizations, worked hard to define the new Customer service that both applications would use. The developers were very familiar with the current data models used by each application, and worked together to define the data models and schemas for the new service. While these developers had some knowledge of how the existing applications manipulated the data, they worked solely with each other in defining the functional interface of the service. In the end, the service interface contained some elements of Customer data that was specific to one of the two applications, but they felt that information could be safely ignored by the other application.

The First Milestone

Soon afterwards, Spencer met with Jennifer, the project manager for the auto insurance application, to discuss their schedule. Spencer said, “Hi Jennifer. I wanted to discuss our delivery schedule with you so we can ensure that you can integrate the new Customer service as part of your effort. I know you’re making some additional changes to the application besides the migration to the service.”

Jennifer took a glance at her project plan and told Spencer, “We’re currently planning on going live on October 6th. Our performance tests are planned for September 2nd, and user testing will begin on July 28th.”

Spencer said, “Okay, we’ll plan on targeting those same dates for our service. Don’t hesitate to contact me if you need anything else.”

Jennifer didn’t. Just two weeks later she sent him an email that said, “Spencer, my developers want to know when they’ll have a service they can test against. They’ve told me that they can’t do anymore work until it’s available.”

Spencer replied, “I’ll have one of my developers provide you the URL for our development service right away.” He had his team provide it, and didn’t hear anything back from Jennifer’s team, so he assumed everything was working well. That lasted for about one week when Jennifer came storming into his cubicle.

“What did you do to the service? We were going to demonstrate where we were to one of our users today, and the application crashed when we tried retrieving data,” she said. It was clear that it had not been a good morning for her.

“We’ve been testing the integration with the home insurance data system, and have run into some issues, so our development environment has been up and down all day long as we try to determine what the problem is,” he replied.

“Well, you’d better get it fixed soon. I now have a key user who’s very nervous about the stability of this new service-based approach, and my developers are simply telling me that they can’t do anything about it. I’m going to report this as a serious issue in our Project Management Office (PMO) update on Thursday.”

“I’ll get right on it, Jennifer. I apologize for this and we’ll get it fixed as quickly as we can.”

Spencer immediately realized where his mistake was. By giving Jennifer’s team the URL for the service in his development environment, he was exposing her application to all of the instability that is normally associated with any development environment. From her perspective, however, she didn’t care about his development environment; she needed something that was stable so she could execute her tests and provide demonstrations.

He gathered his developers and told them that they needed to create a stable version of the service that would be separate from their own development efforts that the auto insurance application could use. He suggested that they determine which of their iterations represented a key milestone from the perspective of the auto insurance application. When those iterations were successfully completed, it would be promoted to the stable environment in use by the auto insurance application. They implemented this plan and things got better, at least from Jennifer’s perspective.

Unfortunately, Jennifer wasn’t the only project manager whose effort was dependent on Spencer’s team. Mark was the project manager for the home insurance application, the other consumer of this new service. Like his initial meeting with Jennifer, Spencer met with Mark to find out what his plans were for the home insurance application. Like Jennifer, there were additional changes that Mark was putting into

LEAVE A REPLY

Please enter your comment!
Please enter your name here