Sitecore as a Service… is it really a good idea?

Sitecore as a Service is the first thing that would come to the mind to a Developer / Architect who is not familiar with Sitecore.

The idea is pretty simple, the non Sitecore developer think: “I do not like products, I do not know how to use Sitecore, I do not want really use it, but I have to… therefore I am limiting the dependency and the role of Sitecore within my architecture”

Unfortunately most of Developers still understand Sitecore as a CMS rather than a Digital Martketing Suite and cannot really get the difference and the benefit of it…

If you have heard about this consideration and you have been in similar situation, this is the right post for you….

As you probably know, Sitecore architecture is pretty flexible and allow you to use Sitecore in a variety of way, consuming Sitecore through the OOTB web api to manage the items or write a custom webApi just to serve content items as a web service or a rest endpoint serving Json is fairly simple and you can find plenty of documentation about it. Other way to access your content structure is through the use of Dictionaries or customising your publish pipeline to create static Json/JS files is also a simple way to consume the content information.

The following approaches are considered a quick win for “non Sitecore developers” who think I will be in control of my website / application, Sitecore will just give me HTML via Json and I will do the rest without having to tunnel all my request through Sitecore pipeline…

Reality for Sitecore people is very different…. the reason for tunnelling all your request through Sitecore pipelines are multiple ones and before going for the “content as a service” should be really considered to tunnel all your request through Sitecore for the following reasons:

  1. Content structure and your website features are very bounded and you cannot decouple it. Decoupling it, you would loose a lot of benefits (eg. Seo, friendly url, linking content elements, etc)
  2. Page Edit mode you would loose it
  3. Page composition having the ability to control page structure on Sitecore open the doors to an infinite number of possibility for your Authoring team allowing them to control your application.
  4. Renderings associated to Content Items associating renderings to Content Items via Datasource allow you to test different configuration and permutation of your application and encourage re-usability principles within your code.
  5. Personalisation allows your content team to deliver a personalised experience is one of the key selling point of Sitecore, decoupling the content from the application would effectively prevent you to Personalise the experience through Sitecore. Sitecore echosystem leverage personalization of Renderings to show and Datasource to use via Sitecore rules.
  6. Content Testing is key in the digital age, continuos testing is the new culture and bypassing Sitecore pipeline force you to a Non Sitecore MVT testing approach.
  7. Analytics & Behaviour personalisation require your Sitecore implementation to tunnel all the request within Sitecore pipelines, moving out from it would mean effectively preventing your trading team to benefit from the great benefits coming from Sitecore

Having done these considerations, is fair to say that if all what you need from Sitecore is the Authoring shell to upload content and images and you are happy to consume Sitecore as Service, you would still benefit some of the features of an enterprise CMS

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s