SharePoint Developer Survey: How do YOU do SharePoint development?

I am curious how many SharePoint Developers (individuals, IT groups, consultants, and ISVs) are making use of any or all of the Microsoft Patterns and Practices SharePoint Guidance.

Advertisements

Why are you still not focused on the business when implementing SharePoint?

Over the past week I have been reading a couple of recent SharePoint-related papers, and thought I would share some of my thoughts.

The first paper is entitled SharePoint – strategies and experiences from AIIM. This document presents the results of a survey of 624 AIIM members last spring regarding experiences and plans with SharePoint. I strongly recommend downloading and reading the entire report, as I do not intend to cover all of it in this post, only those items that seemed interesting to me (which is actually difficult, because there is a fair amount of interesting stuff in there!).

The findings I found most interesting were:

  • Lack of business-case justification for implementations
  • Governance challenges
  • Perceived ROI
  • Implementation challenges
  • The number of organizations planning to upgrade to SharePoint 2010
  • The ranking of most popular uses of SharePoint

For me, the most startling result in the report is

Half of SharePoint implementations went ahead with no business case being made to justify the
investment. Only 23% were required to make a financial justification. Where a business case was
made, improved collaboration and better knowledge sharing were the main benefits assessed.

Is it just me, or is this insane? As I said last year in my column Danger! Do not implement SharePoint in your Organization!, the focus of your SharePoint implementation should be solutions to real business problems, bringing real business value. A business case is not just something you do in order to get funding. It is something you do so you understand what functionality you are implementing and why. Not doing a business plan is setting the project up for failure, but for a failure you may never know about. After all, if you have nothing against which to measure success, how can you even know if you have failed, or at least failed to live up to potential? I guess I am optimistic, but I thought everyone understood this by now.

The second point is equally astonishing to me. While the first links I saw to the AIIM document had headlines implying some weakness in SharePoint governance was found (here for example), the real finding is that many of the organizations implementing SharePoint simply do not put appropriate governance in place. A great many organizations have a lack of definition of governance of features, sites or content.

Surprisingly, despite the lack of business case and governance, most of the organizations surveyed were happy with the ROI achieved (which is amazing if they had no definition of what they were trying to accomplish!). Only 9% said that the ROI was worse than expected. Then again, maybe this is just a reflection of having no real idea of what you expected the ROI to be.

The results also identified some of the challenges faced when implementing SharePoint. Among the key issues identified were:

  • Managing process change
  • Took longer than expected
  • User resistance to new UI
  • Technically more difficult than expected
  • Cost more than expected
  • Poor performance/infrastructure capability

All of these, in my opinion, are reflections of lack of planning and lack of business case. While many of these challenges are common even in the best of circumstances, a lack of a clear, business-focused vision and plan will invariably make them worse.

There were also a couple of positive results from the report (more than a couple, but 2 I will mention here).

The results indicated that 13% of the respondents are planning to upgrade to SharePoint 2010 almost immediately, while half are planning to within a year. I see this as positive, anyway.

It was also interesting to look at what SharePoint features are most popular in these organizations. While I always tend to think of SharePoint primarily as a portal platform, and a solution development platform (hey, I am a developer), the most popular usages found in the survey were:

  1. Collaboration
  2. Document management and file-share replacement
  3. Portals
  4. Intranets

These are just some of the points I found interesting in the report. Again, I strongly urge anyone looking at SharePoint to real the whole report.

What’s Wrong with SharePoint?

So, I am watching Twitter updates go by (as I always do, even on a Saturday night), including my search that shows me all the tweets with “sharepoint” in them. As anyone knows who watches any amount of SharePoint commentary go by, there is a fairly constant flow of comments of the “SharePoint sucks” variety.

So this evening this led me to ask the question “What is wrong with SharePoint?” No, I do not mean I want a list of every nit picking, annoying little defect – every platform has defects and annoyances. I also do not want to know why SharePoint is note good for everything – no platform is good for everything. I also do not give a crap if your opinion is “it comes from Microsoft therefore it MUST suck” – it that is as deep as your analysis can go, well, you’re a moron.

What I want to see from SOMEONE is an intelligent, well thought out description of why SharePoint sucks. Why is it a bad choice for anything? Why should you perform an exorcism on all servers running any version of SharePoint?

I did a web search (notice I did not say “google” – contrary to popular usage, google is not a verb) for “what is wrong with SharePoint?” The only relevant results I found on either Google or Bing were written in 2005 or before, and hence are not particularly relevant at this point. For example, the post Five Things Wrong with SharePoint from back in 2005 tries to talk about what is actually wrong  with SharePoint. Even though I disagree with a lot of what it says, I will not refute it since it is so old.

