What's the measure of a successful integration project? For Jamey Harvey, the deputy chief technology officer for the District of Columbia, it was the ability to get a map of all the abandoned cars that needed to be towed in the city.
"A burnt-out car isn't just an eyesore; it's a place where people deal drugs and get murdered," says Harvey.
Until recently, those cars might have stayed on the streets for months. That's because the city's data on abandoned vehicles wasn't all located in the same database, so some of it never showed up on towing lists.
"D.C. has a very feudal system of government, and the 66 agencies that report to the mayor all had their own IT stovepipes, which were not designed to have any kind of interaction between them," says Harvey.
The city's IT department realized it could overcome some of that lack of integration by using Web services. With Sonic Software Corp.'s enterprise service bus product, the IT department created an application called DCstat that merges information from data silos around the city.
Begun as a pilot project in 2004, DCstat enables city employees to see everything from housing-code inspections to crime incidents around the city. It uses information from more than 150 data sources, including the police department, the mayor's call center, the department of transportation and the water and sewer authority. The city also has a much more coherent integration strategy and architecture.
"We now have a well-defined stack and a well-defined product set for each kind of business integration challenge," says Harvey.
For the District of Columbia and other large organizations that have spent years on ad hoc efforts to integrate piles of legacy systems, there's a critical need for a consistent and standardized approach to integration. Multiple middleware products and hand-coded connections drain IT resources with a constant need for maintenance, troubleshooting and configuration updates. Disparate middleware technologies also tend to aggravate the integration problems they were intended to solve, because they create departmental silos of applications that are integrated with one another but not with the rest of the company.
Achieving a more consistent -- and manageable -- integration architecture is a challenge, particularly for organizations with independent business units and multiple IT shops. It requires constant interdepartmental collaboration and attention to business processes, as well as a thorough inventory of technical requirements.
To help draw a middleware road map, CIOs and integration experts suggest the following six strategies.
|
1. Inventory user requirements. To determine the technical requirements for integration tools, take an inventory of proc¿esses and problems.
At The Nemours Foundation, one of the nation's largest children's health systems, the IT staff regularly holds joint application development, or JAD, sessions, where application developers and data warehouse staffers meet with end users to discuss business needs and how IT can address them.
Nemours, which owns and operates the Alfred I. duPont Hospital for Children in Wilmington, Del., and children's clinics in Delaware, Florida, Pennsylvania and New Jersey, based its decision to migrate to a new extract, transform and load (ETL) tool on information gathered in those JAD sessions.
"The input we received was a huge component in determining what tool set we needed and what we didn't need," says Edward Todd, data warehouse manager at Nemours, which ultimately selected Business Objects SA's Data Integrator product. The requirements included metadata management and the ability to handle a large volume of data; support for a range of data formats, including the hospital industry's HL7; and data cleansing capabilities.