Explaining the "SharePoint Application Platform" to novices...

Since the first betas of SharePoint 2007 I have read a lot about the power and the characteristics of SharePoint as an application platform. More that two years ago, for example, I have found this post by Andrew Connell; for my learning ramp-up on this technology, the concepts described by Andrew helped me a lot in understanding the advantages of SharePoint as an application platform!

Recently I had the chance to present the same subject to an audience composed by IT professionals and developers that was mainly neophyte about the SharePoint technology. Now that the technology is evolving, with the advent of SharePoint 2010, Visual Studio 2010, SharePoint Designer 2010 and Office 2010, I have had new impressive set of arguments to explain why it is worth to consider designing and developing a business solution "inside SharePoint". 

Here below I show a few graphical slides that I have designed and shown to my audience during my speech.

This first slide shows the components that can be used as "bricks" for developing a custom application in a SharePoint execution environment.

 

The list of components here shown is not exaustive and is relative mainly to a SharePoint 2007 environment. SharePoint 2010 updates many of them and adds a bunch of new components to the list.

The sense of this slide is to highlight how many additional "bricks" are available when developing for a SharePoint execution environment, instead of for a pure ASP.NET execution environment; for example, how great is the value to have an already well-designed, well-documented and ready-to-use "security model"? 

The slide below shows an architectural view of an application solution hosted in a SharePoint infrastructure.

 

Please note that the list of "type of assets" shown and grouped on the slide is not exaustive and that it is relative to a SharePoint 2007 environment. SharePoint 2010 updates many of them and adds a bunch of new types to the list.

SharePoint offers "out-of-the-box" many different implementation of each of those assets. A custom application solution can be designed as a composition (mix) of those "out-of-the-box" assets and custom developed assets (mainly of the types here listed).

Some of these "out-of-the box" assets can be highly customized using Office tools like SharePoint Designer, InfoPath or Access; it is worth to verify if such a fast and cheap (but also always somehow "partial") customization is suited for the business needs driving the solution implementation. The same tools can be used to allow a light post-deployment customization also to the same custom developed assets (if they were built with this possibility in mind), giving a lot of power to personalize and optimize the final solution for each business need.

The following slide gives a graphical representation of the concept yous espressed, by showing how a "custom solution" built into a SharePoint environment can be a mix of "out-of-the-box assets" and "custom assets" . The trade-off is between the need of a fully-custom beahvior and the need of a cheap and fast implementation.

The following slide shows the three implementation scenarios for the assets of an "application solution" hosted in a SharePoint 2007 environment:

The three scenarios can be quickly described in these terms:

• no need of custom implementation: the specific asset is already available as an "out-of-the-box" functionality; can be accessed by the end-user through an Internet browser or an Office program;
• simple custom development: the specific asset can be developed by "power users" using Office tools like "SharePoint Designer 2007" (e.g.: a custom workflow) and "Access 2007" (e.g.: a set of relationed "linked tables" published as SharePoint Lists)
• complex custom development: the specific asset requires an implementation realized by using the full customization power of Visual Studio (for any type of SharePoint asset) and/or Expression (for Silverlight applications hosted into SharePoint pages).

The following slide shows the same three implementation scenarios for the assets of an "application solution" hosted in a SharePoint 2010 environment:

The sense of the three scenarios is almost the same explained above:

• no need of custom implementation: the specific asset is already available as an "out-of-the-box" functionality; can be accessed by the end-user through an Internet browser or an Office program;
• simple custom development: the specific asset can be developed by "power users" using Office tools like "SharePoint Designer 2010" (e.g.: a custom workflow) and "Access 2010" (e.g.: a set of relationed "linked tables"  published as SharePoint Lists, with the addition of custom "navigation controls", "data-macros", "reports" and "forms")
• complex custom development: the specific asset requires an implementation realized by using the full customization power of Visual Studio (for any type of SharePoint asset) and/or Expression (for Silverlight applications hosted into SharePoint pages).

Please note that a new possibility is available with SharePoint 2010 in comparison to SharePoint 2007: the developers are finally allowed to "post" custom developed assets throught the web, thanks to the new "Sandeboxed solution" support in the 2010 platform. This mechanism allows a much wider customization power to the remote developers, while allowing the IT departments to maintain a full control on the execution environment. For example, this can be a fantastic new possibility in the scenario of a remotely-hosted environment, where the developers normally were not allowed to publish any kind of custom asset requiring a deployment through a physical login on the SharePoint servers. Another big step made by the SharePoint technology for breaking the paradox often setting the business users - requiring empowerment - against the IT staff - claiming the need of control...