Using CNAMEs for Flexibility

I'm no "real" DBA - I'm an "accidental" one.  (And relatively bad at it.)  My servers probably have performance and disaster recovery holes large enough to drive tractor trailer rigs through.  It's a good thing I have some backstop from my hardware guys - who are just about as accidental as I am, but from the other direction.  Sooner rather than later, somebody's going to have to bite the bullet and get the gaps filled in to become the "real" DBA.  (I voted for them.)
Anyway, I wanted to pass along a neat trick that those gents in the server room came up with.  At least it sounds brilliant to me - and is working very well in practice.  In the process of planning to migrate some servers and applications around our server farm, they suggested we start to use CNAMEs to decouple our infrastructure a little bit.
What's a CNAME?
Truly, I don't understand the exact technical definition.  I would read this, but I have other non-network administration things to do, and I prefer to kill brain cells with C# and Hefeweizen.  (Separately.)  In layman's terms, it's an alias for a computer's name.
What Do You Need An Alias For?
Our main issue was how inflexible we were in being able to redistribute applications and services around our server farm.  From time to time, we needed to move a database, a web application, a networked service, or something else from one server to another.  We aren't completely virtualized - but even in the places we were that didn't help us out completely, because moving virtual servers from metal to metal just wasn't granular enough.  Doing piecemeal moves of apps and services wasn't extremely hard - but it can be complicated and involved to orchestrate taking something offline long enough to change configuration settings and the like to refer to the new environment.  And it's rarely easy to ensure that all the little "bits" out there get redirected to the correct server.
How Does a CNAME Help?
Again, the CNAME is an alias - and it's all in how you use it.  In our environment, since we're not a very large shop, we tended to name our servers from a "hardware" point of view - PRISQL for example for our "primary" SQL Server.  Again, since we're a smaller shop, we only used the default instance.  It's great to map server software to hardware that way - if you're focused on managing the hardware infrastructure.  But if you need to manage the software infrastructure that uses that - and need to move some of it off that server and onto SECSQL... you're looking at manual labour.
Using CNAMEs allowed us to create a set of application-specific names for services, and map those to hardware resources.  For example, we have an application well call "3PS" that uses a Citrix server for remote access, an App server for the business layer heavy lifting, and it (of course) has a database on SQL Server.  Lets say that those three parts of the application resided on servers named CITRIX04, APP03, and PRISQL.  We created three CNAMEs for this system: 3PS-CTX, 3PS-APP, and 3PS-SQL, mapping them to the respective "physical" servers.  Once this was done, if we wanted to move the database to SECSQL, we could completely and easily do so by changing the CNAME alias instead of reworking vendor-specific configuration.
I don't know if it will help for you, but it sure did (and continues to) for us.