Case Study

It was the usual story: a short deadline and a tight budget. The client's internal staff said "No way" to build the Web-based application in fewer than six months, with any fewer than three full-time resources. The project needed to be completed in two months. It included custom authentication, collaboration, business rules, and forums. Therefore we chose SharePoint 2007 as the development platform and configured the solution to handle 80% of the functionality. Where SharePoint could not meet the requirements through configuration, we developed custom code to complete the other 20%. Herein we'll detail some best practices and lessons learned from our implementation.

Project Background
The client, a leading provider of information and technology solutions to the worldwide financial community, wanted to construct a social networking portal. They wanted to establish mindshare and market leadership in this area, driving more business to the company from technical investors. This notoriously fickle but lucrative group of investors represented a great market potential for the company. They wanted to get in touch with this community, and provide an opportunity to expand their brand presence in this demographic. Their internal user base was in the hundreds, and they planned on an external user base of over 10,000.

The portal had some fairly general requirements (support documents, blogs, forums, and wikis) as well as some specific requirements. For this particular portal, content would primarily revolve around documents, especially Word, Excel, and PDFs. The technical investors would be able to post ideas, financial models, equations, and charts/graphs to the portal in documents. Each document would be version controlled, and would generate its own discussion area automatically upon submission. This made it easy for the technical investors to comment and improve upon the documents, collaborating to make the models and content better. The company wanted to be able to access the portal internally to administer it (using their internal proprietary authentication system to connect), as well as allow users from the Internet to access the application using Forms Authentication - a hybrid authentication model that has become more commonplace, as companies want to share specific parts of their portal content with external users, vendors, clients, and partners.

The marketing department sponsored the project with the blessing of the IT department to use SharePoint 2007 and to deploy the solution to production servers. However, they did not have the resources to get the project done. The IT department was already committed on several other projects and was unable to lend implementation assistance. The company retained Syrinx to help design, implement, and deploy the solution. Our extensive experience in developing SharePoint solutions, and our experience doing so in the financial services vertical, made the choice easy for the company.

Development Approaches
Most Web applications are developed using a well-worn project life cycle that roughly follows these steps:
Gather loosely defined requirements

1. Build a prototype to demonstrate flow and navigation
2. Finalize requirements
3. Build the application
4. Test
5. Deploy

Some content is part of the application (dropdowns, choices, pre-existing data). The rest of the content is added by the users after deployment, as they start to use the application. There might be some automated data loading to pre-seed content as well (see Figure 1). It is very important when developing solutions that the architect understands how the business processes work from the user perspective. Otherwise, the application may not reflect how the user works and will surely fail. Also, the application tends to start its life in a development environment, and both code and content push forward in one direction to the production environment. This process is repeated in subsequent releases.

SharePoint 2007 projects that feature a heavy amount of user-generated content and documents follow a slightly different project life cycle:

1. Gather loosely defined requirements
2. Create a Site Collection
3. Add real content
4. Gather specific requirements for custom development
5. Build custom developed features
6. Test
7. Deploy

In this case, the site collection is created in the production area first. Users are encouraged to add real content, and templates, lists, libraries, and files are constructed. SharePoint functionality is used to create as much of the application as possible through configuration. When the limits of SharePoint's built-in capabilities are exhausted, a gap analysis is performed and any features that require custom code development are now defined and designed. Content is pushed back from production to development, by way of staging. From there, custom code is developed as a Feature (a package of deployable code in SharePoint 2007) and pushed forward to staging and then production.

Figure 2 shows code and content flow in a SharePoint application.

Why do things this way? Why not just develop everything (code and content) in development, and then push everything forward? Or perhaps just do all of your development in the production environment? The latter approach can lead to obvious stability problems, as the developers introduce new code and the users constantly introduce new content, with the potential to clash. Defining the content in production and pushing it back allows this process to be iterative and parallel without breaking existing content and features. For a first iteration, developers could just push everything forward (content and code) from development to staging to production. But users in production can then do things like create new lists, add columns, create views, and otherwise add to and alter content. Code needs to be developed against this latest version of the content schema in order to work correctly. For this reason, the sequence of bringing the content back from production, developing, and then pushing features forward for every iteration makes sense. This also obviates the need for a staging environment. Since users might change the production content schema while you are developing, you must pull the latest content back to staging just before a deployment. Pushing the new code up from development to staging after this allows you to make sure your features work with the absolute latest content schema in production before releasing them to the world.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...