Author explains some of the perceived shortcomings of TFS and what solutions exist that can eventually replace the functionality of TFS. Basic premise is that TFS is a tool that promises to do everything, but in actuality does it all poorly (and doesn't talk to anything else).
With TFS, the product manager can create work items. The architect or developer can create tasks. A project manager can sync these tasks into a Microsoft project file and prepare a schedule. This schedule can be uploaded back into the team system. The tester can create test cases against the requirements. The test results can be recorded in TFS either manually or using Test manager. Loads of reports can be created from TFS like progress of the project, and quality of the product.
As a version control system, it has a few shortcomings. But, there are work-arounds to them. There are various tools that are built around TFS. One of them is TFS Shell extensions. This allows TFS to work more like SVN. If you do not like TFS integration from Visual Studio, you could use TFS Shell extensions.
I do agree that a lot of training is involved in getting to understand TFS. Also, most organizations do not like TFS because of Vendor lock-in or they already have existing systems to do requirements management, test management etc.
If the organization is working on Microsoft .Net technologies alone, TFS is the way to go.
If TFS is down, it is not possible to unbind the solution from the source control. So, the previous comment from me was a mistake.
If TFS is deployed within the intranet environment, it will hardly go down unless there is a planned maintenance. In the case of maintenance, the developer will be notified well in advanced. In case of server restarts, there will be a loss of availability. Bringing TFS online after the restart hardly takes a second.
If availability is a concern, (and for some reason, TFS server has to be maintained continuously), the integration with TFS should be done in an offline mode. Developers should have a clone of the TFS source (just like SVN). The working project should be a different one. And check-out/in should be done whenever required.
Thanks for doing the research on this, in my mind it justifies my choice to stick with distributed source control solutions.