Boy bands – how to understand the site definition/template debate
Hi all
I’ve read a few blogs on site definitions vs site templates and reading some development centric articles, particularly the alternative presented by Raymond, and expanded by Mike and summarised neatly by Chris. Being a part time developer, I found that the explanation were a little…shall we say… geeky and I had to expend far too many brain cells.
So to assist the rest of the SharePoint community who are not developers, I am going to attempt to explain the whole sorry debate to you using a more suitable analogy – boy bands. That way you do not have to worry about developer-speak.
Boy-band "definition"
There are several mandatory characteristics of being a boy band.
- All have to be pretty-boys
- One is permitted to be tough in a non threatening way
One is sensitive - There must be 5 members
- All must be able to dance
- Playing a musical instrument is not permitted
- Clothes are always the latest fashion
- Members do not write their own songs
- Must do exactly what the record company tells them
When you create a new boy-band, you audition a bunch of hopefuls, using this core set-up and then just give them a nice radio friendly name.
Now, it really doesn’t matter which band it is, this is the formula that is followed by record producers with staggering success. But there is a catch! Change any of these parameters and the whole thing falls apart. For example, if we replace the non-threatening tough guy with a fat kid who can’t dance, teenage girls will rebel and the band will have to break up. It makes no difference which boy-band we are taking about either. You have broken the fundamental structure of how they work and the whole thing will disintegrate.
This, my friends, is a *site definition*.
Also – this is very important to note. The "boy-band" definition is an out-of-the box definition. In other words, no matter what environment that you are operating in, you will always find that the boy-band definition is there.
Boy-band templates
However, just because you have to follow this definition doesn’t mean you can’t make some changes here and there. For example, you can safely change a boy-band’s musical style from pop to light opera and "New Kids On the Block" effectively turns into "Il Divo". If "Il Divo" turns out to be popular among the user population, then the record company will want to produce more operatic boy bands. If we could take "Il Divo" and somehow save them as a template, then we can create new operatic boy-bands quickly and easily.
But the core fact remains that if you modify the original boy-band definition, this new template will crash and burn as well.
"Operatic boy-bands" and "Pop boy-bands" are therefore examples of "site templates".
Both bands are based on the underlying "boy-band" definition and as a result, cannot exist independently without that definition. So what if we want to use the "Operatic boy-band" template in another location?
Not a problem, because as I described earlier, the boy-band definition is out of the box in all locations, and therefore the templates will always be able to be used in other locations.
Unfortunately, sometimes there are limitations with boy-band templates. The bands themselves have "grown" and now realise the original *definition* they have based their template on is too restrictive and will not scale with their future "artistic requirements". There is only so much that you can do when tweaking the more limited options provided by the template model. But since they are based on the underlying boy-band definition, then we are stuck.
New Kids On The block are a great case in point. In 1994, when they released their 4th studio album, they attempted to write their own songs to the detriment of their boy-band career. As we now know that violates rule 6 of the boy-band site definition and as expected, the group split up shortly after.
New site definitions and portability
So let’s just say that we want to make the first ever "hybrid death-metal boy band". We know that we cannot do this with a template alone because it will violate the boy-band definition and the world will explode. So we have to make up a new definition to accommodate this unique requirement. Suddenly we are faced with a lot more complexity here. Instead of just re-using a template we have to come up with a brand new definition and this requires specialised expertise. We already know that once we have made up our new definition that it can never be changed, so we had better make sure that we have it right the first time.
Now, let’s say that we create our first death-metal boy band called "New Kids on the Cannibal Corpse" and launch them in Sweden – where all the good metal bands come from. We create our new definition and then set up a new record label, hire PR guys, roadies, stylists, personal assistants and it all goes terrific. Sweden loves this new music sensation. But then when they try and break into the UK scene, it fails miserably. Why? Because we don’t have a record label there. They do not know how to properly deal with a new band based on this hybrid death-metal boy band definition because they have never seen this definition before.
This is one of the problems with making up new site definitions. Since it is not out of the box, if you try and move "New Kids on the Cannibal Corpse" to a new operating environment such as the UK, the definition is missing and therefore they have no idea how to handle it. This creates a dependency issue. Before "New Kids on the Cannibal Corpse" can be launched in the UK, we have to set up the "hybrid death-metal boy band" definition there *first*. Contrast this to "Il Divo" which can tour anywhere because the "boy band" definition is out of the box and therefore already set up by default at all locations.
Future Directions
Musical tastes change over time. Fads come and go, and alas, even boy-bands go out of favour. To achieve real longevity, all bands have to occasionally reinvent themselves – in effect go through a complete upgrade process and emerge as something completely new. The one advantage that boy bands have is that their popularity among teenyboppers means that the record industry will provide assistance to help them emerge as something new.
Unfortunately, the same cannot be said with our poor hybrid death-metal boy band, who, being a custom designed product, will have no guarantees that the record company will help them reinvent.
Therefore, there are disadvantages to a custom band definition. Future upgrades are tougher. But if you have managed to remain on the boy-band definition, despite working with the reduced flexibility of being a customised template, you should be able to upgrade to a newer version with much less pain.
This is important because although you might have more flexibility when freed from the confines of a boy-band definition, you pay for it with future upgrade uncertainty.
Conclusion
So now you should be full-bottle on the difference between site definitions and site templates. So, which one should you use? At the end of the day, it depends on whether you want to be a one-hit-wonder or achieve long term staying power. However, remember the most important thing above all else…
Under no circumstances should you *ever* listen to boy-bands!
Thanks for reading
Paul Culmsee
Good article Paul.
For anyone interested in this, you may also want to read the pros and cons of each approach on the SharePointDevWiki.com:
http://www.sharepointdevwiki.com/display/public/Site+Features+vs+Site+Templates+vs+Site+Definitions
Appreciate more collaboration on this page if you have any good pros and cons that are missing too!
… and I thought I understood both sides to this debate, now I am more confused then ever! lol.
“you pay for it with future upgrade uncertainty…” is good IMHO, as it means more work for us all in 2010 and beyond ;o} If its gonna be a massive problem in a year or two I don’t really care today, I worry about solving todays problems I am faced with. I don’t have time to gaze into a crystal ball and speculate that a specific development/design decision is going to result is a mass catastrophe years from now.
I can’t wait for all these massive, complex and dirty dirty site def upgrade/migrate projects when vnext arrives, if anyone needs help with this come see me in a cupla years.
The whole “preserve the perfect upgrade path” stand point I think is highly over rated – the primary focus for people implementing custom SharePoint solutions is to meet the requirements of the customer, and a lot of customers have weird and wacky requirements than can only be met with extensive & complex custom dev that are best implemented as custom site defs. The last thing SharePoint customisers/developers/architects/whatevers should have to worry about is whether the solution will upgrade to the next version smoothly, it’s a lower priority compared to providing the solution required TODAY.
SharePoint OOTB is simply a demo app, a proof of concept to show manager/cio types what is possible, to get the full power and possibilities available in platform it needs to be extended to fit an organisation, to provide solutions to solve its problems, and sometimes custom site defs are the answer.
Sezai
Although I was kidding around, your reply is actually more suited to the “one Best Practice…” series. Almost by definition, if a client wants something “wacky”, you can be guaranteed by next week that they will either change their mind as they learn something new, or get even wackier as they think about their problem more. Additionally, you have different people going through that same cyclical exercise and so even within a group, often there is disagreement and lack of clarity between what you will deliver and what *they think* you will deliver.
“The whole “preserve the perfect upgrade path” stand point I think is highly over rated” and “The last thing SharePoint customisers/developers/architects/whatevers should have to worry about is whether the solution will upgrade to the next version smoothly, it’s a lower priority compared to providing the solution required TODAY.”
That is essentially an ROI question. If I were cost-justifying a highly customised site definition, I’d add costings for how hard a service pack would be, a restore, how easy things are to move from one place to anothter, etc, as well as upgrading to vnext. Then we account for how long we expect this solution to be suitable for and consider rework and re-engineering costs. Think this can’t be done? Well it can 🙂
One of the characteristics of wicked problems is that they can have “waves of repercussions” that can be even more wicked than the problem being solved the first time around. Dangerous stuff – hence why people like at least try and make a pop-rock band, despite a boy-band definition underneath 🙂
Sezai, I also think you may want to read this post too: http://wss.made4the.net/archive/2009/02/15/the-sharepoint-implementation-market-needs-to-grow-up.aspx
🙂
We should be educating the clients on ROI long-term, not just giving into their demands of getting stuff out the door.
Yeah I guess I should think about long term ROI more. My usual focus is on getting stuff out the door, keeping people happy today.
Also – don’t get me wrong, Site Definitions shouldn’t be used all the time. If possible always try and implement customisations as Features on the regular ootb site definitions. I haven’t developed a custom site definition this year – but if I am asked to implement… say a large custom WCM solution I will always start with a custom site def. For regular Intranet portals used for collab and doc management I think site definitions are rarely needed. Also – you can implement work in a site definition OR a feature – in cases like that always go with a Feature as its more flexible into the future. Still I think site definitions have their use and their place and are one of the tools in your SharePoint toolbelt you can call upon in times of need.
As for wicked problems – yeah I’ve been involved in some huge custom projects involving custom site definitions and being locked in a forever spiraling wicked problems vortex resulting in a lot of wasted time and customers who are never happy, so there is some merit to poo pooing custom site definitions. Still I think they have their use at times.
Great article – I’m someone who loves SharePoint – and heavy metal – this had a few laughs for me !
Nice one. 🙂
in the first picture at the top what was their name again?? im lookin 4 a song of theirs an i cant remember the name of their band please help cos its buggin the hell outta me
Custom Site Definitions: 2010 – another reason not to.
SharePoint Joel’s international man of mystery presentation on 2010 readyness covers the SP2 tool, stsadm –o preupgradecheck.
One of the things this will tell you, is you need to have an Upgrade Definition File in place to upgrade your Custom Site Definitions (KB article 954761, not yet published).
Just like the last major SharePoint version udgrade, do you have a UDF?
First of all. Thanks very much for your useful post.
I just came across your blog and wanted to drop you a note telling you how impressed I was with the
information you have posted here.
Please let me introduce you some info related to this post and I hope that it is useful for community.
There is a good SharePoint resource site, Have alook
http://www.how2sharepoint.com/
http://www.sharepoint2003.com/
http://sharepointbank.com/
Thanks again
Rahul
Hallo ich bin aus berlin