First you should see the official word by viewing the webcast from MS:
Jean-Francois LeSaux, EPM Lead Architect, Microsoft Corporation, Project Server 2010 - Coexisting with SharePoint Server 2010.
Webcast Agenda:
- The Challenge
- Deployment Scenarios Pros and Cons
- Deployment Procedures
- Resources
Then I want you to consider these arguments:
Sure now Project is build on SharePoint Server Enterprise edition adding tons of value to the already existing service apps, BUT…
If you have Project as a service in your main farm you’re going to have to worry about 1) Licensing 2) Performance 3) Patching and the synchronization of the testing of patching of SharePoint Foundation
Licensing – It’s in the farm, but you can do different things for different web apps and even in tenant admin you can come up with some creative ideas. If you later change your mind it can be very tough to split sites that were based on project site templates. Some will want to do collab on standard license and run project on enterprise licenses. Another challenge.
If you’re going to be doing a collab farm I’d push you to put your project in a farm that’s focused on analytics and PMM type stuff. Will reduce the complexity and dependencies. Even though you can do fancy shmancy stuff in SharePoint 2010 with tenant admin the administration is in powershell and might be more complex than you think.
Performance – Project 2010 on top of the other dozen services is something to think about. Yes you can put it on it’s own app server(s) but if you’re doing that wouldn’t it be better as a service app that can be consumed by a web app that needs projects services? What about that template… You’ll have to think about that.
Patching – I am one to keep things clean. It’s one thing to run SharePoint Server Enterprise farm with Project and another to have a collab farm, portal farm, power pivot, performance point, and as an after thought throw project in the mix. It’s a lot to add to complexity and it’s the dependency that I’m thinking about here. Now you’re watching for the SharePoint Foundation patches, and the SharePoint Server Patches and the Project patches, and then there’s SQL and of course all those Windows ones, but the more you’ve got the more you have to be careful of. For small and medium business I have less of a problem here. It’s the enterprises that are turning it all on and then wondering why things are slow, and wondering why the patches are having issues and are having deeper longer sessions to troubleshoot.
Dependencies on upgrade… that’s worth it’s own consideration. Think about that one for a while. If one web app wants to be upgraded, but the project one isn’t. You’re waiting. There’s no coexistence in 2010… will there be in vNext?
My $.02
I did put a few thoughts together for 2007. While things have changed including all the service app stuff, I’m still reluctant to combine “the rest of the SharePoint content” with the “structured Project Content” in most cases. Curious to hear your thoughts.
More EPM Webcasts: