I've always thought of integration as a tactical issue. True, it's important and certainly critical to supporting strategic initiatives. But I just couldn't shake the idea that integration was akin to making the trains run on time -- people would certainly notice if there wasn't integration, but in an ideal world, integration was what happened behind the scenes, and smoothly, so that business could function as it should.

It's important to note that I do think IT can be a strategic differentiator. I just tend to think of integration as one of the tactical tools for making that happen.

I'm not sure how universal this view is. But this week, a few pieces have forced me to question my thinking that integration is the domain of IT. In fact, both of these items show that integration increasingly requires collaboration with the business.

The first item was a blog post by John Schmidt of Informatica. His thesis is that integration should be viewed a distinct discipline, not just a management practice and, as such, should be a strategy:

"Organizations that view integration as a 'strategy' and that focus their people, policies and investments around the strategy will have a clear competitive advantage. They will create an agile business where each link in the chain can change and adapt to meet local needs while the end-to-end chain remains strongly aligned with the overall operating model."

I have to say, I had a hard time buying that. I mean, trains running on time could be called a competitive advantage because it's a critical component of resource delivery -- but in general, trains are really more of a tactical concern. Isn't integration very similar? Sure, you've got a problem if it's not working -- but do you really notice when it is? Isn't that saying "competitive advantage" is just synonymous with "functional and competent?"

But Schmidt also pointed out that integration now requires more collaboration with the business units:

"... many large organizations today operate more like a federation than a dictatorship. And the people that work in the organizations have a mind of their own, come from all over the world (and even work all over the world) and often aren't permanent employees of the company. Traditional management practices are no longer sufficient in this new environment."

Integration, he notes, now requires "more of an agreement process rather than an analytical process."

The word choice caught my eye, because TDWI Research manager Philip Russom used the term "analytical" to categorize certain types of data integration projects. That's coincidental, I'm sure, but Russom struck a similar chord about integration's growing collaborative and strategic role during this presentation on "Second-Generation Collaborative Data Integration."

When Russom refers to analytical data integration, he's talking about master data management and data integration involving data warehousing and business intelligence projects.

He contrasts this with operational data integration, which applies to projects that involve consolidation, migration, upgrades or somehow synchronizing operational databases. As an example, Russom discusses a company that consolidated 13 ERP systems worldwide down to three regional ERP systems.

You would think that the bulk of data integration projects would be analytical, what with all the talk about business intelligence and MDM but, according to Russom, research from TDWI suggests that most data integration projects are actually operational:

"I'd say that operational data integration is growing even faster than analytic. Let that sink in for a moment. If you're a DI specialist you might want to be sure you've got a lot of stuff on your resume in the operational data integration area not just analytic, because it's very much a viable practice and it's going to be bigger. And as it gets bigger, you need more collaboration between data integration specialist as well as externally to the green data center programs out to the big consolidation programs due to mergers and acquisitions."

It's part of an overall trend Russom terms "second-generation data integration." There are several factors that differentiate first-generation data integration from second-generation data integration, and you can learn what those are by watching the presentation or downloading Russom's free paper on the topic.

But the number-one thing that marks second-generation data integration is collaboration. That's important because, as Russom points out, the focus on collaboration gives data integration specialists a chance to step outside their cubicles and do a new kind of work in the data center.

Data integration specialists are even getting a chance to interact with executives and support business goals with consolidations and mergers, he added.

After hearing that, I had to concede that integration sounds much more strategic than I previously believed.