If technical debt is a disease, SXA is the cure

It happens like this – let's say you are building a website in a web content management system like Sitecore, Kentico, DotNetNuke or Adobe. It really doesn't matter. You install your CMS platform, which has all the infrastructure for you to start building upon. 

Cool.

When you install the CMS it most certainly isn't a website, it might be a website template system like say, DotNetNuke, where on installation a site is kind of built, albeit without content or a theme, it's a bare framework to add modules, content and the design layer. Or it might be a 'build from the ground up' system like Sitecore.

Whether you use an open platform like Sitecore, in which you build literally everything from the ground up, or use DotNetNuke, or even Wordpress, the second you add to that code base you have the beginnings of technical debt.

Not so cool.

As soon as you have to upgrade the platform, your sitewide code is out of date. Your CMS product evolves, and your code simply doesn't. Sure you may patch it where you have to, to keep the lights on – but more or less, over the years much of your legacy code is still built for and optimised towards a version of your CMS that is increasingly left behind on each update. The train has left the station!

I'm a Sitecore guy, so I'm going to stick with that product for the following example. OK, I've installed Sitecore, and fired it up. I really have a blank canvas and need to build my data templates, my IA and my presentation layer, as well as adding the design and CSS to bring the site to life. This is all custom development, and it's custom development based on the version of Sitecore I installed. So far, so good.

Most agencies want to be able to provide speed to market, and really want to replicate code to shortcut the development lifecycle. It's more profitable, and in many cases more reliable. This reused code is often considered a framework that is built on top of Sitecore. It's not a bad plan, and there are benefits, but as we will see ultimately there is a 'gotcha"', as code currency just got kicked down the road. 

Many agencies built their own reusable frameworks, often called solution accelerators because broadly that's what they do – they let the developer copy code from a core library of pre-written snippets, modules or what-have-you and roll your site faster.

Sadly this custom framework is the part of the site that makes your site... well... yours – and every single instance of custom development locks you back in time at the version of Sitecore you initially developed for. Trust me, this framework hardly ever gets upgraded as you upgrade Sitecore. It sits there at the heart of your digital offering, getting old and older even if new scaffolding is applied when you upgrade Sitecore.

Technical debt-au-go-go.

Sitecore realised there is a better way. What if they made a framework themselves and wrapped it in absolute best-practice code, laser designed to work with the platform, and released it – and critically upgraded it – with each update of Sitecore? All that technical burden suddenly is shifted to the vendor, rather than the agency. 

Hallelujah!

SXA offers so many benefits it's bewildering why some agencies still don't adopt it – a super fast rollout accelerator, 100+ pre-built and pre-tested modules, a mandated best-practice code base, scalable, extensible and enterprise reuse ready.

Perfect. What's not to love?

Of course there will always be some custom work because every business and site is different. That's a given. The age-old trick to managing technical debt is to minimise custom dev, especially on the boring bits, the common components that all sites use. It makes huge sense there to use out-of-the-box modules that can be modified to suit your look and feel without damaging the core code.

When you consider that Sitecore upgrades this vital asset, and you don't have to do it, it makes it a complete no-brainer.

SXA is so elegant that many agencies are now not dragging their customers through the painful, grudge spend oriented, upgrade process, where each piece of technical debt (old code) is dragged kicking and screaming into the light and fixed, often by simple brute strength trial and error testing and programming. Instead, they are recognising that major version upgrades represent a perfect opportunity to update their framework to SXA – and the easiest way to do this right now is to simply rebuild using SXA. It's fast!

Take for example upgrading from 8 to 9. Glassmapper (if used) will require much fiddling, forms and numerous APIs will need to be rebuilt, Mongo can be removed from your architecture (note Mongo 3.4 is 'end of life' in Jan 2020, so you are going to have to upgrade that as well) and in general a pile of work has to be done to get there. Subterranean plumbing work – below the waterline, with no visible benefit, and still you have technical debt.

Ugggh.

How good does a completely fresh Sitecore install sound, removing all existing technical debt, delivering an update that covers both Sitecore and your framework? It sounds even better when you consider that every subsequent upgrade will include an SXA upgrade as well, making the process easier, faster and more cost-effective.

Not Nirvana yet, but pretty close!

And best of all, everything you bought Sitecore for will work, as advertised! No roadblocks on optimisation. No getting (finally, maybe) to Phase Two optimisation and finding that there are numerous errors that need to be refactored to make the cool stuff work.

Ok, I'll say it at the risk of dating myself: "All the way with SXA". (Older heads will get the reference 😉)