Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | Android | TuneIn | RSS
John WilliamsThe rise of omnichannel content strategy and the emergence of new technical capabilities like cloud computing, API-delivered microservices, and headless software platforms have created entire new content ecosystems.
John Williams explores these new systems and modern content and experience architectures on his “Going Headless with John” YouTube channel and in his work as CTO at Amplience, a headless-CMS company.
We talked about:
- his YouTube channel, Going Headless with John, and his role at Amplience, a headless CMS company
- the rationale behind the MACH alliance and the elements of the acronym
- Microservices
- API first
- Cloud native
- Headless
- the ability to scale and to implement version control that a multi-tenant architecture permits
- how decoupled architectures let companies choose “best of breed” software solutions
- his take on the differences between the concepts of “headless,” “MACH architecture,” and “composability”
- how to help content authors work in (non-WYSIWYG) decoupled systems
- the importance of understanding the “why” in decoupled content authoring environments
- the benefits of adopting an iterative approach to implementing composable architectures
John’s bio
John Williams is a highly experienced and innovative CTO with over 25 years of experience in the tech industry. He is passionate about leveraging technology to drive growth and innovation. His expertise lies in creating and executing technology strategies that deliver transformative results for businesses, and he has a proven track record of building high-performing teams that thrive in fast-paced and rapidly changing environments.
Connect with John online
- Going Headless with John YouTube channel
Video
Here’s the video version of our conversation:
Podcast intro transcript
This is the Content Strategy Insights podcast, episode number 187. The rise of omnichannel content strategy and composable commerce – along with the emergence of new tech practices like microservices and headless software platforms – has given rise to new content systems architectures. It’s also inspired many new conversations around concepts like composability and decoupled-ness. John Williams explores these topics on his “Going Headless with John” YouTube channel and in his work as the CTO at a headless CMS company.
Interview transcript
Larry:
Hi everyone. Welcome to episode number 187 of the Content Strategy Insights podcast. I’m really happy today to welcome to the show, John Williams. John is the CTO at Amplience, a commerce-oriented, headless CMS. He’s also the host of Going Headless with John, a YouTube channel that I really enjoy. So welcome John. Tell the folks a little bit more about what you’re up to these days.
John:
Yeah. Well, we’re actually working on… In Amplience we’re working on a whole bunch of things around headless. We’re doing a whole new release around our content form. We are doing a hell of a lot around AI and how we incorporate that into the MACH world, which is what we’re talking about today, and how we keep consistent with our technology practices around MACH and headless, as well as incorporating new technology.
John:
So we’re all pretty busy at the minute. We’ve got a really big release coming up, out in June at Shoptalk. For anyone who’s going there, coming over and see me have a chat at the booth, we’ll show you some really cool things.
Larry:
Cool. Yeah, and you’ve just hit on the… We’re all infinitely busy these days trying to keep up with, not with just AI. But there’s also the fundamental architectural stuff that we’re dealing with in this new composable, MACH-ey, headless world.
Larry:
I guess one of the things I like to do in this podcast, it’s all about democratizing practice and principles and what’s going on out in the world. And one of the things I like about your YouTube channel is you’re really good at explaining the benefits and the concepts that surround headless, but that’s happening in the context. Headless is the H in MACH and maybe the… I’m not sure I would say a MACH or MACH. But anyhow, I know that Amplience is one of the founding members of the Alliance. Maybe you could talk a little bit about that? And for folks who don’t know, that it’s an acronym for microservices, API-first, cloud-native, and headless architectures. So maybe you could talk a little bit about that world?
John:
Yeah, sure. So the actual concept evolved. So we were found a member of the MACH Alliance, which we can chat about later. But the actual principles just evolved in terms of an ethos of how we build software. And it’s not like we just turned up one day and said, “oh, let’s just do this thing called MACH,” because it didn’t exist.
John:
It was just the approach using lots of modern approaches together. So microservices, that’s more about doing very small self-contained pieces of code that ultimately have a service that deliver a service, but keep it really tight and focus on those services for a specific business problem or a specific business domain. And keep it really self-contained, including things like the database so that individual teams can actually work on these microservices. And it allows you to build things a lot more quickly, because you can iterate on those smaller areas. And you can also deploy them separately so your teams can be more independent of each other. Because they’re all working to a contract and they’re all on these different microservices.
John:
So it’s a really good way of pulling a system apart, which is always what you do in software engineering terms, abstract, and then pull the system apart and then allow you to focus on those individual areas. So microservices is the thinking about services in actual… Think of business demands, think of them as fixing a specific problem, those kinds of things.
John:
Then there’s the API-first, and this was the one that always gets people a bit confused, I would say, between the microservices and headless. The API-first is really about thinking about the things you’re building in terms of their APIs before you start thinking about how you’re going to actually build it. So if you are going to work on a particular business demand, start thinking about the APIs that are necessarily around that, and by doing that, it allows you to actually make that system more flexible in many ways because you start thinking about how the system is going to be used from the outside.
John:
One of the big things around API-first is the coverage. So if you go down an API-first route and you’re down a headless API-first route, the whole system should really be accessible through an API. There shouldn’t be some special thing somewhere that you have to go and log onto something and that you can only get access it through an SDK. Or it’s only ever accessible, even if there is an API, through a very specific SDK, because it’s got lots of other special routing in there.
John:
So having that sort of API-first approach allows you to basically turn your system more like a toolbox. So you’ve got all of these different APIs you can connect with and do lots of interesting things around. The reason that it’s… I would say I’m going to miss the C for now, but the reason I’d say it’s different from headless, is you could have a system that’s headless, but it’s still not API-first because all of your admin system, all of your backend could still be, I don’t know, running on a server somewhere that you have to connect into, but your content or your features could all be delivered headless.
John:
So it’s quite a subtle distinction. But a headless and API-first are not necessarily the same thing. And also when you think about… I’m quite passionate about this, when you think about headless, it’s actually not just the API, and I’m going to use CMS because that’s the world that I live in. If you just have an API that allows you to access your content, you may still have dependencies on the presentation layer. It may not be completely separate, it may not be completely headless, because your underlying database, your structures and how you think about the world may be more monolithic because it’s come from a monolithic aspect.
John:
Which means that there’s still parts of the technology that are considering the presentation layer. You still have to understand the nuances of how it’s going to be deployed, whereas in pure headless, you’ve abstracted it all away. So that you don’t care whether it’s in a presentation layer or not actually.
John:
And that’s been at the fundamental level. That’s why you see many headless CMSs that use things like, allow you to define the schemas or completely schemeless for delivering their content. And obviously the C in MACH is cloud, being cloud-native. That’s been done to death now, I think in the industry for many years, but it’s all… Your system should be completely deployable in the cloud, it’s running in the cloud.
John:
When we’re in the MACH Alliance, what we look for are things like being multi-tenanted, so not just being a managed service in the cloud, but be a more multi-tenanted version of that in the cloud. So you can take the full power of scale that you get from working on Amazon AWS or as your… Does that help?
Larry:
Yeah. No, that helps a lot. In fact, a couple of concepts there you’ve mentioned. I want to revisit the need to abstract things and separate concerns out. But I wanted to talk just real quickly about multi-tenancy. One of the reasons I wanted to have you on is because you’re very technical. And probably over the course of the 186 prior episode, there’s probably been 80% less technical. So I really want to go…
Larry:
One of the things I think you can maybe help my folks understand, is that notion of multi-tenancy. And I think you distinguished it from… I forget how you did it. But anyhow, that notion of… The benefit of that is scale, the ability to leverage some core competencies across a number of tenants or clients of the system.
John:
Yeah, well there’s a number of things on that. So you’re right. You’re exactly right. There’s one thing in terms of scale. We’ve went from right at the beginning we were having say millions of requests a week, and now we do billions of requests a week. And we’ve all got the same infrastructure and we’ve just been scaling it up. And everybody then benefits from that, because you’ve got this huge amount of scale.
John:
And I’ve had customers in the past, for instance, who’ll go, well, are you able to deal with our level of scale? We’re huge, we’ve got… I’m not going to name any customers. We do a million requests in a day or something, and we’ll go, yeah, we’re 10 times that in an hour. It’s that kind of thing. So therefore we can scale.
John:
And that’s the difference. If you’re not multi-tenanted, then you have to actually worry about scaling all the individual customers as they come on board. You have to size them up. It’s both good for the customer and good for the vendor as well, because it means that you can build an architecture where you’ve got peaks and troughs and different customers and you can flatten them out and manage that whole scale and the provisioning of that. So you’re doing it holistically.
John:
So that, you’re definitely right. Scale is something that’s really, really important. And I always look at… When I’m looking at vendors, not just CMS, but when we’re buying customers and partners to work with us, if they’re not multi-tenanted and they start using scaling language, it always makes me concerned that maybe their system can’t scale. Because you have to be able to scale to do multi-tenanted.
Larry:
Oh, interesting. If they even say that it’s something that they’re fretting about a lot and…
John:
If they say something like, “oh yeah, we’re multi-tenanted but I tell you what we’re going to do, we’re going to put you on a dedicated instance, so we can have the scale.” And you think, well, wait a minute. There’s something not quite right.
Larry:
I got to say I love the way you skipped over the C at first, because I’m like, “that’s just the water we swim in. That’s just where everything is now.”
John:
Yeah.
Larry:
But one of the benefits of it is that the fact that not all multi-tenant, but the things that makes AWS and Azure and those cloud services work is that they can quickly spin up whatever you need. It permits that multi-tenancy, their infrastructure.
John:
Yeah. But you’ve got to build the architecture underneath, on top of that, in the right way to do it. The other big massive benefit, and you see less of this now today, the other big massive benefit is that of version control for… Remember in the past when you bought some monolithic software, you spent maybe, I don’t know, six months, a year if it’s a big system, installing it, getting it all working. And when you’d finished the vendor has now created a brand new version and you think, great, let’s upgrade to the new version. And then you realize it’s going to take you three months to do that upgrade, because there’s different hardware involved, there’s different operating systems, different this, different that, the front end needs to be changed. The data model’s different. There’s all of these complexities that you need to deal with.
John:
Because the backwards compatibility of those things, they really just pushed it off onto the customer and their partners who would then do that work. Whereas with multi… And even in a managed service, if you’re buying a service as a managed service, not multi-tenanted, you still have to deal with that. Because they’ll do a new version. It may not be backward compatible. You have to switch between versions. And I’ve seen people, I’m not going to say which software it is, where they’re having conversation, “are you on this version of that version? Our software, that if you to use it doesn’t work on that version, it works…”
John:
It’s all of that mess that comes with having different versions of the software. When you’re true MACH and and you’re multi-tenenated, most of the releases you do are backward compatible, well, all the releases you do backward compatible, but you may have new features that you want to incorporate, which is different. It means all your APIs will still work. And you’ve seen this with Amazon and a whole bunch of other systems out there, but our systems themselves, we do 100s and 100s of releases every year. They’re constantly happening in the back. But everybody is on the same version. There is no version.
John:
And I remembered in the past even bringing people into our company and they get confused, what version are we on? I said, it doesn’t matter. Everyone’s on the same version. And it just takes away that pain, because it’s up to us. It’s up to vendors like us, who are in the MACH Alliance, who are doing this new form of architecture, it’s up to us to make sure it works, not the customer. I think that’s the big difference.
John:
So you provide a set of services. When you are in the SaaS world, if you think about what you’re doing in SaaS, you’re renting in a lot of respects. You’re renting a service, you’re paying for that service, so therefore it’s up to you and that service to make sure that it fully scales and it’s going to be backward compatible. And that’s one of the big benefits of building things in this way, building the right architecture.
Larry:
And you’re hinting at some of the benefits of the abstractness of these systems and their foundation in microservices. Because SaaS, those are by definition micro, they’re parts of the whole system.
Larry:
But I would love to revisit that a little bit too, that notion of… Because a lot of the stuff you were just talking about, that fundamental concept in these architectures have separation of concerns, like you do design here, you do content here, you do payment processing here, you do something else there. Can you talk a little bit about… Because you’re at an architectural level in this, some of the maybe challenges but benefits of teasing these things out, because one of the benefits of the traditional monolithic architectures is you just do it all in one place. But there are real benefits of teasing things out and focusing on one thing in one place. Can you talk a little bit more about that?
John:
Yeah, I think from a business point of view, what it allows you to do is it goes more to that composable end, which is a whole new discussion, which it allows you to have best of breed suppliers. And best of breed doesn’t mean it’s the best one in the industry, in my opinion. Best of breed means it’s the best one for you as a customer. It’s the best one for you as a business.
John:
Every business you deal with has different dimensions and deals with things in lots of different ways. And even if you say that you are the top commerce platform, the top CMS, the top personalization engine, whichever bit of software, it doesn’t always mean that you’re going to fit into every single customer in the same way. And by allowing you to have these separations of concerns, it means that customers can really focus on the business problems that they have and choosing the right pieces of software to fix those actual business problems. They don’t have to deal with… You know what, I’ve bought this big monolith. I’ve got three big monoliths. This one does e-commerce quite well. This one does e-commerce or care, but I like the CMS, this one… I like the searchendizing on this other one.
John:
And then they’re going, “well, which bit’s the most important to us? Should we do more on the searchandizing, merchandizing stuff, or are we going to do a lot more content?” And it’s always about a compromise with trying to choose it, choose the right level of platform, whereas if you can then choose the individual pieces, you can choose the one that’s best for you, going, “you know what, why can’t we have… Why can’t we just have the pieces that allow us to do our job?” Which, I think is one of the biggest benefits there, which is that ability to actually choose and assemble the pieces that you need.
John:
There’s a really good article, I think it was one of the Forrester guys wrote around DXPs, which is another big monolithic concept. Which was, are DXPs dead and actually are people just assembling their own DXPs? So in other words, rather than choose one that does all of their content management, personalization, et cetera, you just choose the pieces that you need and bring them together. And digital experience management is really about the assembly of all of the individual components, individual pieces of software brought together to then deliver what you actually need…
Larry:
As you say that, I’m reminded, DXP stands for digital experience platform, but you can build your own platform, is the point.
John:
Yeah. Exactly.
Larry:
Exactly. It doesn’t have to be a single solution. But hey, I want to revisit just a little bit. You mentioned the word composable a minute ago, and before we went on the air, you talked about your current pet peeve is the conflation or misunderstanding, the difference between these decoupled architectures and the notion of composability. Can you talk a little bit about that?
John:
I’ll go around the… Rather than pure wide-scale composable architecture, let’s focus more on composable commerce. And that phrase was coined in Gartner, and it was a reflection of when MACH architectures started to appear and more sort of headless-based architectures appeared. There needed to be more of a business point of view on what those were.
John:
So I always say that the MACH architecture is how you’re going to build something. It’s the ethos and how you’re going to assemble things. It’s the architecture, it’s a set of technical principles of how to build software, whereas composability is what you’re going to do with it. It’s a little bit more like the why. It’s more of a business framework to understand how these pieces of technology might fit together in your business. And not many people use it as much now, but I always like the cube that they used, which was, I think it was technical stack on one side, customer journey on the other, and then capabilities.
John:
And it was actually understanding what shape within that cube that you were fitting, and the pieces that you needed. And this is what I’m saying. So like customer journey, that’s a business concept. It’s like, well, where in the customer journey does this piece of technology fit? Or what capabilities does it supply? And where does the technology stack fit in? And the technology stack is really the MACH architecture piece, so that fits in the technology stack.
John:
It’s quite subtle and nuanced. So what happens is people conflate them together. And I get into loads of conversations, people go, “oh yeah, we’re looking to go in headless, MACH, composable,” because it’s not really clear about what that really is. So for me, composability is more of a business technique, more of a framework, more of a concept, whereas MACH architecture are the set of principles in which you would build software to get a composable system. You could have composability without MACH architecture, and you can do lots of other things with MACH architecture they’re not necessarily building a composable system.
Larry:
It’s not like separation of concerns, it’s like different views on the same world.
John:
Yeah, it is. Yeah.
Larry:
Yeah, that’s great. Hey, from that, I want to drill down a little, way deeper actually, because one of the implications of these new systems, and a lot of my listeners I know are either content designers working on these SaaS systems or more publishing-oriented or marketing, or web content folks, and they’re the ones who are in these authoring systems every day that are just one part of these big systems.
Larry:
And there’s been this… I think there’s an ongoing challenge, and it’s not just a challenge, but it’s just a generic issue around going from WYSIWYG editors where what you’re working in… And you hit “publish”, and it looks pretty much the same on the website to… One of the things with these composable architureres or headless architectures, is that you end up with… Sometimes you’re authoring in a system that looks very different from what end output is. Have you had to help authors in this transition or adaptation to these new systems?
John:
Yeah. At the beginning, it can be quite tricky for people to really understand what’s going on. So if you think about the old world, you were really just building a website and that website was probably only ever going to be used on a desktop. And then it wasn’t until later we started to get… Nearly everything’s mobile now. And then we got responsive design.
John:
So you can still kind of do, what you see is what you get type model with a… It’s not very responsive to time. But then it goes beyond that with native applications. And so for instance, we have a customer that, and it’s my favorite one, where it actually uses content in a website, in a native application, and in an actual grill, it can actually use the content across those devices. And they’re all very different. So how do you know what you’re going to get? Because you don’t, it could be used in all sorts of different ways.
John:
The same where I’ve got customers that use them in direct content into gas station kiosks as well as kiosks in-store and on the website. So all of these different ways of thinking about how the content is deployed, it will look very different. So trying to build an interface of how that content is used is really, really tricky. And it’s also quite difficult for some people to make that leap initially. So how we’ve done it is we have a representation on one side, which is this is what it’s going to look like, and you can choose the channel, you can choose the device. You can choose everything. So you can see what it’s going to look like when it comes out. And then you’ve got the authoring interface on the other side. So as you do the changes, you can see how that reflects across.
John:
There is a movement I can see going on right now, where some headless CMSs are going back and building front ends so that they can do more WYSIWYG type interfaces. But then I look at it and say, are we just swinging back towards a more web CMS world? How’s that really going to work when it comes to native applications and all the other endpoints that you’re going to do?
John:
And also, if you look at CMS in its entirety, if you are in e-commerce world, CMS is a part of an ecosystem of other things that are going on, hence going back to the composable side of things. A page is composed of, it could be a list page with many products listed out from a search and you want some content at the top of the page. If you’re on the home page it’s going to be more content rich, but then you may have product recommendations in the center of that. You may want to put additional content in a product details page.
John:
But the whole experience is assembled from many other systems in an ecosystem. So actually separating out the concerns in a different way where the presentation layer becomes a storefront in that scenario and you are pushing content into a storefront. It makes sense. And then again, if you try to do a pure WYSIWYG environment in that, it’d almost impossible. Because not only do you not know what it’s going to look like at the other side, the composition of all of those different elements and the development of the storefront is also very different, because it’s also transactional. It’s not just about viewing content.
Larry:
Yeah, that’s right. And it’s interesting. I personally haven’t done a lot of commerce stuff, but you’re making me realize that it’s a really interesting use case for these architectures. Because like you mentioned, gas station kiosks and other storefronts, and there’s probably point of sale systems and all kinds of non-web-page looking things where this content appears.
Larry:
I’m curious, one of the things I’ve done a little bit in some big SaaS systems, working with helping authors navigate that system, because sometimes you can’t preview it. It gets… Again, back to the abstractness, where you might be offering content to an end intent, but it’s almost impossible to preview. It sounds like in your world you’ve been able to help people navigate that with a preview thing, but have you done much with, or are you aware of folks helping authors make that transition from WYSIWYG to more abstract environments?
John:
Yeah. We spend a lot of time with… When we’re going through the process of defining… I think when you go through the process of defining what you’re using the content for. So it goes back to the why, right? So if you just switch a business user from… There’s one interface, now you’re using that one, then you’ve got a real problem. But actually what happens is that you will go through and work… It’s more of a collaborative type environment in which you have to work when you go more towards these headless systems.
John:
And I think there’s a switch between hierarchical organizations, where they’re in the different departments to more agile like product-based teams, which I’m seeing more and more in our customers now. So you’ll have more of a product-based attitude to the system. Say you might have a product team that is literally just focused on doing the content for promotions on the home page and say some landing pages or certain categories.
John:
At that point in time, they’ve got a blend of technical, maybe creative copywriters and business folks all working together. So therefore they’re going, we need a new type of content to promote this particular thing. And in that aspect, they work together to pull that together so that the creatives will do their work to see what it looks like. To go through that. Working with the engineers to then build it out. Because it has to appear somewhere in the front end. But also then, building, say a schema, that then will be used to populate that from the CMS into the other side.
John:
And that is a collaborative approach to doing it. So by going through that whole process, business users are more involved with how it’s being done, therefore understands much more about what they’re trying to achieve. So when they go into the interface, they can understand what they’re actually doing around creating that content. And also they feel much more empowered, because they feel like they’ve got a lot more control, which they didn’t have before. Because before it was just a fixed template that you could do nothing with.
Larry:
Yeah. Well, empowering content people, that’s my hope, my fondest hope for this whole podcast. Hey, John, I can’t believe it. We’re coming up close to time, but is there anything last, anything you want to revisit from the conversation or just share with the folks before we wrap up?
John:
Yeah. I think we mentioned this previously, and it was around the composability and MACH side of things. I think there’s only one frustration I’ve had recently, which is when people think about composability, they think about composable architecture or composable platforms, I think is the word they often use. Which sends many businesses down a route that they have to replace everything that they’ve already got because they need this new composable platform, when actually the origins of working with MACH Architecture has been much more of an iterative approach, which is about: choose your pain points, implement the microservices, the nature of what we’re doing to fix those pain points and then iterate.
John:
So instead of going towards a big huge bang approach, you can go down a more iterative approach. And I think we can’t lose sight of that, especially today in the macro environment that we live in, where actually it’s better to do smaller things and with less budget and less risk, than it is to try and change the world all in one go.
Larry:
Nice. I love that pragmatic, iterative approach that seems very appropriate to this century that we’re currently in. Hey, one very last thing, John, if folks want to connect with you online, what’s the best way to follow you or connect?
John:
Yeah. Following me, reach out to me on LinkedIn, John Williams. I’m the CTO of Ampliance, so you can easily find me on LinkedIn. Also, have a look at my YouTube channel, Going Headless with John.
Larry:
Right. And I will definitely put links to those in the show notes as well. Well, thank you so much, John. Really enjoyable conversation.
John:
Yeah, thanks a lot, Larry.
Leave a Reply