4. Use one architecture, multiple approaches. The District of Columbia chose to go with two integration platforms, one for tight integration and the other for more loosely coupled integration.
For tight integration between related systems, such as applications related to education or crime, the city uses Sun Microsystems Inc.'s SeeBeyond eGate Integrator and eInsight enterprise application integration (EAI) offerings. For looser integration, it employs the ESB to enable agencies to publish specific functions and data as Web services over the bus.
"We use the EAI when we want the systems to get married and take vows, and we use the ESB when we just want them to date," says Harvey.
Schulte notes that most large organizations will not have, or should not have, just one integration backbone. Practical considerations may well dictate maintaining existing integration schemes, even while deploying a primary architecture for other systems.
"While on paper it may sound good to have the same backbone across all departments and applications, not everyone will or should get there," says Schulte. "A business unit may have a packaged application that comes with its own integration technology. To try to strip that out and plug it into the company's ESB may not be practical."
5. Build incrementally. A common mistake, say experts, is to assume that you need a full suite of integration applications before beginning to integrate.
"A lot of people think that the way to do integration is pay a load of money to put in a complete infrastructure and start integrating. That's completely the wrong way around," says Steve Craggs, president of Saint Consulting Ltd. in Romsey, England, and vice chairman of the Integration Consortium.
Instead, he says, the first step should be to map out the key systems and business processes that need to be linked and then determine the technical options for doing so. Then build the infrastructure gradually.
"Put in the minimum amount of infrastructure you need -- maybe a communications backbone -- and incrementally build your integration architecture. It's much less risk and much more financially viable," says Craggs.
6. Test, Pilot, Deploy. Integration projects can touch dozens, maybe even hundreds, of applications -- and they can break most of them if not done right. So integration demands more than the usual attention to testing.
ClubCorp Inc., a Dallas-based chain of hotels, resorts and country clubs with dozens of IT systems, bought an enterprise job-scheduling tool only after lots of testing.
The company needed an ETL tool to handle the thousands of tasks flooding its Oracle database each day, says Tracy Baker, ClubCorp's manager of computer operations. "It was a free-for-all. Jobs would queue up and wait on each other," she says.
Four schedulers were installed in a simulated production environment and tested on everything from scalability and support for existing applications to the usability of their adapters.
"We monitored them for two to three weeks, looking at how administration would be, what the ease of use is, how they handled thousands of processes at once -- a whole checklist of things," explains Robert Ayala, manager of production support at ClubCorp.
The extensive review led ClubCorp to select AppWorx Corp.'s job scheduling application, which ClubCorp now uses daily to coordinates thousands of processes from 25 different applications.
For many integration projects, a pilot test is also a good idea. It not only provides the technical validation but also offers an opportunity to showcase the benefits.
In the District of Columbia's case, it was during a demonstration of the DCstat pilot that Harvey uncovered all of those untowed cars -- some 2,600 that were still on the streets. And what happened to the abandoned cars? Harvey says the city towed all of them the weekend after the DCstat demonstration.
Hildreth is a freelance writer in Waltham, Mass. She can be reached at Sue.Hildreth@comcast.net.