Over the past few years, I have been struck with the level of integration in the business application environment. Oh sure, it was not a total surprise. About 15 years ago I was responsible for the support of two of our company’s large databases that contained customer master information and detailed sales data. It seemed that every other application in the shop used one or both of these databases.

In a more recent job, the application environment was made up almost entirely of packages. We had package solutions for financials, revenue, customer relationship management, time reporting, etc. This was when the level of integration really hit me. On the surface, you might think that a company that utilized packaged solutions for most of its applications would not need much of an applications support staff. In fact, the staffing level was lower than it would have been if these applications were developed and supported internally. However, there was one area where we still needed to write custom code: application integration.

The challenge of integration
Application integration is a challenge faced by most organizations. It’s actually a good challenge, given the alternative. In fact, you want your applications talking to each other. In my recent job, we had close to 15 major and minor applications to support the business. I don’t believe that any of them were standalone. All of them either needed information from another application or sent information to another application.

This experience is not unique. Integration comes into play when you’re developing applications and when you’re supporting them. In the development world, you might be surprised if you calculate the amount of time and effort that is associated with integration. Depending on the application, you could spend a substantial amount of the project dealing with integrating your application with the others in the shop. Integration is not just a construct and test issue. You need to deal with integration in your analysis and design as well.

Application integration is also one of the major areas that provide job security for support staff. A substantial amount of the time spent resolving problems ends up in understanding how data gets passed from one application to another. One of the frustrating aspects of support is finding that two applications are working perfectly well by themselves, but that there is a problem in the formatting or the interpretation of data between them.

Enter XML
XML helps to ease the pain of application integration. Its benefits are broader than that, but a substantial value lies in the integration challenge. XML helps resolve two of the problems associated with application integration: data formatting and interpretation.

Data formatting with XML
Part of the complexity associated with integration has to do with mapping data from one application to another. You may have one application that stores data in fancy, modern databases. A second, older application may only accept input in 80 column flat files. The challenge is in trying to understand exactly how the second application wants to see the input data. Substantial programming can be required to get the data in exactly the right format.

If both applications can work with XML, a large portion of this mapping problem goes away. The second application may still need the strictly formatted 80 column records. However, that application instead gets changed to accept XML transactions, which it then formats into the appropriate input records itself. Once this change is made one time by the second application, all interfacing applications can pass data using standard XML. The intricacies of understanding exactly what data goes in which columns is no longer an issue. Instead, applications pass data in standard XML files for the receiving application to interpret and reformat as needed.

Data interpretation with XML
Using XML also helps get away from the problem of interpreting the data. Interpretation problems occur when one application refers to a customer number as “custno” and one calls the same information “cst#”. In one application, the field is numeric and nine digits long. In the other, the field is alpha and eight characters long. When you use XML, the underlying data characteristics of the sending and receiving applications are no longer relevant. The only thing that matters is the XML interface rules. Each application only needs to understand the XML rules and have the ability to send and receive data based on those rules.

Simplifying the integration
These two benefits simplify application integration tremendously. Consider a company with just five business applications, all of which need to talk to each other. Some of the integration involves passing files back and forth. Without XML, each application needs to create custom interface files. There could potentially be 25 instances of files (or more), each one being formatted in a manner that the other application can interpret.

Theoretically, with XML, you can create a common definition that would cover your entire organization. Each application would be programmed to read and write to this common XML specification. The result is that each interface file follows a common format and can be interpreted consistently. Of course, each application still needs to be able to correctly read and write the XML files. However, once they can do that, the complexity of the integration is significantly simplified.

Of course, another benefit of XML is that it is not applied on only a company-by-company basis. It is being adopted by the entire IT industry. This means that packaged solutions you purchase, and databases you utilize, will all be able to read and write XML themselves. This simplifies your task even more. Of course, even if every application can handle XML, you need to ensure that they are all using a common data definition. Common XML definitions are even defined on an industry level, but if your data is cross-industry, you still need to make sure that all of the data is being interpreted consistently.

XML can ease the pain of integrating your applications, but using XML isn’t magic. There are still some items to resolve. The remaining work involves ensuring that each application can read and write XML using a common definition. However, the beauty is that once you have agreement on these rules, the technical interface itself can be much less complex.

Application integration causes many of the problems that IT organizations face today. XML goes a long way to reducing this pain in both the development and support environments.

More XML?

Did you find this information about integrating your applications with XML helpful? Would you like to see more Builder.com management articles on XML? Send us an e-mail or post a comment on the discussion board.