SharePoint 2013 Solution Type Diagram


Update May 16 2-2014:
A recent announcement by the Office 365 team just made our architectural decisions for SharePoint Apps a little bit easier. Although the program was in Preview and you couldn’t submit Autohosted Apps in the Office Store, it was still an option in some (or rare) cases. Not anymore: the Office 365 Autohosted Apps Preview program will end on June 30, 2014. While current Apps will not be affected for now, this path is no longer an option for new projects. For more information, see the: Office Blog.

I for one am glad to finally see some clear info on this and am curious to see how this evolves. Like the Office 365 team states in their post, I liked the goal of Autohosted apps: hassle free development experience for this type of solutions.
End update May 16 2-2014:

A couple of years ago I wrote this post about the Solution Type in SharePoint 2010. Since the introduction of SharePoint 2013 we now have the new App Model to consider so I thought it was time to create an updated version.

I use the Solution Type Diagram in my day to day decisions to get an idea on what kind of solution I would like to architect or at least start out with. Remember, as with every SharePoint project circumstances may differ and it always depends (J). So this is my version and you probably need to adapt it a little to suite your needs and your customer needs (your mileage may vary).


Let me walk through the considerations on this fairly simple chart:

Decision: “Just Artifacts?”

We all probably know by now that Microsoft has deprecated the Sandbox Solution model. But as MSDN states, this is true only for the use of custom managed code within the sandbox solution. If you just need to deploy SharePoint artifacts like lists, content types, images or JavaScript code Sandbox solutions are still a viable option and in fact not deprecated. More information on this subject can be found on MSDN:

So if we can stick with just declarative markup for deploying our SharePoint artifacts, the Sandbox solution is usually the fastest way to go. In all other cases it is not and we need to move further down the Solution Type diagram.

Decision: “CAM compatible?”

Compatible with the Cloud Application Model as Microsoft likes to call it (or App Model). So first you look at the technical side of the question. Can we deliver and meet the requirements with the Apps Model components. So we don’t need to deploy legacy stuff like Timer Jobs, Application Pages, etc. If we do, we could opt for separating these legacy bits and try to come up with a hybrid solution. But we also look at a more concept level. The Apps Model is pretty much intended for on demand installation, like picking an app from the store and have and end user install it him or herself. So if you have an Intranet Branding solution complete with My Site branding, an app might just not be the right delivery model. But if you have a collection of Web Parts an app is probably the right way to go.

My bottom line: Apps are intended for End Users, Full Trust and Sandbox solutions are for Administrators.

Since the App Model is new and still sort of version 1.0 there are a lot of caveats. Most of these are technical like the issues with apps published through Microsoft UAG. Or apps reading or writing lists on an anonymous Office 365 public facing internet site.

Decision: “Office 365?”

Do we target Office 365 or SharePoint Online? And I mean SharePoint Online or Office 365 multi-tenant (not the Office 365 dedicated version). And I tend to look a little bit further down the road with this one. So you might have customers asking for an on premise solution, but if you know the customer is considering or even evaluating O365 you might want to answer yes to this question. You don’t want to design a solution that could potentially block a customer from migrating to the cloud or implementing a hybrid environment.

The next couple of decisions are when we actually are compatible with the App model.

Decision: “Workflow, scheduled tasks?”

If we are just using HTML, CSS, JavaScript, local SharePoint lists and external data through REST a SharePoint Hosted App is probably what we are looking for. Remember, no Server Side Custom Code is available! If we do need things like custom workflow (or workflow behavior), scheduled tasks or remote/ app event receivers SharePoint Hosted is not an option and we need to move further down the diagram.

Decision: “Office 365?”

Again we look if we need to target SharePoint Online or Office 365. If we don’t, Auto Hosted is not an option and we need to go with a Provider Hosted app.

Decision: “Sell through the store?”

Do we need to sell through the Microsoft Store? This option is currently only available for SharePoint Hosted and Provider Hosted Apps. Auto Hosted Apps are not permitted in the store (yet). In that case you can of course opt to license, sell and distribute the app yourself.

So these decisions should eventually get you to a solution type:

Sandbox Solution (No Code Sandbox Solution) Still a viable option and O365 compatible
Sandbox Solution (with custom managed code) Deprecated, use with caution
Full Trust Solution Avoid if possible since it blocks customers from moving to the cloud
Apps The preferred solution model but watch out for technical and architectural caveats

And while you are at it, remember to check the availability of your choice if you are targeting Office 365 or SharePoint online. Luckily not much diversity there, although it never hurts to check if this has been changed. See TechNet for more information:

Developer features O365 Small Business O365 Midsize Business O365 Enterprise E*O365 Education A*

O365 Government G*

App Deployment: Autohosted Apps Yes Yes Yes
App Deployment: Cloud-Hosted Apps Yes Yes Yes
App Deployment: SharePoint-Hosted Apps Yes Yes Yes
Full-Trust Solutions No No No
REST API Yes Yes Yes
Sandboxed Solutions Yes Yes Yes


One comment

  • Awesome man!! Lol…. Love how we both seem to be thinking in “Workflow”…. 🙂

    Really nice way to explain things to management as well (They just love pictures, you noticed? 😉

    Really awesome blog man, it is helping me a lot in deciding which route our company should take when it comes to the MS SharePoint ALM and integrating with other teams using GIT but also keeping the best technology to support the methodology.

    What is your personal experience? We do a lot of custom dev, workflow, SAP integration, BCS, ECM……

    Thanks again Yuri!