This is article six in the epic saga exploring my Art of SharePoint Success framework for achieving long-term business benefits from investments in SharePoint based initiatives, (eagle eyed readers will note that last month’s article claimed to be number 6, it was in fact number 5).
There are four elements to the framework:
Last month we began our discussion of the Strategy element by posing the tricky question, “What is SharePoint?” I offered my answer which is,
SharePoint is a set of integrated technologies which provides a platform upon which an organization can build a flexible, long-term information and knowledge management infrastructure.”
We discussed the concepts of SharePoint as a set of integrated technologies, and as a shared infrastructure. This month we explore the idea of SharePoint as an application development platform and examine the implications of deciding to fire up Visual Studio and cut SharePoint code.
SharePoint Is an Application Development Platform
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 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, 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:
- What is SharePoint’s role in your application development strategy?
- Which applications are right for SharePoint?
What Is SharePoint’s 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).
- application and Intranet
- enterprise Portal
The simplest approach is to view SharePoint as an application only. Under this approach, SharePoint is deployed as-is, customizations are probably limited to either configuration through the web browser, or no-code customizations using SharePoint Designer.
Next, SharePoint can be used as an application and an intranet platform. In this model, intranet application(s) are built on the SharePoint platform. Often this includes significant customizations and you may work with a partner during the initial deployment. Once the deployment is complete you may limit in-house customizations to no-code solutions through SharePoint Designer or configuration through the browser.
Finally you can adopt SharePoint as an enterprise portal, a core component of your application development strategy. Under this model 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), e.g. 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 coordinate efforts and standards across dispersed development teams.
Provision for application development is much improved in SharePoint 2010, 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 organizations 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 organizations it is the I.T. team that introduces SharePoint, and developers usually want to develop. Step away from the keyboard!
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 customizations 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, e.g. 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 website 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, 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 for ICS Solutions where a client produced a list of functional requirements for a 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, and that was way over the available budget. 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 a successful solution was delivered for £90,000, and we didn’t write a single line of code.
For Next Time and Beyond…
In my next article, I’ll conclude my definition of SharePoint with a look at SharePoint as an information and knowledge management platform. Next, we’ll move on to look at the "strategic lenses" that I use with clients to help them form their SharePoint strategy and then we’ll start the new year with a bang when I’ll reveal the never-seen-before, definitive guide to the business case for SharePoint.
Editor's Note: You may also be interested in reading: