Project Server 2010 and SharePoint 2010: one farm or multiple?

[Update 11/30/2010 – another great reason to deploy it in a single farm is the ability to integrate Project Server web parts in other location within a farm, see this documentation on TechNet for more info. Plan for Project Server 2010 Web Parts]

Following a number of questions on this topic at Tech.Ed a few weeks ago and this recent post from Joel Oleson: Project Server 2010 and SharePoint 2010 Coexistence please find below my humble opinion on this question: Should Project Server 2010 be deployed in a standalone Farm or should it be deployed in an existing SharePoint Farm?

First lets start with an overview of the two deployment scenarios:

1. Together/Coexistence - Single farm with both Project Server and SharePoint Server 2010
2. Apart/Standalone - Dedicated Project Server Farm running SharePoint Server 2010

As a reminder please find the version compatibility below (see recent Tech.Ed presentation below); in a nutshell you cannot mix 2007/2010 version of Project Server and SharePoint:

So while mix scenarios are not supported, it is possible to go from 1 to 2 (Together to Apart) or the reverse from 2 to 1 as shown below

So back to the initial question, which scenario to choose (again there are plenty more pros and cons I have put together in these slides listed below), well it depends as listed below, but I would recommend a single farm for the following reasons:

Why Together (#1) in no particular order:

• Single Infrastructure: You can leverage the same infrastructure you have put in place for your farm, for instance lets say you have architected the farm for high availability on all tiers (redundancy/multiple servers at the Web Front End and Application tiers, and a SQL cluster for storage), why buy another set of hardware for a Project Web App (PWA) Farm and duplicate resources? Similarly why not apply software update, cumulative updates at the same time, why duplicate efforts across farms?
• Content Management: If you have two separate farm all the SharePoint content generated during the usage of Project Server (document artifacts etc…) cannot be stored in your main content management farm, hence you will duplicate your Enterprise Content Management efforts (governance, digital asset management, record management, etc…), similarly you cannot integrate PWA web parts across farms (we will publish an article this month on what PWA web parts can be integrate in different sites/pages of a Farm)…
• Project Server is a SharePoint App: yes it is and yes it’s not free! but since 2007 we have been build on SharePoint so again why a separate farm. As an anecdote since we are built SharePoint if you deploy Project Server in a standalone farm (scenario 2) you are effectively deploying a second SP Farm in your organization… The 2010 version has gone a long way in terms of scalability, stability/quality so why not deploy it in the same intranet farm according to documented best practices and as usual monitor it so you are always pro-active if issue arises or if the PWA is becoming resource constrained. So why start putting every Service App/Web App in separate Farms, isn't the power the consolidation from a IT and functional point of view?

While with the 2007 version most customer deployment I saw was about a 50/50 split between 1 and 2 (I did talk to a few customers that did not realized what they lost from a functional point of view by separating the farms and were looking for non-supported workaround); in 2010 with the tighter integration with SharePoint 2010 (the Business Intelligence/Reporting capabilities used by PWA or the Demand Management/Workflow capabilities to name a few) and the fact that organization want a consolidated infrastructure for Collaboration (whether its document management, performance management or project management) I would  strongly recommend option 1. To follow up on Joel’s arguments (yes this is a constructive argument and Joel and I know one another!):

• Licensing – one could argue that it could cost more to have two farms, if for instance you have redundant servers in both farms you will need to purchase more SharePoint Server licenses for instance. Additionally while its important to focus on acquisition cost, a more important vision is to look at Return On Investment, Total Cost of Ownership and measure the true value of a single/multiple farm over their lifespan. Again you will loose value and incur additional maintenance cost by going with two separate farms as mentioned above.
• Performance – well yes potentially but if you Farm has been architected properly by SP experts and if it’s monitored according to best practices then performance should not be an issue, typically the bottle neck at the end of the day is the database tier (SQL servers: CPU/RAM and disk I/O)
• Patching – yes but again there are two sides to this, you can argue that since Project Server Cumulative update are part of the SharePoint Server CU why not patch all at once instead of duplicate efforts?

So again think of the functional, technical, maintenance, licensing implication of deploying Project Server and SharePoint Server together or apart, thanks to Joel for starting the debate , in the end the great news whether you decide to go with 1 or 2 is that you can always reverse the decision as mentioned before. As with all my post feel free to send feedback and share your opinion. Happy Project Server 2010 and SharePoint 2010 deployment!

Resources on this subject:

• Project Server 2010 IT-Professional TechNet Webcasts see this webcast: TechNet Webcast: Project Server 2010 - Coexisting with SharePoint Server 2010, PowerPoint deck can be found here: Project Server 2010 IT-Professional Webcast Series slide presentations page – recorded webcast and deck
• Overview: Project Server 2010 with SharePoint Server 2010 Architecture – article
• Capacity planning in Project Server 2010 – white paper
• Tech.Ed Online Project Server 2010 and SharePoint 2010 Sessions – recorded session and deck
• EPM and Office SharePoint Server 2007 Coexistence — Intranet Scenario 2007 white paper still applicable to 2010