Nuance is dead. May it rest in peace.

The headline: PC shipments crater and tablets are the bogeymen,” (Woody Leonhard, InfoWorld, 10/10/2013).

First, let me assure you, Woody is a bright guy and I have a lot of respect for him. And second, writers don’t always write their own headlines. In any event, here’s what “crater” means: Worldwide, PC shipments are down around 8 percent, depending whose numbers you believe. In the U.S. PC shipments are up … up … a couple of percent.

Hardly the stuff of cratering.

The more interesting factoids in the story (and as I work for Dell I’m not an entirely disinterested party, although I have no connection to the product side of the company): The major manufacturers (HP, Lenovo, Dell) saw slight growth in their sales worldwide. Lenovo and Toshiba saw double-digit growth in the U.S. Yes, that’s right, growth … also not the stuff of cratering.

An interesting sidelight is that Apple’s U.S. sales took a sizable hit (more than 10%).

The truly fascinating bit was that Acer and Asus saw their sales plummet — down around 25% from last year. That really is cratering.

How to interpret these numbers? It’s probably much as pointed out here a few weeks back (“The post-PC era isn’t post-PC. It’s PC plus,” 9/16/2013). What cratered was consumer demand for PCs. Acer, Asus, and even Apple have a strong consumer orientation. Enterprise demand is, most likely, stable — enough from new ventures and replacement units to continue to support the major manufacturers.

It isn’t as attention-getting as “crater,” though.

As long as I’m quibbling with my friends at InfoWorld I might as well take issue with another recent piece they ran: “The end of the CIO as we know it — and IT feels fine,” (Galen Gruman, 10/11/2013). I’m afraid it got a lot wrong, starting with when the CIO title first appeared and what drove it. It wasn’t, as the article claimed, 15 years ago, driven by Y2K combined with the rise of ERP and eCommerce.

As evidence … why would any of those change “Director of Electronic Data Processing” to “Chief Information Officer”?

No, the CIO title came into existence twice that long ago, in the early 1980s. The driver: A newly introduced technology for mainframe computers called the database management system.

DBMS licenses were expensive. Very expensive in the context of what companies were already spending on their mainframe systems. The real, tangible cost-justification for spending the additional money was that it increased programmer productivity. Which it did. (Disagree? Imagine having to program without one.)

Except that, as anyone who’s tried it knows, programmer productivity is excruciatingly hard to measure, which means proving the tangible benefits of the new technology would have been excruciatingly hard.

So IBM’s marketing department came up with a new concept: The primary value EDP provided wasn’t increased employee productivity, as we’d been claiming until then. That was secondary. The big value was the information itself and what companies could do with it to improve decision-making. What, you thought this was new with data warehouses, data mining, and big data?

Whether you agree or disagree with the concept, the title “Chief Information Officer” flowed directly out of this idea — that information is where the big value is.

The concept’s legitimacy is questionable, by the way. Among its drawbacks: It elevates the importance of management decision-making above the value of actual work. But that’s a different, and very long diatribe.

Anyway, Galen’s piece is one of many that are appearing these days that predict we’ve entered the end-times for the CIO, and probably for corporate IT as well. Read any of these pieces. Squint at them sideways and you can predict the outcome of following this advice: A proliferation of “islands of automation,” because when companies push IT into business departments, nobody will be willing to pay for integration, let alone have the skills to handle it, let alone the authority.

And, the advice-followers will see significant fortification of political siloes. The reason? A big chunk of spending that used to be strategic (or at least enterprise in scope) will now be tactical, or, more accurately, departmental.

Siloed.

For a very long time … since, in fact, the advent of the DBMS … IT’s most important role has been integration. Maybe if CIO had stood for “Chief Integration Officer” we wouldn’t need to have this little chat.

* * *

Speaking of the 9/16 column, which talked about how IT’s role is expanding while its budget isn’t, I’m embarrassed. At the end I promised a follow-up that talked about what CIOs can do to survive the experience. But my vacation distracted me. Sorry. Next week for sure.

– Bob

Ever wonder what separates successful IT departments from the ones that generate nothing but gripes?

Not what separates star-performing IT from “the pack,” but what separates the competent from the rest?

150 factors make the difference, but they aren’t all created equal. Squint at the list hard and 18 float to the top. (Why 18? Because that’s how many actually floated to the top. I didn’t start with a number in mind.)

Some background: Back in the last century when I wrote the  IS Survival Guide I organized the factors needed for IT to work into four buckets. Over time these evolved into the framework I use today: Business integration, process maturity, technical architecture, and human performance.

The 150 factors on my list of what makes the difference come from drilling down into these four categories. Selecting the 18 “critical success factors” from that list was less than scientific but more than arbitrary — it was the result of experience and lots of correspondence over the years.

This week’s column defines the big four and their overall scope. Starting next week we’ll dig into the critical success factors and what to do about them if your organization comes up short. So without further ado:

Business Integration

Business integration covers everything about how IT fits into the enterprise as a whole. It happens at three levels: strategic (meaning enterprise-scale), tactical (divisional), and business-infrastructural (overall “lifestyle” technologies) integration. And yes, I’m abusing the language using it this way. Live with it.

Those are the whats of business integration. The hows are governance and the business/IT relationship.

Process Maturity

Process … more accurately, processes and practices … are how an organization does its work. IT’s processes and practices fall into five broad categories:

  • Delivery management: Primarily on the applications side of IT, how the organization makes sure IT actually does deliver what it’s supposed to deliver. Delivery management breaks down into three levels: Program management, initiative management, and project management.
  • Application support: This includes everything having to do with designing or selecting; building or installing, configuring and integrating; enhancing; maintaining; and (when the time comes) retiring business applications.
  • Information management: Making sure all structured databases and unstructured data repositories contain what they’re supposed to contain, and are organized so as to maximize their maintainability, integrity, and value.
  • IT Operations: If the systems are down, nothing else matters. If they’re sluggish, something else matters but not much. IT Operations is where IT makes sure the value it’s already delivered is there, ready to use when it’s needed.
  • Personal technologies: The ERP suite is strategic and runs the company. The CRM suite is strategic and drives revenue. But employees live their lives on their PCs, smartphones and tablets, using the office suite, email system, and telephones. Handle these well and employees will forgive a lot. Handle them badly and your reputation is shot.

Technical Architecture

Yes, IT might be “about the business,” but in the end, someone has to make sure the company has the right technologies in place, organized well, and put together to facilitate the company’s next step instead of acting as a barrier or bottleneck. Notwithstanding all that’s written about shadow IT, non-IT IT and so on, when it comes to the stuff that can’t just be a standalone “island of automation,” that someone is IT.

Technical architecture encompasses the applications portfolio, the company’s structured and unstructured data repositories, and all the platforms and technical infrastructure they reside and run on. And how they all fit together.

Human Performance

IT might be “about the business,” and its job might be to provide the technology the company needs (and by the way, its job is now bigger than that, but that’s a different topic for a different column).

IT might get its work done through well-organized processes and practices, but in the end it’s the people who work in IT who make the difference between success and failure.

Human performance isn’t about whether the people who work in IT perform. It’s about everything that has to come together so IT has great people working in it, with as few barriers as possible standing between them and success.

These four factors — business integration, process maturity, technical architecture and human performance — are what IT has to be good at if it’s going to be considered competent.

How does IT become good at them? That’s what the list of critical success factors is for. We’ll start digging into it next week.