All Posts in Technology

|In: Industry Commentary|Last Updated:

Have we spent enough time criticizing Nicholas Carr?

Naw … we can squeeze at least one more column out of his Harvard Business Review article, “IT Doesn’t Matter.”

Carr, you’ll recall, asserts that information technology has become a commodity, and as such is now more of a defensive play than a strategic advantage. We’ve reached the point of diminishing returns, it’s become uninteresting … got the picture? It’s a message that’s simultaneously baloney and something lots of business executives will eat up with gusto, because it reinforces their deep-seated belief that IT is just a money pit filled with propeller-heads who use the company’s money to buy themselves toys.

Among the many well-thought-out rebuttals to Carr’s article is “IT Doesn’t Matter”: A Critical Analysis of Nicholas Carr’s I.T. Article in the Harvard Business Review, an upcoming book by Howard Smith and Peter Fingar which (ahem) quotes quite a bit of my recent KJR article on the subject. The key point, upon which Messrs. Smith, Fingar and I agree, is that unless how you do business doesn’t matter, IT has to matter since it’s built into every aspect of how you do business.

It is, of course, our own fault. As I pointed out in Bob Lewis’ IS Survival Guide (Macmillan/SAMS, 1999) we should never have placed our emphasis on information in the first place.

Not that information is a bad thing, you understand. It’s that information is the frosting, not the cake. The most important value “information technology” brings to most organizations isn’t the information, it’s process effectiveness. Want proof? Perform a gedankenexperiment. Turn off all of your company’s information technology and look at what forces you into bankruptcy: Your inability to do anything useful at a cost within two orders of magnitude of your most inept competitor will end your business’s sorry stay on this planet, long before anyone has a chance to notice a lack of information.

The devil is in the details (or maybe it’s God who lives there, as Ludwig Mies van der Rohe asserted. Or maybe both, which has fascinating theological ramifications not relevant here … but I digress.) Ahem. As I was saying, details matter. Our profession’s failure to understand that IT’s first priority is promoting efficient business processes has led to a staggering number of bad decisions, most of which are in the details where nobody ever sees them.

Nobody, that is, except everyone in the company who does real work. They live with the bad design decisions resulting from a focus on information instead of a focus on business process effectiveness. We call what they live with the “user interface.” We should call it “helping get important work done,” or maybe the “business process manager.” Then the user interface, which frequently ranks between “low priority” and “afterthought” in IT projects, would be elevated to where it belongs: The single most important factor in any IT project’s success.

Because there isn’t any such thing as an IT project in the first place. Projects are about business change — about how to make the business run better. With some exceptions (data warehousing projects, for example) the goal is to improve business effectiveness — to improve, that is, the efficiency of business processes and the impact of each employee.

So the next time someone charters an “IT project,” give it the right focus. Somewhere near the top, in the statement of objectives, make sure it says something like, “The purpose of this project is to optimize the company’s ability to xxx.

“And maybe, along the way, generate useful information, too.”

Comments

|In: Industry Commentary|Last Updated:

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.

Comments