The ever-quotable Larry Ellison has told us that software is about to become uninteresting. Nicholas Carr has stated, in the Harvard Business Review, no less, that IT doesn’t matter anymore — that since everyone has “it,” it’s no longer a differentiator.

I don’t know which parallel dimension they live in, but I’m pretty sure it isn’t the one you and I inhabit. In their dimension, I guess, the moment a process owner in the business decides to change how something gets done, they just plug a cable into their heads and the company’s ERP system automatically and instantly reconfigures itself and all of its interfaces to the outside world to implement the new business practice.

In our world, we sit down with them, figure out the various implications of their new idea, map out the numerous inconvenient exceptions to the main process flow … the ones that take just as much coding time, even though they only occur infrequently … and develop a coding strategy.

Then we look at the interfaces.

Making software do what the business needs is difficult work. On the other hand, it’s relatively straightforward work. The seamy, sordid, ugly red-light district of IT is the collection of interfaces we’ve collected over time to make everything work together. Interfacing two software packages that weren’t designed to be compatible is intrinsically difficult. Need evidence? Synchronize your Palm PDA with Outlook.

The Outlook calendar stores each appointment using Greenwich Mean Time. The time it displays automatically adjusts the schedule to your current time zone. If you know what you’re doing, this can be mighty handy — for example, if you’re a consultant who schedules a conference call while you’re in Los Angeles that you’ll dial into when you’re in a New York hotel room.

The Palm datebook’s designers used a simpler paradigm: Your Palm simply stores whatever time you tell it to. So what happens when you synchronize it with Outlook? It fails to report a scheduling conflict between your 4pm meeting in Chicago and the call you have to make to your west-coast client at 2pm their time, unless you remember to conscientiously re-synchronize every time you change time zones.

This isn’t a solvable problem. Even were you to build a custom interface to replace the standard synchronization software, you’d have to make assumptions, because the Palm datebook schedule is semantically inconsistent with the Outlook schedule.

I’ll be the first to admit that the Palm-to-Outlook interface shouldn’t be high on anyone’s priority list. It just isn’t that big a deal.

Here’s what is a big deal: Something as trivial as synchronizing a desktop calendar with a PDA calendar has intrinsically unresolvable design ambiguities.

IT rarely deals with issues this trivial. IT deals with business applications several orders of magnitude more complex than Microsoft Outlook, let alone the Palm datebook. While IT developed some of them in-house, it licenses most of them from outside vendors — multiple outside vendors, who designed them with different and conflicting assumptions and perspectives. Building interfaces that work isn’t a trivial matter; making sure the interfaces continue to work as we change and reconfigure the systems to meet changing business needs is also a non-trivial matter.

Nor are we finished, because on top of our internal interfaces, we flow data back and forth with our business partners. Electronic Data Interchange has never been easy and inexpensive, and while many industry pundits blamed the early standards, the problem wasn’t ANSI X.12 or Edifact. Any working programmer involved in EDI could have explained this to the pundits who hyped XML as the magic bullet that would fix it all, just as they could have predicted that enterprise application integration (EAI) and Web services would be useful, but hardly a panacea that makes internal integration simple and seamless.

Carr might be right, I guess. Since the definition of “strategic” is slippery, deciding which nouns you can and can’t attach it to is debatable. I’d argue that the ability to execute is the most significant strategic advantage any company can have. That makes your ability to reconfigure the applications portfolio to support planned business change as strategic as it gets.

It’s entirely possible that Larry Ellison is right, too — that software is about to become boring. That, after all, is a matter of attitude, and software always has been boring to many business executives.

But that doesn’t mean information technology has reached either the point of diminishing returns, or a plateau where the pace of change and innovation will slow. Software, that is, isn’t about to become boring in any intrinsic way.

Nothing, in fact, has changed: Those who lack the time, patience, aptitude, or desire to understand information technology found it boring before, find it boring now, and will continue to find it boring in the future.

That’s what is really uninteresting.