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
Dimensions:
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.
Dimensions:
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
Dimensions:
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
Dimensions:
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.