This blog post is part 1 in a series on “Creating good Sitecore solutions”. You will find part 2; “The page template mistake” here.
Having now worked as a Sitecore consultant for well over 8 years – sometimes in regular employment at one of the many Sitecore Partners in Denmark and the UK, but more often as a freelance consultant/contractor for the very same clients – I have been exposed to pretty much all aspects of what it means to create a Sitecore solution.
Sometimes I’m brought in to help a new and upstart Sitecore partner get some of their first Sitecore clients. They usually need help in scoping, defining and estimating the proposed project. Sometimes they keep me on to help in the actual implementation of the site as well – more often I am kept on to help train their existing developer resources in the practices and uses of Sitecore.
Other times – and these days, this is more often the case – I am hired as a Sitecore Architect for a project. In many ways the tasks I perform are the same as what I just mentioned, but the title Architect tends to imply doing all the above, alongside ensuring that whatever implementation eventually ends up getting built; will also fall in line with the almost mythological Best Practices for Sitecore implementations.
I say mythological with some irony, of course. While a lack of documentation used to be a problem, we now have nothing short of 1000s of pages of documentation and “cookbooks” available to us. These cookbooks will describe in detail, all the intricacies of implementing your Renderings, Rules, Templates. How to set up security, how to set up cloud solutions – pretty much how to do everything you’d want to with your Sitecore solution.
And this is it, really. If one was ever to define Sitecore Best Practices, this complete set of cookbooks would be it. NOT this – The Sitecore Recommended Practices Cookbook. While I would certainly recommend that the practices described in this cookbook be followed, it in no way can be said to hold a complete set of “Best Practices” for a Sitecore solution. There’s so much more to it than that.
There simply is no single “manual” that will tell you everything you need to do. Everything you need to be aware of, everything you need to consider. There is no substitute for experience, as the proverb goes. This certainly holds true here.
And that actually brings me closer to the point I was wanting to make, and has brought me back to the keyboard after such a long absence from blogging. See the thing is – when I first started blogging, it was mostly about technical details. “The little things”. Information on Sitecore was somewhat scarce, and sharing whatever information we learned was the name of the game. With all the information now available, not to mention the probably 100s of bloggers who has taken to the blogosphere – I find myself in need of a new game. Experience. I will start using this blog to write and share some of the information you will not find in cookbooks, other peoples blogs or even John West’s book.
I’ll kick this off by beginning to answer the very question I pose in the title of this post. You will find it is going to take quite many posts to follow, to arrive at any sort of answer – but we have to start somewhere.
To create a good Sitecore solution; you must first decide to create a Sitecore solution.
“What? That it!?”
No. That’s not all of it, but this is most definitely where you need to start.
See the thing is; as any project I’ve been part of goes through the same motions – the same pattern. Doesn’t really matter if the process in place is Agile or Waterfall. If you have a Scrum Master or a Project Manager (or both).
In the beginning (or as you go along, if you are truly Agile. I have yet to see my first truly Agile Sitecore project implementation); everyone is on about features, design and (usually most importantly) the cost. If you’re in an agency, your agency has to win the bid. If you’re building in-house, the project will still have a cost and will need an approved budget.
Then comes the construction. Developers, designers and whatnot get to work. Here the focus becomes jQuery libraries, lightboxes, valid HTML, performance and of course the actual Sitecore implementation. The perceived necessary stuff from the cookbooks mind you, whatever it takes to make it work.
And if all goes to plan, eventually the “site” (which is usually what a Sitecore project will be – the delivery of a “site” for Company A, or a re-make of a “site” for Company A – and herein lies the problem) will get handed off, go live, start receiving visitors and everyone shakes hands.
I know, I know. I am both simplifying the whole process and adding a bit of irony on top. Bear with me, this post is already turning out to be much longer than it seemed to be in my mind.
My point. The project is about a “site”. Or new features on a “site”. Very very rarely – if ever – does it get discussed, how the end user (the Sitecore end user, not the “site” visitor) will be interacting with the Sitecore solution. One simple – and when you look at it; astonishing – fact, and no-one usually thinks to ask it.
What happens is; the “site” gets built, gets handed off, gets approved – all from looking at the “public face” (if you will) of the “site”. If it ticks all the boxes, “we’re done”.
Sure enough, depending on the actual level of experience (see above) of the team that actually did the scoping and ultimately the Sitecore implementation of the “site” – parts of it will also be content manageable. Not all of it – very rarely – but parts of it.
Is this a good Sitecore solution then? Well I would argue; “no”. It’s a “site” running on Sitecore and could therefore in the strictest sense be dubbed a “Sitecore solution” (as the customer ordered, and got). But a good one?
At this point, if you don’t really know what a good Sitecore solution should feel like, I would recommend you contact your local Sitecore office and have one of their excellent sales people demonstrate the “Nicam” site for you. But in summary, I would say that a good Sitecore solution should at the very least tick the following boxes:
- It doesn’t restrict the use of the built-in Sitecore tools
- The Sitecore Page Editor
- The Sitecore Debugger
- The Sitecore Profiler
- It allows you to use at least the basics of Sitecore functionality – probably the very reasons being why Sitecore was chosen over a competing system to begin with
- All components on any page can be M/V tested
- Sitecore Analytics Goals and Failures can be defined for relevant parts of the site
- Alternatively that these are triggered in the code, hardcoded
- Editor User usability has been considered
- Placeholder settings have been set up
- Insert Options
- Permissions, if necessary
- It can run on a single-server environment or scale to multi-server
I mean… The CEO (usually) who ultimately approved the considerable license fee for a Sitecore solution was told by Sitecore sales people; “Sitecore can do all this”. In most cases I have seen, the CEO doesn’t dig deeper into the subject matter – he or she will sign off, and (quite naturally) expect to be getting exactly this. As well as the “site”, mind you.
Less than 5% of all the Sitecore solutions I have seen delivered, would tick all of the above boxes.
Yes. This includes some of “my own” – albeit delivering any Sitecore solution can probably never be put down to just one persons influence.
The “reasons” are many, but the most common one that gets passed around is this. “It would require extra work for us, if we were to expand the “site” with the necessary “stuff” so you can work with it in Page Editor/Set it up for Sitecore Analytics/Configure bespoke security settings”. Extra work in this business means “more money” or at the very least “more time” – none of which any of us has enough of to pass around in this economic climate.
And so it usually ends. From time to time customers will put in tasks like; “We want a split-test set up for our Add To Basket button – how much time will that take/what will it cost?”. Small improvements like that are made over time – everyone is happy. Except – if you’ve read this far, you will once again sense a slight irony behind my words – perhaps me.
Over the posts to follow I will demonstrate how most of these boxes can be ticked, and actually not cost you any more time or the client any more money. Not to any significant degree anyway.
It comes back to experience. It comes back to what can only be read between the lines in the cookbooks and blog-posts. It comes back to first deciding:
“I want to build a Sitecore solution”
And if you get at it from the onset with that attitude, and start considering what that actually means – you are on the right track.
And if you’re in the other end; the person buying the solution. Don’t go “I need my “site” on Sitecore by the end of this year”. Go: “I need this “site” implemented as a proper Sitecore solution. I’ve seen the impressive features of Sitecore and I want to use that platform to improve my business/user experience/conversion rate”.
Decide to build or get a good Sitecore solution, and you’ve at least started with the right mindset.
