SharePoint Background

SharePoint is now in its fourth version. It has matured over the past decade since its first versions of SharePoint Team Services (STS) and SharePoint Portal Server (SPS) 2001.

It is amazing to see the vision that the early SharePoint team had and how they have come through to deliver on that vision.

To get a good glimpse of the product history, read Jeff Teper’s post on SharePoint History.  Jeff is the Corporate VP of SharePoint and he gives a good perspective on how the early vision of SharePoint has prevailed over the years.

As stated in the blog post, the strategy from the beginning has been:

• Great Integrated Solution
• Out-of-Box Web Workspace
• Compelling Office Integration
• Easy & Flexible Deployment

SharePoint, in the early days of its product lifecycle, was there for team and portal implementations as an application. True customizations were limited. Unlike subsequent versions of SharePoint, SharePoint Team Services (STS) and SharePoint Portal Server (SPS) did not completely share a common framework.

With the second version, Windows SharePoint Services (WSS) 2.0 and SPS 2003, a third party developer community began to form. This community was primarily focused on the gap between SharePoint features and the typical needs for team sites and portals. These products typically took form as components (like a web part) that would empower end users to put together lightweight applications. Also, the concept of mashing up data from sources inside and outside of SharePoint started to take shape. Outside of the development of Third Party Products, the developer community shied away from customization because the techniques for customization were typically fragile. For example, the ONET.XML had to be changed to make branding changes and the ONET.XML is a SharePoint system file which has the potential to be changed in service pack updates, overwriting the customizations. Also, the SharePoint technology stack was executing in parallel to ASP.NET runtime instead of being built directly on top of it (i.e., SharePoint had a separate ISAPI filter and did not run through the ASP.NET ISAPI filter).

Evolution of SharePoint’s Name

2001 • SharePoint Team Services • SharePoint Portal Server

2003 • Windows SharePoint Services v2 • SharePoint Portal Server2003

2007 • Windows SharePoint Services v3 • Microsoft Office SharePoint Server 2007

2010 • Microsoft SharePoint Foundation 2010 • Microsoft SharePoint Server 2010

With the release of WSS version 3 and Microsoft Office SharePoint Server (MOSS) 2007, a developer community for in-house developers and consultants started to form, while the third party developer community continued to expand rapidly. The extensibility story became richer and the viability of SharePoint as a Web application Development Platform emerged. The services available to build upon in SharePoint allowed for enhanced custom solution scenarios that could leverage Windows Workflow Foundation, Web Content Management (via the merge with Content Management Server),  and a rich Eventing Model and Search, to name just a few.

With SharePoint 2010, the names of the component products have changed. The successor to Windows SharePoint Services 3.0 is named Microsoft SharePoint Foundation 2010 and the next version of Microsoft Office SharePoint Server 2007 is named Microsoft SharePoint Server 2010. The SharePoint 2010 name is often used as an umbrella term to refer to SharePoint services generically, without being specific to SharePoint Foundation or SharePoint Server. For SharePoint 2010 the developer story has greatly improved. Whether building composite applications without code or getting into Visual Studio and building a packaged solution, there are many tools and features available. In addition, the platform story has only gotten better in 2010 and is becoming a key strategy for the SharePoint product. This paper will dive into a few key platform capabilities and reveal why they could be important to your product development technology roadmap.

The SharePoint Team has done an excellent job of establishing SharePoint as an “Application” and has made major strides toward SharePoint being a “Platform”. From developer tools to open source communities to development APIs, it is clear that the SharePoint Product Team does not intend SharePoint to be a “sealed” application. To the contrary, SharePoint has evolved into a web application development and integration framework for Microsoft Developers to Connect, Extend, and Build On this platform.

SharePoint Platform Strategies

There are three primary strategies for using SharePoint as your product platform. These strategies were described by Owen Allen, Senior Product Manager for SharePoint ISV Partners at Microsoft, during that same SharePoint Conference in October 2009.

Connect: Integrating an existing product with SharePoint by connecting that product with SharePoint in a way that enables the two products to work together.

Extend: Enabling new solutions or streamlining the development, administration, or user configuration of solutions in SharePoint.

Build On: Building a product on top of the SharePoint infrastructure and embrace the abundance of capabilities provided by the SharePoint platform.

These strategies, for the most part, progress in the order of Connect, Extend, and then Build On. While advancing through these strategies, a dependency on SharePoint develops (either SharePoint Foundation or Server). Most product companies that take a dependency to SharePoint will give the option to run on SharePoint Foundation and Server. Depending on the target customer, the product company will determine if they will offer SharePoint Server features. For example, many medium to large Enterprises have SharePoint Server deployed. A product that builds a dependency to SharePoint Server Features can save development costs by leveraging Server Features that otherwise need to be developed (e.g., Form Services or Web Content Management).

Let’s explore these strategies of Connect, Extend, and Build On in more depth.

Connect

Existing products can be connected to SharePoint by providing integration points such as content embedding, cross-product search, and single sign-on. The goal is to give users a seamless experience and allow them to work in their product of choice without having to spend time switching contexts between various products. This connection/integration can be unidirectional or bidirectional.

Connect strategies are common when a product does not share the same platform or technologies as SharePoint (e.g., Java-based instead of .Net-based).  SharePoint and the connected product are typically running on separate servers; either in the same network or maybe in completely different networks (one could be in the cloud).

Here are more details on some of these integration points.

• Content Embedding – Content embedding may involve SharePoint content being viewed or used within your product and vice-versa. This allows a product’s data to be used in new ways. Maybe the data could be seen via a custom web part, referenced through some SharePoint list data, be part of a SharePoint workflow, and/or simply be put on a SharePoint team site for easier collaboration. Think of this type of connection when the product is sharing data FROM SharePoint or sharing data TO SharePoint.
• Search – Cross-product search allows users to work in the product most pertinent for their task, but be able to find relevant data from the other product. So, while users are in SharePoint they may find data from other products/applications. This can be integrated using federated query search or a common search index with either a common search results UI or simply a shared search query API.
• Single Sign-On – This simply ensures that users can easily move from a product to SharePoint and vice-versa without having to enter credentials more than once. In addition, any content embedding and search results should be relevant for the current user (i.e., security trimmed appropriately). This may involve delegation (i.e., Kerberos), custom services that do impersonation, or use claims-based authentication.

Products can be connected to SharePoint using existing or custom web services and can be connected regardless of whether they are built in .NET, Java, or another technology. The integration points are more compelling in SharePoint 2010 with its richer web services infrastructure (WCF), richer UI capabilities (AJAX, Silverlight and Client OM), improved search architecture, and new claims based authentication capability (including SAML).

“From a strategic standpoint, connecting to SharePoint provides a number of benefits to both ISVs and customers:

1. Bridging teams – When it comes to collaboration software, teams within an organization tend to select the tools that suit their style of work. For example, the marketing team may use SharePoint for collaborating on documents while the engineering team may use a wiki for this. Connecting your applications to SharePoint allows individuals to collaborate across team boundaries while giving teams the flexibility to choose the tool best suited for them.
2. Eliminating content silos – the “Holy Grail” of knowledge management for any organization is to attain a unified, organized and searchable knowledge repository for all employees to access. Connecting your applications to SharePoint through content embedding, search and single sign-on brings you closer to achieving a “shared brain” within your organization.
3. SharePoint as a corporate standard – For many large organizations, SharePoint is becoming the corporate standard for collaboration, document management and content management. Any ISV’s looking to sell into these organizations should consider a “plays well with SharePoint” strategy in order to satisfy your customers’ requirements. ISV’s without this strategy may find themselves eliminated from sales opportunities they’re otherwise qualified to win.”

Bill Arconati, Product Marketing Manager at Atlassian

A clear example of a connect scenario for an ISV is the SharePoint Connector for Confluence. Read about the technologies involved in a How We Did It Article on the SharePoint Product Team Blog. Also, read more about an enterprise example that involved an unique requirement to connect SQL Server Reporting Services (SSRS) and SharePoint beyond what was provided by SharePoint out of the box – Allowing Connections to Multiple SSRS Servers with Report Viewer and Explorer Web Parts.

Extend

There are many products that extend SharePoint to allow others to take SharePoint to the next level. This can be viewed as a product that provides services that extend existing SharePoint capabilities, and it can also be viewed as a product that incorporates SharePoint services and capabilities into itself, in such a way as to extend the product value proposition by incorporating out of the box SharePoint capabilities.

The Extend strategy, in many cases, creates a dependency to SharePoint for the features of their product. In some cases, the product could still function without SharePoint, but its features would be limited without the presence of SharePoint. With most Extend solutions, the SharePoint interface is not abstracted from the user and the focus is enabling the customer to speed up the process of building business value added solutions that involve SharePoint.

Many Technology Solution ISVs are examples of product companies taking the Extend strategy (e.g., Nintex Workflow and Colligo). They are providing solutions for the SharePoint community which have incremental value to what comes standard with SharePoint. For example, for the products mentioned with SharePoint 2007, Nintex provided WYSIWYG workflow editors in the browser and Colligo provided a rich, offline synchronization experience with SharePoint Lists and Libraries. Note that enterprises often take an Extend strategy with their SharePoint application development. A good example of this is extending InfoPath and Forms Services to provide a canned Service Request template/site definition with custom InfoPath consumable web services particular to the enterprise. With this type of solution, individual departments can implement their own service request site customized to their needs yet have access to common services within the enterprise. Read about this enterprise example in the following article – Automating Service Requests using InfoPath Forms Services.

