The most basic definition of systems integration is “making your stuff work with my stuff.” We live in a world where increasingly no one company solves the whole problem. Any number of companies provide the pieces, and those pieces must be joined together. When faced with systems integration projects, insurance professionals must be ready to do the job.

Trains and Integration

Examining the history of trains is a good way to illustrate the issues associated with integration. By the early 1840s, there were several independent train companies. Each served its own geographical region, and any uniformity was coincidental. In particular, not all trains could operate on all tracks.

Trains were different across regions, which caused no harm—as long as everyone stayed in their own territory. Hauling freight a hundred miles between two cities on the same rail line worked fine. But when freight was moved from one geographic region to another, such as from the East Coast to the West Coast, a train could go only as far as the local railroad's territory. To proceed, the local company had to unload freight from its cars and then reloaded it onto the next territory's cars, until it made its way across the country.

Later in the century, the federal government dictated that railroads must work together. The government published standards for trains, expecting adherence and including a standard track size.

The government achieved interoperability between railroad carriers, which allowed new opportunities for commerce. Mail-order delivery from catalogs became feasible. Towns along railroad tracks could import and export goods, eliminating the need to be self-sufficient. And tourism cropped up from coast to coast.

But this progress came at a price. Unless a town was lucky enough to have tracks of the standard size, entire set of tracks had to be torn up and put back together. Engines and freight cars had to be modified to run on the new tracks, and traditional traffic within a territory was no better off than before. As a result, the advantages of interstate commerce had to compensate for all the transition costs.

In addition, many business and logistical issues arose. Towns were forced to ask each other: If my trains are running on your tracks, how much do you charge me? What happens if my train breaks down on your tracks? Do I need to carry enough coal for the entire cross-country trip, or will you sell me coal along the way? How much will you charge me for the coal?

Challenges of Computer Systems Integration

The challenges associated with computer systems integration are similar to those associated with trains. Each system is independently built. To integrate the systems, there are two fundamental choices.

At the boundary of a system, users can convert their data format into the format of another user. Coming back, they must convert in the other direction—the equivalent of loading and unloading freight cars.

Or users can agree on a standard data format. This implies that one user will have to modify a working system to interoperate with the other system. Modifying a working system does not add any functionality, and it incurs time, expense, and risk. But it enables users to interoperate.

Computer systems integration is obviously much more complicated than integrating trains due to factors such as data, networking, security, performance, legal compliance, graphical user interface (GUI), and varying operating systems and databases.

Data format is the most significant way systems can vary. If one user represents the days of the week as text and another uses numbers, one of them must change. Data conversion is a key integration challenge.

Networking is another challenge. Data can be transferred between two machines by an alphabet soup of protocols that include file transfer and Internet protocols such as HTTP, secure HTTP, message queues, SOAP, and REST. If users communicate in different ways, one of them has to change.

Security is another area where users must be compatible. If two people share a house and one always leaves the door unlocked, there's a potential for theft. The same is true for computer systems. They are only as safe as their weakest link. And one user must adapt its behavior.

Performance is usually measured in terms of speed or response time. If two people decide to go jogging, but one likes to run and the other likes to stroll, it won't be a satisfying experience for either person. They need to be reasonably compatible. If one user is expecting one-second response time for a transaction and another user “adds value” but takes ten seconds, the first user won't be happy.

Compliance is another area where there is an “alphabet soup” of standards, such as HIPAA, GLB, and DPPA. Modern-day systems integration dictates that if one user is HIPAA compliant, the other user must be as well.

The look and feel expressed in a graphical user interface is also important. A user who spends time on a system maintained by two different people needs to have a seamless experience. If the user can tell two different systems are patched together, than the integration was not successful.

Operating systems and databases are two final integration challenges. If users work on different types of databases or if one user is on UNIX and another on Windows, they will have trouble integrating.

Practical Business Solutions

As a practical matter, most integration occurs between the insurer's system and the vendor's. Vendors sell features and benefits. Vendors don't like to talk about integration, because integration involves cost and risk. But success depends upon integration just as much as selecting the right features. The trick is to identify the risks up front and be prepared to deal with them.

The first challenge is the number and complexity of the integration points.

Examples of a system with one integration point include when one file is transferred that covers the United States, when one web session is opened, or when one queue is established.

Examples of a system with many integration points include when 50 files are open for the United States (one for each state) or when two Web sessions are open, one queue is established, and ten files are transferred.

As a design principle, the fewer the number of integration points, the better. One integration point is best. When considering vendors to integrate with your system, ask the vendor: How does my system talk to your system? Get exact details.

Even if the number of integration points is small, users can still get into trouble if one or more of the integration points are complex. The design principle is this: the simpler, the better.

Let's assume, for example, that a user is interfacing with a vendor by transferring a file. The simplest and best scenario is one file that is the same format for both the user and the vendor. In that case, the integration is likely to be problem-free.

More complex is a user transferring 50 files (one for each state) in a format different from the vendor. The odds of a clean integration will decrease significantly.

The worst case is a user with two files for each of the 50 states and a vendor with three files for the each of the 50 states. Because all the formats are different, the potential exists for an integration headache.

Users should question vendors about the number of files and the compatibility of file formats.

Users should also seek out vendors with a single product that solves the specific problem. But in many cases, the needed functionality requires more than one product offered by the vendor. Thus, a vendor's products must integrate with one another as well as with a user's system. Vendors want to treat this as an expense issue, but it's also an integration issue. More vendor products usually imply more servers and more complexity. When choosing a vendor, simpler is better. Ask the vendor if the solution consists of one product or a combination of many products.

There are larger vendors who regularly acquire companies and products. In most cases, these vendors need to integrate the newly acquired company's products with their existing products. Vendors often try to sell the new products before the integration is complete.

It's easy to make a product family appear as if it's integrated on a marketing slide. But the integration might really be a work in progress. The vendor's legacy product might run only on an older version of UNIX, while the newly acquired product might operate using only a newer version of UNIX. As a result, a user ends up buying two servers.

Be aware if one of the vendor's components was purchased from another company within the last year. Even at two or three years, there is still some risk. After three to five years, it's relatively safe to purchase. Ask the vendor if any of the product components are newly acquired and how long they've been part of the system.

People Issues

Successfully integrating computer systems requires different groups of people working together. At a minimum, integration will involve the business organization, the IT organization, and a vendor. IT may consist of two groups, development and operations. The security and compliance organizations may also participate. If the integration is to succeed, it's particularly important that all parties are involved and engaged—the earlier in the process, the better.

A common integration mistake is for a subset of the relevant organizations to sign a contract with a vendor and then inform other stakeholders. If the excluded stakeholders then say the integration is impossible, there may be in trouble before the process even begins. Another common mistake is to underestimate the cost of testing the newly integrated system for functionality, security, and performance. Users tend to comment on look and feel. The database group cares about the amount of data. Operations staff care about the operating system. All of those aspects matter.

In Summary

There are many factors associated with modern-day systems integration, and a single mistake can lead to failure. Users need to meet head-on the challenges of data formatting, networking, security, performance compliance, operating systems, databases, and graphical user interfaces. It's sometimes a daunting task, and there's a tendency to avoid the concerns, trust our vendors, and hope it will all work in the end. But that's how most integration projects fail.

Users need to pay particular attention to vendor issues such as the number and complexity of the integration points. The maturity and dependability of the vendor offering must also be carefully examined. If part of a vendor's solution is sourced from a company the vendor acquired recently, be wary.

Finally, include all stakeholders from the outset. Collectively, they're the ones that can help sort through all the factors and make the best decisions to ensure a smooth and successful integration.