I presented in local Finland TechDays 2012 details on one global SharePoint 2010 deployment, which I worked for the past 1.5 years in different roles from infrastructure architecture to actual customization design and implementation (I can’t keep my hands away from code). This deployment was based on large on-premises private cloud and services provided from the Office365-Dedicated. Public reference process is still on-going, but for the time being, we can’t publish any details on customer name, so presentation is using Contoso Corp as the company name.
Some key pointers and figures from the project
- 3 internal services from Office365 Dedicated: corporate communication intranet, my sites and collaboration sites
- Close to 10 individual internal services (SP applications) in on-premises
- Seamless user experience for end users cross the services – end users don’t care where things are hosted
- >10 Internet facing services in platform targeting for 99,999% availability
- 150 full time employees in overall project
- SP was one side of the project, also other interesting things were happening
- >500.000 lines of code and xml configurations for internal and external services
- Note thought that less code is less maintenance costs – so it’s not something to be proud of…
- Full ALM process with separate environments for different quality assurance purposes
- Daily builds and automated testing using TFS
- Unified SP platform designed to support ad-hoc changes for internal and external services–
- New external sites could be released in matter of hours with consistent branding and customizations – no need for large projects for each separate .com sites
- New business projects can concentrate on business requirements, not on platform – platform is provided for them as service from customer IT
- Platform to support truly customization re-use cross the services hosted in SP platform to minimize costs with future customizations
Wait – That seems quite complex deployment… why is that? – First rule for any SharePoint deployment is to keep things simple as possible based on requirements. Simplicity and avoiding complexity will degree overall costs of the deployment. In this particular deployment however there was business and technical requirements which drove the solution to this side. Project it self was complete success by providing simplicity as possible, yet achieving business critical requirements.
If you’re interested on the slides (in English), you can have a look on different architectural patterns from following presentation. I like drawing my stuff in PowerPoint and many these drawings came out quite nicely… Session was also recorded, but that’s in Finnish, or in my case it’s always Finglish.
Here’s also direct link if WebApp is having difficult day - http://sdrv.ms/yjeFiX
Teasers on slides
You’ll lose some due missing transcripts, so sorry for that…