+ All Categories
Home > Documents > SharePoint P - Nitor Infotech · SharePoint 2010 sandbox has lot of limitations in terms of amount...

SharePoint P - Nitor Infotech · SharePoint 2010 sandbox has lot of limitations in terms of amount...

Date post: 26-Aug-2020
Category:
Upload: others
View: 3 times
Download: 0 times
Share this document with a friend
18
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:
Transcript
Page 1: SharePoint P - Nitor Infotech · SharePoint 2010 sandbox has lot of limitations in terms of amount of customization possible, and the limitations varied between on-premise and SharePoint

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:

Page 2: SharePoint P - Nitor Infotech · SharePoint 2010 sandbox has lot of limitations in terms of amount of customization possible, and the limitations varied between on-premise and SharePoint

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.

Page 3: SharePoint P - Nitor Infotech · SharePoint 2010 sandbox has lot of limitations in terms of amount of customization possible, and the limitations varied between on-premise and SharePoint

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

Page 4: SharePoint P - Nitor Infotech · SharePoint 2010 sandbox has lot of limitations in terms of amount of customization possible, and the limitations varied between on-premise and SharePoint

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

Page 5: SharePoint P - Nitor Infotech · SharePoint 2010 sandbox has lot of limitations in terms of amount of customization possible, and the limitations varied between on-premise and SharePoint

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

Page 6: SharePoint P - Nitor Infotech · SharePoint 2010 sandbox has lot of limitations in terms of amount of customization possible, and the limitations varied between on-premise and SharePoint

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

Page 7: SharePoint P - Nitor Infotech · SharePoint 2010 sandbox has lot of limitations in terms of amount of customization possible, and the limitations varied between on-premise and SharePoint

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.

Page 8: SharePoint P - Nitor Infotech · SharePoint 2010 sandbox has lot of limitations in terms of amount of customization possible, and the limitations varied between on-premise and SharePoint

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

Page 9: SharePoint P - Nitor Infotech · SharePoint 2010 sandbox has lot of limitations in terms of amount of customization possible, and the limitations varied between on-premise and SharePoint

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

Page 10: SharePoint P - Nitor Infotech · SharePoint 2010 sandbox has lot of limitations in terms of amount of customization possible, and the limitations varied between on-premise and SharePoint

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.

Page 11: SharePoint P - Nitor Infotech · SharePoint 2010 sandbox has lot of limitations in terms of amount of customization possible, and the limitations varied between on-premise and SharePoint

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

Page 12: SharePoint P - Nitor Infotech · SharePoint 2010 sandbox has lot of limitations in terms of amount of customization possible, and the limitations varied between on-premise and SharePoint

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

Page 13: SharePoint P - Nitor Infotech · SharePoint 2010 sandbox has lot of limitations in terms of amount of customization possible, and the limitations varied between on-premise and SharePoint

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:

Page 14: SharePoint P - Nitor Infotech · SharePoint 2010 sandbox has lot of limitations in terms of amount of customization possible, and the limitations varied between on-premise and SharePoint

Product Architecture in SP 2010

Page 15: SharePoint P - Nitor Infotech · SharePoint 2010 sandbox has lot of limitations in terms of amount of customization possible, and the limitations varied between on-premise and SharePoint

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

Page 16: SharePoint P - Nitor Infotech · SharePoint 2010 sandbox has lot of limitations in terms of amount of customization possible, and the limitations varied between on-premise and SharePoint

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.

Page 17: SharePoint P - Nitor Infotech · SharePoint 2010 sandbox has lot of limitations in terms of amount of customization possible, and the limitations varied between on-premise and SharePoint

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.

Page 18: SharePoint P - Nitor Infotech · SharePoint 2010 sandbox has lot of limitations in terms of amount of customization possible, and the limitations varied between on-premise and SharePoint

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.


Recommended