Good design practice, quite rightly, dictates that network design should be driven by business needs, not technology. Unfortunately there’s a more prevalent form of (bad) network design we have to contend with.

I’ve helped out with a WAN design for a company that is doing some work for a government department. I can’t tell you any more than that or I’d have to shoot you.

The project is struggling a bit trying to get a detailed design together ready for some proof of concept testing, so they asked if I could give some advice. After a couple of conversations, I found out the following:

  1. There is no customer requirements document specifying what this network is supposed to provide to the business.
  2. There is no agreed high-level design describing the overall technical features and functionality that this network must support.
  3. The hardware has already been purchased.

Now it’s not too difficult to take a step back and sort out the first two points. It’s the third one I have a bit of a problem with. We’re now at the stage of trying to bodge some sort of working solution onto the bits of kit that have been bought. And guess what—it doesn’t support some of the features we now find we need to configure.

If the customer insists on using the shiny new tin he has sitting in his warehouse, he will end up with something that will probably more or less almost work, but won’t scale, will be a pig to manage, and really isn’t fit for purpose. But he is understandably less than keen on the idea of submitting another budget request for more hardware before the project is even off the ground. Especially since someone, somewhere, obviously told him that this kit would work just fine for “whatever” he wanted to do.

Speaking of which, while we’re struggling with a technical nightmare, some salesman somewhere is merrily spending his commission on a golfing holiday in Portugal or some such thing. I can’t exactly blame him—it’s his job to sell this kit. OK, maybe I can blame him, but this probably isn’t the time to go into the ethics of (mis)selling since I don’t want to be sued.

The project should of course never have got as far as it did without clarifying the requirements up front, but in this case, even if they had, it would still have been too late, as by the time the design team got involved, the hardware in question was on its way from the factory.

We still have to figure out how to best work round this particular mess, but as a rule of thumb, if you’re thinking about any sort of network redesign or upgrade, make sure you bar the door to anyone with a vested interest in pushing tin until you know exactly what it is you’re trying to do.