Sitecore Trendspot ANZ 2014

This week I had the opportunity to attend both the Sitecore Partner Summit and Trendspot down here in Sydney. Off the back of attending I thought I would share my top three take outs from the two events.

3. The Experience Database is the Future of Sitecore
More then anything else, the experience database is the key to success to Sitecore in the future and Sitecore is investing heavily in this area going forward.

If you haven't heard about it, it has been built as an efficient big data store for all of you data about people. I know that sounds like it is starting to take on the role of a CRM and it does feel like that when they present what it can do, but Sitecore has repeatedly said that it is not a CRM replacement, but it can certainly pull and push data into a CRM system.

The xDB, as its referred to, is tightly integrated into all parts of Sitecore, as you would expect, but has also opened up the ability to integrate data from a tonne of other sources. This is the major difference to the DMS that we have today.

2. The Device Ecosystem is Alive

At the moment I am feeling all inspired by the use of non-traditional digital channels by the partners and Sitecore themselves at the conference. 

There has been a lot of buzz for a while now around digital breaking out of the browser and the phone and starting to integrate with things like i-beacons, digital signage, second screen, etc. But to be honest it has all felt out of reach of the average project. This conference has shown that the technology has matured and it is now much easier to integrate these tools into you marketing plan, as well as into Sitecore. 

It has also shown what can be done when you start integrating all these things into Sitecore, leveraging some of the cool kit they have developed. With the new scale that's available  imagine the forms of communication you can have with your consumers if you connect  to one person via

• in-store wi-fi 
• iBeacons
• web
• print
• TV/streaming
• paid advertising

On top of that imagine if you can do it real time. This is what Sitecore is promising us and what some of the demonstrations have shown us.

1. Sitecore is not a CMS

The biggest take out for me from the conferences is that Sitecore is no longer just a CMS. With the work Sitecore is doing around experience marketing it is dramatically exceeding the boundaries of what we consider a CMS. I can see scenarios in the future where:

• Sitecore is used to personalise and track sites that are built on other CMS's. Think legacy sites
• Sitecore is used for email distribution
• Sitecore is used as a pure marketing tool for tracking campaign success and consumer engagement across all platforms

Obviously all of these scenario's can be augmented by the CMS component of Sitecore, but in the future I see the CMS component of Sitecore be exactly that, a component in a bigger ecosystem of functionality that the platform provides.

Summary

The thing that surprised me most about what I have taken out of this conference, keeping in mind I'm a tech guy not a marketing guy, is that my take away's have all been around what can we do for people. There was certainly a lot of good tech presentations there, but I already have confidence in the platform from a tech point of view. The way the technology is evolving is allowing us to chase down those interesting cross platform project, which to be honest is quite exciting.

Leaving Global.asax in Sitecore Untouched

So one of the things I strive to do on each project I work on is to leave core systems completely untouched(where possible). There are two main reasons that I do this:

1. The upgrade path. If you haven't modified the system you want to upgrade and you have no concrete dependencies on its files, then in theory you can upgrade it quite easily, by replacing it.
2. Multi-tenant architectures. If you are working in a multi-tenant scenario, then avoiding modifying shared resources can make you life a lot easier, as individual applications are self contained.

With a lot of my work involving Sitecore, I come across these two scenarios quite regularly and up until recently I had strategies for managing:

• Views/Layouts - separation by folder convention
• Sitecore Items - separation by content tree convention
• Sitecore configuration - separation by Sitecore config patching
• .Net configuration - separation by asp .net configuration sections

But even with all of this I didn't have a great way of managing the separation of application start-up and shutdown events, that are typically setup in your global.asax file. Enter Web Activator (available on nuget here). To summarize the module simply it is a "A package that allows other packages to execute some startup code in web apps" (direct from the nuget site).

Now for an example, lets say we are using dependency injection and we want to setup our dependency configuration and then tear it down on application start-up/tear down and we don't want to alter and of the out of the box Sitecore files. The code looks something like:

   
[assembly: WebActivatorEx.PreApplicationStartMethod(typeof(UnityWebActivator), "Start")] 
[assembly: WebActivatorEx.ApplicationShutdownMethod(typeof(UnityWebActivator), "Shutdown")]

namespace Sample
{
    using System.Linq;
    using System.Web.Mvc;

    using Microsoft.Practices.Unity.Mvc;

    /// <summary>Provides the bootstrapping for integrating Unity with ASP.NET MVC.</summary>
    public static class UnityWebActivator
    {
        #region Public Methods and Operators

        /// <summary>Disposes the Unity container when the application is shut down.</summary>
        public static void Shutdown()
        { }

        /// <summary>Integrates Unity when the application starts.</summary>
        public static void Start()
        { }

        #endregion
    }
}

The important bits of this are:

• WebActivatorEx.PreApplicationStartMethod - this invokes the specified type/static method combination for the global application start event.
• WebActivatorEx.ApplicationShutdownMethod - this invokes the specified type/static method combination during application shutdown.

Now, armed with this, there is one less file you need to modify from a base Sitecore install.