Delivering The Sitecore Experience

On a recent project, we proposed microservices architecture for e-commerce to the a client and it was a no brainer.  The next decision was to choose a hosting provider. The client had subscriptions for both AWS and Azure and since the team predominantly had Microsoft skills, that decision was easy enough as well.  In Microsoft Azure, we primarily were looking at two options: Azure Kubernetes Service (AKS) Azure Service Fabric (ASF) The System Engineers were pretty set on their recommendation of AKS but the client wanted to go through a detailed analysis of  the pros and cons before arriving at a decision. So the team put together a good comparison chart between the AKS and ASF and arriving at the conclusion that AKS is the future of for hosting microservices.  During all the analysis and research, our CTO came across a very elegant decision tree that made it much easier for the client to digest and arrive at their own conclusion. I thought it was ...

A while back I worked on a Sitecore specific QA assessment for a client. The idea was to take our QA competency's methodology and best practices and tailor them to be Sitecore specific. One very interesting out put from it was what I called Sitecore Testing Matrix. Here it is:

There was a great report from Gartner a while back that summarized e-commerce architectures into three categories: Commerce-led architecture Experience-led architecture API-led architecture Following which, Rob Earlam wrote a great summary of Sitecore Experience Commerce's experience-led architectur e. Looking back at my e-commerce experience, I would like to propose a possible fourth one, which is Hybrid Architecture.   Now, before I get into the Hybrid architecture. Let me quickly summarize these three architecture types. Commerce-led Architecture The idea here is simple, self-contained commerce solution, often times a monolith, where each every commerce feature is tightly coupled. The advantage in this case is in quickly deriving ROI from the system by shortening the time to market. However, there are several disadvantages to this approach such as single point of failure, lack of scalability options, high cost of maintenance etc. Experience-led Archit...

I have been meaning to write this post for a while as I have been using this nifty little feature in all my content search API implementations using the Solr provider. Unsafe: Defining SearchResultItem classes using hard coded Solr fields names for IndexField data annotation attributes as follows: [IndexField("page_title")] public string PageTitle { get; set; }   Problems : Cause runtime errors when field names change in Sitecore Hard coded strings, sort of magic values Unmanageable code Safe: Define SearchResultItem classes using strongly typed constants for data annotation attributes as follows: [IndexField(SampleItem.PageTitleSolrIndexFieldName)] public string PageTitle { get; set; } Solution : Compile time errors are way better than runtime errors More manageable code More readable code More dynamic query building Trick : Fetch Solr translated field name values on template fields  using  FieldNameTranslator  and reference them  w...

Achieving the  Run phase means that you have arrived when it comes to your digital marketing goals and capabilities. Before you continue with the Run phase, if you haven't already read Part 1 and Part 2 of this 3 part series, I highly recommend reading the Crawl and Walk phases first. As this the last phase of experience marketing maturity, sky is the limit to what you can do with Sitecore's experience marketing features. Let's see what more we can do within our four categories of experience marketing tasks: Content Profiling Content Personalization Contact Profiling Analytics The Run Phase One thing you will start to notice as we get into the Run phase is that you start to blur the lines between the 4 categories mentioned above. Each category will start to get intertwined with another. Let's see how occurs in this phase: Content Profiling - Run Phase By now you should have a good grasp of audience segmentation and having arrived at well define...

Welcome to part 2 of the three part series of  The Crawl, Walk, Run of Sitecore Experience Management. You can get a good context of what this series is about by reading  Part 1 . In this part we will add more digital engagement tasks to our 4 primary categories: Content Profiling Content Personalizatiton Contact Profiling Analytics The Walk Phase In this phase we will do more of what we did in crawl phase but by looking back at the analytics we have collected thus far. We will also add and expand on our list of to-dos. Content Profiling - Walk Phase After having collected sufficient web analytics data, you should be able to move on to the walk phase of content profiling.   Data Driven Personas: Evolve your existing personas from research driven to data driven personas. Have a data science team analyze your web analytics data in order to come up with personas and profiles. Create Profile Keys, Profile Cards, Pattern Cards: create...

In all my experience delivering Sitecore solutions, and having worked for a few platinum implementation partners, I have come to know the "Crawl, Walk & Run" pitch quite well. To most customers, when they hear the crawl, walk and run, I think all they hear is Phase 1, Phase 2, other parking lot items. And guess what is often a Phase 2 item...enabling xDB and its features such as content personlization, visitor identification, campaign management etc. Implementation partners actually may help you justify this by giving various excuses such as, the implementation of these featured will have a significant impact to budget, timeline, etc. I think this has been the challenge Sitecore as a company has been trying very hard to overcome. Moreover, the past two Gartner reports show Sitecore neck to neck with Adobe as clear leaders in the Digital Marketing space but falling short on execution of it's experience management features (now digital exeprience). One of the bi...

Almost every life-size Sitecore implementation has a multi-lingual aspect to it. Asking the right questions separates the men from the boys, in other words, shows how mature your digital practice truly is. Here are my top questions I commonly ask my potential clients before implementing a multi-lingual/multi-cultural implementation: Question #1: What languages are to be enabled in Sitecore? Seems like an obvious one but there can be some nuances to consider here and our job is to dig into them.  A good reason to know all the languages you will need to support up front is that certain languages (German, Japanese etc.) can and do have an impact on your creative design and UX.  Speaking of nuances, if a client says they would like to enable Chinese, it's not enough to ask if they would like both Mandarin and Cantonese. I would further ask them if they are looking for traditional or simplified Chinese, and mind you they all have different language codes that you w...

Going through the recently published Sitecore StackExchange site, I came across a question regarding modifying the date format of visits in Experience Profile since it shows the dd.mm.yyyy format by default. In case you don't know what I am talking about, here is what it looks like: It's not just that one view, the default date format seems to apply to other views as well: My obvious thought here was that there has to be a config setting somewhere that controls this date format. Here is my process of elimination: Eliminated Experience Profile configs since it did not contain any date related settings Looked at showconfig.aspx and found some index fields that contained date formats but eliminated since the default format was yyyy/mm/dd Eliminated the Reporting Database since the data formats were different Looked at the service calls made by Experience Explorer to fetch view data and found this: "InteractionStartDateTime":"2016-10-20T15:34:20.44...

A simple solution (maybe too obvious to some) to a rather cryptic error. This error occurs if you use a MVC rendering (.cshtml or controller rendering) on a page whose Layout item points to a .aspx file. As in, make sure you have a MVC layout when adding MVC renderings to a page. Duh!