Friday, June 6, 2014

When to use and not to use SharePoint

Introduction


SharePoint technology is adopted in many organizations and supported by IT due to it’s Out of the box features and its Integration with other systems. Although we can do everything in SharePoint because of its rich features and support, we need to analyze and take a decision whether to use SharePoint or ASP.NET (Forms or MVC).

When to use SharePoint


If the new application requires more collaboration, less database intensive operations, BI, Publishing, Content & document management and adopts most of the SharePoint OOTB features (with less custom development), then SharePoint is the best choice.

Key features of SharePoint technology


1.    Collaboration
2.    Single Sign on
3.    BI Insight
a.    Reporting Service Integration
b.    PerformancePoint
c.    Excel services ( Power view, Power pivot, Power Map)
4.    Project Server Integration
5.    Office
a.    Web based access to the office applications
b.    Drag and drop from desktop to the platform
c.    Exchange Integration
d.    Improved notification
6.    Social Networking
7.    CMS Integration
8.    Advanced Search
9.    User profiles
10.  Business Process workflows with Workflow manager
11.  Business connectivity services (BCS)
12.  Security
13.  Mobile support (contemporary HTML5 view, Device channels, Office Web Apps Ux with touch support)
14.  OOBT Site columns, Content types, Page layouts, Master pages, Themes, Web parts and Workflows etc.
15.  OOBT Site templates (example Team site, publishing site etc.)
16.  OOBT Objects such as lists and document libraries (example Task list, Issue list, contacts list, picture library etc.)
17.  Document and Records Management. (Versioning, co-authoring, Retention policy, Barcode, Label, Audit etc.)
18.  WCM
a.    Cross site publishing
b.    Video and Embedding
c.    Image Rendition
d.    Clean URLs
e.    Variations and Content translation
f.     Metadata navigation
g.    Search Engine Optimization (SEO)
19.  SharePoint Store
20.  Cross browser functionality
21.  e-Discovery feature with e- Discovery center site templates.
22.  Publishing to Multiple formats (Intranet, Extranet, Internet, Mobile, Tablet)
23.  OData
24.  And much more.

When not to use SharePoint / When to consider ASP.NET


However there are certain circumstances we may not choose SharePoint and the better alternative is ASP.NET custom application development.
1.    Complex database: If the application uses RDBMS with many tables with relations and Indexes, It is better to go with traditional ASP.Net application. Although we can achieve the same database table structure in Sharepoint List and document library using lookup columns and Taxonomy, it is flexible and easy in SQL and traditional ASP.NET applications. In addition, creating OLAP cubes using Database tables, Creating BI reports and creating Indexes to fine-tune the BI report performances are easy. In simple words, SharePoint lists and libraries are not the correct substitute for Relational database.

2.    Database vs. SharePoint list: If your business logic requires transactions, storing data in a database is preferable to using lists. Also, SharePoint lists are meant to store simple data structures. If you require a complex data model with intricate relationships, a database is more appropriate.
Benefits
Database
SharePoint list
Handles complex data relationships
Yes
No
Handles large numbers of items
Yes
No
Handles transactions
Yes
No
Is easy to use
No
Yes
Accommodates workflows
No
Yes
Includes a standard interface
No
Yes
Can easily add binary data
No
Yes

3.    Administrator / IT Configurable UI Components: SharePoint webparts such as Announcements, Weather Information, Sales dashboard web parts are reusable in multiple pages across the multiple websites and required to create new pages and include the reusable web parts by Sharepoint administrators or site collection administrators. If such requirement is not required, we need to consider choosing traditional way.

4.    Branding: Sharepoint branding Implementation is comparatively time consuming than ASP.net and the end results not great especially in admin interfaces which have ribbon and breadcrumb. Ribbon and Breadcrumb design requires some styles customization, if we are using our custom branding (custom master page)

5.    Performance: SharePoint have an extra layer which translates CAML query to T-SQL and then it executes it. The SharePoint lists and document libraries have some extra overhead in accessing Data and have items boundary and over the limit SharePoint won’t support and have performance Issues. However Database table item storage boundaries are high and optimized according to our data volume.

6.    “Untouchable” Database: Microsoft strongly recommended not to touch the SharePoint content database and its objects, as the structures of the Sharepoint tables are not like normal application table structure.

7.    Time and Dev server hardware and software requirements: Developers normally use visual studio to build & deploy many times during the day, moreover the time spent for building & deploying a SharePoint solution is normally double or triple the time for a normal ASP.NET application. This will increase much more if the Developer machines have less than the Microsoft recommended hardware such as RAM, Processor and Free hard disk space.

8.    Complex knowledge platform: It requires a very advanced understanding of the complex concepts of ASP.NET, database & windows server like Active directory, PowerShell, Memory management, caching, hardware capabilities & networking.

9.    Deployment: Complex compared to ASP.NET, which require to copy DLLs (GAC or Bin directory) and a files in to a specific folders. A few SQL commands to add Tables, add Meta data etc. In SharePoint it is complex, and we need to prepare the solution and write PowerShell commands to add, upgrade, Activate solutions. In addition we need to activate the features in Farm, Site collection, Web levels. The deployment process also includes Metadata Import scripts, some manual and automated process.

10.  Estimation: Estimation is difficult and sometimes we can get a solution from codeplex for free and sometimes we need to develop from scratch. In addition, there are multiple ways in Sharepoint to get a required solution such add a list of contacts from a csv file to SharePoint list. This task can be achieved using Server object model (c#), CSOM, PowerShell script, SharePoint UI data entry (if the contact list is small).

11.  Administration: Backup and restore of ASP.Net application is simple and the administrator needs to take the backup Database related the application only, whereas in SharePoint we need to take the snapshot of the server and All the databases related to Site, Central admin, IIS configuration, Service applications etc.

12.  Full Control: Since SharePoint is a framework we can’t change certain features and needs a few workarounds to attain the solution. In case of ASP.Net application we have a full control over all the UI, Libraries, controls which we have created and we can modify and fix issues very easily and quickly.

Advice from Jeff Teper, Corporate Vice President SharePoint


  • Use SharePoint as an out-of-box application whenever possible - We designed the new SharePoint UI to be clean, simple and fast and work great out-of-box. We encourage you not to modify it which could add complexity, performance and upgradeability and to focus your energy on working with users and groups to understand how to use SharePoint to improve productivity and collaboration and identifying and promoting best practices in your organization.

  • Be thorough in custom web design, development and testing – We know many SharePoint sites are published portals or custom web apps and are excited about the new features we designed for these scenarios. We encourage you to review the new features and guidance to reduce the amount of custom work you need to do. But even there, code is code and we encourage you to validate your design early in your development cycle and with particular focus on peak usage performance testing for how your customizations impact HTTP and SQL Server roundtrips. We have guidance and page and object caching techniques that can help here.

Reference:



Other references:



SharePoint Performance and boundaries



No comments:

Post a Comment