Gotcha! Building An Application “Backbone”

Did you know that:

Before you can get where you’re going, you have to know where you are

The first step to building a means of instantly sharing all information anywhere in your company, like Delta Air Lines’ Delta Nervous System, is knowing which applications and databases are already tied together. “Most people don’t even know what they’ve got,” says Kristin Weller, webMethods’ executive vice president in charge of product development.

Among the items a company must get a handle on: what connections already exist between applications; how applications connect to mainframes or servers; how applications communicate with databases; what programming interfaces exist to communicate with the applications; and what documentation explains any of this.

“You have to nail these things down quickly to build a plan,” Weller says.

You can’t start putting together an integration architecture until you have a handle on what you have and what you’re missing.

After you grasp that, you can start building a model for how things should link together in the future.

You’ll need to do some (data) remodeling

Most big companies will find that they they’ve stored data in a lot of different places, in lots of different formats on lots of different systems.

But, if applications are going to communicate with all that data, there has to be a common way of getting at it.

“Your definition of very basic concepts may be very different from one database to the next,” Weller says.

For example, Delta had several different types of customer records, all individually formatted, sitting in its reservation, ticketing and flight-information databases. “Delta might have had 35 different types of customer records across its applications,” says Charlie Feld, who, during his stint as Delta chief information officer, oversaw the development of the Delta Nervous System.

The way to get all the applications talking is by creating a single “data model.” The model describes how information is stored in a database and is then used to determine a common format in which the data can be sent from one system to the next. For instance, if a flight is canceled, the data model will spell out how the canceled flight’s passenger, gate and aircraft information is sent around Delta’s operations.

Without a backbone, your integration won’t stand up

Often, applications and databases tend to be connected by lots of adapters—software that directly connects two specific applications together. But that quickly creates an unmanageable tangle of software and traffic.

“We have 160 applications. Every application has to talk to every other application,” says Dan Gallaher, information technology director for Jefferson County, Colo. To get every application talking to every other application, Gallaher figured he’d have to set up almost 13,000 adapters. (In a set of 160 applications, each application would have to connect to the 159 other applications—for 25,440 individual connections and 12,720 pairs). “We looked at this and said, ‘Guys, this is going to be impossible. We’re going to spend the rest of our lives doing this and maintaining it.'”

Not only would it be difficult to code and maintain that much software successfully, but having that many applications talking directly to each other would create a great deal of excess network traffic, as the same information required by multiple applications is re-broadcast from the source. If every application were calling directly to every other application, it would create a huge traffic jam.

It’s much better to talk to many than to just one

One way to eliminate that problem is to avoid adapters altogether. The key is to strip out new data being entered into a system and broadcast it throughout a network. Any system that’s been programmed to receive a certain piece of data can then tune in to the broadcast and receive the information. Feld says, “Just hang it out there, and whatever has authorization can tune into that. It doesn’t jam up the bandwidth sending it out to a million people.”

The approach, called “publish and subscribe messaging,” works much like pay-per-view cable: applications that require information broadcast by a data source “subscribe” to that source; middleware then watches network traffic for messages from sources to which an application is subscribed, and alerts the application when a message is received. Delta uses messaging middleware from Tibco, for instance. Jefferson County, Colo., uses software built with BEA’s WebLogic application server and the Java Messaging Service.