My point is not to whine about a silly mortgage broker. This article is about integrating complex systems, and systems begin with the first interaction with the customer and end with the last interaction. (I was going to say something smarmy about how those beginning and ending events are more clearly defined for life and health people than for our property folks, but I will resist.)

Let me take my mortgage example one step further. As I said before, I am lazy, so I never notified my insurance company about my new acquisition. I did have the foresight to list correctly the carrier on my application, however. I made an attempt to notify the carrier, but when I went to log on to my online account service, I discovered my old user name and password were no longer adequate to log me on. I now needed a PIN, and to get my PIN, I had to call a CSR. Phone menus scare me like the plague, so my attempt to change my policy stopped right there. Fortunately, my carrier realized something was amiss when the lender contacted it for proof of insurance. So, on the day of closing, I received a call from my insurance company, and we were able to change all my policies in minutes. That was a positive experience. I did not have to suffer through a phone menu or a synthesized version of the Third Brandenburg Concerto, I did not need to fill out a form manually, and I did not need to get a PIN (I still don't have one). But I got my insurance with relatively little pain.

HTTP://WWW.MAINFRAME.COM

Complex systems all begin with gathering data about our customers. We live in a world where people are less willing to spend time talking about insurance–whether in person or remotely–and even less willing to spend time filling out forms. At the same time, the Internet has become the ubiquitous framework for communication in the Western world.

I can remember a keynote speaker at the ACORD technology conference in the late '90s saying the insurance industry had to wake up and get on the World Wide Web if it was going to be relevant in a "wired" world. The problem was the insurance industry was stuck in the mainframe world, and wiring an AS400 to the Internet was no easy task. (I know technically an AS400 is not a mainframe. I am just using the common parlance I run into today. To a 30-something software engineer, anything that isn't PC based–or that has been around for more than 15 years–is a mainframe).

Jump forward some eight years later, and we now have carriers that quote and sell insurance products online. Those products currently sold online may represent a particular, limited slice of the insurance market, but that slice is growing and will become less limited. The simple fact is the insurance firms–from the agency to the carrier–all have a need for online transactional systems if they are going to stay competitive. The decision is not if we are going online; it is when and how.

The Lady or the Tiger?

Our industry still is overwhelmingly dependent on mainframe computers, and when we start to build Internet-facing transactional applications, we are faced with two routes:

1. Create applications and services that interact with the mainframe and expose functionality to the Internet.

2. Start from ground zero with a front-to-back system based on SOA architectures such as J2EE or .NET.

I Am Not Amish!

All business tends to live by the worn-out adage about not fixing things that aren't broken, perhaps in the insurance industry more than others; that is the perception on the street. And there is nothing wrong with practicing that conviction . . . if you live in a static world. Just maybe, though, it is time to think about getting off the mainframe. If a 30-year-old system adequately can handle the logic and reporting, a cutting-edge system based on the latest technologies and methodologies should be able to do even better. The DC3 was a perfectly good passenger and cargo plane in the 1940s and still is in widespread use today, but most successful air carriers have moved on to more sophisticated equipment.

The decision to stay on the legacy system is based on whether it is more cost efficient to build systems that integrate with existing technologies today or to invest in all new technologies. There are trade-offs for either decision. You probably will be able to get an online self-service application in production faster and with less current expense if you choose the first route. Building a new Internet system is going to take longer and require more expense upfront. But you just might have a system that will chug along happily for 30 years before the next new wave of technology provides a compelling reason to upgrade again. Notice I did not say obsolete–a system that is delivering the goods is not obsolete. Obsolete is a value word. I have seen organizations that had to hire people to haul away their midrange systems while other organizations build shrines to them.

I can't even begin to say which is the better decision. Perhaps you can justify doing the mainframe add-ons with the expectation you will grow your revenue so much over the next few years you then will have money to burn and then will do a full system upgrade. Or maybe you can't afford to do a clean sweep technologically. Whatever your decision, just know you are only postponing the inevitable. One day there won't be any radial engines around to power that DC3.

This Is Complex

Once you have made the decision to build new applications around your legacy systems, you begin to understand what complexity means. You have a rating system and an application-submission system built on a flat legacy database and RPG. The preferred method of accessing that system is green screens. There are a limited number of ways to interact with the system. If we are talking RPG IV, IBM's Websphere Development Studio provides hooks into the system. Other technologies have similar hooks. You can query and interact with the database using ODBC or Web services. You can use screen-scraper technologies to interact directly with the application. You can wrap all of your applications under the umbrella of service-oriented architecture, but you still are cobbling the latest technologies to old. COBOL may have been ported to .NET and Java (via Enterprise JavaBeans), but it still is COBOL. It was old school when I learned it, and that was a long time ago.

Duh!

The trick to designing systems that allow your legacy systems to continue to function in the world of Web services and SOA is to design carefully each component so it is not dependent upon old technology. That ensures the killer self-service application you build today is not dependent on your mainframe. That means architecting interaction layers that make the data source transparent.

For example, if you need to read and write directly to the database, don't ask your application to do so. Create middleware components that stand between your new applications and applications that are not built on SOA. The middleware will act as a broker, so when the time comes to retire the legacy system and database, it can be done without major modifications to the SOA-based application. Design your messaging between the middleware and your application so the middleware is all that needs to be modified when a new database is implemented.

In fact, everything we build should be designed as a plug-and-play component. And this is something that is much easier to talk about than accomplish. SOA has been lurking around forever, and we still can't adequately define it. Last week a headline in one of the newsletters I subscribe to read: "OASIS Forms Six Committees to Simplify SOA." There's an oxymoron. The computer press is having a field day with SOA: "Is SOA Working?" . . . "SOA vs. Web Services" . . . "SOA–Is It Ready for Prime Time?" Let's lose the jargon. Build software components that can use standard messages and messaging formats to communicate, and you are doing SOA. Leave the rest to the pundits.

No Easy Solution

The secret to integrating complex applications is no secret at all. It simply is a matter of designing and architecting systems properly. You first need to map functionality to individual components. You then need to discern the best way for those components to interact with each other with the caveat you never want to duplicate effort. You then design messaging between those components based upon the standards of the framework you are working in. Every interaction–whether it be a query string or a 10 kb XML string–should be defined before writing a single line of code. Once you have built your blueprint, building the system should be straightforward with realistic deliverable schedules. Do your planning, and the rest is easy. Do you believe that? I didn't think so, but the reality is proper design is a necessary part of a successful implementation. Do your homework, and the rest will follow.