MANAGEMENT SPEAK: We are not interested in helping the users here. We are only interested in clearing the help desk queue.
No translation will do justice to this sentiment.
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 would say, "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. Some drawings will help.
The first 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 supports only 3278 terminal sessions (LU6.2 sessions, to be precise) through the network.
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 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 centre 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.
(Remember that "clients" are software processes. When you fill out an HTML-based form on your browser, for example, the browser isn't the client. The client process runs on the Web server. 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. Don't, however, fall into the trap of equating "simpler architecture" with "that's what we need to do". When simplifying your architecture reduces functionality, be careful.
As always, keep your purpose in mind: 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.