Railroad Gauges and Enterprise Application Integration

Communication within the independent software vendor community is critical to application integration.

InformationWeek Staff, Contributor

April 16, 2004

3 Min Read

Have you ever wondered why the distance between rails in the U.S. railway system is 4 feet, 8-1/2 inches? Casting aside urban legends about Roman chariots and horses’ behinds, the railroad industry settled on a common gauge as the result of economies of scale, practicality, and the engineering needs of the day.

Why, then, in our 21st Century sophistication is it so difficult for software from different vendors to communicate with each other? Independent software vendors (ISVs) still have the tendency to create software without regard to connecting to anything else. It was this type of thinking that created the whole EAI industry in the first place. When enterprise application integration first became important, it was a case of "who knew?" As in, who knew all these applications would one day have to play well with each other? Today, however, there is no excuse. ISVs need to keep in mind these key goals:

  • Build in Secure Web Services. No matter what type of software you’re creating, it should contain secure Web services for any back end function— authentication, privilege levels, encryption, logging, auditing, etc. Web services and service oriented architectures are becoming increasingly important in today’s enterprise. If you can’t connect to them, your software may not get a second look.

    Create True Interoperability. Interoperability is one of those words that crops up a lot in press releases, but its meaning seems to vary depending on who’s using it. True interoperability, however, is really an automatic function rather than a manual one. Two applications should be able to deal with each other natively, rather than after a great deal of gnashing of teeth. If someone has to create a connector manually every time your application needs to interface with another application, your application will quickly become bloatware — it probably won’t work well across the board, and users won’t be able to get the support they need. Make it simple by building in automatic interoperability. Look Beyond the Walls. Interoperability isn’t limited to internal systems. Financial institutions and manufacturers, for example, both need their applications to interface not only internally with each other, but also with suppliers and dealers. Making sure information such as purchase orders can move from one system to another — no matter what that “other” is –— is key to taking advantage of technology. Every time something needs to be re-keyed, it creates an opportunity for error. Keeping data exchange automatic without either side having to change their systems is a huge advantage for all. Allow for Multiple Sources. Most communications applications draw information from a variety of different sources, including LDAP, databases, e-mail, CRM, and HR systems such as SAP and PeopleSoft. Each of these has a protocol, so the more technology-agnostic you can make your application, the better able it will be to serve as a central point to all of them. This is particularly true when information will be integrated into a portal or may be sent to someone else’s portal for aggregation. Becoming the conduit between all of these different applications makes your software that much more valuable.

Whether you are building software for designing wheel bearings or customer relationship management, remembering that we’re part of a community that needs to communicate with one another isn’t such a bad thing. In fact, you’re likely to reap many rewards for doing as much.

JT Smith is the director of technology for WDI, the makers of the Business Integration Engine and other Open Source enterprise application tools. He can be reached at [email protected].

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights