This is one of the very few technical principles that I absolutely insist upon and tend to have sense of humour failure when it is not adhered to. This has saved my life so many times that I have lost count.
The principle is simple:
All applications and end users should, wherever possible, only ever connect to a service by an aliased name, never the real name of the service.
By service I mean server, remote application, or anything with a name on the network.
In other words, always use the magic of indirection:
client -> alias -> service
So why is this so important? Well it is so much easier, orders of magnitude easier in fact, to change an alias to point at a different service than to change all the clients to point at a different name or to reinstall the service elsewhere with the same name. When things need moving, either for planned maintenance or because they break this gives us so much flexibility and control. Unfortunately too many techies only think about that when they are planning the move, by which time it is a nightmare.
The normal technical way to do this is using a CNAME in DNS. So we create a DNS record for the service like this
my-service IN A 10.0.0.1
and add the CNAME
my-alias IN CNAME my-service
But don’t forget, it is not just DNS where this can be done.
When you manage a large infrastructure there are plenty of good reasons to standardise on particular hardware and software. It makes training simpler, it makes movement of people around the organisation easier, it reduces support and maintenance costs and so on.
However there is a strong movement to impose the same standardisation on the IT department, usually following the reasoning “we should be seen to be doing the same thing that we expect of the rest of the company”. Well, having been guilty of this in past I came to realise this is quite wrong.
The purpose of end users using computers is to help them do their work and in order to do that they need to learn how to use computers as effectively as possible. But the one thing that is special for people in an IT department is that they must learn about all sorts of things that are *not* used within the organisation. That’s because it is their job to improve the infrastructure and one of the best ways to do that is to introduce new or different hardware and software. And the only way the IT people are going to know to do that is if they get to use all sorts of things not on the approved list in real depth.
So give your IT people the freedom to choose their own hardware and their own software. Obviously this sits outside the normal support structures so make them responsible for supporting it themselves, that way they will learn even faster. Of course they still need access to the ‘corporate’ desktop for all those applications that only run there and to make sure they know the end user experience. But don’t force them to see everything only through the eyes of the end user.
The alternative is monoculture. Your staff get stale as their skills only develop in a limited framework and innovation dries up. This then becomes self perpetuating as you as a manager end up being frustrated that they don’t seem to be innovative and increasingly listen to the things that outsiders say (i.e. consultants and suppliers) because they are the only people saying anything different. Then, of course, the staff feel threatened by the consultants and resist, which compounds the view that they are not innovative.
So avoid the dangers of monoculture and let your staff use whatever kit they want and if it goes wrong then make them fix it. They will be a lot more innovative as a result.
Recent Comments