I would feel sorry for IT's favorite punching bag, Nicholas Carr, if he weren't so pompous and occasionally clueless. Let's face it: Those are great qualifications for a punching bag.

Of course, it's been a long time since Carr wrote his infamous, "IT Doesn't Matter" thesis, but like most experts, he occasionally resurfaces with new twists on the same theme, for example: His latest book, The Big Switch.

So, kudos to John Schmidt for this smack down on Carr, wherein the vice president of Global Integration Services at Informatica Corporation points out that we're far, far away from a world where enterprise technology is a utility, primarily because integration is so complicated and gosh-darn hard:

"IT complexity has been growing exponentially for the past 15-20 years -- and integrating it all in support of changing business processes, dynamic organizational restructuring, mergers, and technology evolution is very difficult. So while the individual technology components might be commodities, integrating the business data and processes seamlessly and efficiently is hard to do."

Schmidt backs up his premise with a sampling of statistics showing the seriousness of the integration challenge. He also points out that integration isn't a defined science, and so, at this point in time, organizations that can do integration well will be ahead of the competition.

Given how hard integration can be, you might want to ask yourself whether that integration project you're about to start really requires integration, or whether you can achieve the same results -- perhaps even better results - with an alternative approach.

In a recent IT World article, Sean McGrath, the CTO of Propylon, raises questions about whether integration is really necessary in all cases, even if the CEO thinks so. He examines two scenarios that seem to require point-to-point integration. In one case, the integration will aid a business process, while in the other, it will only help with reporting. His conclusion? Opt out of integration in the second scenario.

I also liked the "related read" mentioned at the end of the article. It was written in 2003, but McGrath does a great job of explaining the downside of tight coupling, while warning that some forms of loose coupling can be just as bad.