Let me preface this post by saying that Roundedcube has a lot of Sitecore CMS implementations under our belt (we've actually lost count I think), but in the last year and a half we've been involved with a couple Sitecore Foundry implementations. We quickly realized that while the two products share a common foundation, developing a solution with Sitecore Foundry is a different beast than with Sitecore CMS. My hope is to share some of the most significant differences we've encountered to help you overcome the same issues in your solution development.
In case you don't already know, the Sitecore Foundry Solution is built for organizations having hundreds or even thousands of affiliated websites (i.e. franchises). Foundry allows these organizations to create and manage all of these websites with nearly the same effort as one while distributing the content editing to these affiliates and maintaining a centralized control of brand and strategy.
If you've worked with Sitecore Foundry in the past, it's important to first note there is a significant difference between Foundry 2.0 and Foundry 3.0. What we're discussing is 3.0, which is built on Sitecore 6 as opposed to 2.0, which was built on Sitecore 5.3.1. If you're familiar with Sitecore CMS, then you know that alone implies some significant differences and improvements.
Upgrading Website from Foundry Version 2 to Version 3
Let's first start with the prospect of upgrading an existing Foundry Solution from 2.0 to 3.0. For those of you who are familiar with the upgrade process for a Sitecore 5.3.1 instance to a Sitecore 6.x instance, the Foundry process is basically the same. The Sitecore Foundry upgrade process relies on the Sitecore CMS upgrade process but with a couple of extra steps. We recently used this process to upgrade an existing Foundry instance and encountered a few hurdles as lessons learned. One such lesson we learned is realizing that even though all of the security entities (users and roles) are upgraded, the new security domain for each site may not be configured correctly after an upgrade and will require some manual configuration. This issue prevented our content contributors from being able to log into the management area of the site to modify content. After properly setting up the required security roles and accounts manually for a Sitecore domain, our content contributors were able to login and manage their content again.
Page Editor vs. Content Editor
Since Foundry presents a totally different content management user experience - affiliate editors typically do not see the traditional Sitecore login page with Content Editor and Desktop options; rather they have a new login page that takes them directly to Page Editor mode. This presents a new perspective as it forces us as developers to make the Page Editor experience 100% user-friendly as you can't rely on the Content Editor UI. And overall, that's a good thing! The Page Editor is a valuable asset to the system overall. But it is something you must account for in effort, timeline and expectations. Depending on the intricacy of the website design, making everything editable via a rendering or UI control can be tricky. Several times we ran into JavaScript conflicts that only appeared once the HTML prototype provided by the design team was implemented into Sitecore. Significant pieces of code had to be re-worked to display correctly in edit mode.
Speaking of the editing experience, we found in several instances that we wanted to customize the Page Editor ribbon to optimize the editing experience. Fortunately, it was easier to add buttons (or "commands") and chunks to the Page Editor ribbon than it is to the Content Editor ribbon. Sitecore Foundry provides a nice option to add commands via a toolbar administration tree as opposed to adding directly to the Core database as you would with the CMS edition of the product. This also came in handy in terms of workflow since Foundry doesn't come with workflow enabled out-of-the-box. We were able to easily add workflow commands to the Page Editor ribbon as well as our new custom commands.
Security and Account Management
Sitecore's security changed drastically from Sitecore 5.3.1 to 6.1 by using the ASP.NET Membership Provider. In Foundry 2, which is based on Sitecore 5.3.1, users and roles were identified by the following convention "sitename.user" or "sitename.role." In version 3, it uses a new convention where each user/role actually has its own Sitecore domain to better separate security by site. This makes it easier to keep security confined to a domain architecturally and provide more separation...better organization.
We found these three areas (upgrading, use of page editor, security) to be the most noteworthy when getting acclimated to Sitecore Foundry. Sitecore Foundry is a very powerful solution, though still somewhat untapped in the marketplace so I hope this will be of help for those considering it as a solution for your organization. Recently, Roundedcube architected and developed a Foundry CMS solution for Feeding America and its network of over 200 food banks across the country. Since then, we've upgraded them to Foundry 3.0 and made some great enhancements to their solution. These new Sitecore Foundry 3 food bank websites are rolling our one-by-one throughout the year.
I'd love to hear about your experiences with Foundry as well - if there's an issue you solved another way or if you have any questions about anything I've mentioned here.
*EDIT October 28, 2010. We have moved our blog to http://blog.roundedcube.com and you can now comment on this specific post at http://www.roundedcube.com/WhatsNew/Blog/developing-with-sitecore-foundry-30-tips-for-success
