Friday, January 13, 2012

The SharePoint Development Decision

Parts to this Series (this is Part 1)
Part 1: The Decision to Develop on SharePoint
Part 2: SharePoint Development - People
Part 3: SharePoint Development - Process (coming soon)
Part 4: SharePoint Development - Technology (coming soon)

About this Series
Custom application development is rapidly evolving into a standard subset of an organization's Information Systems infrastructure. It has been a part of most larger organizations for many years now, but I am seeing it rapidly permeate into the lower tiers of organization size. This post will, at a high level, focus on what it means for an organization to have its own application development group--how I think it should be structured and how SharePoint development fits into the picture.

Organizations to Which this Series Applies
The scope of organizations covered in this series is small to medium size businesses (roughly 50 to 5,000 people) whose primary business does not involve the development and delivery of software products to it's customers. That is, they are not a software development company and they are not large.

This post is also geared towards organizations that have made a strategic decision to use Microsoft and related technologies as the foundation for its software development and IT infrastructure. That is, from a development perspective, they are primarily .Net shops.

Definition of Customization
Note that, for this series, I am not defining customization as anything done in SharePoint Designer, through standard web parts, or what many are calling the "Middle-Tier" of SharePoint. For the purpose of this series, I am defining customization as something that uses the SharePoint server-side object model, is usually written in C# and deployed via a solution package.

The Alternatives
Many organizations don't realize or understand the strategic implications of deciding (or deciding not) to develop custom software solutions. In my opinion, there are four basic choices:
  1. Purchase software. Don't customize.
  2. Purchase software. Customize as needed
  3. Write your own software.
  4. Any combination of two or more of the above.
Option Number 1
There is a clear contrast between number 1 and the rest. Specifically, if an organization makes a strategic decision to not write code, they do not need the internal infrastructure that goes with having an internal development process. However, there are a few important drawbacks worth noting. First, rarely can a software product or a set of software products meet all the needs of an organization without customization. Second, the evolution of this strategy ultimately results in a number of disparate systems that don't always play nice together. Third, software companies can be a transient bunch; when a software company goes out of business or stops supporting a product, this can put an organization at risk.

Options 2, 3, and 4
These options all require an internal development infrastructure. This series will go into a lot of detail about what this means for an organization and how to setup this infrastructure, but, in terms of the decision making process, it involves setting up a sometimes costly infrastructure to support the development process.

The Grey Area
It used to be the case that developers wrote code. You knew who the developers were and you knew what code was. This is evolving and will continue to evolve. Both the definition of developer and the definition of code are changing. Is C++ code? Probably. What about C#? jQuery? Javascript? Html? PowerShell? What about a VB.Net macro? How about using a tool like SharePoint Designer 2010 to insert a content editor web part into a page and then copying and pasting some html into the web part?

Eventually, depending on how you define code and developer (and there are already a lot of discussions about this), either everyone will be a developer or virtually no one will.

The Slippery Slope
Increasingly, software is not only more easily configured, but it is also more easily customized. In addition, complex business systems increasingly require both configuration and customization to meet a particular organization's needs. For example, in order to enable a certain feature, the organization may have to write a script. In order to perfectly match business needs, the organization may have to write .Net code--even though they purchased a software product. If the organization is writing a script to enable a feature, why not write a little code to make it more closely match the organization's needs?

SharePoint as a Development Platform
SharePoint is the perfect example of a flexible software product that entices organizations down the path of writing custom code and (sometimes unintentionally) developing an internal software development infrastructure. There are a plethora of scenarios where this might happen. A simple scenario is when an organization needs something that SharePoint can do but requires customization. They are faced with the decision to purchase a different product and possibly pay consultants to implement it and integrate it. Or they could just write a few lines of code in SharePoint to solve the problem. But then, a little while down the road, something changes and the code has to be modified. Or new code has to be written. Or another feature is desired. Suddenly the organization has a full staff of SharePoint developers fixing bugs and writing new features.

The Decision
At some point, organizations need to make a conscious, strategic decision to either have a software development infrastructure that can support customizations...or not. For many organizations SharePoint does not meet all of their needs without some customization.

This is not an IT decision. IT should certainly be consulted, but they do not make the final decision. Organizations, at the most senior levels (CIO, CEO, COO, etc...) need to take a strategic look at how applications support the primary business functions and whether the benefit of building or customizing those applications outweighs the cost and risk of purchasing the applications or doing without them. This applies to SharePoint too. No one should fire up Visual Studio and pound out some code without an organizational decision to have a software development infrastructure that supports custom SharePoint development. I can't stress this enough. Too many times, I have seen organizations trapped by difficult decisions brought about by rogue SharePoint customizations.

Next Step
Once an organization has made the decision to have an internal SharePoint development team, IT will build out a plan for the organizational infrastructure and negotiate resources with senior management based on expected need. This will be covered in detail in the next part of this series.