I watched a documentary (of sorts) last night called "Crumbling America" that talked about America's infrastructure issues. They detailed how roads, bridges, electrical grids and water systems are having serious issues and are basically falling apart. I think they were sensationalizing a bit, but it was interesting to note that America spends only 4% of it's income on infrastructure now, down from a high over over three times that amount. Even the "stimulus" plan containing almost a trillion dollars has less than 9% of the money earmarked for infrastructure.
I found all this interesting because it has corollaries to our IT infrastructure. While I can't control our federal infrastructure, but I can affect my local IT infrastructure, especially the database. I pulled out three things from the television program that I thought was applicable to IT. They mentioned three main issues with infrastructure that I think we should evaluate in our own systems:
1. The system had a design flaw.
The first thing that they pointed out about a road or bridge that failed was that in some cases the engineers decided to go with a lighter steel plate, or a different kind of surface that turned out not to be strong enough or last long enough. This holds true in IT as well. I've seen many systems that just had a fundamental design flaw that caused an issue later. What can we do about this? Two things: educate yourself about good design patterns and implement them in your own code, and evaluate any "canned" solutions your company buys and ask the hard questions about the design of the software. After all, you have to live with it when it is gone.
2. The system can't handle the load or speeds required in a modern environment.
In the case of a water system or electrical grid, the initial design or even the overall arrangement of the components cannot handle how much work required from the users. This of course has obvious parallels to IT. The thing we can do as DBA's and Developers is to do a good job of projecting load, and constantly monitoring the systems to make sure we know when we're reaching a limit.
3. The system upgrades keep getting deferred.
Keeping a road, bridge or other system maintained and upgraded is very expensive and disruptive. Politicians take the easy way out and defer that maintenance over and over. This leads to eventual disaster. It's the same in IT. As you monitor your systems, make sure you push for upgrades along the way. I run into firms every day that are still using SQL Server 2000 - even though it is out of maintenance, has lower security, and does not perform as well as the newer versions. I'm told "my vendor won't upgrade" or "it's working just fine" and it reminds me of the inspectors on the bridges that fail.
There are more parallels, but I think you have the idea. You can take almost any system that handles "traffic" or load and learn from it. The question is, will you?