I strongly agree. I recently changed positions in one of those evil corporate monoliths to do exactly that - extract the critical requirements early in the project phase so the solution winds up being more than a new set of problems. That's simply the changing nature of the landscape - the technical folks from a few years ago who have good communication skills and a willingness to listen are in an excellent position to provide consultation. I can not emphasize enough the importance of this basic tenet: you must listen to what the client wants, and not assume you have the answer simply because you know apt-get. Understand their needs and come up with a solution that a) meets them as much as possible b) within the project scope and budget c) with as minimal an impact as possible to daily operations.Specalised applications are a pain in the neck to support, the real issue here is that who ever implemented them did not fully understand what the end user requirements were. There is a real art of extracting that sort of information out of people and it requires an inquiring mind, good communication and people skills. There are application houses that milk corporations of money due to scope changes because they couldn't get the original spec right
But if this is not what you want to do with your background in CS, then don't do it - there are an ever-increasing number of companies that do need things built from the ground up with serious attention to low-level detail: medical research facilities, geographic planning organizations, and metropolitan governments aren't going to find all they need on a shelf somewhere. They just don't post the positions on careerbuilder.com, so you have to pound on doors, wedge your foot inside, and make yourself indispensable.