Years ago, I used to tell a joke with no punch line. It went, “How many vendors does it take to print a memo?”

For us, at the time, the answer was 10: (1) IBM – PC; (2) Microsoft – DOS; (3) Automenu – DOS menuing front end; (4) WordPerfect – word processor; (5) Synoptics – Ethernet hubs; (6) Anixter – Ethernet cable; (7) Novell – NOS; (8) Compaq – file server hardware; (9) Hewlett-Packard – laser printer; and (10) Pacific Data – font cartridge.

“Imagine,” I was fond of saying, “how many vendors we’d need to do something complicated.”

Understanding what computing functions are involved in addressing common end-user tasks, and what products deliver those functions, is an important goal in managing technical architecture.

This is our 10th article on creating an integrated IS plan and the sixth on technical architecture. We’ll be done soon. I promise. We do have a few more topics to cover, though, and managing your technical architecture well is awfully important.

As last we left our heroes, they had just finished mapping platform-layer products to computing functions, scoring each product in terms of how well it serves its purpose and also looking for redundancies and incompatibilities. Let’s see what they’re up to now … .

Our product/function grid doesn’t address integration and design; that is, it doesn’t ensure that anything actually works.

To do that, some drawings will help.

The first drawing is a physical connectivity map of your enterprise. It shows, not every device on your network, but every class of device that connects through your network.

Your goal in creating this drawing is ensuring that electrons can flow between any two devices that need to communicate, so next to each connection, list the types of service or session available through it. For example, you may have a mainframe connection that only supports 3278 terminal sessions (LU6.2 sessions, to be precise) through the network.

That’s important to know, because that means your connectivity will have to change when you start using the mainframe as an application server. If your mainframe connection supported TCP/IP communication and T3270 sessions, on the other hand, it would work just fine for the new requirement while still supporting the old one.

The second drawing, really a set of drawings, is a client-centric view of your platform environment. Create a drawing for every device that hosts at least one client process or acts as an end-user workstation. Put that device in the center of the drawing and around the periphery depict the resources – server processes – that device must access.

Then, for each resource, list the client process needed to reach it, where that client process runs, and what protocols and connectivity are required to achieve the connection.

(Remember that “clients” are software processes. Although many clients run on desktop computers, that doesn’t make desktop computers clients, and client processes often run on server hardware. A commonplace example: When you fill out an HTML-based form on your browser, the browser isn’t the client. The client process runs on the Web server, perhaps in the form of a Perl script. That client process interacts with a host computer in the background, formats the results, and sends them back to your browser.)

Your goal in creating this second set of drawings is to look for opportunities to simplify. The more commonality between different connections, the simpler and easier it is to manage your architecture.

Don’t, however, fall into the trap of equating “simpler architecture” with “that’s what we need to do.” When simplifying your architecture reduces the level of functionality you provide, be careful.

It may, for example, seem attractive to use a browser as a universal terminal and Web servers as universal clients. It may to you, but browsers make for second-rate interfaces when compared to a full-featured GUI.

As with the rest of the process of managing architecture, keep the purpose in mind at all times, and that’s making sure you know how to connect resources to the processes that need them. Don’t get lost in the technique, because if you do, you’re just painting by numbers.

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.