- The Problem with the Evolutionary Approach
- Microsoft SharePoint 2010 Lists to the Rescue!
- A Short Introduction to Microsoft SharePoint 2010
- Survival of the Fittest
- 3<sup>rd</sup> Party Products
- Divinity versus Darwinism
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
You're probably at least vaguely aware of Microsoft SharePoint. It's an ASP.NET application, a platform that allows users to build websites, using Microsoft SQL Server as the database. SharePoint users can create multiple websites, with different content and for different purposes.
Microsoft SharePoint 2010 (as well as previous versions of SharePoint) has a mechanism called lists that look similar to Microsoft Access tables. A list is a container for information, similar to a simple database or worksheet, and is the most common way to manage information in a SharePoint site. In a list, data is gathered in rows; each row is known as a list item. A list can have multiple columns, also known as properties, fields, or metadata. Users enter information in these rows, and at the back-end that data is stored in a SQL database.
This means life is easier for business users – they don't need to create forms for data entry or for searching, because SharePoint has those capabilities built in. Users cannot create macros or custom code (one limitation of SharePoint lists, as opposed to Microsoft Access), but most users still manage to get exactly what they need.
Lists can have relationships, such as "lookup" columns pointing from one list to another, to the user database, or to external information sitting in a line-of-business application. A common example is to create lists for customers, products, and orders (the latter with a customer column and a product column). This kind of order-entry application can be created by an end user in a matter of minutes. Allowing users to see a need and act on it is the whole purpose of the evolutionary approach.
Users can develop any number of list-based applications for themselves. In addition to their obvious similarity to Microsoft Access tables, some lists are actually based on list templates that Microsoft has provided in SharePoint:
- A task list allowing users to assign and track tasks within the team.
- A survey for gathering opinions of fellow employees.
- A list of projects and a related list of contacts.
- A vacation calendar in which each team member records when he or she will be away, allowing the manager to have a unified view of vacations.
Figure 1: An entry form for a simple task list in SharePoint 2010.
Microsoft SharePoint lists are more than simply forms for data entry. They also provide users with various ways of getting at their data. Even the free version of SharePoint that comes with Windows Server includes functionality for searching on lists by using keywords. Users can create public or private views to display the data in different ways, and to ease their search for information. Views can be sorted, filtered, or grouped. For example, a “Data Sheet” view works similarly to an Excel worksheet, a calendar view is date-based, and a Gantt view shows project status.
Users can add columns to lists and manage their security on those lists, all without the intervention of the IT department. The IT department can rest easier knowing that all the data is backed up (since it's on SQL Server, which presumably is well managed by the data center). Users can share information just by sending other users a link to the list and giving them appropriate permissions. If the IT department sees a user-created list that's a good idea, they don't need to redevelop it in another platform; they can just reuse that list in other sites.
Before long, users will demonstrate their lists to colleagues in other departments, and the use of these lists will grow even without IT department intervention. The business will gain efficiency without having to contract business analysts to figure out what users want, since the users themselves build what they want!