SharePoint is notoriously difficult to define.  For example in the keynote presentation at the Microsoft SharePoint Conference 2009 Microsoft’s CEO Steve Ballmer said,

“What is SharePoint?  This is still a question I get asked when out visiting customers… It’s kind of magical in a certain way.  It’s a really special kind of product… It’s kinda like an operating system” (Ballmer 2009)

I’ve presented to a team of Microsoft employees who sell SharePoint for a living and they weren’t able to offer any more coherent answers. zForrester Research sum up the problem,

“Like the ‘Shimmer’ product commercial in the old Saturday Night Live skit, SharePoint can be difficult to define… Without clear definition of SharePoint Enterprises struggle… lacking appropriate guidance, organisations grapple with SharePoint..” (Koplowitz & Le Clair 2008)

Here’s my attempt to define SharePoint,

SharePoint is an set of integrated technologies which provides a platform upon which an organisation can build a flexible, long term information and knowledge management infrastructure.

A bit of a mouthful! But this definition includes what I believe are the most important elements.  The following sections explore these ideas in more depth.

SharePoint is an umbrella term (and license) for a set of technologies that could be packaged as individual products.  Performance Point Server, Portal Server, and Content Management Server are three former products that are now part of the SharePoint brand, the anticipation is that the FAST search product will cease to be a product in its own right with the release of SharePoint wave 15, and Microsoft have recently announced their acquisition of the social networking product Yammer and if Microsoft continue with their integrated platform technology that too will likely become part of the SharePoint brand.  It’s also easy to see how technologies such as Excel Services, document management,  and  MySite could be stand-alone products.  Microsoft  has an explicit strategy to develop these technologies as an integrated set.  Historically the  strength of SharePoint is in its breadth more than its depth,  but the depth increases with each product iteration as the technologies become more mature.

A SharePoint license provides a full range of information management capabilities and the more of those capabilities an organisation uses the greater the potential return on investment.  If you already use SharePoint for your enterprise search then perhaps you don’t need to invest in another document management system? Understanding the breadth of SharePoint and the extent to which you anticipate leveraging the range of different capabilities is one key element of developing a SharePoint strategy.

SharePoint is a rich platform for building multi-tiered web applications. It possesses the three defining characteristics of an application development platform (Lele 2007)

• extensibility
• scalability
• reliability

Extensibility refers to the hooks which enable integration  with other systems and applications, and the mechanisms for expanding the platform by developing new capabilities. SharePoint’s many such hooks and mechanisms include but aren’t limited to  the following:

Scalability is a characteristic of a system which enables it to handle growing amounts of work in a graceful manner.  SharePoint is a highly scalable platform at both the physical and software layers.  At the physical layer SharePoint can be scaled up by adding additional resources to the servers in the farm, or scaled out by adding additional servers to the farm.  At the logical or software layer the key to SharePoint’s scalability is the containment hierarchy of web applications, site collections, sites, and lists and libraries; and the service application model.

Finally, reliability refers to the ability of a system to perform consistently, on demand, without degradation or failure. SharePoint exhibits this characteristic by supporting redundancy at the physical layer, with multiple servers at the web front end, application, and database level; and at the logical layer through service applications.

There are two key questions that arise from viewing SharePoint as an application development platform:

1. What is SharePoint’s role in your application development strategy?
2. Which applications are right for SharePoint?

The following sections explore the answers to these questions.

What is SharePoint role in your application development strategy?

There are three basic strategies when considering SharePoint’s role in your application development strategy (Rymer and Koplowitz 2008).

1. application
2. application and Intranet
3. enterprise Portal

The simplest approach is to view SharePoint as an application only. Under this approach SharePoint is deployed as-is, customisations are probably limited to either configuration through the web browser, or no-code customisations using SharePoint Designer.

Next SharePoint can be used as an application and an intranet platform. In this model an intranet application is built on the SharePoint platform. Often this includes significant customisations, and you may work with a partner during the initial deployment.   Once the deployment is complete you may limit in-house customisations to no-code solutions through SharePoint Designer.

Finally you can adopt SharePoint as an enterprise portal, a core component of your application development strategy.  Under this model the you are likely to have a fully-fledged and experienced internal software development team or a close relationship with a development partner, and SharePoint is considered for all web based applications.   There are a number of additional considerations when taking this approach such as,

• The development and enforcement of SharePoint specific coding standards for internal developers and external development partners
• Maintaining the necessary skills within your development team, ideally your SharePoint developers should have the two Microsoft SharePoint development certifications
• You’ll need to establish a robust approach to Application Lifecycle Management (ALM) i.e. defining the process, procedures and standards for creating SharePoint solutions and moving them through development, integration, UAT, and production environments
• In a global deployment with regional SharePoint farms you might have to co-ordinate efforts across dispersed development teams

Provision for application development is much improved in SharePoint 2010 technologies, but establishing a robust, efficient and effective SharePoint development practice is still a significant undertaking.  Will the costs outweigh the benefits in your case?  My usual advice is that organisations should begin with the first or second strategy and evolve towards using SharePoint as an application development platform rather than starting at that point.  The challenge is that in many organisations it is the I.T. team that introduce SharePoint, and developers usually want to develop!  For example in 2010 the Head of Global IT Strategy for a major investment bank told me of his frustration that although SharePoint was supposed to make things easier, “Every time I ask a question about implementing something on SharePoint I am told it will take thousands of lines of code.”  When I asked him who he was asking he answered, “My development team.”  After a short period of investigation we discovered that in many cases the developers were writing new components to replicate existing functionality in SharePoint because they didn’t like the way the SharePoint components worked.

