Benefits of share_point_2010_as_a_product_platform

Benefits of
SharePoint 2010 as a
Product Platform
For Independent Software Vendors and Enterprises
Date published: June 2010

Authors:
Owen Allen – Senior Product Manager for SharePoint ISV Partners, Microsoft Corporation
Eric Bowden – Senior Consultant, ThreeWill
Kirk Liemohn – Principal Software Engineer, ThreeWill
Danny Ryan – Principal, ThreeWill
Tommy Ryan – Principal, ThreeWill
Pete Skelly – Principal Consultant, 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
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
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

Summary
During the 2009 SharePoint Conference, Christian Finn, Director of SharePoint Products for Microsoft,
commented that given current trends, building products on the SharePoint Platform is the “new black.” To
make his case, he cited the momentum of the SharePoint platform along with significant announcements from
companies building integration with SharePoint into their products and services. This white paper, designed
for Independent Software Vendors, software architects, CIOs, and other enterprise technology leaders picks up
this discussion by addressing the perceived limitations that may cause development companies to discount
SharePoint as a development platform when drawing up a technology roadmap – and illustrating the value of
leveraging SharePoint as a Web Application Development Platform for those organizations.

Contents
Why This White Paper...............................................................3 Perceived Barrier 3 -
Lack of Integration with External or Relational Data.........21
SharePoint Background............................................................4
Perceived Barrier 4 -
Audience for this Paper............................................................6 Application Lifecycle Management (ALM) and
Code Isolation..................................................................................21
.
Making the Case for SharePoint.............................................7
.
Is Perception Reality?.....................................................................22
Does SharePoint Fit..........................................................................7
Misconceptions of SharePoint as an
Making the Case................................................................................8
Application Platform...............................................................23
Leveraging the Platform............................................................8
.
Misconception 1 -
Understand Your Value Proposition.......................................8 A SharePoint Dependency Means
Closed Architecture........................................................................23
SharePoint Platform Strategies...............................................9
Misconception 2 -
Connect................................................................................................9
. SharePoint Applications Are Too Restrictive.........................23

Extend.................................................................................................11
. Misconception 3 -
SharePoint Is Only a Document Repository..........................24
Build On..............................................................................................12
Misconception 4 -
Platform Capabilities...............................................................13 SharePoint Cannot Be Used to Run Line
of Business Applications...............................................................25
Infrastructure....................................................................................13
Community Support and Tooling.........................................26
ASP.NET HTTP Pipeline.................................................................. 13
Community.......................................................................................26
.
Application Security........................................................................ 14
Visual Studio.....................................................................................26
Service Applications........................................................................ 14
Debugging........................................................................................26
.
Packaging and Deployment........................................................ 14
SharePoint Designer......................................................................27
.
Content Management...................................................................15
Third Party Tools..............................................................................27
External Data..................................................................................... 15
.
Next Steps. ................................................................................28
.
Business Intelligence...................................................................... 16
.
Feature Mapping.............................................................................28
Search................................................................................................... 16
Market Analysis...............................................................................28
.
Workflow............................................................................................. 17
Bake Off..............................................................................................28
Data Model User Interface........................................................... 17
Pilot Project.......................................................................................28
And More............................................................................................ 17
Consult with Others.......................................................................28
.
User Interface...................................................................................18
.
ISV Ecosystem Map........................................................................29
.
Platform Capabilities Summary.................................................19
Key Resources...................................................................................30
Barriers to Adoption as a Development Platform. ...........20
.
References.........................................................................................30
.
Perceived Barrier 1 -
Unique Developer Skill Set..........................................................20 Glossary of Terms............................................................................31
Perceived Barrier 2 - Footnotes...........................................................................................34
Closed or Restrictive Platform Services...................................20

2

Why This White Paper
As with any evolving product, there are false ceilings set due to people’s experiences with previous versions. The initial core
features/capabilities for SharePoint were targeted to provide out-of-the-box features that made the product easy to use
and administer for team sites and portals. The product was extensible from the beginning, but it was not architected for the
mainstream developer. This focus has changed over the years and there are very compelling reasons that product companies
should consider SharePoint in their technology roadmaps.
The ability to leverage the rich features of SharePoint technologies is reason enough to consider SharePoint as a web
development platform. Another key reason to consider either building on top of SharePoint or having a connection strategy
with SharePoint is market opportunities that come from being associated with this popular platform (over 100 million licenses of
SharePoint have been sold). The purpose of this white paper is to address the perceived limitations that typically cause product
companies to discount SharePoint when determining a technology roadmap for their products.
This white paper will dive into some of the features of the platform, including how a company could build a better product faster
and take advantage of the rapid adoption and increased market interest in SharePoint as a platform. Also described in this paper
are the Connect, Extend, and Build On strategies and the advantages of each approach.

3

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 vision1.
SharePoint, in the early days of its product lifecycle, provided an application for team and portal implementations. True
customization was limited. Unlike subsequent versions of SharePoint, the two collections of services in its first version, SharePoint
Team Services (STS) and SharePoint Portal Server (SPS), did not completely share a common framework.