The list of ways to extend SharePoint is large, but some include:

• Custom web parts that can be used for mash-ups and composite applications
• Custom workflow actions for use in SharePoint Designer
• Custom out-of-the-box list or site workflows that can be used as part of an overall solution
• Custom field types for use in any SharePoint list or library
• Custom event receivers for programmatic action upon item submission
• Custom content types specific to a particular need
• Custom information management policies for placing custom policies around content
• Custom search indexing pipeline stages for us in FAST Search for SharePoint

Build On

Products built from the ground up on top of SharePoint can take advantage of the broad range of SharePoint features. Out-of-the-box SharePoint provides the plumbing for authentication, authorization, provisioning, data viewing and editing, workflows, events, versioning, scaling to multiple servers, deployment, administration, auditing, Office integration, etc. This Build On strategy takes on many dependencies to SharePoint and would not exist without having SharePoint installed. With this dependency the product development can focus primarily on business functionality and leverage SharePoint for common framework services. Note that products using the Build On strategy might abstract the user from the SharePoint user interface (leveraging the SharePoint Services but creating a totally different user experience than what is provided with the SharePoint user interface).

Using the Build On strategy does not preclude some external component from existing (call it a Hybrid Build On/Connect strategy). For example, a back-end component from a product such as a processing server or database may be completely external from SharePoint. Alternatively, a custom UI such as a ClickOnce WPF application may be part of the solution as well. Before deciding how certain components may live completely within or outside of the SharePoint infrastructure, invest in understanding the new Services Architecture, the vastly improved Business Connectivity Services (BCS), the new SharePoint Workspace features, and the benefits SharePoint’s deployment model can provide (e.g., managing web.config changes across multiple web front ends).

As an example, CorasWorks and its application publishers provide a broad line of off-the-shelf departmental business applications through a Build On SharePoint strategy. For reference see the CorasWorks App Store.

Note that Enterprises also have internal development efforts that are very similar to product development that is done with ISVs. Enterprises will connect, extend, or build on SharePoint to provide solutions like:

• Connect: SharePoint to proprietary or legacy systems that have poor usability or accessibility to employees or client/customers
• Extend: SharePoint’s Team Site Collaboration to include standard capabilities that are specific to the companies’ collaboration disciplines
• Build On: SharePoint line of business applications that automate processes based on the companies’ intellectual property

That being said, Enterprises should also consider SharePoint in their technology roadmaps and Architects, CIOs, and other Technology Leaders can benefit from understanding these strategies.

What’s Next

In this article we focused on the three primary strategies for using SharePoint as your product platform – hopefully you’re beginning to think that the skies the limit.   The upcoming articles in this series are entitled “Four Perceived Barriers to Adoption as a Development Platform” and “Four Misconceptions of SharePoint as an Application Platform.”

If you found this article interesting, please download the white paper from http://www.threewill.com/whitepaper.

Credits

For this initial blog post we would like to recognize and thank the team involved in the white paper :

Authors:

Owen Allen – Senior Product Manager for SharePoint ISV Partners, Microsoft Corporation
Kirk Liemohn – Principal Software Engineer, ThreeWill
Pete Skelly – Principal Consultant, ThreeWill
Eric Bowden – Senior Consultant, ThreeWill
Tommy Ryan – Principal, ThreeWill
Danny Ryan – Principal, ThreeWill

Contributors:

Geoffrey Edge – Senior Technology Specialist, Microsoft Corporation
Kirk Evans – Developer and Platform Evangelism for Communications Sector, Microsoft Corporation
Chris Mitchell – Technology Architect for Microsoft Technology Center, Microsoft Corporation
Adam Morgan – Digital Marketing Platform Group, Microsoft Corporation

Reviewers:

Bill Arconati – Product Marketing Manager, Atlassian Software Systems
Tony Clark – Director, Enterprise Architecture, Cox Enterprises
Geoffrey Edge – Senior Technology Specialist, Microsoft Corporation
Bo George – Senior Application Developer, Aflac
Murray Gordon – ISV Architect Evangelist, Microsoft Corporation
Aaron Rafus – Technology Evangelist, McKesson Corporation
William Rogers – Chief Workplace Architect, Corasworks Corporation
Scott Schemmel – VP of Global IT, PGi
Brendon Schwartz – Senior Platform Engineer, JackBe Corporation
Cole Shiflett – Solutions Architect, Equifax
Dr. Todd Stephens – Senior Technical Architect, AT&T
Matt Waltz – Chief Technology Officer, NextDocs
Michael Wilson – Solution Specialist for Office and SharePoint, Microsoft Corporation

Related posts:

1. Connect Multiple SSRS Servers
2. WSS in a Build Process