Today, I was involved in a meeting that was developing an entire computing environment including wide (WAN), metropolitan (MAN), and local area networks (LAN) plus all the associated workstations, switches, servers, printers, and backbone wiring.  I am not sure why it struck me as so humorous at the time, but the facilitator kept on stressing that we were there to ensure that our end-to-end (E2E) system was successful.  I have been at dozens of these exact same events, but this was the first time that it occurred to me how silly that actually sounds.  Computer ecosystems are primarily communications spider webs.  They are designed to connect my head to your head — I am not sure that I want to know what happens when millions of dollars are spent attempting to connect your (rear) end to mine.  Maybe face-to-face (F2F) or mind-to-mind (M2M) is better?


Seriously, this type of architecture planning session is very common in the Information Management workspace.  No matter what people like to call it — enterprise architecture, E2E assurance, global planning, Continuity of Operations Planning (COOP) etc… — it is really just systems engineering plain and simple. 

There are two very distinct points of view to accomplish this type of engineering.  Unfortunately, I rarely see both embraced in any one network and you really them both if success is your goal.

  1. Outside-In Approach. This can also be called top-down.  Essentially it follows the paradigm that the network is the system.  It is done by imagining that you are looking at the system from 50,000 feet.  You draw the wide area network (WAN) first, followed by the Metropolitan (MAN) ones, then local (LAN), servers, nodes, and so on until you eventually “descend” to the desktop and plot your users’ workstations.  It assumes that given the choice of links or nodes, you will favor the links in your architectural planning. 
  2. Inside-Out Approach. It would be tempting to say that this is just the opposite, but that would be overly simplistic.  In this mode, you start by thinking about the requirements of the individual user and then proceed to build a network around them that delivers connectivity to them.


Does this really matter?  You bet.  In practice, if you use only the inside out approach you end up with the sort of jury-rigged, cobbled together, sub-optimized layouts that were popular, but inefficient, expensive, and unsecured from a decade ago.  On the other hand, the “top-down, user be dammed” approach that has been dominant for the last ten years or so results in excessive computing resources where they are not needed, users who feel shoe-horned into one-size-fits-all workplaces, and tends to put computing power where bosses are vice where the actual work gets done.  Neither is the least expensive either.

The best compromise that I can come up with is to have two teams working in parallel, with one committed to each focus, produce an architecture.  Then a jointly manned optimization team arbitrates both according to whatever success criteria – cost, performance, or reliability – that management chooses.  I can’t think of a better procedure if overall network success is the goal.


So when it comes to system architecture development: Are you an Outtie or an Inniie.

That is my Information Technology Thought of the Day (ITTOD) for April 10, 2009 ©Scott Coughlin.