With the second version, Windows SharePoint Services With the release of WSS version 3 and Microsoft Office
(WSS) 2.0 and SPS 2003, a third-party developer community SharePoint Server (MOSS) 2007, a developer community for
began to form. This community was primarily focused on in-house developers and consultants started to form, while
the gap between SharePoint features and the typical needs the third-party developer community continued to expand
for team sites and portals. These products often took form rapidly. The extensibility story became richer and the viability
as components (such as a web part) that would empower of SharePoint as a web application development platform
end users to put together lightweight applications. Also, the emerged. The services available to build upon in SharePoint
concept of mashing up data from sources inside and outside of allowed for enhanced custom solution scenarios that could
SharePoint started to take shape. Outside of the development leverage Windows Workflow Foundation, web content
of third-party products, the developer community shied away management (via the incorporation of the Microsoft Content
from SharePoint customization because the techniques were Management Server product), a rich event model and search
often fragile. For example, the ONET.XML had to be changed to capabilities, to name just a few areas.
make branding changes; yet this SharePoint system file has also
had the potential to be changed in subsequent 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: SharePoint had a
separate ISAPI filter and did not run through the ASP.NET ISAPI
filter. As a result, SharePoint could not take advantage of the
extensive features offered by ASP.NET.

SharePoint History
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
provides a good perspective on how an 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

4

SharePoint capabilities. capabilitie
by the ShareP

SharePoint Background
With SharePoint 2010, the names of the component
products have changed. The successor to Windows
SharePoint Services 3.0 is named Microsoft SharePoint 2001
Foundation 2010 and the next version of Microsoft Office • SharePoint Team Services
SharePoint Server 2007 is named Microsoft SharePoint • SharePoint Portal Server
Server 2010. The term “SharePoint 2010” is often used as
an umbrella term to refer to SharePoint services generically,
without being specific to SharePoint Foundation or 2003
SharePoint Server. The developer story has also greatly • Windows SharePoint Services v2
improved in SharePoint 2010. Whether building composite • SharePoint Portal Server2003
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 2007
gotten better in 2010 and is becoming a key strategy for
the SharePoint product. This paper will dive into a few key • Windows SharePoint Services v3
platform capabilities and reveal why they could be important • Microsoft Office SharePoint Server 2007
to your product development technology roadmap.
The SharePoint Team has done an excellent job of 2010
establishing SharePoint as an “Application” and has made
• Microsoft SharePoint Foundation 2010
major strides toward SharePoint being a “Platform”.
• Microsoft SharePoint Server 2010
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.

Terminology
Sites
Throughout this white paper we will use the terms SharePoint 2003, SharePoint 2007, etc. when we need to differentiate between
releases of SharePoint. If necessary, we will use the license names/abbreviations (e.g., WSS v3, MOSS 2007), will be used.

Composites Communities

Insights Content

Search

5

Audience for this Paper
The audience for this white paper is software product
Note that Enterprises also have internal development efforts that
companies, which we will refer to as ISVs (Independent
are very similar to product development that is performed with ISVs.
Software Vendors), as well as software architects, CIOs, and
Enterprises will connect, extend, or build on SharePoint to provide
other enterprise technology leaders. The information in this
solutions such as:
paper is technical in nature so technical decision makers will
best connect with the content. • Connect SharePoint to proprietary or legacy systems to share
data among systems or to provide an improved usability or
For SharePoint, Microsoft groups ISVs (see “Appendix A:
accessibility experience to employees or client/customers
SharePoint ISV Partner Ecosystem Map” for examples) into:
• Extend SharePoint's team site and collaboration templates and
• Technology Solutions – ISVs that extend the functional
capabilities to include standard features that are specific to the
areas of SharePoint
companies’ collaboration disciplines
• Horizontal Business Solutions – ISVs that create broad
• Build On SharePoint through the development of custom line-
solutions that can apply to most companies’ needs
of-business applications that automate processes based on the
regardless of their industry; this paper refers to them as
companies’ intellectual properties and business requirements
Horizontal ISVs
That being said, Enterprises should also consider in their
• Vertical Business Solutions – ISVs that create industry-
technology roadmaps and architects, CIOs, and other technology
specific solutions; this paper refers to them as Vertical ISVs
leaders can benefit from reading this white paper.

6

Making the Case for SharePoint
2010
• Microsoft SharePoint Foundation 2010

Does SharePoint Fit
SharePoint can fit many product scenarios. Understanding if there is any alignment of SharePoint product features to your
product’s features is key to determining a fit. A good place to start is exploring the six high-level product capabilities of
SharePoint 2010 found in the diagram below (these descriptions
can also be found on the SharePoint 2010 Capabilities2 page).
Sites - SharePoint Sites deliver a single infrastructure to provide
portal and collaboration capabilities across intranet, extranet,
Sites and internet sites. SharePoint Sites bring users together to share
information, data, and expertise across organizations.
Communities - SharePoint Communities empower people to
Composites Communities work together in ways that are most effective for them. SharePoint
Communities make it possible for people to collaborate in groups,
share knowledge and ideas, connect with colleagues, and find
information and experts easily.
Insights Content Content - SharePoint Content enables all users to participate in a
governed, compliant content management lifecycle. SharePoint
Content makes it possible to expertly balance user experience with
Search policy and process.
Search - SharePoint Search gives users the ability to find the
content, information, and people they need by combining an
integrated, easy-to-manage platform with best-of-breed enterprise
search technology.
Insights - SharePoint Insights enables users to access and interact with information across unstructured and structured data
sources. SharePoint Insights empower users to discover the right people and expertise to make better and more agile business
decisions.
Composites - SharePoint Composites empower users to rapidly respond to business needs by creating their own no-code
solutions, on premises or in the cloud, through a rich set of building blocks, tools, and self-service capabilities.

