SharePoint P roduct Re
architected
in SharePoint 2013
401 - 408 , A - Wing, Pride Silicon Plaza, , S.B. Road, Shivajinagar, Pune - 411006 , Maharashtra, INDIA Email: [email protected] Tel: +91 - 20 - 41020202
Global Delivery Centre:
Objective We are all excited with the prospect of SharePoint 2013 hitting the market. There are many
expectations from the product. Nitor, with help from Microsoft got its Architects and developers
trained on SharePoint 2013. It was so overwhelming that we decided to migrate a product
developed on SharePoint 2010 to the 2013 version. This is an Architect’s analysis on various
considerations and approaches of migrating a SharePoint 2010 based product to SharePoint
2013.The outcome and the process of migration itself were very refreshing since we discovered
many things which a training program could not bring in. The outcome was the combination of
structured learning, research on best practices and platform centric deployment. This white paper
is aimed at organizations who want to migrate their workflow centric products from SharePoint
2010 to 2013 platform.
General Considerations on migrating/re-architecting SharePoint platform based product Before we get into the specifics of how to migrate from 2010 to 2013 it is important to review below
mentioned considerations or pointers that can help in strategizing the SharePoint based product
migration.
Capabilities A thorough analysis on new feature improvements and features deprecated will give better insights
on the effort and approach required to migrate the product on the new SharePoint platform. It can
even happen so that some part of the product which had heavy customization can be made
redundant by new out-of-box feature introduced. Hence it becomes more relevant to leverage this
new feature and have customizations on top of it to meet product requirements rather than
competing the out-of-box feature. New improvements in SP 2013 can be found at:
http://technet.microsoft.com/en-us/sharepoint/fp142374.aspx
Scalability If the product relies on storing data in SharePoint, it would be good to understand the SharePoint
boundary limits. Based on these boundary limits the product architecture needs to be revisited and
validated. SharePoint 2013 boundary limits can be found at: http://technet.microsoft.com/en-
us/library/cc262787(v=office.15).aspx
End User experience The Product UI experience in most of the cases should be complement to that of the underlying
SharePoint UI experience and cannot be designed to give different look and feel unless the product
is meant to replace SharePoint UI experience. So if SharePoint 2010 based products has ribbon
based Office look and feel approach, SP 2013 based products would require to have metro style
UI.
e.g.: Consider a DMS product built on top of SharePoint meant to leverage existing SharePoint
DMS features and at the same time add various other features to it would require to add command
options to the document for the new features. This command options has to have similar look and
feel as that of out-of-box SharePoint command options for better user adaptability.
To understand more about SP 2013 branding, please refer:
http://technet.microsoft.com/en-us/sharepoint/fp142374.aspx#Branding
External tools and device integration Since SharePoint is a collaboration platform, the users would rely on their day to day productivity tools
such as outlook and mobile to do collaboration with SharePoint. With the new
SharePoint platform providing improvements in areas such as Mobile, it isn’t a lot of work to get SharePoint content on to mobile. For e.g.: the new improvements in SP 2013 makes user to view BI reports on mobile devices as well without much efforts. Understanding and leveraging these features can add value to the product.
Similarly the new Office 2013 App model (please refer
http://msdn.microsoft.com/enus/office/apps/fp160950.aspx) can be leveraged to build office Apps
(outlook, word and excel) which can integrate data from SharePoint using Oauth to give a better
collaboration aspect to the software. Also these Office Apps can be deployed to SharePoint online
easily.
Deployment Strategy – On-premise vs. Cloud version Traditionally the SharePoint based products were developed as on-premise products. Onpremise
products come with planning around various governance related issues. SharePoint 2010
introduced new Sandbox solution capability to have a solution building approach which will not
have to worry about governance related issues and at the same time helps developers deploy
customization on the SharePoint online, however this approach has lot of limitations in terms of
customization possible.
With Office365 SharePoint Online getting mature with every release, it makes lot of sense for
Product companies to have a Cloud variant of their product. Office 365 SharePoint 2013 is having
a new Cloud app model which supports deploying of products on to SharePoint online via App
market and has lesser limitations compared to earlier version of SharePoint online. With office App
model, the office app’s can be built for deploying in SharePoint online as well.
Security The product developed needs to support all the authentication types supported by SharePoint
which includes Windows, Forms based authentication and Claims based authentication and
identity. More on SharePoint 2013 security can be found at:
http://msdn.microsoft.com/en-us/library/ms457529(v=office.15).aspx
API requirements With new version of platform newer set of API’s are available for working with SharePoint data.
SP 2013 API set includes server object model, client object model and REST/OData web service.
For more information on SP 2013 API set, please refer: http://msdn.microsoft.com/en-
us/library/jj164060(v=office.15).aspx
Up gradation strategy Any architecture planning should involve considering the up gradation strategy. Up gradation can
involve the solution upgrade, underlying data schema changes (e.g.: List structure change) and
UI related changes. Things can get complicated if the solution is designed multitenant way.
Applicability of the above mentioned considerations for the product in question
Sr.No Considerations Pointers Pointers w.r.t SP 2013
1 Capabilities New platform
features that
can be
leveraged to
add value to
product
Various new improvements available which can be leveraged,
please look at
http://technet.microsoft.com/enus/sharepoint/fp142374.aspx
for complete list of new improvements
2 Scalability Boundary
limits need to
be analyzed
carefully to
make sure
product
architecture
meets
performance
requirements.
Boundary limits for SP 2013 can be understood at
http://technet.microsoft.com/enus/library/cc262787(v=office.15)
.aspx
3 End-user
experience
Since the
product is
built on top of
SharePoint
the user
experience
should be
similar to
SharePoint,
means
product UI
should adapt
SharePoint UI
as much as
possible.
SP 2013 UI and branding related articles can be found at:
http://technet.microsoft.com/enus/sharepoint/fp142374.aspx#B
randing
4 External Tools
and device
integration
Product built
around
collaboration
space would
always
demand
integration
with external
productivity
tools such as
mobile,
outlook and
other office
tools.
One of the key new improvements in SP 2013 is around Mobile
which allows BI reports to be viewed on mobile devices with out-
of-box effort.
These
integration
requirements
can be
leveraged
out-of-box to
great extent.
Also the new Office App model
(http://msdn.microsoft.com/enus/office/apps/fp160950.aspx)
we can build office app’s integrated with SharePoint much
better than before.
5 Deployment
Strategy – on
premise vs.
Cloud version
Architecture
planning so
as to have
one version
of product
which can be
deployed on
premise as
well on cloud.
SP 2013 cloud all model
(http://msdn.microsoft.com/enus/library/fp179930(v=office.15)
.aspx) can be leveraged to build products using HTML,
JavaScript and OAuth which can be easily deployable in
onpremise and cloud.
6 Security The product
developed
needs to
support all the
authentication
types
supported by
SharePoint
which
includes
Windows,
Forms based
authentication
and Claims
based
authentication
and identity.
Understanding about
SharePoint 2013 security can be found at:
http://msdn.microsoft.com/enus/library/ms457529(v=office.15
).aspx
7 API
requirements
API set
available with
SharePoint
platform
needs to be
carefully
studied and
understood.
This will
help
Architect’s
design
applications
better.
SP 2013 API set includes server object model, client object
model and REST/OData web service providing Architect
various options in re-designing the application. For more
information on SP 2013 API set, please refer:
http://msdn.microsoft.com/enus/library/jj164060(v=office.15).
aspx
8 Up
gradatio
n
Any
architecture
planning
should
With SP 2013, depending upon
strategy involve
considering
the up
gradation
strategy. Up
gradation can
involve the
solution
upgrade,
underlying
data schema
changes
(e.g.: List
structure
change) and
UI related
changes.
Things can
get
complicated if
the solution is
designed
multitenant
way.
the product built as Farm solution or App way the up gradation
strategy needs to be planned. Solution upgrade, List schema
changes and branding updates for the much of the up gradation
task most of the time.
Analyzing the various possible various approaches in migrating product from SP 2010 to SP 2013
Farm Solution migration from SP 2010 based to SP 2013 as it is This approach is best suited when the product is packaged as Farm solution and targeted as on-
premise product with clearly mentioned SLA as to what governance related changes needs to be
done in the target farm.
Considering the SP 2010 based product developed as Farm solution, the easiest and less
expensive approach to migrate or have this ready in SP 2013 is to recompile it into SP 2013 Farm
solution. High level tasks involved in this would be (some or all can be applicable):
• Identify the part of the solution which is deprecated in SP 2013, if any found plan for rewriting in
the new version.
• Recompiling the code using SP 2013 version of SharePoint dll’s
• Plan for changing the UI experience of the product to meet that of 2013.
• Plan for mobile integration using new capabilities in SP 2013 if applicable
• Any office component which is used as extension to this product can be re-written using new
Office App model or have the earlier versions re-compiled into new version.
Pros 1. Faster and less expensive approach, so time to market is low
2. Lot of code base gets re-used
3. Best approach if the core product features are somewhat tightly coupled with SharePoint’s core
features.
Cons 1. All the governance related issues get inherited.
2. Cannot have a SharePoint online version of the product
Sand box solution re-writing to SP 2013 based App Model This approach is best suited when the product is originally packaged as Sandbox solution and is
intended to be deployed on-premise as well as on the cloud without having to worry about 2
versions of same product. SharePoint 2010 sandbox has lot of limitations in terms of amount of
customization possible, and the limitations varied between on-premise and SharePoint online
version as well. As a result Sandbox solutions are generally not a popular approach of
development. With introduction of SharePoint 2013 Cloud App model (refer
http://msdn.microsoft.com/en-us/library/jj163091(v=office.15).aspx), building one version of
product (the App way) which can go with on-premise as well cloud is possible and at the same
time can leverage SharePoint store and App catalog for delivering the App. Note: This will have to
be build using JavaScript and HTML and no server code possible. High level tasks involved in this
are:
• Re-design the entire product architecture the App way.
• Re-plan the UI to meet SP 2013 user experience.
• Any office component which is used as extension to this product can be re-written using new Office App model or have the earlier versions re-compiled into new version.
Pros One code base multiple deployment targets (on-premise and cloud)
Cons 1. Needs complete re-writing of product into App model, so time to market is high
2. Having a mobile extension or office app is easier as lot of HTML and JavaScript code will be
available for re-use.
Farm solution re-writing to SP 2013 based App Model (partial or complete) This approach is best suited when the product is packaged as Farm solution and has fewer
modules tightly coupled with SharePoint core features and also wants to have a Cloud variant of
the same. High level tasks involved in this are:
• Identify the modules which are tightly coupled with SharePoint features and the ones which are
not new Office App model.
• Re-design the modules which are not tightly coupled with SharePoint features the App way.
• Validate the complete architecture with respect to on-premise deployment and Cloud
deployment.
• Re-plan the UI to meet SP 2013 user experience.
• Any office component which is used as extension to this product can be re-written using new
Office App model.
Pros 1. One code base multiple deployment targets (on-premise and cloud)
2. Time to market is high
Cons 1. Needs complete re-writing of the product into App model
2. Having a mobile extension or office app is easier as lot of HTML and JavaScript code will be
available for re-use.
Case Study: SP 2010 based product re-architected on SP 2013
This case study talks about how Nitor architecture team re-architected a SP 2010 based product to
SP 2013 along with leveraging new features of SP 2013.
Product Overview A HR recruitment portal based on SP 2010 was built to meet the requirements of HR team and to
automate the recruitment process which involved multiple workflows and multiple touch points with
various department members. Collaboration becomes key requirement here as the HR team and
the department users sit at different locations/offices most of the time. This product has below high
level process:
Product Architecture in SP 2010
This product was built on SP 2010 as Farm solution. On a high level this was developed as a
site definition with SharePoint lists, complex workflows and web parts packaged as
features. It had a mobile extension so that managers could do quick actions on field such as
viewing interview schedule and updating results of interview.
Product Architecture in SP 2013
Business decision was taken to have this product’s 2013 version to incorporate and leverage SP
2013 new features and also to look at being able to deploy onto SharePoint online. Nitor’s
architecture team chose to use the approach of re-writing complete Farm solution to the new
App model way as the features of the product weren’t tightly couples with SharePoint core
features. At the same time new office app model was also considered to build Outlook App
so that HR and managers team can update the workflow right from their inbox.
Consider one of the scenario’s in the process where manager wants to notify the HR about need
to have a new recruitment: Manager sends a mail to HR asking for new recruitment. HR manager
whens receives the mail would want to initiate process of recruitment by entering data into the
recruitment portal (which means login into the SharePoint portal and add recruitment details in
some module of the application). With the new outlook app the HR personal can simply open the
app as shown below and creates a new position as asked for without having to login into the
SharePoint portal.
Conclusion Product migration from SharePoint 2010 to 2013 needs to be planned well with considering various
aspects such as new capabilities present in SP 2013, scalability issues, security, end user
experience, deployment strategy and up gradation strategy. The new features in SP 2013 such as
mobile support, social computing improvements, BI related improvements and web content
management improvements if studied well can be used to add value to the existing architecture of
the product. Further with new Cloud App model it is possible to have entire (or partial) product to
be re-architected in such a way that it can be deployed in office365 SharePoint online as well. This
re-architecting approach will give value addition to the product from extensibility and multi-platform
deployment perspective.