It just works, it always has worked, and it always should work. How many clients have you heard this from? How many could have been saved problems with a little forethought, and a little vigilance?
The problem with this lack of vigilance is the trouble it causes. Oh maybe not immediately, but eventually. Today I’ll give 2 real world Network Design cases to prove this point, and hopefully teach you to think things through.
Case 1 is a client who we took over their network. This network has a Linux box running a mission critical database app. Not a big deal. The rest of the network consists of a 2003 Domain Controler/DHCP/DNS server, 1 domain, and now 2 workgroups. Not a single PC is part of the Domain. Most PCs are using host files for internal DNS resolution. No PC is registering itself on internal DNS in fact all the machines have external DNS servers hard coded on them. Then their Windows 2000 Professional (Not server) box that serves as a scan server dies. They go cheap and get an XP box to replace it, and because of the mish mosh of a network they have, there are of course problems. I tell them this is the perfect chance to fix all their network problems and redesign this 20 person company into a proper network structure to prevent issues in the future. The go to another company which does a few registry hacks to get things working.
Now we all know what is going to happen, this company will hit another problem, troubleshooting will take 2-3 times as long as it should, and they will complain about the amount of time they are charged, saying their IT company doesn’t know what they are doing. Mind you, they have no documentation on all the kluges done to keep the network going.
Case Study 2 is a client who had their exchange server go offline recently. The company has grown since the network was originally designed. The problem turned out that the edb file grew so large it used up all free space on the drive it was on. Yes, this is a bad thing, but it gets worse. It is a single database file that is over 300 GB. If this file gets corrupted, I fear how long a restore will take.
Of course case 2 is a little more understanding, and we are going to get more drive space, force people to clean up their mailboxes, and once we have new drives added onto the RAID, and space is increased, we shall make new databases for the IS and get that 300+ GB database down in size by using multiple databases. Unfortunately, this was just one small design flaw in a network that was added onto without thinking of what the future would bring. No thought of growth for the company, and no thought of how things will work together.
Luckily case 2 is fixable. Well technically so is case 1, but case 2 understands it needs to be fixed. All of this could have been avoided with proper planning at the start of it all. When rounds of upgrades were done, more thinking and planning should have been done.
I tend to ask a client where they expect the company to be in 5 years. I try to design for 5 years later, that way when they are ready for upgrading in 3-5 years, there is still some spare room for migration. I also let my clients know that they should start saving at that moment for their next round of upgrades in 3-5 years. If they take 5-10% of their monthly revenue and put it aside for IT, they will not only be able to afford to upgrade on a regular cycle, but they will have a slush fund should something go wrong, and have money to keep software such as Quickbooks on the latest version.
Its all about our own vigilance. We are the experts, and we have to think of each of our clients as our future. Honesty and a plan showing forward thinking will show value to your client. Value means they will stay with you.