These product capabilities have considerable depth. This paper • Provisioning – The ability to allow users to easily provision
will not cover each one in detail, but will provide descriptions new sites and lists as their business needs dictate.
that could be helpful to those considering whether to build
• Security – A comprehensive authentication and granular
similar capabilities into their product(s) from the ground up.
authorization system are built in and govern access to all
For more detail, please read this post from the SharePoint
aspects of SharePoint.
Product Team Blog3 . It provides 40 examples of investments
in the six functional categories of SharePoint 2010 mentioned • User Interface – “Web Parts,” wiki style editing, a “Fluent”
above along with Administration and Development areas of ribbon-based menu system, AJAX- style dialog boxes
the platform. and more are all provided. These features not only
save development effort, they provide a strong level of
In addition to these high-level solution areas, SharePoint
consistency that aids in usability and adoption.
provides a number of built-in features required by many web
solutions. Thus by adopting SharePoint, an ISV can reuse rather • Forms and Workflows – Tools such as InfoPath and
than reinvent them. These capabilities include: SharePoint Designer allow business analysts and power
users to construct workflow-oriented business applications.
• List and Library Management – The ability to store
ISV’s can easily add to the capabilities available in such
information in lists which can be created by users or
solutions, and can also provide pre-built forms and
programmatically, and which have rich built-in capabilities
workflows oriented to specific horizontal or vertical
such as check-in and check-out, versioning, approvals,
business scenarios.
folder hierarchies, data validation, user-configurable views,
calculated fields and more. Input forms, item and list level The reuse of these capabilities allows ISV’s to focus on their
views, grid-based editing, RSS rendering and more are also core values rather than reinventing yet another security system
built into all lists. Libraries build on lists by including binary or UI. They also allow business users to combine SharePoint
objects such as documents, images, and digital media. and ISV features to build solutions that uniquely address their
business needs.

7

Making the Case for SharePoint

Making the Case
Getting the most out SharePoint as a basis for ISV offerings comes from understanding the platform and the value of having a
product associated with SharePoint in the marketplace. Let’s explore this idea further.

Leveraging the Platform Understand Your Value Proposition
To get the most from leveraging SharePoint as a platform, When building a roadmap, it is important to understand
begin by considering its built-in features and which of SharePoint’s strengths and weaknesses along with those of
its capabilities are relevant to your solution space. Most other SharePoint ISVs. A significant part of the product value
organizations typically deploy one to two key workloads or is usually based on the feature gap between SharePoint and
capabilities at a time. For the best ROI (return on investment) what the current users and administrators need from their
and TCO (total cost of ownership), incorporate as many of the SharePoint environment.
SharePoint built-in features as possible and follow common
With Vertical ISVs, it is easier to determine the value
SharePoint best practices. This will allow faster time to market
proposition. The vertical markets have their own ecosystem
and lead to a product that will benefit from new releases of
of products that have established pricing and licensing
SharePoint.
models. If determining what features are needed in a vertical
One simple example of leveraging the SharePoint platform market, perform a gap analysis of what features exist in the
is document management. For instance, with the check in products of a vertical market. Based on that gap analysis, it
and check out of documents, you can embrace the built-in can be determined how SharePoint can help penetrate that
document management features of SharePoint that provides market with built-in features (including what is configurable
this capability. Taking this approach will save money by within SharePoint). Understanding what it takes to connect,
not having to build the feature from scratch, and will avoid extend, and build on SharePoint will help you understand
confusing users by providing a consistent way to perform this the incremental investment to turn SharePoint into a vertical
task. In addition, the product will benefit from future upgrades solution that fills a market need.
to the SharePoint feature. Thinking of SharePoint as a web application development
platform? Explore the rest of this paper to get some further
Because SharePoint is a platform built on top of ASP.NET, many
insight on the value of the platform.
development skills are readily transferable. Understanding how
to build ASP.NET applications with .NET framework languages is
an extremely sound foundation for leveraging SharePoint as a
development platform. The SharePoint tooling in Visual Studio Keep in mind that some horizontal ISVs are creating solutions that
2010 is quite mature, and there is a well-established SharePoint fit in vertical markets. They are typically not fully featured, but with
community to help in the learning process of your team. customizations they can compete in certain verticals.

8

Se
Windows Server
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 the SharePoint Conference in October 2009.

Connect Extend Build On
Integrate an existing Create integrated solutions Create solutions on top
product with SharePoint to that extend SharePoint of the SharePoint
enable the two products to feature offerings - or that infrastructure that leverage
work together. leverage or include the breadth of
SharePoint capabilities. capabilities provided
by the SharePoint platform.

These strategies, for the most part, progress in the order of Connect, Extend, and Build On; advancing through them increases
a dependency on either SharePoint Foundation or SharePoint Server. Most product companies that accept a dependency on
SharePoint will provide the option to run on SharePoint Foundation or Server, sometimes with a more comprehensive feature set
enabled if a customer’s environment includes SharePoint Server.
For example, many medium to large enterprises have SharePoint Server deployed. A product that builds on that that dependency
can save development costs by leveraging Server features that otherwise need to be created (i.e., Form Services or
Web Content Management). 2001
• SharePoint Team Services
Let’s explore these strategies of Connect, Extend, and Build On in more depth.

• SharePoint Portal Server
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
2003
without having to spend time switching contexts between various products. This connection/integration can be unidirectional or
bidirectional.
• Windows SharePoint Services v2
Here are more details on some of these integration points.
• SharePoint Portal Server2003
• Content Embedding - Content embedding may
Connect strategies are common when a product does not share
involve SharePoint content being viewed or used within
the same platform or technologies as SharePoint (e.g., Java-based
your product and vice-versa. This approach allows the
instead of .Net-based). SharePoint and the connected product
product’s data to be used in new ways. Maybe the
can also execute on separate servers in the same network or in a
2007
data could be seen via a custom web part, referenced
completely different network (e.g., one could be in the cloud).
through some SharePoint list data, be part of a SharePoint
workflow, and/or simply be easier to collaborate on using
• Microsoft Office SharePoint Server 2007
a SharePoint team site. 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 to their task, but to also find relevant data
from the connected product. This approach can be integrated using a federated query search or a common search index with
2010
either a common search results UI or simply a shared search query API.
• • Microsoft SharePoint Foundation 2010
Single Sign-On - This approach 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 (e.g, security trimmed appropriately). This may involve delegation (e.g., Kerberos), custom
services that do impersonation, or utilization of claims-based authentication.

