In twenty-five words or less, what business value did you gain from your last operating system upgrade? A return on investment (ROI) analysis is an acceptable substitute.

Can’t do it in twenty-five words? Sorry, that’s all you get. Business leaders don’t have time for more than a few bullet points on any subject such as an operating system upgrade that isn’t directly related to the health of the company. That doesn’t mean you shouldn’t upgrade. It means “business value” is the wrong question.

We upgrade our operating systems for two reasons. We may want the new features and bug fixes offered by the upgrade. More likely, we simply need to stay current, because in the long run we have no choice. If we don’t, eventually some application, DBMS or utility we need won’t run on our obsolete OS.

An OS upgrade is part of what we have to do to provide a working computing environment. Business value comes from the capabilities, performance and reliability of that computing environment, not from any single element of it.

From the perspective of technical architecture, the subject we’ve been flogging for the past several weeks, it’s the platform layer that provides your company’s computing environment.

Managing the platform layer starts with a list of every platform you support. “Platform” includes hardware, operating systems, database management systems, languages, hubs, routers, cabling systems … everything that’s “under the hood”.

Some software will be hard to classify. Electronic mail, for example, sometimes acts as a platform and sometimes as an application. Don’t worry about it too much — just decide where you want to manage the hard-to-classify stuff so it isn’t forgotten.

Make the platforms the rows of a large grid. In the columns, list the computing functions you provide and support. In the cells of the grid, place a score wherever a platform provides a computing function.

For example, you may use Solaris (platform) as an application server (computing function), the Oracle DBMS (platform) as your enterprise client/server DBMS (computing function) and DB2 (platform) as your DBMS for host-based computing (computing function). Some platforms provide computing functions used by other platforms. You may, for example, use Windows NT as the OS platform for your departmental DBMS. Don’t get confused by this.

Each score is your assessment of how satisfactorily a particular platform delivers its computing function. You may use a fairly subjective score, or you can be more precise, devising a scoring system that weighs performance, stability, and other factors such as market presence and vendor quality.

Only list direct linkages or you’ll go nuts trying to sort it all out. Don’t, for example, link your Dell Poweredge (platform) to “file and print services” (computing function). Link the Poweredge to the Network Server Hardware computing function. It’s Netware 4.x that’s linked to file and print services.

You can use this grid in several ways. For example, you can use it to find platform redundancies. When you have more than one platform supporting a single computing function, you probably have a redundancy. This isn’t necessarily a bad thing, but it should be a conscious choice, not an accident.

Having two platforms supporting the same computing function also may signal an incompatibility — you installed the second platform because the first didn’t support a key application, perhaps. Incompatibilities happen, but you should monitor them because vendors sometimes resolve incompatibilities, providing you with opportunities to simplify your architecture.

You may find the grid useful when managing upgrades, too — it quickly documents which computing functions will be affected by any platform upgrade.

You can also use it as a planning tool. If a business change drives the need for a new computing function, add it to the grid and figure out whether you can (and should) support it with an existing platform.

The platform/computing function grid isn’t magic. You may find a simpler, more conceptual approach, works better.

It isn’t complete, either, because by itself it doesn’t help you understand how everything works together to provide a complete, integrated computing environment.

We’ll talk about that little subject next week.

A CIO of my acquaintance once described his priorities for the new megasystem his developers were busily constructing. “What I want is the database,” he said. Waving his hands disparagingly, he added, “I don’t much care about the applications that feed it.” Guess what? His system never got built, and he didn’t last two years in his job.

We’re continuing to develop the technical architecture section of our integrated IS plan. This week we home in on the information layer. The techniques for managing this layer are well understood. Instead, let’s elevate the discussion (elevate in the sense that snipers like high places). Our goal this week is to place information in the proper context. We begin by avoiding the mistakes of the aforementioned CIO, realizing that although information is the center of our universe, applications drive the business.

We made a horrible mistake when we changed our name from electronic data processing (EDP) to management information systems (MIS) back in the early ‘80s.

When we were EDP, we did something valuable – we processed something, and as we did so, we automated manual processes.

MIS managed information. Even worse, we declared that our purpose is providing information to managers. Helping employees do useful work became a byproduct.

We would be much better off calling ourselves “process automation systems.” We got offtrack because of database management technology. With the advent of the DBMS, we changed how we designed systems. We put information in the center of design. Information, we realized, is more stable than the programs that make use of it.

Next we figured out that because information is the heart of our designs, it must be at the heart of the enterprise. So far so good, but then we left the halls of reason and jumped to the notion that it’s information, not processing, that delivers the most value.

Take a fresh, hard look at this. IS delivers the bulk of its value through process improvement: lower unit costs, reduced cycle time, and increased accuracy.

This is just as well. If we really do think information is the point of it all, our efforts are way out of whack with the company as a whole. About 80 percent of an average company’s information is unstructured. (I’ve run across this estimate several times, and it passes the “feels right” test, too.) It’s text, voice, and pictures. A simple-minded feller might figure that if information is the point of it all, and 80 percent of all information is unstructured, well then 80 percent of our efforts should be devoted to the management of unstructured information. They aren’t, of course. Eighty percent of our efforts go to managing alphanumeric data – the kind we know how to process. Telephone systems and personal computers – the technologies that handle unstructured information – have been the poor stepchildren of IS, not because we couldn’t manage the information, but because we couldn’t process it.

We’ve been able to get away with this so far. No longer, though. Maybe it’s the influence of e-mail and the World Wide Web, but companies are waking up to this deficiency.

Want to know your future? Look at a modern call center. It records every conversation digitally, along with every screen visited during the call. It’s indexed and ready for online retrieval to help call center management assess individual performance. It’s also available for computing sophisticated performance statistics.

Today these systems are closed and proprietary. Tomorrow they’ll store everything in the same document management system that will store scanned images and word processing documents, all linked through a common index. That’s just one example of how you will have to manage and process information in the near future.

Thought your information layer was in good shape? Maybe for today, but you have some serious planning to do.