In Part 1 of this series, we looked at a simple template to help you can use to help document the security roles that need to get created for your new SharePoint application. In this part, we will look at a common process that is used to augment your Software Development Life Cycle (SDLC)and targets applications that you think might be suitable for running on the SharePoint platform.
As you read through this blog post it is important to note that this process (or something similar) can be used to augment your SDLC, not replace it. SharePoint does a lot out of the box and can be configured to solve a wide variety of business problems. However, many of your SharePoint-based applications will require custom development. When developing custom code for SharePoint, you should always follow your existing SDLC process.
There are many many blogs/articles/books/etc. that describe how to properly document, architect, develop, test, etc. your application. There hasn’t been much written on how to properly document an application that is configured rather than custom developed. Many times (especially in larger organizations), SharePoint configuration is not done by a development team but rather a configuration team with skills specializing in SharePoint Designer. Before we discuss this, let’s look at an example of a process that can be used for SharePoint application configuration:
Let’s walk through each phase of the process and describe the flow.
1.1 Receive Requirements, 1.2 Review Requirements, 1.3 Revise Requirements
This process starts at the time that the Architect receives the application’s requirements. At this time, it is typical that he/she will review the requirements and determine what type of application is required (custom developed application or SharePoint application). During the requirements review (which usually occurs with a representative of the business and a business analyst), you will quickly begin to understand what type of application will need to be built. This is the time at which you will need to revise the requirements to ensure the best technology fit for whatever type of application you will be building. If the requirements need revision, then you as the architect will need to help revise the requirements and then either re-review or proceed to the next step.
2.0 Determine the Application Type
Probably the most important decision that you are going to have to make in this process is to determine what type of application that you will need to build. This decision will determine how successful your application will be once the users start using it. Many times, your users will have in their mind what type of application they want, but you will need to make the final decision. As a side note, you can get into a real bind if you try to fit a square peg into a round hole here. If your application should live in SharePoint then design it to do so, if not then you will need to develop something custom. The key advice that I can give you from experience here is try to stay objective and don’t let politics, or preconceived notions get in the way of the right decision. You will be thankful in the end.
If you are going to build a custom application, proceed to step 7.0, which is your existing SDLC. If you are going to be building a SharePoint application, proceed to step 3.0 and perform a gap analysis.
3.0 Perform a Gap Analysis
Now that you have decided that you will be building a SharePoint application, you will need to do a gap analysis against the requirements. You can easily store the requirements in a SharePoint list, however for demonstration purposes, this example will use an Excel Workbook. I typically add a few columns for the analysis as illustrated below the sample (and VERY barebones) requirements document.
As you can see, the gap analysis process is very simple. In this example, you are only concerned with four columns: Requirement ID, Requirement, Architect Comments, and Effort. I will be detailing this process out in a future blog posting, so please stay tuned.
4.0 Requires Customization or Configuration
The results of your gap analysis will need to be looked at very closely to determine if your application can be configured using the SharePoint OOTB features or will require custom code to be written. Here, you will need to evaluate which requirements are supported OOTB, which require configuration, and which require custom code. Many times if a small percentage of the requirements require custom development, you can likely negotiate these requirements so that you can deliver a custom configured application.
If your application requires custom development, proceed with step 7.0 (SDLC). If you will be configuring your application then you will next need to document how your application will be configured.
Side note: I have seen that SharePoint applications that do not require custom code can be delivered much faster than SharePoint applications that do. You can deliver a custom configured application in a matter of days as opposed to weeks/months for a custom developed application. This will save you and your company both time and money (in development and maintenance) if you can configure you application with no custom code.
5.0 Document Configuration
Step 5.0 in the process is probably the most controversial. Why do you need to document the configuration of an application when (many times) you can get the application configured in about the same time that you can document the configuration? That’s a trick question and it all comes down to your SharePoint governance plan. I have seen this step skipped in a lot of applications and 100% of the time it will come back to bite you.
Software applications are funny things in that they almost always break. If your application breaks, and it usually happens weeks, months, or even years after your application has been deployed, then you will need to remember how the application was setup before you can begin to solve the problem. It doesn’t have to be complex, so any documentation that you can do here will be helpful.
It is also important to note that a SharePoint application that doesn’t have any custom code offers the ultimate flexibility to add future features to your application. Without documenting what has been configured, you will find it very difficult to add custom-code features to your application without knowing what will be affected when you deploy the custom features.
I will be covering this in detail in a future blog posting.
6.0 Configure and Test the Application
Once you have documented your application configuration, you can now configure it using SharePoint Designer and/or the SharePoint web interface so that your users can start using the application. Once the application is configured, you should always test the application to ensure it works as intended. I have seen this done many ways, but it helps if you have use cases so that you can test different user scenarios. In the absence of use cases, you should walk through the application with your users to ensure everything is working properly.
Once your application has been configured and tested, it is ready to be released to your users.
If you skipped step 5.0, please go to step 5.0 and document your application’s configuration!
7.0 Proceed with SDLC
Step 7.0 represents your Software Development Life Cycle.
I hope that you find this process useful and can integrate it into your SDLC for SharePoint applications. I have seen a lot of success by adding a few steps to the SDLC to ensure that I am developing applications that should be developed and configuring applications that should be configured. Please let me know what you think about this and if it works (or doesn’t work) for you. I will be detailing out sections 3.0 and 5.0 in future blog postings, so please stay tuned!