Skip to main content

Discovery on how to carve a path from monolith sitecore to composable DxP

 

 

 

 

 

Hi People,

Recently, I carried out a research for our internal clients (product owners) about what it takes to go from monolith to headless and headless & composable stack (yet very far in the road map but going to XM-Cloud down the line).

We are currently on Sitecore 9.1.1 (Monolith), the mainstream support for which ended in Dec 2021,  and the extended support will end in Dec 2023, so if we should continue or upgrade to 10.2 or do upgrade along with headless, all these exercise were carried out in this discovery.

There were also questions like, Why one should go headless if demands are being met with current set up and version of Sitecore? 

And this is the exact question which defines our (your) journey of this research and finally moving to headless, It all depends on the business needs and how far we want to go and invest.

But to decide something, First we need to know what it has to offer and to understand it, this research was carried out, This research also carried out what XM-Cloud offers and how much market ready it is or if we are ready to go that direction, but this blog only covers the composable DxP part, will cover XM-Cloud part in upcoming blogs.

So before even diving deep into answer of all these question and discovery, we wanted to have high level overview of how to go about this approach and what should be our next steps and that is where we had direction from our "Vice president, Technology" - Sheetal Jain to do a deeper dive by carrying out a discovery by a technology team and once the deeper discovery is done, carry out a PO interview to know their thoughts on efforts, ROI, cost, budget and other things to decide which direction to take, and that is where the discovery started.

Following are high level tasks we did in our discovery

  • ROI - Listing or putting more light on ROI that it will give down the line
  • List system mappings - Decompose the solution & map applicable composable system against it.
  • Conduct PO interview - To know their gut feeling by showing all pointers by asking right questions.
  • Technical regrouping - Going back to leadership team with our discovery to find answers to the open questions & headless system mappings to come up with estimate & a roadmap.
  • Deciding the roadmap & the path - Estimation & the road to take.

 

ROI (Return On Investment)

Before we even decide to go headless & full composable, business will always have a question about, what about ROI? Why should i move to something else? but if we see bigger picture and on a longer term, following benefits will give the actual ROI to the business. As per Sitecore following are the benefits 

  • Best of breed approach 
Make the most of all the best tech. With a composable solution, you can tailor your DXP to your business and select only the applications that you need to fill the gaps. It gives you the choice of  the best technology on the market for each individual component and allows you to act efficiently and cost effectively, Basically you can introduced any tool of your choice which is MACH & API based.
  •  Faster time to value  

The nature of composable tech architecture is that it is agile, scalable, and quick to pivot. Therefore, as your customer's needs change, you can act swiftly and recoup any investment costs  sooner.

  •  Customer-centric

Custom is at the center where he can choose his favorite vendor or tool, Customer is not forced to buy a full suite but select the composable piece of his choice, Composable DXPs allow you to truly prioritize your customers and create slick omni-channel experiences. Seamless, consistent interactions and a personalized experience will help to build  likeability, trust, and loyalty. And as you collect data from every customer journey, you can adapt as required.

  • Freedom to MARTECH
Marketers can connect their favorite tools, from marketing automation tools to CRMs to conversion optimization technologies. Vendor lock-in becomes a thing of the past as you are free to explore best-of-breed technologies for each dimension of your marketing campaign.
 
  • Future ready
By using the same technology to connect with any device or touchpoint on the market today and tomorrow, a headless CMS removes concerns about the future. You’re always prepared to meet your customers on the new frontier of interaction, wherever that may be.

NOTE: It is about asking ourselves, "Can we live without composable DxP and live with monolith? answer might be YES, but if you ask same question like "Can we live with monolith forever? answer might be NO.

As an organization, you should also think where you will be in your roadmap 3-4 years down the line and prepare for it now.

and as gartner also says following


By 2023, organizations that adopt a composable approach will outpace their competition by 80% in the speed of new features that they can implement. – Gartner

 

Mapping out non-composable systems against MACH complaint API based systems

As we know composable means best of breeds, and monolith means all in one system, it's not pluggable if i want to remove analytics part and plug in with the system which i like, or if i have a commerce but i want to have some other vendor plugged in, These all can be possible if you are composable approach.

