SharePoint is an Awesome Dev App Platform

In the last week I've read a blog posts about SharePoint as a development platform and scratched my head around some of the weak arguments.  Great comments by SharePoint MVPs, thanks AC and Spence.  Since then AC has done a post on his blog explaining that SharePoint is a *GOOD* development platform for applications.  He explains the dev experience which has some challenges and takes some getting use to, but stands up unparalelled as an application platform.  

Today I went to a briefing from MS IT not the traditional SharePoint IT team, but the business development team.  In Microsoft recently there were 2 CIOs.  One headed up the traditional IT hosted services for the company (was Ron Markezich).  The other heads up the business unit IT application needs (Stuart Scott). 

(Side note: Recent changes made Ron Markezich VP of Managed Services thus having him focus on the "hosting" of these commodity services of communication/collaboration.  Hosting being the key word.  It makes Ron and the whole team think about making these dial tone and focus on how Microsoft can turn around and host these same services for customers.) 

One of Stuart Scott's development teams has been tasked with taking 100 existing applications at Microsoft written on various .NET and existing ASP, web services and COM components and moving them to SharePoint.  Their goal is #1 to "simplify."  This simplification process comes from both the development, management/maintenance/operations, and reduce datacenter hosting footprint.  60 applications have already successfully been moved from various servers and services to now be built on top of SharePoint.  The majority of them were simply able to be moved directly into the vanilla commodity based service using SharePoint team sites and simply had customized lists and workflows created with SharePoint designer.  Others seen as high value were created and consolidated on hardware in the extranet space.

The question I had for this team was... "What is your evaluation process for building an app on SharePoint?"  I'm sure that's your question as well.  There quick answer was...

1) Is it highly transactional? If yes, then we won't immediately plan to put this on SharePoint

2) Does it need to write to a database? If yes, then if it can't simply be accomplished with a dataform or forms services then they wouldn't immediately consider it as a SharePoint application.

My thoughts...

1) Is it something that can be accomplished in a traditional SharePoint list or leverage a SharePoint list or web part?  Is it data that will be stored that needs to be in a presentation layer?  If it isn't highly relational and need to be rolled up in a transaction and the data looks and feels like data that you'd want to display in a list then I would consider it for SharePoint.

2) Does it line up with any of the pieces of the SharePoint pie?  Can you leverage existing functionality without haveing to rewrite.  (Do you really need to invent or reinvent the wheel?)  i.e. Do you need a Platform with Security (do you need security trimmed UI, extensible navigation, breadcrumbs, web parts, expose data from web services, AD or LDAP needs?), Is it Collaborative (team sharing, sharing files and information, list data, files, images, discussions, calendaring, contacts, site templates, surveys, blogs, wikis, need for RSS or exposed web services of data), Search (need to crawl data from various sources), Portal (dashboards, my sites, need to display reports, need to display data driven UI, departmental rollups, content rollups, etc...), Publishing and Content Management (WCM/ECM/RM/DM) (Design page layouts, master pages, navigation, content authoring and approval, management of documents, assetts and records.)  Then leveraging the enterprise features such as BDC connecting to existing datasets and searching, exposing, and leveraging this data in forms, lists, results, etc... Excel Services exposing of charts, spreadhsheets, etc... and reporting.  This is where you can really see some of the power of publishing from excel.  Business processes with workflows and forms have never been easier to do over the web and despite it being difficult at first to create workflows leveraging Windows Workflow Foundation exposed by WSS with visual studio, the frameworks, the rich interface is there for the users in Office and over the web.

3) Are you trying to save money on hardware and interested in accomplishing economies of scale with your SharePoint investment?  If hardware is not a factor you can much more quickly build a simple application on .NET and deploy it with .NET Nuke or the like.  PHP and or other solutions on IIS are quick and simple.  It's not necessarily simple to create SharePoint solutions, but from a business standpoint the payoff is in empowering the business to leverage the existing functionality in the box and building solutions on top of it when business requirements demand it.

Other thoughts from a note from Steve a SharePoint Ranger summarized... Does it need to store more than 5000 records/items in a day?  Then I might not put it in a single list and might put it in a separate db.

From a performance perspective do I need security, do I need security trimmed UI, does it need to be slim, mean and lean or does it need to be rich?  The richness is what you get in the box, and stripping it all down to the HTML at a page level and dropping the styles and CSS really abandons the richness of the platform.

</end of Steve comment>

As you can tell from these points it's about leveraging the existing functionality, it's about not having to reinvent the wheel, it about leveraging the deployment frameworks with solutions and features.  When you already have an existing SharePoint/Web operations team it's the economies of scale.  Hosting 100,000's of applications by a small SharePoint operations team in a single SharePoint farm isn't unrealistic.  You wouldn't want all those applications to be custom apps, but minimizing what needs to be built vs. using out of the box functionality is the power of the app.

There is an argument of buy vs. build.  In a previous company I use to work for the mantra was always FIRST evaluate what exists in an off the shelf application.  So first buy, if you can't buy then and only then would we build.  The idea that with SharePoint you can buy and then reuse, reuse, and continue to use the building blocks to not have to build from scratch and then maintain custom applications with separate support processes, separate operations practices for how to backup, how to operate, how to maintain, how to configure and manage... You establish these processes and you can establish your best practices and continue to reuse them accomplishing an amazing amount of economies of scale.

What SharePoint is NOT good for is building a simple component very quickly, not having any knowledge of development in SharePoint.  It's not all about building a "good" web part or building your fuctionality in a content viewer web part.  There is SOOO much more. 

It is still best practice to have a separate development environment from production, it is also a best practice to have these developers using source control and rolling up their rollout in a feature or solution deployment package for consistency and ease of deployment, configuration mangement, and/or quick removal.  I know a call for content in this area has been in high demand and this is I would also argue that a .NET developer today would need time to ramp up and learn some of these packaging techniques, learn the object model, get use to the visual studio projects for web parts, workflows, content design for layouts and master pages, and how features and solutions work here, learning what can quickly be accomplished with SharePoint designer and ramp up on the SDK.  This time to learn is an investment that is well worth the training, education, and will quickly pay off.  There are now over 50 books, and a bunch of training organizations from the Ted Pattison group, SharePoint Experts, Mindsharp, U2U, Combined Knowledge, and the various other training organizations... there is some awesome training for developers and it will make you more valuable to the business and be able to make more $$.  From the business perspective it's the off the shelf value and about saving money by minimizing the necessary development effort.

The argument about it being difficult or it not running on Vista is worth looking at for the Microsoft dev tools team that focuses on making it easy to develop on SharePoint and I see some of the argument, but my argument for taking the plunge and becoming a true SharePoint dev... the value is in the platform.  Value is in reuse of what's already there, and that's where you find of the 200-400 out of the box, easy to use features depending on your SKU that there is a whole TON of functionality and adding on a bit of your own in an easy to use application is VERY powerful.