Skip to main content

The Fundamentals of building Client Networks

Recently I've been thinking a lot about the best way to help my clients understand and engage with their IT networks and systems. I have also been thinking a lot about how to best manage and look after these systems for my clients in a sustainable way. In order to do this I've been looking at the fundamental basic building blocks of my client base and considering the commonalities. The reason for understanding these commonalities is to put into place simple guidelines for developing and maintaining a network. Each network will of course have certain unique circumstances but if the fundamental infrastructure is well understood, these unique aspects of each network will be easier to manage.

So thinking of all of these things, I've looked at the commonalities in my clients and found they can be grouped into several broad categories:

  • sites with a single server, single location and a small (less than 30) number of users. They may have some mobility but generally only a small requirement.
  • sites with multiple servers but only a single location and between 25 and 50 users. Again, some mobility but not a lot - potentially they'll want more.
  • sites with multiple servers, multiple locations and 25 plus users. Requirements for mobility including file access and remote VPN access.
Although these categories are quite broad, they cover 90% of the small to medium business clients I tend to deal with. These clients are all important to me, and given I have a finite amount of time to work with them, its critical that understanding the fundamentals and underlying structure of the networks doesn't need to be re-discovered every time I'm on site. How then to ensure efficient support of clients?

Firstly by grouping sites into the broad categories I mentioned earlier, I have a quick higher understanding of each site. By building each network following standard procedures there is plenty of efficiency to be gained and also it's a lot easier to explain to a client what is on their network.

Secondly good documentation is key. It's not just writing stuff down, but having it available to review when you are onsite - and this means there are several things that have to be in place:
  • data must be available via some sort of mobility
  • data must be secure
  • data must be organised and detailed
Having the data secure is incredibly important - if it's available using some type of web interface, it has to be SSL secured and the passwords have to be strong. Although this seems obvious, it doesn't seem to be well executed. Having data organised and detailed is the key to keeping client networks well looked after.

Thirdly using the same basic ideas to build each network type mean that if the key support staff member is not available, other support staff can easily work out what is where and how it's set up. These basic ideas also make it far more efficient to produce quotes and proposals, and, I've found anyway, that development of new ideas can be more easily implemented into proposals and integrated into networks.

Recently I've noted that lately I have been speaking with businesses that aren't currently clients of mine and I've found some over-complicated and under-documented networks. By applying some of the basic principles I've touched on in the post I'm able to start getting these networks back under control. I've found that the easiest way to do this is the following:
  • determine what the client needs
  • determine what the client wants
  • determine what the client already has
  • determine what the client actually can have
  • document it all and discuss at length and in as non-technical a manner as possible
These are the fundamentals of building client networks and they are also the fundamentals of recovering a client network from a state of disrepair. The major difference is that the former causes a lot less pain than the latter.


AB out.


Popular posts from this blog

Plone - the open source Content Management System - a review

One of my clients, a non-profit, has a lot of files on it's clients. They need a way to digitally store these files, securely and with availability for certain people. They also need these files to expire and be deleted after a given length of time - usually about 7 years. These were the parameters I was given to search for a Document Management System (DMS) or more commonly a Content Management System (CMS). There are quite a lot of them, but most are designed for front facing information delivery - that is, to write something, put it up for review, have it reviewed and then published. We do not want this data published ever - and some CMS's make that a bit tricky to manage. So at the end of the day, I looked into several CMS systems that looked like they could be useful. The first one to be reviewed was OpenKM ( ). It looked OK, was open source which is preferable and seemed to have solid security and publishing options. Backing up the database and upgradin

Musings on System Administration

I was reading an article discussing forensic preparation for computer systems. Some of the stuff in there I knew the general theory of, but not the specifics of how to perform. As I thought about it, it occurred to me that Systems Administration is such a vast field. There is no way I can know all of this stuff. I made a list of the software and operating systems I currently manage. They include: - Windows Server 2003, Standard and Enterprise - Exchange 2003 - Windows XP - Windows Vista - Windows 2000 - Ubuntu Linux - OpenSuSE Linux - Mac OSX (10.3 and 10.4) - Solaris 8 - SQL 2005 - Various specialised software for the transport industry I have specific knowledge on some of this, broad knowledge on all of it, and always think "There's so much I *don't* know". It gets a bit down heartening sometimes. For one thing - I have no clue about SQL 2005 and I need to make it work with another bit of software. All complicated and nothing straightforward. Irritating doesn&

Traffic Monitoring using Ubuntu Linux, ntop, iftop and bridging

This is an update of an older post, as the utilities change, so has this concept of a cheap network spike - I use it to troubleshoot network issues, usually between a router and the network to understand what traffic is going where. The concept involves a transparent bridge between two network interface cards, and then looking at that traffic with a variety of tools to determine network traffic specifics. Most recently I used one to determine if a 4MB SDSL connection was saturated or not. It turned out the router was incorrectly configured and the connection had a maximum usage under 100Kb/s (!) At $1600 / month it's probably important to get this right - especially when the client was considering upgrading to a faster (and more expensive) link based on their DSL provider's advice. Hardware requirements: I'm using an old Dell Vostro desktop PC with a dual gigabit NIC in it - low profile and fits into the box nicely. Added a bit of extra RAM and a decent disk and that&