9

Products can be connected to SharePoint using existing or A clear example of a connect scenario for an ISV is the
custom web services regardless of whether they are built SharePoint Connector for Confluence4. You can read about
in .NET, Java, or another technology. The integration points the technologies involved in a How We Did It Article on
are more compelling in SharePoint 2010 with its richer web SharePoint Product Team Blog5. You can also read more about
services infrastructure (WCF), richer UI capabilities (AJAX, an enterprise example that involved unique requirement to
Silverlight, and Client OM), improved search architecture, and connect SQL Server Reporting Services (SSRS) and SharePoint
new claims based authentication capability (including SAML). beyond what was provided by SharePoint out of the box -
Allowing Connections to Multiple SSRS Servers with Report
Viewer and Explorer Web Parts6

“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

10


Extend
There are many products that take SharePoint to the next level. Some provide services that extend existing SharePoint capabilities.
Others incorporate SharePoint services and capabilities in such a way as to extend the product value proposition.
This Extend strategy, in many cases, creates a dependency among such products on particular SharePoint features. 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 (i.e., Nintex Workflow and Colligo).
They are providing solutions for the SharePoint community that have incremental value above those that are included as standard
with SharePoint. For example, Nintex provides WYSIWYG
workflow editors in the browser and Colligo provides a rich, Extend strategies are common for products that provide integrated
offline synchronization experience with SharePoint Lists and building blocks from which others can build a final solution.
Libraries. Note that enterprises often take an Extend strategy
with their SharePoint application development. A good
example of this strategy is the extension of 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 custom service-request sites yet still have access to common services within the enterprise. Read
about this enterprise example in the following article- Automating Service Requests using InfoPath Forms Services7.
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
• Custom user-defined functions for use in Excel Services

11


Build On
Products designed and built from the ground up for SharePoint can take advantage of its broad feature set. 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, and more. This Build On strategy
creates SharePoint dependencies and would not exist without having SharePoint installed. With these dependencies, the product-
development effort can focus primarily on business functions and leverage SharePoint for common framework services. Note that
products using the Build On strategy might abstract the user from the SharePoint interface (leveraging the SharePoint Services but
creating a totally different user experience than what is provided by the SharePoint interface).

Using the Build On strategy does not preclude some external Build On strategies are common when a product uses the same
component from existing: call it a hybrid Build On/Connect platform and technologies as SharePoint. Products built on ASP.NET
strategy. For example, a back-end component from a product and SQL Server should consider the Build strategy and would use all
such as a processing server or database may be completely or most of the SharePoint infrastructure (front end servers, application
external from SharePoint. Alternatively, a custom UI such as a servers, content databases, IIS web sites, list infrastructure, web
ClickOnce WPF application may be part of the solution as well. services architecture, etc.).
Before deciding how certain components may live completely
within or outside of the SharePoint infrastructure, invest in
understanding the new Services Architecture, vastly improved As an example, CorasWorks and its application publishers
Business Connectivity Services (BCS), the new SharePoint provide a broad line of off-the-shelf departmental business
Workspace features, and the benefits that SharePoint’s applications through a Build On SharePoint strategy. For
deployment model can provide (e.g., managing web.config reference see the CorasWorks App Store8.
changes across multiple web front ends).

“Over the last 3 cycles of SharePoint CorasWorks has been transitioning
its products from technology solutions to horizontal and vertical
business solutions. Using a strategy of Building On SharePoint 2010,
CorasWorks and our application publishers are able to focus on the
business solution vs. technology extensions – thereby addressing the
critical last mile to unleash business value”
William Rogers, Chief Workplace Architect at CorasWorks

12

Platform Capabilities
Silverlight JavaScript Windows App
SharePoint provides a great foundation for application development at all levels of the software development stack. The
capabilities extend outward to include search, workflow, scalable and extensible services architecture, and administrative features.

Client OM

Client OM

Client OM
Being built upon ASP.NET and Windows Server platforms allows SharePoint to expose infrastructure features and inherent

SvcProxy
AJAX

AJAX
points of extensibility to application developers. ISVs who choose to build upon SharePoint will find that they inherit a rich set
of platform capabilities, letting them put more time and effort into developing unique product features vs. generic features.
Applications that connect to SharePoint can reveal application data and features either in the SharePoint UI, Business Connectivity
Services (BCS), or via one of the many options for extensibility provided by SharePoint.
Let’s explore the platform capabilities using more developer-centric categories of Infrastructure, Content Management, and
SharePoint Web Services
User Interface similar to n-tier architecture models. This is a departure from the SharePoint wheel shown earlier. This SharePoint
Server-Side UI
wheel works well from an end-user point of view, but the below diagram is more useful when looking to understand SharePoint
as a developer platform. SharePoint SharePoint API

Infrastructure
SharePoint is now at version
4 and has become a well-
Request Membership

Service Application
tested and trusted platform Authorization Provisioning
Pipeline Provider
for securing content and

Architecture

Deployment
Scalability

