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.


  1. Great idea for a series! I agree that the decision to do custom app dev should come from mgmt-generated needs, not administrative ones. Do you think there are particular types of organizations whose work cultures are more suited to custom dev than others?

  2. Thanks for you question Claire.

    It is somewhat difficult to write a good response without writing a whole other blog post, but I do think the culture of an organization can play a role in whether it makes sense to do custom development. I will get into the methodologies in future posts, but development methodologies have evolved very rapidly in recent years. Being good at developing software is, to some degree, an organizational competency that has to be nurtured. That is, the organization nurtures knowledge, processes, and culture that facilitate high quality, rapid development.

    Most development projects today require high flexibility in timing and delivery, a constant feedback loop between developers and end users, and a strong understanding of the business need driving the software development. Culture can inhibit or help any of these things. I have seen organizations, for example, that have a culture that does not support thorough and steady communication to developers regarding project direction and strategy...especially when the project direction and strategy change over the lifetime of a project. This culture may exist for good reason and help the organization maintain profitability in its core business function for other reasons. Requirements may get updated, tasks reassigned, deadlines pushed, etc... but the difficulty, is that, depending on how the development process is structured, a developer may make a thousand small, independent decisions when writing an application. If she doesn't understand the bigger picture, those decisions, while insignificant by themselves, collectively add up to a project that doesn't meet the business need.

    Organizations need to evaluate how capable they think they are at meeting business needs by doing custom development. That capability needs to then be compared to the alternatives (purchasing a third party product, hiring a consulting company to do custom development, etc...). Part of the process for evaluating an organization's ability to do custom development is answering the question, "Does our culture support or inhibit the development process when using the best methodology for the types of project we would undertake?"

  3. Actually Products and Technologies offer a manageable and scalable server platform that employs the benefits SharePoint Development.

    SharePoint Developers

  4. Doug you are quite correct at your points, people are going for custom development without any reason, means when there is no requirement why to apply it. There should be someone in the organization who can identify the exact needs of software development and the things being applied on it.

  5. The release included a library of reusable components, a guide, and a new reference implementation of a Partner Portal application. It expands upon the first release which delivered a Training Management application.