The most basic definition of systems integration is “making yourstuff work with my stuff.” We live in a world where increasingly noone company solves the whole problem. Any number of companiesprovide the pieces, and those pieces must be joined together. Whenfaced with systems integration projects, insurance professionalsmust be ready to do the job.

Trains and Integration

Examining the history of trains is a good way to illustrate theissues associated with integration. By the early 1840s, there wereseveral independent train companies. Each served its owngeographical region, and any uniformity was coincidental. Inparticular, not all trains could operate on all tracks.

Trains were different across regions, which caused no harm—aslong as everyone stayed in their own territory. Hauling freight ahundred 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 goonly as far as the local railroad's territory. To proceed, thelocal company had to unload freight from its cars and then reloadedit onto the next territory's cars, until it made its way across thecountry.

Later in the century, the federal government dictated thatrailroads must work together. The government published standardsfor trains, expecting adherence and including a standard tracksize.

The government achieved interoperability between railroadcarriers, which allowed new opportunities for commerce. Mail-orderdelivery from catalogs became feasible. Towns along railroad trackscould import and export goods, eliminating the need to beself-sufficient. And tourism cropped up from coast to coast.

But this progress came at a price. Unless a town was luckyenough to have tracks of the standard size, entire set of trackshad to be torn up and put back together. Engines and freight carshad to be modified to run on the new tracks, and traditionaltraffic within a territory was no better off than before. As aresult, the advantages of interstate commerce had to compensate forall the transition costs.

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

Challenges of Computer Systems Integration

The challenges associated with computer systems integration aresimilar to those associated with trains. Each system isindependently built. To integrate the systems, there are twofundamental choices.

At the boundary of a system, users can convert their data formatinto the format of another user. Coming back, they must convert inthe other direction—the equivalent of loading and unloading freightcars.

Or users can agree on a standard data format. This implies thatone user will have to modify a working system to interoperate withthe other system. Modifying a working system does not add anyfunctionality, and it incurs time, expense, and risk. But itenables users to interoperate.

Computer systems integration is obviously much more complicatedthan 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 oneuser represents the days of the week as text and another usesnumbers, one of them must change. Data conversion is a keyintegration challenge.

Networking is another challenge. Data can be transferred betweentwo machines by an alphabet soup of protocols that include filetransfer and Internet protocols such as HTTP, secure HTTP, messagequeues, SOAP, and REST. If users communicate in different ways, oneof them has to change.

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

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

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

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

Operating systems and databases are two final integrationchallenges. If users work on different types of databases or if oneuser is on UNIX and another on Windows, they will have troubleintegrating.

Practical BusinessSolutions

As a practical matter, most integration occurs between theinsurer's system and the vendor's. Vendors sell features andbenefits. Vendors don't like to talk about integration, becauseintegration involves cost and risk. But success depends uponintegration just as much as selecting the right features. The trickis to identify the risks up front and be prepared to deal withthem.

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

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

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

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

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

Let's assume, for example, that a user is interfacing with avendor by transferring a file. The simplest and best scenario isone 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 eachstate) in a format different from the vendor. The odds of a cleanintegration will decrease significantly.

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

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

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

There are larger vendors who regularly acquire companies andproducts. In most cases, these vendors need to integrate the newlyacquired company's products with their existing products. Vendorsoften try to sell the new products before the integration iscomplete.

It's easy to make a product family appear as if it's integratedon a marketing slide. But the integration might really be a work inprogress. The vendor's legacy product might run only on an olderversion of UNIX, while the newly acquired product might operateusing only a newer version of UNIX. As a result, a user ends upbuying two servers.

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

People Issues

Successfully integrating computer systems requires differentgroups of people working together. At a minimum, integration willinvolve the business organization, the IT organization, and avendor. IT may consist of two groups, development and operations.The security and compliance organizations may also participate. Ifthe integration is to succeed, it's particularly important that allparties are involved and engaged—the earlier in the process, thebetter.

A common integration mistake is for a subset of the relevantorganizations to sign a contract with a vendor and then informother stakeholders. If the excluded stakeholders then say theintegration is impossible, there may be in trouble before theprocess even begins. Another common mistake is to underestimate thecost 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 staffcare about the operating system. All of those aspects matter.

In Summary

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

Users need to pay particular attention to vendor issues such asthe number and complexity of the integration points. The maturityand dependability of the vendor offering must also be carefullyexamined. If part of a vendor's solution is sourced from a companythe 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 andmake the best decisions to ensure a smooth and successfulintegration.