allowing ISVs to move forward ASP.NET
into adding application value.
Its infrastructure starts with Authentication Content & Configuration Databases
Windows Server and the IIS SQL Server
.NET Framework and heavily
relies on IIS, ASP.NET and Windows Server
SQL Server. Out-of-the-box
authentication includes Windows
NTLM or Kerberos while
SharePoint and ASP.NET extensibility allow for developers to provide custom forms and web single sign-on options. SharePoint
resource authorization can be managed at site collection, site, page, item, and custom action levels; security permissions can also
be applied in custom code. Role membership can be defined individually or by using SharePoint or Active Directory groups.
ASP.NET HTTP Pipeline an existing
Integrate Create integrated solutions Create solutions on top
ASP.NET extensibility goes further by allowing developers to add in HttpHandlers and HttpModules for custom request
handling. Developers can use this handling to support features such as global changes to the SharePoint interface, custom
file-type processing, custom authentication, and more. For example, an HttpHandler could be created to prevent cross-site
scripting errors when processing requests for file types stored in an external system. The HttpHandler could accept a request
for the custom file type, forward the request to the external system, and then return the results to the requesting browser (note:
credentials delegation may be required). This would allow the file that resides on an external server to be requested directly from
SharePoint. The SharePoint API, including site and user context, are available from within the handler. Because SharePoint is built
upon ASP.NET, application developers have available both the ASP.NET customization options as well as SharePoint context and
configuration.

2001

2003
• SharePoint Portal Server2003

13
2007


Application Security Packaging and Deployment
Another example of extensibility provided by ASP.NET includes The deployment capabilities of SharePoint cannot be
creating custom membership providers that enable login overstated either. Custom functions are packaged into a
credentials to be retrieved from a custom store. Membership solution package file (WSP) and may contain one or more
providers supplied by SharePoint allow connecting to features scoped to the farm, a web application, site collection,
membership stores created using SQL, LDAP, or Active or site. SharePoint handles the deployment of files to the
Directory. The base MembershipProvider, like many ASP.NET GAC, bin, and virtual directories within the web site on
and SharePoint classes, can be extended, allowing developers the front end web servers. It also handles deployment of
to create custom implementations. The membership provider content to the content databases. After files are deployed to
is configured in the site web.config file allowing, among other the web front ends (WFEs), additional WFEs can be added
things, a custom login page to be supplied. and SharePoint handles updating the new WFEs, including
web.config file updates. SharePoint 2010 adds additional
Claims-based authentication is a significant infrastructure
deployment capabilities with its versioning support and
feature new to SharePoint 2010. With claims, user
Sandboxed Solutions. With Sandboxed Solutions, WSPs are
authentication is provided by an “identity system” that
deployed to a content database and farm administrators are
may include corporate credential providers such as Active
given more control by isolating the execution environment of
Directory, LDAP, or credentials stored in databases. Credentials
the features within the package. This enables administrators
authentication may also be provided by web sign-on providers
to upload solutions only once that are automatically deployed
such as LiveID and OpenID. Claims-based authentication will
to all web front ends, increasing predictability and reducing
make it easier for additional identity systems to integrate with
maintenance cost.
SharePoint, thus opening up another point of extensibility.

Service Applications OOTB Content Extension Point
The service application architecture, new in SharePoint Management Highlights
2010, provides another point of extensibility and enterprise
scalability. Services developed on the new platform can • Content Versioning • Event Receivers
be scaled across one or more servers and can cross the • Check-in/Check-out • Custom Field Types
farm boundary to provide services for multiple SharePoint • Content Approval • Rendered Columns
installations. SharePoint services support additional scalability • Records Routing • Custom View Types
by providing “services in the cloud,” delivering new ways that • Information • External Data
ISVs can extend SharePoint. The services architecture includes Management Policies • Custom Actions
a configuration store for application settings, a common • CRUD UI • Custom Information
SQL database provisioning infrastructure, support for storing • Social Content Management Policies
custom data in databases that are managed by SharePoint, • Workflow • Custom Workflows
• Content Types • Custom Workflow Actions
a location to host middle-tier web services, a provisioning
• Field Types • Custom Content Types
mechanism for web services, and a service-scoped timer
• Office Integration • Custom User Defined
job infrastructure to support scheduled operations. This is Functions
• Offline Data
probably the largest investment Microsoft has made • Web Services • Custom Web Services
toward using SharePoint as a platform in 2010. • Search • Custom CRUD UI
• Custom Search
Content Sources

