Some of My Favorite Sayings/Stories for System Architecture

The Principle of Superiority (also called the learning curve):

The first example of the superior principle is always inferior to a mature example of an inferior principle.

Corollaries include:

• The first roll out of a superior process is always inferior to a mature inferior process.
• The first roll out of a superior product (like the automobile) is inferior to a mature product (like the horse and buggy).  That is, it does not go as far; it goes more slowly; it's much less reliable; it's difficult to find "feed"; and it's dangerous to have that "feed" (gasoline) around because it could explode--when was the last time you heard of a horse or oats exploding.... 

The (Key) Principle of Optimizing Systems:

Optimizing sub-systems (e.g., functions, activities) always sub-optimizes the system. I've often wondered why system architect cannot take a lesson from manufacturing engineers--they balance the processes and tooling of an assembly line rather than allow private agendas of the functions be translated by a combined  process of beauty contest and back room dickering to dictate where to invest to optimize the effectiveness of the line.

The To Be Architecture Principle:

Start with the end in mind (to quote Steven Covey).  Have a big picture, but without much detail.  Acquiring the "detail" will take so much time that it will be obsolete before its ready to use.  Instead, remember that "the end", in this case, is the vision or long-term goal. Then "plan a little/build a little."  Choose where to start based on the initial objectives or mission. Then, at least if you're working in information technology like I have most of my life, choose one of two strategies, either implement the "low hanging fruit" first (first, implement the things that have the least risk associated with them), or implement "the hard" things first (first, implement the things with the most risk associated with them).  Either way, ensure that you have good configuration management and good V&V processes in place that are well executed--otherwise "the plan a little/build a little" approach will not work.

The Airport scheduling Algorithm:

Never over-schedule the runway.  The problem is defining what "over-schedule" means.  I once read in a systems analysis text, which I own but have not been able to locate, that an airport has two choices in scheduling; either schedule for the best case, or allow for some of the worst case or "imperfection" an attribute of being human.  For example, suppose that under the best conditions an aircraft can land or takeoff once every 30 seconds.  Some airports will plan for one aircraft every 30 seconds--Laguardia and Reagan National (before 9/11) seem to be two.  What happened and continues to happen when the weather conditions are not perfect?  Laguardia is known for taking an hour or more for a plane, from the time of push back to when it reaches the runway for takeoff.  See my post "Lean or Agile Enterprises and Architecture".

The Law of System and Product Development
Cost, Schedule, Quality; choose two of the three.  This may be a correlary of Arrow's Impossibility Theorm.