Which applications are right for SharePoint?

If you decide that SharePoint will play a role as an application development platform then you’ll need to be able to determine when to use SharePoint and when not to use it.  One of the dangers with SharePoint is that when you have a hammer everything looks like a nail, which is to say that if you’re not careful SharePoint can seem the default solution to every problem.  Using SharePoint introduces an additional layer of cost and complexity in application development and maintenance, and the heavy customisations can make things tricky when it’s time to upgrade the platform to the latest release of SharePoint so are you sure you need to use SharePoint for that application?  There is no single right answer but here are some of the key considerations in my experience.

• SharePoint is best suited to managing unstructured information, i.e. documents as opposed to data.  If your solution is entirely data driven then perhaps SharePoint isn’t the best way forward?
• if you’re not using any of the SharePoint workloads such as search, content, communities, insights, sites, or composites then why would you use SharePoint?
• SharePoint is an excellent tool for situations when you need to create multiple instances of a web site based on a common template.  For example a site for every supplier, every customer, or every project.  if you only need one site that displays different data to each user or audience then again perhaps SharePoint isn’t the right tool for the job?
• Can you leverage the out-of-the-box functionality to achieve your goals, rather than building a custom solution?  I was involved in a project where a client produced a list of functional requirements for solution which was to replace four existing legacy knowledge management applications.  Our first estimate for a custom solution to meet the specified requirements was £250,000.  When we sat down with the client and discussed their goals rather than their requirements we were able to demonstrate to them that built in functionality within SharePoint could be used to meet the goals in a slightly different way than they had anticipated.  The end result was that the solution was successfully delivered for £90,000, and we didn’t write a single line of code.

In 2005 analysts at Forrester Research Inc. coined the term “Information Workplace” to describe the work place of the future for information workers (Driver and Moore 2007).  They define the information workplace in terms of seven tenants.  Table 4 summarises the seven tenants of the information workplace.

Table 4: Seven tenants of the information workplace

To realise the vision of the information workplace an organisation needs a technical platform which provides the following set of capabilities:

• content management
• collaboration and communication
• portal framework
• pervasive business intelligence
• office productivity
• search
• human centric business process management
• information rights management

This presents us with a basic strategic choice:

1. Select best of breed products for each area and integrate them
2. Select a unified infrastructure that delivers the breadth of capabilities

Option 1 has the benefit of delivering best of breed functionality across all capabilities, but do you really need the best?  On the downside the IT function has to maintain several different technologies from different vendors who may all have different strategies and roadmaps for their products; integration can be difficult, costly and time consuming; and for the users learning to use several different technologies can be a barrier to adoption.

Option 2 has the benefit of lower costs as a single license and technology platform delivers the breadth of capabilities; integration is simpler; and users only have one technology to adopt. On the downside the single platform may not have the same depth of functionality as the best in breed products, and you may prefer not to put all your eggs in one technology vendors basket.

If you follow strategic option number 2 and select a unified infrastructure then your next challenge is to select the technology and vendor…

SharePoint is infrastructure

Infrastructure can be defined as,

“Substructure or underlying foundation; esp., the basic installations and facilities on which the continuance and growth of a community, state, etc. depend, as roads, schools, power plants, transportation and communication systems” (Yourdictionary 2011)

SharePoint is your information management infrastructure and infrastructure  has a number of defining aspects.

Infrastructures are open.  There is no limit to the number of users, stakeholders or vendors that can be involved.  There is always something on the outside of the infrastructure that could be connected.  With SharePoint this could refer to opening up or connecting your SharePoint platform with partners, suppliers, customers.  The openness of the SharePoint platform could be a problem when defining your approach to SharePoint.  Where do you draw the borders?  How do you define the scope of your SharePoint implementation and use?

Infrastructures have a supporting or enabling function.  SharePoint is an enabler as it  provides a set of capabilities which can be used and reused in many ways and for many purposes.  For example a transport infrastructure consisting of road, rail, and air links enables commerce, education, health services, and social activity.  The benefits are derived from the services that are implemented on the infrastructure rather than from the infrastructure its self and so it is with SharePoint.   This is one contributing factor to the difficulties that many organisations face in creating a business case for SharePoint.  There are significant costs involved in deploying the base infrastructure of servers and software, yet this base platform does not deliver any direct business benefits, cost reduction through technology consolidation notwithstanding. Often the first SharePoint project in an organisation has to bear the costs of implementing the infrastructure, even though the benefits are spread across the multiple solutions it enables.

Infrastructure is shared by a larger community.  A single SharePoint platform can appear to the users in many different ways. A shared infrastructure requires commonly understood guidelines, or rules of the road, to co-ordinate the multiple groups of users.  This underlines the need for effective governance and management of SharePoint.

Building large infrastructure takes time.  As time passes requirements will change and evolve and the infrastructure needs to adapt.  Infrastructure is never complete, and your SharePoint implementation will never be finished.