Web Pages (ASPX
Master Page
Site Pages
Customized Ribbon
Custom
Action
Web Part
Server Control

User Control
14


Content Management
SharePoint 2010 provides plenty of out-of-the-box capabilities to meet many ECM requirements. This is an advantage for ISVs.
Content- management features provided by SharePoint include content versioning, check-in/check-out, content approval and
disposition, records routing, and information-management policies such as content expiration. In addition, there is opportunity to
extend the SharePoint ECM capabilities at all levels. To cover all of them would take several books, so just a few will be highlighted.

Enterprise Perspective
SharePoint can also be used as an underlying CMS to feed into other portal technologies. At McKesson, we use Vignette as our portal today and
SharePoint as our collaboration platform. RSS and other technologies have allowed us to start taking advantage of the easy SharePoint CMS
capabilities but the content is available in the company wide portal.
Our SharePoint CMS strategy in the initial phase was to use out of the box capabilities. Now that users understand the product and the needs of
their Team/Department/Business Units they are taking SharePoint to the next level with data integration, creative redesigns and heavy process
automation projects.
Aaron Rafus, Technology Evangelist, McKesson Corporation

External Data
Application developers can choose to use SharePoint as a Another key advantage for using BCS is that SharePoint
data store or use a separate, external data store such as one automatically provides a customizable UI that supports read/
provided by a relational database, abstracted by web services, write as well as view/sort/filter capabilities. Standard ASP.NET
or provided by custom code. Using the SharePoint data store, forms are created for external data connected to SharePoint.
in the form of SharePoint lists, allows for the full utilization Using SharePoint Designer or InfoPath Designer, developers
of SharePoint content-management features, including the can create a richer interface for external data by generating
ability of users to configure and extend the schema. However, InfoPath forms. InfoPath forms also allow for a richer
SharePoint lists are not fully relational data stores. Application experience, including a deep set of form rules that can, among
developers in need of a more relational or custom data store other things, connect to external data sources to fill user choice
can instead choose to connect to an external data source by fields and perform field-level validation.
using external content types provided by Business Connectivity
There are also external-data innovations outside of BCS
Services (BCS). A hybrid approach involves connecting
within Microsoft and the ISV community. For example, there
SharePoint list data to external data by using external data
are several ISV products that expose external data within
columns. An external data column is a field in a SharePoint list
SharePoint. The Data Integration Toolset9 from CorasWorks and
which is a look-up to an external data source. The external data
MashPoint10 from Bamboo, for example, provide external data
column can select one or more fields from an external record
connections to easily surface data into their web part suites.
to be included in a SharePoint list item.
Furthermore, standards such as OData (Open Data Protocol)
BCS allows external data to participate in SharePoint content- are emerging. Similar to Microsoft ODBC efforts, OData is an
management features such as enterprise search, offline data open protocol for sharing data across various data consumers
access, and integration into Office client applications including and data providers. OData is based on web standard such as
Outlook, Word, and Access. External data can also participate HTTP and AtomPub (Atom Publishing Protocol) using JSON
in content-management features such as tagging, workflow, notation. To learn more about this emerging data protocol,
check-in/check-out, versioning, information management see Mike Flasko’s “Breaking Down ‘Data Silos’ – The Open Data
policies, and permissions by using proxy records in SharePoint. Protocol (OData)”11 on the WCF Data Services Team Blog.
External data columns in SharePoint allow SharePoint list items
to relate directly to external data (e.g., proxy record). Custom
code in workflows, event receivers, and custom information
rights management policies can then propagate activities that
occur on the proxy records such as the application of tags or
check-in/check-out to the external data records.

15


Business Intelligence Search
Data analysis is becoming a more frequent demand of any Search is a key capability for applications. Enterprise search
application, and this demand is rapidly expanding beyond supports searching data stored in SharePoint lists as well
the need for basic operational reporting. SharePoint 2010 external data. In SharePoint 2010, the BCS indexes external
provides a rich suite of offerings that application developers content and can involve no-code solutions for simple models
can leverage to accomplish this goal. They include native or custom-managed code for more complex scenarios (e.g.,
Charts and Data Indicator web parts, Performance Point nested/hierarchical data). Developers can customize the search
Services, Excel Services, Visio Services, and Reporting Services, experience by creating search scopes that limit a user’s search,
and more. Each is designed for a unique business case. For for example, to application records or by generating a set of
example, Performance Point Services supports business search refiners, allowing the search to be filtered and explored
scorecards, charts, and analytic dashboards. Using this feature by metadata at query time. Additionally, the search UI includes
of SharePoint 2010, an ISV could provide a dashboard that points of extensibility such as the ability to configure the search
leverages Key Performance Indicators (KPIs) to give users results page and extending out-of-the-box search web parts.
a quick view of operational health. The real purpose of a This is a very simple way to surface your existing solution’s
dashboard is to direct users to highlighted areas that need data into SharePoint search through configuration rather than
attention. through programming.
ISVs who choose the Connect strategy may want to use query
Business Intelligence federation to enable SharePoint and an external application
Note that business intelligence features are extremely powerful in to maintain their own search indexes. Or they may choose to
SharePoint 2010 and are a big part of exposing external data inside use SharePoint’s enterprise search Connector Framework12 to
SharePoint. Since business intelligence features are in such high maintain a single index across applications. In SharePoint 2010,
demand for enterprises today, this is an area of SharePoint that federated search is a core component in the search API and is
should not be ignored. even used by the Core Search Results web part.
In SharePoint 2010, the Connector Framework no longer
One of the most exciting new features in Performance Point requires writing unmanaged protocol handlers for crawling
Services is the Decomposition Tree visualization. Visualizing custom content. The Connector Framework, and even BCS
data has many challenges, and each visualization strategy search, provides security descriptors (ACLs) at index time
has pros and cons. Grids show numbers but don’t highlight if the information is available. This allows for trimming the
relative values, charts highlight relative values but don’t do a search results to only those items available to the individual
good job of showing actual values, and neither charts nor grids performing the search.
do a great job of visualizing hierarchical relationships in data. The Connector Framework is common across SharePoint Server
The decomposition tree highlights hierarchical relationships, 2010 Search as well as FAST Search for SharePoint 2010, so
shows raw numbers, and includes a graphing component that ISVs who build upon it will find their solution works with both
provides the best of each of these worlds. This visualization can enterprise search options. On the other hand, ISVs who need
be selected by users on demand and offers a great alternative more search capabilities can build upon FAST and have even
for users to perform ad-hoc analysis. more flexibility with its indexing and query pipelines as well as its
ISVs looking to add analytics to their applications can leverage entity-extraction capabilities. The ability of FAST to automatically
Performance Point Services in both the Connect to and Build create and categorize metadata introduces options for
On scenarios as it provides a rich set of database connectors for developers looking to create search-driven applications or
querying application data, and can leverage existing reporting to aggregate structured and/or unstructured content from
investments in its dashboard technology. Using this approach, disparate repositories while pivoting off common fields.
Performance Point dashboards and scorecards can be built
to consume data from an existing application database and Strategy: Connect or Extend
leverage existing custom reports. By using these features, users ISV’s looking to Connect or Extend SharePoint may find ample
can perform ad-hoc analysis of application data, and correlate opportunity within the SharePoint search infrastructure to provide
that information with other business data. Furthermore, as custom indexing or federated search connectors to third-party data
with any good reporting solution, users are shielded from the sources. One can even imagine a federated search web part that
underlying complexities of source system data models and aggregates similar data sources such as news feeds and organizes the
query languages. data in a meaningful way.

16


Workflow And More...
Developers can further use content-management features Application developers can also dive deep into the SharePoint
through out-of-the-box SharePoint workflows such as data-management structure by adding event receivers. Event
the “Approval Workflow” or by writing custom SharePoint receivers allow custom code to be executed when a change
workflows to control features such as content approval or occurs to a site collection, site, feature, workflow, list, or list
records routing. SharePoint provides the workflow execution item. Typical events that are handled include when a list or
environment and Windows Workflow Foundation provides library item is added, updated, or deleted.
the building blocks. In addition to custom workflows, ISVs
SharePoint provides out-of-the-box information-
can provide their own extension points by creating reusable
management policies that govern the data life cycle within it.
workflow activities for power users with SharePoint Designer or
Examples include expiration, bar code, and auditing policies.
for developers with Visual Studio.
ISVs can create custom information-management policies so
In SharePoint 2007, workflows are associated with a list/library that SharePoint can manage their data but have it governed
and workflow instances are tied to a list item. SharePoint by their specific rules.
2010 provides for this association and also adds the ability for
SharePoint’s latest social features around content
workflows to be independent of lists so they can be reused
management are also available to applications that store data
across lists and content types. This capability opens up a whole
in SharePoint lists or connect external data using external
new world of possibilities for Workflow and SharePoint.
data columns. Users can choose to tag application data using
either a managed, hierarchical term store (taxonomy) or
community-generated tags (folksonomy), with both types of
Data Model User Interface metadata residing in a unified, centrally-managed location.
Users can also rate “favorites” and bookmark data records
Using SharePoint content management features also provides to share and re-retrieve content they deem interesting.
a functional UI around the data model. By default, SharePoint Additionally, items in document libraries can appear in the
will create the CRUD (Create, Read, Update and Delete) forms SharePoint Documents web part of a user’s My Site (their
around application data. The forms may be replaced and personal web site) to display documents which the user has
developed as ASP.NET application pages, or may optionally be recently modified. Documents can also appear in the Relevant
developed as InfoPath forms. InfoPath forms then bring in a Documents web part which displays recent changes for the
large set of customization capabilities such as a form designer current user on the site.
and a rich set of built-in form rules.
SharePoint Workspace, formerly Groove, allows users to easily
Users can customize the presentation of data in SharePoint by take the application data offline. SharePoint Workspace is a
creating custom views. Custom views in SharePoint allow users windows desktop collaboration environment allowing users
to customize which columns are viewed, as well as add sorting, to interact with content and other team members. Users
filtering, paging, sub-totals, and more. ISVs can further extend can work with application data offline and then synchronize
the behaviors of data in SharePoint views through custom with the SharePoint server when a connection is available.
actions that can appear in the Actions menu of the view or on Offline mode is available for applications that store data in
the list item drop-down menu (e.g., Edit Control Block). ISVs SharePoint lists as well as to those that connect to SharePoint
can also extend SharePoint out-of-the-box views by creating using Business Connectivity Services.
rendered columns, custom view types, and custom field types.
Custom field types provide custom storage and presentation of
data types that are not native to SharePoint. Custom field types
can also be used to connect external data to native SharePoint
lists through custom controls for editing and rendering data.

17

• Offline Data Functions
• Web Services • Custom Web Services
Platform Capabilities • Search • Custom CRUD UI
• Custom Search
Content Sources

User Interface Web Pages (ASPX)
Master Page
Being built upon ASP.NET also allows for
points of extensibility in the SharePoint UI. The Site Pages
interface uses master pages, web parts, server Customized Ribbon
controls, and user controls developed using
Custom
ASP.NET. This means that ASP.NET application
Action
developers can use familiar skills to build custom
UI components and then integrate those Web Part
solutions into the SharePoint UI. Server Control
Custom Actions provide additional options
for UI enhancement. Custom actions include User Control
content drop downs, “Site Actions” menu items,
and links placed on administrative pages.
As a result, it is very easy to create custom
administrative pages and provide links to these Server Control
pages such that they look completely integrated
with the rest of the SharePoint administration
pages. SharePoint 2010 goes a step further with
the introduction of the SharePoint “Ribbon”. The
new ribbon can be customized and extended by
SharePoint developers to include content-sensitive menu options alongside the standard menu options that are provided.

Web parts are a key UI component for ISVs, regardless of
Strategy: Connect
whether they use the Connect, Extend, or Build On strategy.
Client OM

Client OM

Client OM

SvcProxy
Connecting at the user interface layer allows users to view and interact
Web parts are an ASP.NET concept (and base class) and are
AJAX

AJAX
with external data from within SharePoint while keeping the data and
hosted by SharePoint. SharePoint also manages the storage
data access code external to SharePoint. This is typically achieved by
of web part properties, including shared property values and
developing custom web parts or application pages which use custom
per-user property values. Web parts give users the ability to
code libraries to directly access external data. Developing custom UI
design and configure site pages. They can configure custom
components is a lightweight strategy for connecting to SharePoint;
web parts to connect to one another such as in a master/detail SharePoint Web Services
arrangement. Standard web part connection interfaces, such as this approach from the consistent SharePoint user interface Server-Side U
those provided by SharePoint filter web parts, allow out-of-the- paradigm and the ability to be used in SharePoint configuration and
deployment scenarios.
box web parts to connect with custom web parts. For example, SharePoint SharePoint API
the Choice Filter web part can be connected with web parts
which implement the IFilterValues connection interface. There
are nine filter web parts available from SharePoint Server,
providing several options for connecting to a custom web part
that implements IFilterValues.

Request Membership
Service Application
Authorization Provisioning
Pipeline Provider
Architecture
Scalability

ASP.NET
Authentication Content & Configuration Databases
IIS SQL Server
Windows Server

Integrate an existing
18 Create integrated solutions Create solutions on

Server Control

User Control

Server Control
SharePoint 2010 provides for even broader UI customization with the new client object model. This model allows for easy
access to SharePoint data from client side JavaScript enabled browsers, windows desktop, and Silverlight applications. This
point of extensibility makes it much easier for developers to provide rich client- side features and usability when a web based
interface is not desirable.

Client OM

Client OM

Client OM

SvcProxy
AJAX

AJAX

SharePoint Web Services
Server-Side UI

SharePoint SharePoint API

Platform Capabilities Summary
Request Membership Service Application
Authorization Provisioning
The robust and extensible infrastructure, content management, and Provider
UI capabilities position SharePoint as a solid choice for
Pipeline
application development. The flexibility built into SharePoint 2010 allows ISV developers to envision ways in which the platform
Architecture

Deployment
Scalability

can be extended to provide even greater value. For more details from a developer perspective, see Introduction to SharePoint
ASP.NET
Products and Technologies for the Professional .NET Developer13.
Authentication Content & Configuration Databases
IIS SQL Server
Windows Server

Integrate an existing Create integrated solutions Create solutions on top

2001
19

Barriers to Adoption as a Development Platform
We have described some of the ways SharePoint has matured just within the last two product cycles. But are there real
impediments to using SharePoint as an application platform? Let’s address four common perceived barriers: a unique developer
skill set, a closed or restrictive set of horizontal services, the inability to integrate with external or relational data sources, and ALM
and code isolation.

Perceived Barrier 1 - Unique Developer Skill Set
Early in SharePoint’s history, ISV integration and extension of the platform was slow to take hold due to product immaturity and
the complexity of platform integration or extension. For example, the lack of a tight integration into the ASP.NET technology stack
in SharePoint 2003 required investments in specific skill sets or making risky implementation decisions (e.g., ASP.NET developers
could either decide to not leverage their existing knowledge or make unsupported changes to ONET.XML). Although the skills
needed were still based on .NET, the ability to have utility players jump in and code different product features would have been
difficult. This presented some decision points about investment in education, skill sets, and more.
While some decision points persist, the investments can now be amortized across core .NET technologies with less investment in
SharePoint specifics (see Chappell’s Developer Whitepaper14 for a compelling discussion of the technical aspects of the platform).
While it is still imperative for architects and senior developers to have a deeper understanding and specific expertise on the APIs
and architecture of SharePoint, all good .NET developers have a core .NET framework services expertise that will benefit their
work on SharePoint applications – and SharePoint will continue to embrace the new .NET framework capabilities that benefit its
solutions, giving them additional and transferrable skills. Making the investment in understanding the SharePoint Framework
streamlines solution creation because developers can focus on solving business problem and build fewer framework services from
scratch. For larger development teams, the SharePoint expertise investment can be weighted more toward those involved with
architecture and design, resulting in a shorter investment time for other developers (e.g., they don’t need to understand the entire
feature set; they can just focus on the SharePoint API they need to use).

Perceived Barrier 2 - Closed or Restrictive Platform Services
Any platform, including hardware, operating systems, gaming, and others, has inherent features and constraints based on
decisions and assumptions made in its development. The test of a platform’s value is the extent to which it:
1. Provides rich, standard features and functionality; and
2. Enables extensibility and configuration
One could argue that early in SharePoint’s history there were barriers due to preconditions for several of the horizontal services,
chief among them the reliance on Active Directory for authentication. The evolution of SharePoint’s platform services has matured
to provide a rich, extensible set of base functions that address most cross-cutting concerns of modern business applications. An
initial set of services that suited small- to medium-sized teams has been supplanted by one that offer flexibility and extensibility
while providing a standards-based approach to large scale implementations.
Current core features including authentication, navigation, provisioning, and others support a provider model to enable extension
or replacement of base services. The use of common standards such as XHTML, WCAG, REST, SOAP, JSON, RSS, and XSLT along
with standard OS platform services such as WCF, WF, LINQ, and PowerShell enables the use of standard, proven development
processes and practices.
Our first criteria of a platforms value (rich features) is certainly met by SharePoint 2007, and is vastly improved with SharePoint
2010. Access to content and data through a variety of standards and channels provides an infrastructure upon which valuable
applications can be developed. The new Client Object Model and PowerShell support are prime examples of the extensibility and
configuration capabilities of the platform that meet our second criteria of a platforms value. The Client Object Model provides the
ability to extend the use of SharePoint objects in a consistent manner across multiple technologies (including .NET, JavaScript, and
Silverlight) in a whole new class of applications that can span web, Office client applications, and fat and thin clients – and even
provide online/offline synchronization. PowerShell integration comes standard with SharePoint 2010; this integration enables
installation, configuration and management through standard cmdlets and extension through custom scripts and modules. There
is even the option of creating new PowerShell Snap-In’s to provide additional capabilities for administration and maintenance,
opening up yet another avenue for ISV’s to provide value.

20

Benefits of share_point_2010_as_a_product_platform

Benefits of share_point_2010_as_a_product_platform

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Benefits of share_point_2010_as_a_product_platform

Similar to Benefits of share_point_2010_as_a_product_platform (20)

More from Apimuk Siripitupum

More from Apimuk Siripitupum (6)

Benefits of share_point_2010_as_a_product_platform