So if you want to go composable DxP route, you first need to know how many non-composable piece you have in your current system, and you will need to list them and plan about what is the replacement or composable block available which we can fit in, Because if you go composable that means CMS should only do CMS part, it should not be responsible for analytics, content search on the site, SEO, CMS should only do content management and rest of those blocks needs to be moved out and mapped to the available composable block in the Sitecore composable offerings or other available in market, and following is the highlight of the experiences where we mapped them


 
As you see the mapped systems, now it was time to find out the answers of outstanding questions, because we needed to find a true composable piece of each systems.
 
Here we suggested SC10 with XM and not XP, Because we want CMS to do CMS only and take out all in one XP approach.
 
NOTE: 
 
  • There can be obvious questions on if we can use "Sitecore Discover", but we found out from Sitecore demo given by them that it is only focused on "Product discovery tool" and not the content search.
  • We did conduct calls with multiple vendors to know their composable offerings, Sitecore Search, Algolia,  Coveo atom, We can not use existing coveo because coveo is semi SaaS where we need to install its package to be able to work with it, while in headless everything should be independent, so coveo atom might be the composable piece, We were inclined towards algolia and sitecore search as they both offered content AI search in composable way.
  • We also mapped every renderings used on the site, and listed them down along with its variants so we know how many of them should be created as new headless renderings, so we can estimate over all effort, Our recommendation is to use NEXT.JS to make it future ready, Because that is also will make sure that you will XM Cloud ready down the line, as XM Cloud only supports NEXT.JS
  • Decision here which system to use and how to rethink on a newer design was also based on how much we can live with and how much we can live without, What composable piece we already have like google analytics, marketo etc., Cost involved, Efforts involved, Time of "Go to market", so we had couple of calls with strategy team + Technology team + Product owners.
 
PO interviews 

Here we made sure to ask all the questions, Because before going headless & composable, we need to ask lot of questions and not just do it without a reason, there should be a strong need of it, of course the world is moving in that direction but its all about investment of time, money and efforts and then deciding what we want to do, and to help those decisions, we conducted PO interview with following questions.

Q : Out of 5, Looking at the ROI and at the future needs, can we live with just monolith and can only do upgrade to SC10 with greatest and latest upgrade and keep on working, Do we really need to go headless? From business perspective? higher the number, higher the point to go towards headless.

reason of above questions was because as our team at horizontal already published one white paper where in after all the research they carried out, they suggested that if you are monolith and if you are on 9+ Sitecore version, it is advisable just to upgrade to higher version and that should suffice otherwise the journey will be longer and almost a rewrite of every piece, Click here to read that white paper, See screen grab of that white paper, I strongly recommend to go to above link and download that white paper.

Q : Out of 5, How many points that you give for urgency to upgrade and business priority vs current feature release? (higher the number higher the likelihood to go upgrade way)

Q: Out of 5, How much keen are you (business) to start roadmap for upgrade vs not upgrading and adding the functionality on top of existing Sitecore? (higher the number higher the likelihood that you are keen)
 
Q : What level of usability are we looking at? Considering content author experience and how are they going to use the system? or we want greatest and latest?

Q: How much design refresh are we thinking? Are we totally having new designs? or we just need page migrated to new headless, algolia and other technologies from tradition SXA and coveo?

Q: Are we ok to pause on new functionalities till we migrate to a new platform? It will be more ideal to pause new feature development till we go headless. Our existing production site will keep working with whatever we have developed till now.

Q: Is our decisions to go for upgrade depends on cost in terms of time and money or not?

Q : This will increase the cost, do we want to consider that part or we should not worry about it? But eventually on a longer run it will be more sophisticated?

Q: As seen in discovery upgrade to SC10 looks the first step which is itself will take time, not days but definitely couple of months. We will need skilled resources (front end / back end) for both approaches - so resourcing is also a key here. It boils down to business decision on having minimum changes and team can work on upgrade, or we can have two team for maintenance and support for current version and one team for upgrade.

Creating a roadmap

Now, with all these research in place, it was time to connect with our technology group directors to have further discussions by presenting this discovery to them and create a roadmap for finalize approach and start estimation and process around it.

We presented following two approaches to the leadership team, strategy team and product owners