So – if SharePoint is so bad…if all the otherwise intelligent people implementing solutions over SharePoint are wrong – where the heck are the statements as to what is wrong with it. So tell me – WHAT IS WRONG WITH SHAREPOINT? I really want to know, and to share it with others.

Working with Association Data in MOSS Workflows

I received a couple of comments in response to me previous post on Custom Association and Custom Initiation forms regarding how to use the Association and Initiation data collected, from within the workflow code. I had answered in my responses that you just access the AssociationData and InitiationData members of the WorkflowProperties, which return the data as XML strings. You then just work with that XML as required.

Here I will present some sample code for actually working with the XML coming from the custom AssociationData.

First, I would like to step back though and look at designing the Association Data. Typically when working with any InfoPath form, I start from the data side, and develop an XML Schema for the data (ideally, this is done as part of the overall design of the solution being developed, and includes all of the data design for the solution). The code snippet below shows the schema I developed for this example.

<?xml version="1.0" encoding="utf-8"?>
<xs:schema targetNamespace="http://t4g.com/TestSchema.xsd"
           elementFormDefault="qualified"
           xmlns="http://t4g.com/TestSchema.xsd"
           xmlns:mstns="http://t4g.com/TestSchema.xsd"
           xmlns:xs="http://www.w3.org/2001/XMLSchema"
>
   <xs:element name="AssociationInitiationData" type="AssociationInitiationDataType" />
   <xs:complexType name="AssociationInitiationDataType">
      <xs:sequence>
         <xs:element name="TaskDescription" type="xs:string" />
         <xs:element name="AssignTo" type="xs:string" />
      </xs:sequence>
   </xs:complexType>
</xs:schema>

Note that this schema represents both the Association Data structure, as well as the Initiation Data. It is necessary for these two to share a schema and namespace, though the Association form need not populate all of the fields.

A Custom Association Form can then be developed in InfoPath based upon this schema, and deployed as described in my previous post.

Now, how do we access this Association Data from within our workflow?

I implemented a simple serializable class matching the schema, as shown below.

[Serializable()]
public class AssociationData
{
   private String _TaskDescription;
   private String _AssignTo;

   public String TaskDescription
   {
      get
      {
         return this._TaskDescription;
      }
      set
      {
         this._TaskDescription = value;
      }
   }

   public String AssignTo
   {
      get
      {
         return this._AssignTo;
      }

      set
      {
         this._AssignTo = value;
      }
   }
}

I also implemented a helper class (creatively named) to support loading the Association Data into this class (note that this helper handles both the Initiation and Association data):

public class Helper
{
   public static InitiationData DeserializeInitiationData(string xmlString)
   {
      using (MemoryStream stream =
         new MemoryStream(Encoding.UTF8.GetBytes(xmlString)))
      {
         XmlSerializer serializer =
            new XmlSerializer(typeof(InitiationData), "http://t4g.com/TestSchema.xsd");
            InitiationData data = (InitiationData)serializer.Deserialize(stream);
            return data;
      }
   }

   public static AssociationData DeserializeAssociationData(string xmlString)
   {
      using (MemoryStream stream =
         new MemoryStream(Encoding.UTF8.GetBytes(xmlString)))
      {
         XmlSerializer serializer = new XmlSerializer(typeof(AssociationData), "http://t4g.com/TestSchema.xsd");
         AssociationData data = (AssociationData)serializer.Deserialize(stream);
         return data;
       }
   }
}

Given these two classes, it is then simple to access the Association Data from within the workflow. For example, add a private member to the workflow class:

private AssociationData _associationData;

Then from within the onWorkflowActivated activity, add the following code:

String AssociationDataXml = workflowProperties.AssociationData;
_associationData = Helper.DeserializeAssociationData(AssociationDataXml);

The association data can then be accessed from within our _associationData object as required. The Schema, and the AssociationData class definition, can be modified as required to add additional fields.

I was considering another post about doing the same thing for InitiationData, but it works exactly the same way. So unless someone really insists, I will not bother.

Coming soon…MOSS Workflow Examples – Custom Task Forms (using InfoPath)

The next post in this series will be coming soon, I hope – maybe the end of April.

UPDATE: Still working on this – billable work is getting in the way 🙂 I am also working on doing the next one as a webcast rather than a long text tutorial. I am curious, what do you think is the best approach to this, text or video?