Business Vs. Technical

This article at developer.* claims advice on the career path of a programmer. It suggests that the programmer needs to shift focus from technical to business specific knowledge.
Similarly, Bertrand Meyer from the esteemed ETH wrote in an IEEE Computer article, "make sure you know the business as well as the technology; that will set you apart from mere techies."

Both seem to guide the programmer away from engineering skills towards business skills. As a survival guide, my current experience seems to bear this out. The system I'm working on will be outsourced, but the business analysts will be retained. But I have a real problem with the former article especially. It's titled, "Career paths for Programmers," but IMO it should be titled "Why to give up Programming". This isn't career guidance for programmers who want to know how to make it as a programmer. This is advice for people who just want to make it, not caring how. Being a business analyst is nothing like being a programmer, generally speaking. I would never want to be a BA. Where I work, people with the BA title handle BA and QA, so it's kinda strange, but BA work in general couldn't possibly hold my attention; I would fail. There isn't anything related to problem solving or design in the BA's role. Further, I totally disagree with the quote in the article,

"he could train anyone in the technical skills he needed for a project, but finding those people with the necessary business skills to guide an IT project to success was something that could not easily be obtained".

I think the exact reverse is true. A person with good problem solving / design / logic skills either has such skills or not. They can be cultivated, but not acquired. Perhaps this person imagines a programmer / software engineer / developer as someone who just knows how to install and configure disparate technological tools. That would be a description of pure technical knowledge that anyone could learn, but programming isn't something you can just teach anyone.
Straight up business knowledge, on the other hand, could be stuffed into anyone's brain it seems to me. You can't train just anyone to be an actuary, but you can train anyone the details of your life insurance business and make them a BA.
I agree with the second article that the programmer who has the business knowledge is of more value, but this doesn't agree with the trend. I see what's happening to me as a trend; the software (technical) work is portioned out to those whose business is software. The particular business details are managed by BAs. So the software people know how to make good software. They don't devote themselves to business knowledge; they get that knowledge from BAs.
This seems natural to me. Now it may be that the software work may not have near the future that the strict business work will. But there's no way I'm going to morph into a BA. If I have to do something I hate, it surely won't be to fill my brain with details about Tonnage price of manila folders. I'd much rather be a sanitation engineer.

Outsourced!

Par for the course for code wannabe. But it is a good thing. After a brief search, I'd resigned myself to my current position for personal reasons; now I must get a better job.

The decision of my employer to outsource the system I maintain seems a no-brainer to me. I could speak all day about the flaws (despite the fact that it does, in fact, work). The most logical reasons are these

1) The system needed a re-write (as much as many of the current developers would disagree). It makes more sense to do it over with fresh blood.
2) The third party company already handles analogous systems for competitors. It's inevitable that we would follow suit so our customers (who are actually middle men) can come to a central location when comparing.
3) Most importantly, my employer's core business isn't software and the industry has somewhat of a reputation for crappy (mostly internal) software. It makes sense to keep the focus on those employees who deal directly with the core business and outsource software to a company who has software as it's core business.

Point #3 begs the question that I've heard (read) asked many times. How much of a focus on business knowledge (of a particular vertical market) should a code monkey devote, and how much on software development itself? Subject for another post.