Well,... not really. Even with only two applications, the task of exchanging data can be extremely complex and challenging. There are many hurdles in the path of integration. As I like to say, “the devil is in the details.” Let’s look at a few.
Staff: The first step is to find someone that understands both applications very well and also understands the business processes addressed by both applications. Let’s not forget that two different applications means two different sets of training sessions from two different vendors. Inevitably, some staff will need to learn both applications. That means learning two different ways of working and two different user interfaces.
Languages: There are hundreds of computer languages in the field. Different languages don’t always have bridges between them so a communication pipeline infrastructure such as web services need to be developed in each application to enable the exchange of information. This is just laying the groundwork for the integration to happen.
Data Models: Data is usually stored differently in different applications. Mapping the data from one application to another can be very complex. Take the simple case of addresses. Some systems have two lines of address, others have three. Going from two lines to three is easy, but not so when going from three lines to two. What do you do with the extra address line? What about if one application has address lines of 40 characters while the other application has 60 characters? What do you do with the extra 20 characters? Some applications store the company’s contact address with the contact while others store it with the company. Some applications store a two character state code while others store the full state name. Some applications don’t validate the state name so typos are common and this complicates the translation from one system to the other. If one system validates the street names based on city and zip+4, what do you do with errors?
All of these are very critical details that can very quickly corrupt massive amounts of data. And this is only looking at simple addresses. Remember that your applications probably have very complex data structures that will make this address issue seem trivial by comparison. There is no easy solution here.
Development Infrastructure: Any significant software development needs an infrastructure. Developers will need their tools. These include development environments, code version control software, editors, compilers, debuggers, automated testing tools, etc. You’ll also need numerous test workstations to test your applications under various configurations. You’ll need a software test team and someone to write your documentation. Yes, all of this costs money.
Upgrades: Each application typically has a new release every year or so. Each new release means upgrading the application in a test environment first. It may mean some changes to the interface applications and procedures, updating documentation, and retesting the entire integration process. In an environment involving many applications, staying ahead of all these various upgrades can be a full-time job for more than one person.
Error Handling: Most application interfaces can’t handle every case. For example, most of you with handheld devices such as Windows Mobile will know that very long notes attached to calendar or task items get truncated. If you edit these truncated notes, data will be lost. Similarly, when enterprise applications are integrated, similar data issues (as described above) usually get written to an integration error log file. Someone has to manually handle each of these conditions in a timely manner to prevent further data corruption. The reality is, this function often falls by the wayside and data corruptions multiply unnoticed, sometimes for years.
Staff Turnover: With staff turnover, finding someone else with the expertise to maintain the integration may be very challenging. Without a large enough staff, it is very common to see application interface maintenance deteriorate or die altogether.
Consultants: Third party consultants are often used to integrate applications. They usually have the development infrastructure in place and the expertise on staff to take on such projects. Realize that integration is not a one time task, it’s ongoing. Consultants are always more expensive than full time staff and the ongoing costs of consultants can be very high.
The bottom line: Integrating applications appear to be the right choice on the surface, but after digging into just a little more details... not so simple.