Monday, February 16, 2009

Grounding Applications

The term 'grounding' is often used in discussing electrical systems, much to the dismay of non-electricians. It is a cruel joke that tradesmen use a single term to represent four different scenarios. The term grounding can mean:
  • A 'common' connection, but not connected to Earth.
  • A connection to the power supply (usually to the negative terminal)
  • A connection to the inside of a shielded metal box
  • A connection to a metal stake driven into the earth (or a connection to a metal water pipe which extends out of the house into dirt.)
Only the last one is actually connected to the ground, a.k.a. the Earth! This is one way that relatively simple science can be obfuscated to accelerate the acquisition of temporally-based financial transactions (i.e. make things sound hard, so people can charge more per hour). Of course, we're no better. Think of the different meanings we apply to 'server':
  • A computer, much like a personal computer only with more power
  • A special purpose hardware component, more powerful than a PC, but limited in other ways such as a blade server
  • A software component that 'serves' one or more clients
  • A special purpose device such as a DNS Server or FTP server
I cannot say for sure whether we I.T. folks do this on purpose or we are victims of an industry that is growing faster than our vocabulary. But I can say that we frequently steal really good ideas from other disciplines. Milton Berle was once quoted as saying, I know a good joke when I steal one." As architects, we should have no qualms whatsoever about stealing good ideas and applying them to our universe. The concept of electrical grounding, i.e. providing a path to which a build up of electrical charge can be displaced is one we can (and frequently do) use effectively.

Without electrical grounding our electrical systems would be erratic, appearing to work for a while and then, without warning, collapsing, or providing a sudden 'notice' of buildup in the form of foot-long electrical arcs. It would be common for people to die from light-switch-induced heart fibrillations. I had the opportunity to manage USAir's network on which their System Control Center operated. If that mission critical system was ever down for four hours, the FAA would require the airline to shut down. Once a month the entire local area network would simply cease to function and the only known remedy was to pull all of the token-ring cables out of the multi-station access units (MAUs) and reinsert them - a process that took a little over three hours. After much investigation we eventually discovered that the original installers never grounded the network.

If we were to treat our applications like electrical systems, we would provide a grounding path; a way for the build up of time-outs, errors, notifications, and bottlenecks to be channelled to a point of dissipation.

Now, some will say that we do log errors, catch exceptions, and terminate threads - and that is good, but if we are treating each of the possible anomalies as separate events and addressing them each on a case by case basis, rather than providing a systemic solution, we open the opportunity to miss one. We should design our systems with a default path for all non-desired behavior, and (this is critical) we should design tests to validate the handling.

Again, let's be sure we're clear. Certainly we should log errors, we should catch database exceptions, and pooled resource exhaustion; but we should have an overall architecture in our applications that allows all of these events to be channelled so that the application itself never fails - or if it must fail, it does so in a controlled manner. Systems that are designed in this manner are well grounded. Programmers who don't do this, should be grounded as well (ouch!).

Follow by Email