The Analogy
SharePoint is like sugar cane juice. What? You don’t get the analogy? Well, neither did I until a few days ago. I personally loved John Underwood’s “SharePoint is like butter” analogy, but I had to capture this one somehow. Just as John said, bear with me, I’ll get there.
The Origin
Over the past 5 years of consulting projects with SharePoint I have had the opportunity to meet some really great people – clients, other consultants and contractors, and even the occasional Java developer. To introduce and discuss SharePoint in general, analogies often are the fastest path to explanation and understanding. On my current project, I have the good fortune of working with a new friend, Neeraj Agrawal.
Neeraj and I were discussing some of the best practices each of us has incorporated over the last several years in SharePoint projects, including analogies to explain the best way to introduce and develop SharePoint based applications, in our experience. I referenced John’s blog post, and mentioned that for ThreeWill engagements we usually try to meet needs with as much of the out of box capabilities as possible before we suggest customization through code.
Neeraj responded with, “SharePoint is like sugar cane juice”. I stood there, motionless, flummoxed. The words hung there, hovering motionless, like a visible, malodorous cloud. After what seemed like minutes, shaking my head in an almost cartoonish fashion, I finally managed, “What?” Neeraj just laughed. And then, he started to explain this jewel. Here’s the abridged version.
First, you have a sugar cane stalk. Fairly obvious.
Next, a sugar cane juice vendor who extracts and sells the juice. The juice vendor sends a stalk through a roller to squeeze out sugar cane juice. Immediately, a customer can now have some juice, no waiting.
The vendor can pass the cane stalk through the press multiple times, and with each pass, another customer gets some juice. Every pass extracts more value of the plant for the vendor, a bit more of the juice, and another happy customer enjoys a glass of sugar cane juice.
There you have it – the perfect SharePoint analogy! Neeraj had just thrown down the best SharePoint analogy ever, short, sweet (literally) and so obscure you are guaranteed to have to explain yourself further.
And here is the explanation of the analogy.
The Explanation
SharePoint 2010 comes out of the box with a large number of powerful and compelling features to address a wide variety of situations. The number and types of situations are too large to describe here, and are explained much better elsewhere. The relevant point here is, with so many features, you can extract value from SharePoint with several passes through the press, there is no need to squeeze too hard on the first pass.
The SharePoint Juice Recipe
- Endeavor to understand standard features
- Prototype and implement a basic business process
- Identify and prioritize the gaps
- Customize the Most Valuable Gaps First
Endeavor to Understand the Standard Features
First, investigate and understand what SharePoint offers out of the box, and what can be consumed without customization. A word of caution, SharePoint is a HUGE product! As in life, you will more than likely NOT know everything there is to know. This is OK, and should not deter you (the consumer or consultant) from understanding what is available to you at low or no cost of entry. You’ve already paid for SharePoint, or at least the hardware in the case of SharePoint Foundation, why not make the most of your investment.
Learn what site templates come out of the box, and determine if they fit one of your situations closely. In the UI, 20 templates were displayed for me, but there were 51 templates by using Get-SPWebTemplate | Measure. Learn what lists and libraries exist (26 in my environment using Get-SPWeb http:///[rootweb] | % { $_.ListTemplates | Measure}) and what each has to offer. Review the default field types (573 in my environment using Get-SPWeb http:///[rootweb] | % { $_.Fields | Measure}) , their options, limitations, and whether a field already exists that might meet your need. Discover what relationships, references, and interactions you can create between sites, lists, content types ((103 in my environment using Get-SPWeb http:///[rootweb] | % { $_.ContentTypes | Measure}) and more. Finally, learn what web parts are available out of the box for your product SKU and how these can help you without creating your own.
Note: I included the PowerShell cmdlets and counts because, as I was writing this, I was shocked to learn some of these numbers and I learned some new things – even after 5 years.
Prototype and Implement an Initial Solution
After you have spent some time learning what comes out of the box, try putting this knowledge to work. Start by picking a business process that is relatively complex and implement the basic needs of the process. For example, do you track expenses? Try creating an Expense Report “application” using a new site, create a few content types using existing or new site columns, and create some views and web part pages to help display, report and print the expense reports. A list to track the different expense items, expense categories, etc. is a good example that is easy to understand and relatively easy to prototype quickly. You’d be surprised how much can be accomplished for a process like this out of the box.
Be sure to have the correct expectations for this exercise. Don’t look for the limitations, do not assume that this is not good enough, and do not look for excuses to jump to code right away. Accept that the “application” will likely fall short of the mark, but take this as an opportunity to see what is possible. Be creative and try to make things that are acceptable, but not perfect. I think you will be pleasantly surprised at how much of an application like this is achievable, and acceptable, using just what a power user has at their finger tips.
Identify and prioritize the gaps
Now that your first run through the press has extracted a healthy portion of sweet, SharePoint juice, and left your users wondering how they can get more of this magic elixir, it is time to determine what to do the next. Let’s take our Expense Report application again. Users liked the idea of an online Expense Report app, but the simple lists with only some content types and views fall short. Management wants a custom workflow, since what you tried initially with the approval wasn’t enough. Users want a way to track expenses offline and then upload them. And, the finance users want a simple way to track and manage payments and some views that show them expenses that are not possible with simple list views.
Now we have enough for a second run through the press to extract some more sweetness. Can you still stay away from code? Maybe. There’s still more juice to be had without squeezing too hard. Maybe a workflow modified in SharePoint Designer 2010 will fit the bill for the managers. No custom code yet, and they might be willing to accept this. Next, you might be able to meet the user’s needs by using InfoPath 2010 or SharePoint Workspace 2010, or by getting even more creative with Excel or other options. Finally, perhaps a third list, secured to only finance users, will enable them to track the payments and a content query web part might provide them with the views they want.
These may work, but what happens when you need to squeeze even harder?
Customize the Most Valuable Gaps First
Finally, once you have exhausted the features you endeavored to learn, start customizing with the new requirements that present the most value by addressing the biggest gaps. The finance team would love to have a more specific UI for their purposes, but they are fine with a list that only they can see and manage. The managers are happy with the new workflow that lets them approve and escalate approvals as needed. But, the users really need a better alternative to the processing of offline expense items.
Since the users at this point are the ones with the most compelling or urgent need for customization, you can now determine a viable alternative for them. You can spend time getting deeper into requirements and scenarios to understand the best way to address the needs, all while the finance team, managers and most users have a viable, functional alternative to managing expenses and are getting reimbursed.
Some Final Thoughts
Think about how you develop solutions today. If your organization immediately moves to gathering and defining deep, fine grained requirements that are intended to ensure every desire of the users is met, then SharePoint may present some mental challenges for you. Developing in SharePoint, and extracting value immediately is a huge advantage that SharePoint as an application itself provides.
Finally, Neeraj did offer a different spin to this crazy analogy. Here it is in summary. First, treat SharePoint like an application and learn to use all of the features it gives you. Once you have learned the features, and mastered it’s capabilities, treat it like a platform and build your own features that exploit the platform to its fullest. Finally, exploit the API of the platform and create your own solutions by connecting, building or extending the platform.
Thanks Neeraj for helping me add another sweet SharePoint analogy to my bag of tricks and for helping me make Mr. Underwood a little happier this week!