Solution Architecture - To SharePoint or Not to SharePoint

You are architecting a web based software solution and are considering custom development (Asp.Net and SQL) or SharePoint list and library based architecture.  You can decide based on the following list of SharePoint pros and cons.  If you can pick 3 or 4 items (or 1 very important item) from the Pro list and are aware of the items in the cons list, it is likely beneficial to use SharePoint.

• Pros
• Authentication, authorization, and membership - Claims, forms, AD, LDAP, and custom
• Security trimming throughout the product - Very important
• Document and content management
• If you plan to upload files, plan to use SharePoint - Very important
• Item Data
• Site, library, and list columns
• Managed metadata
• Customizable ad-hoc list and library views
• Search and Indexing
• Security trimmed - Very important
• Publishing, approval, versioning, and check outs
• Versioning - Very important
• Remember to turn these on where appropriate
• Navigation
• Security trimmed
• Dynamically populated
• Web content management - Sites, pages, wikis, blogs, and web parts.
• Recycle Bin - The big undo
• Email Alerts, RSS
• Integrated workflow and task engine - Pre-built Approval and Review workflows
• Retention policies, legal holds, and record management
• Email enabled libraries
• Unified user interface (Master pages, layouts, themes, and styles)
• Reporting integration
• Excel services
• Better with PowerPivot (SQL Enterprise or BI)
• SSRS
• MS Access
• PerformancePoint services
• External lists and external chart web part
• Using business connectivity services
• MySites (personal web sites) and user profiles
• MS Office integration
• Including Office Web Apps (with MS Office volume license)
• SharePoint Workspace for offline caching and synchronization
• Plethora of third party products and solutions
• Standardized skill-sets - by SharePoint focus
• Ex: Architect, developer, analyst, admin, designer, end-user, bi analyst, librarian, etc.
• Web Part Framework integration
• This is also available in ASP.Net, but does not have audience integration and requires some master page work and is not as flexible for reuse and customization by end-users.
• APIs: web services, client object model, sever object model, and PowerShell
• MS Support
• Load balanced, scalable architecture
• COTS - little to no coding required for many solutions
• Cons
• Relational support limited
• SharePoint supports lookups with referential integrity and reflected columns but does not support hierarchical/tree view and complex entity relationships without custom development
• SSRS does not allow you to query with a join or union
• System integration complexity
• Integrating and maintaining SharePoint and related applications in your environment can be complex and requires a professional to do correctly.  This can be mitigated by using a hosted SharePoint provider.  This admin level complexity is greatly outweighed by SharePoint's inherent functionality.
• Performance
• You can't optimize the performance as well as with a SQL database.  If your system is highly transactional, consider moving these pieces to SQL and front-ending in SharePoint
• New skill set to utilize fully
• SharePoint is still in the early stages of user adoption and training.  Many users will need to be trained to understand how best to use SharePoint.
• Storage hungry
• SharePoint solutions with document libraries can eat up disk space faster than a file share.  Make sure to plan SQL capacity and possibly Remote Blob Storage
• Wildfire effect
• If proper governance plans, quotas, IT professionals, and permissions aren't in-place, SharePoint training and support needs may surpass the IT department's ability to provide
• Initial cost
• Initial costs (server licenses and CALs) should be surpassed by reduced development costs and increased productivity. 
• Search Server 2010 Express (SharePoint Foundation 2010 w/ advanced search)  is available for low cost solutions.  This will not have all the features listed above.
• Not easy to synchronize functionality and content across distributed farms, sites, and lists
• If you plan to utilize site or list templates, you must have a plan to integrate new features into sites after they have been created.  Data migrations, schema changes, and feature additions must be addressed in a solution package or powershell script.
• Troubleshooting bugs and limitations
• The more you use SharePoint, the more you will run into its limitations and bugs.  Troubleshooting issues is usually not straightforward and requires SharePoint knowledgable IT staff and/or many hours on the support line.  Fortunately, limitations are very often overcome by community and third party products and are a google search away.  See the rest of my blog for many of these bugs, limitations, and workarounds.
• Easy to poorly architect a solution
• With great ease of implementation, comes incredibly horrible solutions
• Generally, do not:
• Use folders
• unless they are doc sets, email enabled folders, or OneNote sections
• folder level security and explorer view needs are a possible exception
• Copy/move documents unless you have a good reason
• Utilize in-place publishing, versioning, security, and filtered views whenever possible
• Overwrite the standard list/library CRUD forms
• you can add to the pages, just don't remove the dynamically generated form web part
• Try to use custom fields, third party products, or views to implement custom functionality within a column
• Use too many site collections
• Site collections isolate functionality.  Only split if you are sure there will be little crossover in SharePoint functionality.  Search will work across site collections.
• Use too many sites
• Sites should map to your main navigation, you don't want too many at each level
• The exception would be for dynamically generated templated sites, but you would need to implement code for instantiation, navigation, and disposal.
• Ex: Project sites and my sites.
• Use too many lists/libraries
• Items with similar metadata and security should be in the same library and separated by content type or metadata values.
• Develop a custom solution that can be addressed using native SharePoint functionality
• Generally, do:
• Have a seasoned SharePoint specialist gather requirements and architect a  solution
• This person should know all the dos and don'ts
• Use site content types and site columns
• Define site columns and content types at the lowest level site needed to encompass all sub-sites where they will be used
• When custom development is needed
• Use javascript, ajax, and jquery
• but not for security
• Use PowerShell for administrative functions
• Build SharePoint Designer workflows
• Build Visual Studio workflow actions
• Build Visual Web Parts
• Build EventHandlers
• Package and deploy visual studio solutions as a .wsp
• Be careful with performance on the above
• Dispose items properly
• Cache any collection references, don't use the index
• Ex: Don't use splist.items[x], instead use getitembyid or equivalent
• Perform user testing
• Use lookup lists and columns
• Performance testing
• Disaster recovery testing
• Backup plans are useless without successfully tested recovery plans