Approach 1 – From monolithic to headless or “composable curious”

  1. Phase 1 – Upgrade to Sitecore 10+

    1. This will be done side by side on a sandbox until everything is done. At that time, we can switch DNS over to new platform.

  2. Phase 2 – Go headless & composable stack

    1. Part 1 – Break down static pages by component (and component variant) and start working on it.

      1. Test on sandbox while moving on to implementation for part 2.

    2. Part 2 – (Composable) Move on to implementation of dynamic content / other integrations like Coveo or other composable piece listed in system mapping phase.

      1. Test everything on sandbox and GO LIVE

    3. Part 3 – Clean up old code base


 Approach 1 – From monolithic to composable excluding upgrade to SC10 phase

  1. Phase 1 – Update to SC10 in same phase and do a complete rewrite for headless

    1. Part 1 – Break down static pages by component (and component variant) and start working on it.

      1. Test on sandbox while moving on to implementation for part 2.

    2. Part 2 – (Composable) Move on to implementation of dynamic content / other integrations like Coveo or other composable piece listed in system mapping phase.

      1. Test everything on sandbox and GO LIVE

    3. Part 3 – Clean up old code base

       

NOTE: 

1) We knew journey is not easy as it is listed in the high level approach, but its very high level plan to start with and break down the phases in more detail when the high level plan is approved.

1) There were so many questions/discussion on which composable piece we want to bring in and what competency (technical competency) we have for that (There are open questions for which we will need more discussions), But being on Sitecore, we were inclined towards Sitecore offerings. (CDP + Sitecore Send + Content hub)

2) This research was time bound and time boxed, Suggestions or approaches suggested here might very depending on your business need, and as they say "There’s no one size fits all"

3) This discovery was done when you already have Sitecore monolith setup, but if you are absolutely fresh and starting your journey, approach will be totally different depending on the need, like you can have lightweight CMS "Sitecore's Content hub one" and start building all your composable stack on top of it, but as you see its all to choose from "Best of the breed" and choice is yours what to pick and choose.

If you are an organization or a individual who is looking to go on this journey sooner or later, best part is there no right or wrong answer to any approaches, its all depends on what is best for you considering time & budget & team, you could decide to HOLD and keep on the same Sitecore DxP or can decide to do composable journey in phase wise, it all depends on your decision.

But if you consider what pieces to consider in that decision, it will make the journey easy, and that is what i tried to show in this post.

Addition to above discovery, There is already a white paper published by amazing team Horizontal, Which talks on How should your organization plan a path to a composable future? Download the white paper to get great insights.

 
Currently we are at the stage where we are preparing RFP for our internal client with help of leadership team & technical group director, where we are putting all the piece from discovery and putting in an excel to come up with some estimate around it...

    




Comments

Popular posts from this blog

Sitecore Technical Workshops - Top FAQs customers asked on XM Cloud

Hi Readers, I want to talk to you about interesting things which we have been doing which is "Technical Workshops" for our customers, so here goes the scenarios. So, we have been doing multiple types of technical workshops.  1) Training customer and their Sitecore technical team on latest and the greatest technologies like XM Cloud & Another composable stack and try enabling them for new Sitecore tech stack. 2) Customers / Potential Customers have their agenda of existing pain points, and we take a workshop on topics around them with best practices etc. little on new technologies, so they also know the future. Basically, we prepare custom targeted presentations & demos for individual workshops, and make sure it helps them answer their questions and they get insights of where Sitecore eco systems has to offer from their versatile toolset and try to keep them up to date with it. So, Purpose of this blog is, because in all these customer & their technical team's

An error occurred while receiving the HTTP response to This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details.

You have noticed many times that everything was working fine and suddenly the below error starts coming and you find no way to work it out An error occurred while receiving the HTTP response to This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details. The reason for this is the receiving size of WCF service is smaller then the data which is coming from service It was working before because it was small,So you will have to try to increase the receiving setting in your end point,Possible settings can be following maxStringContentLength="2147483647" maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" maxArrayLength="2147483647" That would definately help you!!!

Set up leprechaun code generation with Sitecore XM Cloud Starterkit

Hi Sitecorians, It has been amazing learning year so far and with the change in technology and shift of the focus on frontend frameworks and composable products, it has been market demand to keep learning and exploring new things. Reasons behind this blog Today's topic is something that was in my draft from April-May, and I always thought that there is already a good documentation out there for  Leprechaun  and a blog post is not needed, Until I realized that there was so many of us facing same kind of issues and same kind of problems and spending same amount of time, That is where I thought, if I could write something which can reduce that repetitive troubleshooting time, That would really help the community. 1)  In a project environment, if we get into some configuration issues, we resolve them, we make sure we are not blocked and continue, but if you think same issue, same step and same scenario will come to other people, so if we can draft it online, it will help other people 2