In our previous blog, we spoke about setting up your MarTech stack to align to the people, processes and technologies within your business and then building an operational cadence around marketing.
Now it's time to get into what this really looks like day-to-day, and some key considerations you need to think about when building your team around MarTech.
So to begin, how do we go about managing these complex marketing technology stacks under the hood?
There are things that marketing technology vendors will tell you – most commonly that their technology is easy to deploy. In reality, if the technology was easy to deploy, it would already be in a Software as a Service (SaaS), or software subscription model - because ultimately, what organisation doesn't want to move to a SaaS-type model?
For those organisations that are already SaaS, you will hear things like open source and API-driven. Whilst that might be true, how many of you have successfully implemented a small, simple, nimble API project to get one small capability off the ground? It very rarely happens, and if it does, it's not a core critical business requirement, or a core capability that you have enabled.
Building a Team around your MarTech
With all that in mind around what these marketing technology vendors will (or won’t) tell you, you then suddenly realise, "Crikey, we don't have the skill sets to manage this platform in-house." Then you will go to market and recruit that skill set. You will hire a series of developers, DevOps engineers, and infrastructure experts. But, have you considered where these functions fit within your core business? Is your core business to be out there building a marketing technology function, a series of capabilities and skills that will almost absolutely be defunct in less than 6 to 12 months' time?
That's a question that only you can answer. If your core business is to deliver marketing technology capability internally, it will make sense to go and hire an infrastructure engineer and application expert.
But in reality, can you find them? Can you find somebody who intimately knows the core capabilities of the marketing technology stack that you have purchased? Whether that’s a Sitecore, Adobe, Kentico or EPiServer solution, you will probably struggle to find the right mix of skills for your stack.
Let’s dive into the mix of skills that are required.
Troubleshooting MarTech with the right skills
At Dataweavers, we find ourselves successful in resolving the lion's share of marketing technology stack issues because we understand the underlying capability required, both from an infrastructure, developer and customer experience perspective.
Just knowing how a website works is not enough to be able to troubleshoot lines of code that have been put into production and are not performing as expected. Being able to troubleshoot lines of code in a Microsoft Azure Platform as a Service (PaaS) world is tough. It’s not good enough to just be a C sharp developer if you don't understand the underlying ARM templating, underlying Platform as a Service, API-driven nature of Microsoft Azure. You need to be able to troubleshoot application services where those servers are perhaps running a little bit too hot, or where there might be a memory leak, or a configuration issue that's been deployed.
You're not going to know those unless you know the marketing technology stack. So to us, it's obvious that being able to troubleshoot marketing technology requires that hybrid mix of skills. If you've successfully been able to manage your stack internally so far, it's because you have one of those developers or infrastructure engineers who does cross over that marketing boundary well.
Business Risk
From a business risk perspective, is finding and keeping those skills sourced and up to date something that you're prepared to bear? Does it make sense for you to have just one developer who can keep your website up and running all the time, because they intricately know the customisations of the Microsoft Azure stack that you have taken, plus all of the lines of code and can troubleshoot that on the fly.
From a commoditised marketing technology perspective, this approach is becoming less and less desirable.
Azure Hosting
There's another approach we take that will help minimize the number of errors and downtime issues that organizations experience, as well as give the ability to pinpoint the problems faster. This is the productised nature to Azure hosting. Sitecore technology, for example, can really only be deployed one or two particular ways. When that technology is deployed, it's usually in a small, medium, large, extra-large type of capacity. For the purists out there, we will see arguments around “Azure Search versus Solr”, or “What about scaling all of the roles versus combining all of the roles?”
Money issues
The answer to this typically comes down to a money conversation.
In reality, if you’re haggling over hosting costs from a Sitecore and Adobe perspective, you're probably focused on the wrong thing. Yes, there might be a difference of $200, $300, $400 here and there by the time you've combined a series of SQL databases, but if you take that approach and maintain that level of customisation for every single time you deploy Sitecore, you should be asking yourself if you’re spending time on the right things.
Is your time better spent delivering great digital experiences, fixing that little JavaScript bug that's been on the site and annoying you for some time now, or making that scrolling mechanism on the homepage work a bit better? You might find the answer is yes.
By thinking about what you're investing your time on, you start to realise that $100 you're saving here and $200 you're saving there tend to build up, and maintaining the infrastructure becomes this hidden cost of people, time, and customization.
Smart deployments
At Dataweavers we take a productised approach. Every single deployment we do is deployed exactly the same. There are some nuances; it might be that one customer needs geo scaling in one region over another, or that a customer is geo scaling in four regions as opposed to two.
These are what we call configuration variables. These are the ways that we make settings and scripts change -- not script changes. These are settings that get deployed when Sitecore is deployed, to help define the customers' particular footprint. But, the configuration approach that we take – the deployment approach that we take – is productized and is maintained across those different versions.
So, when we come to deploy a Sitecore 9.3 installation, we will simply bring out a 9.3 installation deployment capability, choose an S, M, L or XL type size deployment, define 3 to 10 different variables depending on the customers' requirements, and away we go.
Productised approach to MarTech
This productised approach to MarTech means that we remove the guesswork – which is where you lose time.
As an organisation that is already investing in Sitecore or Adobe as capex or significant opex, you need to take the same level of risk management, due diligence care and attention to your hosting platform.
We wholeheartedly recommend deploying your MarTech on the Microsoft Azure stack for reasons covered in blogs elsewhere. But, when it comes to managing your marketing technology stack, it's absolutely critical to focus on where you’re spending your time, and how you're deploying your marketing technology. Doing it in-house is very difficult for most organisations – so we’re here to help.
If you’re interested to learn more about how Triggerfish can help you build, operate and manage your MarTech, book a free 90-minute meeting with us and we will show you how we will help.
