Geeks With Blogs
Thorvald Bøe

I want a discussion on SharePoint architecture in an enterprise scenario. What is the way to go?


SharePoint 2016 has been announced as the last version for OnPrem, and even if OnPrem is far from dead, SharePoint Online seems to be the investment focus for MS, so let's focus on this.


SharePoint Online is a great product, but it has its limitations. Farm solutions are not allowed, and while coded sandboxed solutions still work, they are classified as deprecated and might not be supported any time soon.


In the mean time, MS is pushing their app model, along with their fairly new Office 365 API, aspiring to become a major piece in a SP architect's tool belt.


So, back to the topic - SharePoint (Online) architecture in an enterprise scenario. What are the characteristics?


Each scenario is different, but typically you will have to consider at least these aspects:

1.Supporting business requirements with SharePoint components

2.Integration of legacy systems

3.Mobile access

4.Security and permissions



Together, these aspects each form a dimension in the architectural space, while contributing an immense level of complexion if the requirement is to support all dimensions at once.


One example:

Task: Build a simple project management collaboration tool to be able to manage projects in your organization, providing a list of projects and a workspace (sub site) for each project


This should be ideal for SharePoint, after all it's all about collaboration. So how do you do it?


In the old world:

Approach 0 - Farm solution/OnPrem


1.Ok - standard sharepoint components

2.Ok - retrieve data from legacy systems either within farm solution or by db integration

3.Ok - mobile forms or customized web forms, or even app

4.Ok - full trust farm solution handles permissions and assigns necessary permissions


In the new world:

Approach 1: Use standard SharePoint customizations, lists, workflows etc.


1.OK - use a list for the projects,

2.Limited - use external content type to retrieve external data

3.Limited - limited to mobile forms

4.Not ok - no way to set granular permissions except manually


Approach 2: SharePoint hosted app


1.Ok - build a contained app to support whatever needs you have.

2.Limited: data resides within the app web, no way to access from external application. Can use remote endpoints to retrieve external data ad-hoc. Can put data in hostweb, but that would also fragment your app into two solutions.

3.Limited: Browser based mobile forms

4.Not ok: No way to set granular permissions


Approach 3: Provider hosted app


1.Ok - build whatever you like, although you need a hosting environment

2.Ok - handle integrations from within the app. Provide separate API for external integrations

3.Ok - build whatever you like in the app

4.Ok - set granular permissions from inside the app


Approach 4: O365 API

1.Ok - build your own web app, use SP Online as backend

2.Ok - host your own integration logic

3.Ok - build whatever you like

4.Probably ok - depending on your setup, you could have permission logic using a privileged user to set granular permissions


From this, it seems that both approach #1 and #2 fails miserably, while #3 and #4 seems to hold up.


This makes me very worried, because #1 and possibly #2, would represent the easy way out for many companies. #1 in particular has traditioinally represented the inherent value of using SharePoint in the first place - since you can so easily create new lists, library and workflows to support your needs. Not only as an IT pro, but as a super user or even a regular user. So if we would introduce a 5th dimension of user adoption simplicity, #3 and #4 would definately fail, since developing provider hosted apps or using O365 API requires significant skills.


#3 and #4 are also passing the test mainly because it is more a 'build whatever you like and then connect it to SharePoint' approach. So yes, you can build anything you like and support anything you like, but you have to build it all yourself. So what is then the benefit of using SharePoint at all? I seriously doubt that having a few document libraries or lists in the other end justifies running SharePoint licenses and a potentially huge budget for a provider hosted app. There are other (and free) tools for that.


So, how would you go about supporting enterprise needs in your organisation or for your customer?


Is the provider hosted app/O365 api approach easy to sell to customers?


I am no advocat for farm solutions, they definitely have their problems. But I fail to see how Microsoft has provided us with an alternative, while still being able to benefit from the great possibilities that SharePoint has traditionally given us by providing easy-to-do customizations on top of full trust farm solutions.

Posted on Monday, February 16, 2015 12:14 PM sharepoint , architecture , sharepoint app , o365 api | Back to top

Comments on this post: SharePoint architecture in an enterprise scenario

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Thorvald Bøe | Powered by: