Notice: I wrote this when I was still working for NNIT, but the principles still apply.
Eli Robillard wrote a post on “When to use a database, SharePoint, or wiki” with the following highlights:
A database stores structured data. The structure is typically designed and owned by an individual. Politically, it’s a dictatorship. Line-of-business applications which gather and distribute raw data are typically associated with databases.
Sharepoint provides webs to store lists and documents. Think of this as loosely-structured data. Sharepoint lets you control this data with versioning, backup and recovery, workflow, security, policies and auditing. The structure might be seeded by an individual, but ownership is distributed. Sharepoint should be designed to unfold according to to will of the distributed owners. Politically, Sharepoint provides representative leadership like a parliamentary system though the leaders are typically appointed rather than elected. Sharepoint is used by “information workers” to create, manage, and publish information typically stored in lists and documents. Sharepoint is used as an interface to databases. Sharepoint is a social tool used to recognize and reinforce relationships among people. Through either Sharepoint’s business intelligence capabilities or its integration with Reporting Services, Sharepoint can report on data from structured and loosely structured data stores. Sharepoint can index and provide search for structures, loosely structured, and unstructured data stores.
A Wiki provides webs to store text with embedded references to media. This is unstructured data. Wiki content can be seeded with the intention to unfold according to some master design, but politically, it’s anarchy. A Wiki allow control through versioning and moderation. A Wiki is well-suited for collaborative documentation.
I the years to come eS will hopefully get the chance to convert a lot of Lotus Notes databases to Sharepoint. Each time you have to stop and figure out which one or all of the above mentioned data storage mechanisms you have to use in order to convert the functionality of the Lotus Notes database to Sharepoint.
Lotus Notes databases basically comes in two flavors:
- Plain data (one or more tables) with views and no LotusScript code – basically it’s a spreadsheet with alphanumerical data
- Data with views, references and business logic in LotusScript code – basically it’s an application
In the first case it’s a no brainer to just convert the database into a WSS site with the data in custom lists combined with custom views and perhaps a few Web Part Pages thrown in with connected Web Parts that displays data. This is exactly what JPTL is doing right now with a Lotus Notes database from Novo Nordisk Stakeholder Relations.
In the second case it’s much more difficult and each Lotus Notes database or more appropriately Lotus Notes Application has to be thoroughly analyzed. Once you have a good understanding of the business requirements and these was implemented in the Lotus Notes Application – stop and take a look at the slide below.
Your job now is to transform the business requirements from the square Lotus Notes approach to the round Sharepoint approach.
Can you fulfill the same surface area of business requirements with standard Sharepoint functionality? This is where creative use of lists (custom, tasks, wikis and so on), document libraries, views, Web Parts, workflows and Web Part Pages comes in.
Obviously there will be cases where it’s just not possible to get the job done and you’ll have to revert to a normal application design with ASP.NET (remember that Web Parts in WSS3.0 is a ASP.NET2.0 Web Part) and a backend database – but hopefully it will won’t be very often. You could take the middle road and use a list for storage and you could even use SilverLight for the UX instead of ASP.NET.
