A football coach is in the locker room at halftime. He’s delivering his best pep talk in an effort to inspire his team to work together and play unselfishly in the second half. The coach’s motivational speech includes his favorite phrase—one that he’s repeated all season—“There’s no ‘i’ in team.”

It’s a sports cliche that could also apply to many of the challenges facing businesses today—especially application integration. If you want to get a bunch of systems working together, you need to get your people working together. That’s advice from Roy Schulte, analyst at GartnerGroup. He offers the following recommendations for successful integration of new, purchased, and legacy applications.

Choose a team
In some IT departments, groups that control the development of each of the application systems perform the integration. “That doesn’t work;” said Schulte, “you have to do it on an enterprise-wide basis, not a piecemeal basis. It may sound like common sense, but in fact, only a small number of companies are actually doing it this way.”

Your first task should be to establish one integration team. You will likely need to change the way your IS organization chart is drawn. You must recognize that integration is enterprise-wide in its scope and create a full-time, enterprise-wide integration team to develop, deploy, and maintain the integration infrastructure.

It’s a strategy that some IT managers and CIOs have already embraced, including John Abdullah, president of Information Technology Engineering, Inc. in Oakton, VA. “An enterprise-wide team is critical. You can get a system that is technically very well put together, but the people aren’t going to use it because it doesn’t fit with how they do business,” said Abdullah.

Respect boundaries and interfaces
Respect the internals of the system. If you try to manage what’s inside an application, the job is overwhelming.

“When you’re trying to tie systems together, just look at what kinds of interfaces are being exposed to the outside world and manage those…You can’t change the internals of systems; you have to just take that for granted. Again, this is counter to common practice.”

In many cases, integration must be done non-invasively, because a department or an enterprise cannot modify its programs or databases to conform to standards.

Conformity is not the answer
A common misconception is that if everyone uses the same technology, it will be easy to connect them. The solution isn’t that simple.

“It doesn’t matter which software product you use. In some cases, you can have a very badly integrated set of applications even though you are using the same technology. In other cases, you can have great integration, even though you bought all the products from different vendors, and there’s no technology consistency,” said Schulte.

Think of the situation as two separate issues. The problems are not likely at the technology level. Instead, the trouble is with the design and how you have used those tools.

Managing strategies
ERP deployment may complement an effective integration strategy, but it’s not a substitute for organized, heterogeneous application integration. In other words, the same advice given earlier applies here too: one-stop shopping won’t solve all of your problems.

“A lot of people try to solve their application integration problems by buying all of their applications from one vendor, such as SAP or Baan or Oracle. But it turns out that doesn’t work. Essentially what they’re trying to do is turn a planning problem into an architecture problem,” said Schulte.

Mark Peacock of Deloitte Consulting described an example where this distinction was critical. He spoke of a client who has already added an ERP system and has “already sweated out the tough stuff by putting in a global SAP backbone. When we go to plug in, we’re able to spend our time worrying about the customer experience, rather than the back office plumbing,” said Peacock. “By combining to a single global backbone on SAP, they’ve now captured 25 percent of the benefit. And what’s going to capture the rest of the benefit is the ability for CRM packages, e-commerce packages, and supply chain packages to be able to quickly plug into that global backbone,” he added.

Middleware strategies
Enterprises must have two separate middleware strategies: one for inter-application purposes and one for intra-application purposes.

“The middleware that you use inside of an application system is different from the middleware that you use between application systems. Again, it sounds like common sense, but it is counter to the normal practices of systems development,” said Schulte.

Over the last five years, improved types of middleware and software have become available on the market. The newer products allow systems to essentially “talk to each other.” In addition, they enable e-commerce and Web site design.

Schulte views Zero Latency Enterprise (ZLE) and Straight Through Processing (STP) as solid business strategies. But he warned, “The fact is, there are business strategies and there are IT strategies. [These concepts] basically say, ‘We’re going to change the way your business runs. We can change the way you sell products. We can change the way you service products. We can let your customers do self-service.’ IT can do it, but you have to have that change done by business people, not IT people, because the business people are the ones who say, ‘Do we want to do this in the first place? When is it going to help the company for us to change our processes?’”

Senior management’s role
If you manage an affected business unit, you must understand and champion any proposal for ZLE or STP projects.

At Information Technology Engineering, coordinating a unified strategy among all business units has been critical to the success of the integration effort.

“Even more so than some of the technical issues,” said Abdullah. “[Senior management members] have different needs and requirements and they need to work together,” he added.

Cathleen M. McCarty is founder and president of Demand Strategies Inc., a business and marketing consulting firm.

What are the most common headaches when you approach integration? What advice would you give an IT manager who faces this project? Post a comment below or send us e-mail with a story idea.