Case Study: XYZ Corp.

Please read the following case study, which is based on a fictitious, yet common, scenario and answer the practice questions that follow.

Background

XYZ Corp. is a small company that manages the vehicle recovery, repair, and salvage process for larger insurance companies. For a fee, it takes the burden off larger companies when it comes to getting rid of vehicles that are "totaled" (for example, selling them for scrap, getting the title transferred) or getting repairable vehicles back on the road.

XYZ has satellite offices all across the United States. Because it does not have an exclusive agreement with any one insurance company, it interfaces with all the big names in the industry. (No need to name dropthey know who they are.)

XYZ has been doing business for years by sending all documents through the postal service (or expedited delivery services) and sometimes uses e-mail for less official correspondence.

XYZ also offers its service directly to consumers, providing low-cost, high-quality handling of damaged vehicles. XYZ takes pride in being able to get multiple bids for repair jobs as small as a pit in the windshield or as large as a total reconstruction.

Problem Statement

XYZ Corp. has several issues it wants to address:

• Interactions with large insurance partners take time when done through the postal service. Because time is money, XYZ upper management would like to consider whether using secure XML Web Services would speed up claims processing.

• XYZ would like to offer a service that enables direct customers and those covered by insurance companies to log in to the Web site and check the repair status of their vehicles or, if vehicles cannot be repaired, find out how soon they will be labeled as "totaled."

• Because of an unexpected marketing push by the chief competitor, combined with some delay in getting the project scoped, XYZ's upper management wants the new solution running eight weeks from today.

Current System

XYZ Corp. currently has a mainframe system housing the data, stored in DB/2 tables, and pieces of the business logic. Accessing the mainframe is an n-tier COM application, written in Visual Basic 6.0, that is deployed to each user's desktop in the company. Because there are more than 100 offices nationwide, new releases are deployed using Microsoft System Management Server (SMS). Even with the assistance of SMS, deploying new releases used to be a frustrating activity; however, there haven't been any significant releases in six months.

Both the mainframe code and the COM application's business layer contain complicated business rules as well as a complete business object model. Conversely, the user interface is fairly thin and uncomplicated.

XYZ Corp. has clients (insurance companies), customers (individuals or small non-insurance companies), vendors (body shops, junkyards, glass shops, and gas stations) and vehicles (the items being tracked). XYZ asks insurance companies to supply details about vehicle owners so that they can be set up to view the vehicles' status on the XYZ Web site. In rare instances, vehicles are owned only by another company, not a person. Each vehicle is given a unique ID when assigned to XYZ. Although XYZ eventually owns some vehicles (if their titles are transferred), the original owners are retained in the data stores indefinitely. Through the use of a workflow engine, each vehicle being repaired or inspected is assigned to one of XYZ's 18,000 vendors throughout the United States. In this way, each vehicle has a disposition status that lets everyone know where it is and who it is with. In the current system, the vehicle status (for example, queued, in progress, completed) is not tracked at the vendor level.

Department Manager

"We have a substantial amount of time and knowledge embedded in our current system's COBOL code and business tier. I see no reason to replace these pieces. Any new solution will need to interact with the old, protecting our investment, legacy or not."

Technical Team Leader

"We have been asked to leave the old stuff in place and build on top of that foundation. This requirement limits us in some ways, but it will save us almost a year's time in figuring out everything that's in there. Some of that code was written by our IT manager, back when he was a programmer. That was a long time ago!"

Envisioned System

XYZ Corp. wants a new Web site for tracking vehicle status and an XML Web Services interface for doing business with its large insurance company clients. It also wants to safeguard its investment in the existing COM application.

Department Manager

"Six of our top 10 insurance customers have agreed to swap data with us through Web Services, as long as we get it right. To be honest, this is way bigger than the payback we expect from our direct-to-consumer campaign. The Web site that focuses on selling our service to individuals and showing them the status of their vehicles is probably only 8 or 10 screens. We're just making the information we already have in-house with our desktop application available to the public."

Technical Team Leader

"With only eight weeks, we intend to be strict about what goes into this first release. Getting it up and going is our main focus. We can then plan follow-up releases every quarter that address the areas we are deficient in."

Chief Architect

"We talked and decided that the best way to meet the aggressive deadline is to create a layer, or adaptor, between the old code and the new."

Steve, IT Manager of Really Big Insurance Company

"If XYZ pulls this off, we have agreed to conduct 80% of our business through secured Web Services (and by golly, they better be secure). I know XYZ is planning to save money, but so will we. A lot."