"Why Out-of-the-Box Makes No Sense in SharePoint" – A Rebuttal
One of the great things about open-minded, intelligent people is that they can disagree and still enjoy each other’s opinions. (Yes, you guessed it, I’m saying that so that Bjørn doesn’t just dismiss me right off. He knows me well enough that I don’t think he will, but still…)
Bjørn posted a well-thought-out set of ideas today entitled “Why Out-of-the-Box Makes No Sense in SharePoint“, and I wanted to post my contrarian thoughts on it.
To me, SharePoint implementations in a large percentage of the cases ought to be evolutionary rather than revolutionary. By this I mean that if a SharePoint implementation is successful, it will fundamentally change the way people work. We can’t always know what those changes will be in toto because there are many contributing variables, like the organization’s culture, incentive structures, process maturity, leadership style, etc. So starting with slightly adapted “out of the box” functionality can be a very good idea.
Let’s go back to Bjørn’s house building analogy. We bought our house, which is over 100 years old, because we liked the “bones”. We could see ourselves living it in quite happily. Over time, we’ve changed various things based on our actual living style: new paint in a few rooms, new track lighting in the rooms where we felt we needed it, etc. It turned out that we were wrong about a number of assumptions going in. We didn’t actually need to renovate the kitchen, for example. Even with my wife being a personal chef and cooking constantly, it fully meets our needs. So think of the time and expense that we saved in *not* doing the renovations up front. It’s not that the house is just “good enough”; it’s great.
The same thing can happen with SharePoint, but it all depends on the organizational readiness, and those non-technical factors I list above are the indicators of that readiness. If the “applications” that SharePoint is intended to provide are extremely well thought out right up front, then get out the hammers, nails, screwdrivers, and bow saws. But if the need is more of a vague “we need collaboration” or something closer to that end of the spectrum, then starting with out of the box is exactly the right idea.
This may be the difference between me and what Bjørn or Todd Bleeker et al would call “Developers” (see the comments here). I guess that some of my developer stripes may have washed off in the management consulting car wash, but writing code is often the absolutely last thing you should ever do. I’ve said it a thousand times, so if you know me you’re tired of it, but sometimes note cards are the right answer. Out of the box can be exactly the right starting point; I would argue that a SharePoint implementation should never be “done”. As we live in the SharePoint house, we will need to do renovations from time to time, many of them minor, some of them major. It’s all about getting to the right living space for the family. And an organization’s evolution toward a technically supported collaborative environment can be just like that.
Well, you’re stupid as always.
I’m not talking about taking some 100-year old platform (or Notes as we call it in IT) and getting comfortable with it. A lot of old software is nice. It’s not why people call me, or you.
Also, an analogy shouldn’t be taken literally.
.b
I know i’m stoopid sometimes. This might not be one of those times, but I can never really tell. (In case you don’t know, Bjorn and I know each other quite well, and I take his ribbing when he dishes it out. There’s no offense on either side.)
You’re right that people don’t call you or me to implement some dumb old software. (I actually really liked Lotus Notes back in the day.) But they should want to call us to help them arrive at the *right answer* for their situation. If they have the plans all drawn up by a competent architect (the AIA kind), then let’s get out the toolbox. Otherwise, let’s have them call us to help them understand their lifestyle and then design the additions.
M.
p.s. Yeah, I can beat a dead horse analogy as well as the next guy.
I think this entire debate teeters on your comment about organizational readiness. Companies that do not understand the business problem they are looking to solve should not be making major investments into customizing the environment..
With that said, the environments where I’ve seen SharePoint be the most successful were the ones where multiple business problems were solved by extending or customizing the platform. The business problem and value were clearly understood before those investments were made.
I think there are a couple of good points rooted in this discussion. First is the notion that businesses just dive in thinking that throwing money at things they don’t understand will solve problems; which is far from the truth. I can’t tell you the number of iterations we’ve gone through because of a knee-jerk reaction or because an executive said so. Most times they don’t understand the platform, the capabilities, or the requirements–but yet are so eager to dive in because it’s the new, hip thing.
The second point, is based on a question. What exactly falls into the scope of “Out of the Box”? Some might say that the second you do anything outside of the web GUI you’re customizing SharePoint beyond out of the box capability. I tend to look at it more in the sense that anything you can do in SharePoint designer is within the scope of “out of the box”. The inclusion of things like Data View Web Parts for example, in my opinion is a capability that the platform offers out of the box. This leads to an interesting point, which is for me, that “Middle Tier” development as we’re terming it, is virtually OOTB capability. Now, you obviously need certain development skills to harness that capability, but in my mind it’s not until you start writing custom .NET and deploying your own features and solutions that you break that barrier into non-OOTB capability.
I can honestly say, that there’s been very very few cases where I’ve just created a site, built some lists and handed over to the customer. In my experience generally there’s at least a small amount of “tweaking” required to meet the needs of the business and fully integrate SharePoint as a platform into the business process, but those tweaks can often be achieved via Middle Tier actions that in my mind fall into the out of the box capability of the tool.
I posted this comment on his blog because I highly disagree with his blog post. Repeating it here for those that will miss it.
I respectfully disagree with your statement “Out-of-the-box in SharePoint often refers to some of the sample implementations that Microsoft ships with SharePoint, such as the team site, publishing sites, enterprise wikis, and so on.”
IMO there are three types of SharePoint solutions. OOTB is using it without cracking open SPD, adding code (which would include JavaScript), etc. The 2nd level is adding JavaScript (maybe through CEWP or not) and modifying pages with SharePoint Designer. The 3rd level is Visual Studio and server side web parts, etc. Again, my opinion and YMMV.
I don’t agree that OOTB is using it as-is. That’s like saying using WordPress OOTB means having one Hello World blog post and the default categories. To me, OOTB means using whatever templates came installed and/or building a site/solution with those templates. Does OOTB to you mean not even creating a new site using a Team Site template? How is that any different than adding a new list using a template?
Again, a weird post from you that I just don’t understand. OOTB *does* make sense for many organizations and I highly recommend it and advocate it. There’s a LOT of value-add you can do just out of the box without resorting to code in any form through configuration.
There is A LOT of stuff you can do with OOTB. This means only using the web browser to do what you want. You can create a custom list from scratch or augment an existing template and add more fields to it. You can tie lists together and create something relational. You can create metadata taxonomy with site columns and site content types. Web parts are highly functional and connections are the bomb! But Microsoft has locked us into a certain input mode that most clients don’t like — and you must customize that. Mashups with external data are all the rage and most of it can be done OTB. But it takes alot time to configure and none of it is portable. This is why we have features! SPD is not OTB and requires coding knowledge to customize pages. Visual Studio is used for custom code like Web Parts but it’s also used to create stable reproducable solutions that can be deployed many times. You can build a sizable solution just using the web browser but god forbid if it gets corrupted — having to redo all that work. In the end Bjorn and Marc are both right.
Both points are well-taken. At the end of the day it’s what satisfies the needs of the business.
Identifying / narrowing the scope of the business problem is probably the most difficult step.
At times , they aren’t sure until they actually ‘see’ something.
Here’s where the marketing comes in, we can go with approach A AND / OR B.
We look at timelines / budgets and of course – the old how much is it going to cost me ?
Oh ! What we really wanted was a Cadillac but we can only afford a Toyota !
I think this discussion misses the really controversial point here: Should it be called OOTB or ITB?
When you use SharePoint without writing custom code or third party add-ins, you’re surely using what comes In-The-Box, right?
I mean, when someone says “he was thinking out of the box” it means looking at stuff external to the ‘known space’. When my son wanted to build a space station of of Lego, he would say “there’s not enough stuff in this box”, I need more parts. (To which I replied: You’re not getting more; see what you can build with what you have.)
I would like to start lobbying for a new, unambiguous term: “In The Box” (ITB), and use it when you are treaing SharePoint like a box of Lego: You get a bunch of cool parts that you assemble into a great result. The creativity of how to put those parts together is up to you (and depends on what your client needs). If you want to buy add on parts, or get the glue and saw out and customize your own parts, that’s when your going ‘out of the box’.
There, that should clear things up!
-Ruven
I’m with Bill’s line of thinking. Web UI vs SPD vs Visual Studio…