Migrating from SharePoint configuration to SharePoint development

Daan De Brouckere — Tue, 18 Dec 2007 14:54:00 GMT

If your IT organization is one of the many experimenting with a simple SharePoint implementation, you'll agree that the out-of-the-box functionality is quite amazing. You can enable your business users to quickly manage their own content, setup workflows, and collaborate. The part that gets interesting is when you're ready to actually start building applications on top of SharePoint. For example, the publication and approval process for content changes doesn't require you to maintain multiple environments, such as development, test, staging or integration environments. Your users are making changes in production! That kind of behavior is severely frowned upon in traditional application development. How do you introduce simple applications in SharePoint while at the same time ensure your business users continue to enjoy the same level of freedom for managing their content?

It all starts with understanding the difference between what Microsoft calls “Artifact Development” and “Assembly Development”. For those of you who are familiar with Software Development Lifecycle processes, the transition to “Assembly Development” will feel very comfortable. It consists of developing code, packaging it up, and deploying it through various test environments before deploying in production. The “Artifact Development” process will require some behavioral changes on behalf of your users that had the freedom over your content. Instead of making content changes directly in production, you’re now asking them to follow a more rigorous process where they’re packaging up their content changes using SharePoint Designer. To understand more about these how to join these two processes, check out the following article on MSDN: Team-Based Development in Microsoft Office SharePoint Server 2007

Before investing too much time and energy in building out formal processes and environments, determine how much SharePoint development your organization will really be doing. Are you just considering building a few features that extend some common behavior, or is SharePoint going to be your platform for a custom workflow solution? How robust is your current application development methodology, and how can you best leverage the tools and processes you already have?

Once you’ve thought about these questions, you can start building the plan for your own customized SharePoint development process.

Crowe Solutions Architecture Blog : Development

Migrating from SharePoint configuration to SharePoint development