Konabos Inc. - Konabos
17 Nov 2021
What is: Jamstack, ComposableDXP, and Headless CMS? In this video, we answer the question in simple terms to clarify.
Note: The following is the transcription of the video produced by an automated transcription system.
Welcome everybody, this is Matt Kam and Akshay from Konabos, not exactly the order we have to say here, but we're all going to have a nice little roundtable on some terms that are thrown about in the industry and from the marketing angle, which I tend to come from and trying to manage some of the technology resources. The these terms become almost used interchangeably, and I don't know that they should be. And I think there's a good point here to try to kind of delineate what each one means. So we're going to talk through what is jamstack, what is composable DXP and what is a headless CMS. You know, some almost like those concentric circles, some cross over. And there's probably points where they all cross over with each other at some elemental level. But let's really break it down. Why don't we go to our friend Kam first? Why don't we talk jamstack?
That's a dream. You know, finally funny this a more ActionScript again, right? That's great. But yeah, yeah, it really, really does remind me of that to a certain extent, right? Where you'd use something like Dreamweaver and then you'd be able to. I mean, it sounds like you used Dreamweaver a bit back in the day as well, but you're able to kind of create a page. You'd have a header element and a feature element and then you fill in the content and then you'd hit generate and it spit out a bunch of HTML files, right, that you'd then go and FTP up onto some server somewhere. It almost feels like this. We're what we are doing with Jamstack with static generators and things like that, which we can discuss at some point in the future. Absolutely. So since this is a bit of a primer, why don't we go to the next one? So let's talk composable DXP coming from where we just did with Jamstack. From my brain, I'd like to know where to. How did the two intersect with each other? How are they different? How is one more than the other?
Yeah. So I think the composable DXP fits nicely into the Jamstack world, but it's not necessarily in like super connected or super glued together, right? So I can just use the Jamstack architecture. It's an approach. It's an architecture. It's not something you buy us or something you kind of get off the shelf, right? Similar products or anything. But it's an architecture. It's an approach. It's a philosophy almost with the composable DXP. What that is. So it's kind of important if we take a step back and look at what we are coming from, which is which is the traditional monolith. Now those digital experience platforms, so we've been used to using our a kind of all in one system, you know, you buy one system, everything fits tightly together. It's tightly coupled the content. You put the content in this in the CMS. The CMS is then used to compose the pages, and there's also used to run the code to build the pages, the way they look, the way they interact. And then, you know, then it may also come together with other components such as analytics, emails, forms that you can collect data with. And it might have a commerce system that plugs right into it. And, you know, because it's so tightly coupled you that you can use those that flow that connectivity to use up for personalization and optimization of your website. It's tightly coupled. So in theory, they all just play nicely together and everything just is there, right? The downside of this, of course, is everything is tightly coupled and everybody is not necessarily. People may already be using tools in their business. And this is where the composable DXP comes in.
Yeah. One of the things to remember with the with the monolith, though, is that from a business and technology perspective, the monolith dictates what you can and can't use. So for instance, if the monolith is built in dot net, you're kind of forced to use majority in order to customize it. In order to use it for the way you want, you have to build it in dot net unless you like extracted. That's another story, but it almost forces you to do things a certain way. And if you want to utilize the full power of some of these systems are extremely powerful. But if you want to use the full power of it, you almost have to duplicate your efforts in order to store the media in the monolith, do stuff in the monolith and to Kamruz's this point. If you're already using Google Analytics, you're going to have to do Google Analytics and something inside of the monolith if you're already using Marketo, for instance, for your email and marketing campaigns. But you want some features of the monolith, you're duplicating your efforts in terms of resources, as well as from a development perspective.
Just the over the overhead that comes with that when you buy a system with all of these tools built in, even if you're not using it, there is an element of overhead involved in those systems, right? Well, and I kind of so I've been I always like to try to analogize things in my own brain, and I've almost been looking at like my iPhone, for instance, right? And the traditional monolith almost feels to me as if it's what when you get your iPhone for the first time where you get your Android phone and they have those built in apps on them already. But it seems like in that case, you can't go to the App Store and get others to live on that device and get the best mail client, the best calendar client, the best note, you know, the best browser. It would almost be as if you were locked into what Apple has the applications to do, which are decent. And I think it's another point to make with this best of breed doesn't allow you just to get the best of all the things, but it kind of acknowledges that one monolithic company is going to have a hard time making the best application for each of the needs of the system.
Well, that's actually absolutely true. Not that the monolith restricts you from doing other apps, it's just not as convenient to do other integrations so you could use Marketo, but at the cost of X like you have to put in custom development, you have to do process as well as development duplication in order to achieve that. Cool. Yeah, no, I think it's, you know, you just always want to find those connectors and it's there are so many great products available and you just don't want to be limited. I mean, even if we're talking in cell phones or mobile devices, you can still get the same app on Android or iOS. So that's kind of an important piece. So when we're looking at the looking deeper at the composable DHCP cam, you brought up that it doesn't have to be Jamstack, right? So there's other ways that there's other ways they can go about building a composable DXP is that almost what sitecore, for instance, is trying to do right now?
So Saikawa is taking a Jamstack approach to things. So Jamstack is a philosophy for building your website and then bringing together a bunch of different services in the way that they fit. The Jamstack philosophy is what I would do is upfront. I would take whatever I need and build as much of my website out as possible to generate static HTML files because those are very, very simple to celebrate, right? Because it's just static, there's no processing involved. I can just send those to you. It's just very, very cheap infrastructure. There's no overheads required. It's very secure by its very nature of being just HTML. The composable part of this is I need to build a DXP, a digital experience platform. Now most of these services do live alone, right? So the content management system is just a content management system. It's the best of breed. It does one thing, it does one thing extremely well. I have another system which does forms and email marketing, for example, right? And then I might have another service, which I use, which does my search and I build that out or however I want. And then I have a couple of other systems. Now you're thinking, Oh my God, there's a lot of systems here. And but that's where that composable bit comes in. You need to bring each of these pieces and almost like, almost like the conductor in an orchestra, you need to compose and bring these things together to build in order to build out the symphony, right? So that's so it's just a way of describing, OK, I've got I've got a bunch of different service systems and I need them to kind of work together in a nice way.
So when I look at this in the composable DXP and I focus in my mind on the word platform, if I'm managing, if I'm a content manager, a web manager for these systems, do I? I do have the best of breed. They're talking to each other in their, in their, you know, website, web universe. They're. Do I go to each of these services to manage them to or do? Is there almost like a central place where, you know, a Web manager goes to get to these places easily? So you mean from a from a sorry actually go ahead? Yeah. So from a you can look at everything from multiple angles, right? So from a perspective of can one person or one console let you do all of these? That's more of a monolith kind of view of looking at it. There's nothing wrong with that, if that's how you ORG works, but typically organizations have a team marketing team and a specific group of people who do analytics. They love doing it in Google Analytics, so they're comfortable going into Google Analytics to do their thing. Other guys who are lead nurturing getting more leads might want to work in market or other systems, right? So they work in those they know exactly how to do it. So this almost from my perspective, when I look at it to answer your question, it lets people do what they do best in their systems by themselves. It's not looking for an overall one dashboard to do everything. It's since you're saying best of breed. So if Marketo is the best breed for your org, you have guys who are good at that. They do stuff in that, so you're not really looking for a central place for it. It's also reusing what you already have. Like most of the time, I have my own SAP CRM sitting around or Salesforce, for that matter, you're not going to cross train everyone on Salesforce functionality. You just have a group of people who take care of that.
That is a very good point, actually, because I think back to where we were maybe 10, 15 years ago, where there was a small web team and they had to run anything that was web, right? And it's a good point that Jamstack is a, you know, an architecture on the web. But in many ways, business units have decoupled that way as well. And then they come together, you know, to report, to work in their own. I don't want to call silos, right? But that's a very good point. So it doesn't matter having a single place where you could get to all of this because there's very few individuals who are going to need to be tasked with doing that.
And there's two parts to this as well. There may be the customer who's actually on the monolith systems or traditional systems, and you know, they're happy with their system. They're using all parts of that system. They're fully embedded in those systems. But the other side of that where we have customers who are. The half embedded or not, not in those systems at all, right, they have different multiple different systems already in place and there you're having to build connectors into this third system to try and pull this data in and put this data together. So you already have parts of the composable DXP already in play, but then you're still trying to fit it into this traditional monolith because that's what I was expecting. So there are customers who are like, well, actually that the switch to Monolith is just using systems that we're already using anyway. Yeah, it's almost like you buy, you buy the thing for the whole package, and then all of a sudden you're having to break apart pieces of it anyway, paying for the whole package price and then,
Yeah, that's anyway. That's the other part, right? Like if I'm starting out on this journey and I need something to build my website, I need a content management system. I'm not ready for all the analytics and the personalization, and maybe even not even the email right now, but in six months time, maybe I want to add or two or a year's time or two years time, maybe I want to start to now add in the form's capability and the email's capability. And then a while later, I want to add in the commerce systems. It's a journey. You don't do everything in one go necessarily, and you're almost, you know, you're learning to walk. You're learning to crawl. You learning to walk before you can actually run. So you add the systems in as you need them without overburdening your teams, your tech teams, because they still have to build stuff, right? We've overburdened the business to learn systems that they don't necessarily need right now.
D, do you guys find and maybe I'll pass on this one? Do you find when I look at all of these little are these octagon snow? Yeah, when I look at each of them, I say to myself, Wow, this is actually opening up more innovation. It's creating more companies, right? Because you think of search and how many companies just do internal search, which I didn't even know existed before coming here. We know CMS is right. Analytics is Google Analytics, but there's always, you know, providers coming out with that commerce. Do you see this because there's the best of breed competition? Do you see more business being created because of this composable framework and the Jamstack approach? I maybe I'm not sure if it's if it's if there's more businesses coming out with this approach or if it's just we're seeing more of a prominence of those of those businesses now. There's a lot of these businesses would have been fringe businesses before because, hey, I can't customize that CMS to do x y z. And the only thing I can do with it is just to build this very static website. And now all of a sudden, this architecture is unlocked the potential of those systems.
So why don't we go into our last piece, which is one of these here, right? So now? I hope I'm right, because it's starting to make sense to me. I saw CMS as one of those octagon. And now we're going to look at headless CMS. So is this literally that piece of that octagon? Here, and this is the service of the of that CMS is the headless version of it. Why don't you go ahead, actually?
Yeah, so yes, you're right. CMS is a critical piece for all orgs, especially trying to push data to private intranet extranet and the internet, right? That tricky part to the CMS we've already covered, which was awesome in the composable DXP from a monolith perspective. It controls a lot of things, a monolithic CMS controls the content, which it should. That's the job, but it also includes things like, Oh, you want to add images to these pages? So I want to store that. Do you want to develop on top of me to show things or you have to do it in this certain way? So in a way, monolith systems kind of control that aspect of it. So when you're looking for just something as simple as a web page with images, right? The images are not truly as optimal as you want them to be. So nowadays, the latest or the best way to do it is have them on a continent, on a digital asset management so DAM system, which is not just capable of storing any kind of assets your company needs in terms of product specification, technical specification blueprints, but product, high risk product images, you name it, you can store it in a digital asset management.
But the beauty of digital asset management is you can pull a specific asset exactly to the media you're consuming it on the device. So when you're pulling it from mobile, it's able to pull it exactly what it needs. It's not going to pull a full 4K resolution video down. It's going to tamp it down based on the size of your device, the bandwidth of your device. Same with images, and that's something which a traditional monolith is not able to provide for you. So CMS plays a humongous part. Now, when we talk about headless, the interesting part about a headless CMS is that it's truly a one piece of a ginormous puzzle. It's no longer controlling. You only can do it in a certain way. You want to use react. You can use React. So coming back to our JAM Right, headless CMS. Its responsibility is to hold content. It's going to hold your content for whichever channel you want to push it and you want to hold content for a mobile app you want to hold content for you, said IoT the other day, a little while ago, you want to hold content for a kiosk or like a POS system, you can do that.
But it does really good at storing that information and does really good at giving your authors, the marketers, the machine. You have to produce content, all the workflows in place and the governance to produce the content. That's what its job is. The way it gives the content out is by APIs. That's when we came back to the a of the jam, right? So it says, I have all of this. I'm going to guide all of your authors into using workflows, sending it to legal, sending it to marketers. The content is now approved. It's ready to go to the mobile app, to social, to the email, to whatever you want. Now it's your job to pull it out and to pull it out. It's no longer restricting you. You want to use react. You can use that you want to use next. You can use it, you want to use Gatsby. you can use it to pull that information out to showcase it, whichever way you need in a mobile app, on your Twitter feed, on your email campaign management. So its role has stayed the same, except with less restrictions. That's the way I look at like a headless CMS.
There's a little bit to me of a buzzword to headless, right? And I almost have been thinking about the minute I saw Froot Loops and Froot Loops was like, Yeah, we're gluten free. I'm like, Come on now. Yeah, it's got a little bit of that gluten free feel to it. How? How can a customer be sure that they're getting the headless CMS? Is there a threshold? Is there a stamp of approval? Because I'm seeing, you know, I'm seeing WordPress, for instance. Hey, we're headless and it's like, maybe they are, but. Where's the threshold of the value there?
Yeah, there's a lot of a lot of the traditional vendors are adding modules if you like to make their content headless all of a sudden. So it's a cycle that this was their Genesis implementation. Whether that's truly headless or not, I think, is it's down to interpretation and a lot of it does come down to interpretation. For the most part, I think most headless CMS you consider as they just store content. It's retrieved via an API, and they usually SaaS or cloud based implementations, that's each to their own definition, I'm sure. Gartner has their own definitions of these as well, and Forester's and each vendor will claim to be headless. But most would be, you know, a cloud based SaaS based implementation where data is retrieved by an API. And it's usually, as I say, usually because this seems to be changing a fair amount now is literally just to do with content and not to do with layouts and how pages and things are composed.
So bringing it full circle to kind of close it out before I have one more example analogy for you guys. Headless CMS is a crucial part of a Jamstack play in the composable world. In the composable world, I'd say yes. Is it a crucial part of Jamstack? Not necessarily, no. You can. So the funny thing with Jamstack again, like there's different ways of doing the Jamstack, right? The idea is, you know, you, you run this code, you regenerate the pages and then put it on the web. It's been running for a while. This this this concept of pre generation is not new. It was. It was done in with things like a jackal Hugo. There's a couple of others that I can't remember right now, but they were. They were these three generators, right? We started off with and things like Jekyll would run off markdown. So it would be to be these files, which were formatted in a specific way. And then the code knew how to read those files and generate the end web page. So what was happened with this evolution is they've taken down, taken out this kind of this static file that you would have to write and convert it into some sort of repository, which was. Very, very developer centric, right? Not a user or a marketer centric at all. So what they've done is replace that. Hey, you need to write this file in in this very specific way and check it into this repository and then it will go and do something into a Hey, why don't we just have a system that you can just go in and input that data? And then the same kind of thing happens in the background. But instead of reading a file and now calling this this this service for the data instead.
So my final analogy again, I was trying to think through this. We all, I don't know in Canada, do you have the triple play with television and the television, internet and phone? Yeah, they all get packaged together, right? And it's a really big high price. And then all of a sudden, Akshay was one of the original cord cutters. I remember all of a sudden were starting to decouple the cable and we have the internet, and we had a not an amazing experience early on with those. Roku's right, you didn't have great. But then competition comes in companies like Google and, you know, Amazon and Netflix, and they're kind of coming over the top, giving you a great experience on the on the internet that the, you know, traditional was providing you. We pulled the phone out because we have the cell phones, then we can go voice over IP on it. Now we're at the point where the traditional are trying to come back in and tell, you know, they have a service and you can stream it through, you know, their piece, but they're going to have to have a specific transponder for your television to be able to get it. What do you think?
That's a great analogy. I must say that is a great analogy, and it's absolutely true. And it works because also those services are done well now because technology has evolved. In the early days that the internet bandwidth just wasn't enough to get a good enough or a stable enough reception or a picture. Now internet is. It was almost 100 percent reliable and say 100 percent, it's like ninety nine point. However, however many nines and it's just a service as reliable as telephone was back in the day, but it's enabled those companies to offer what they do.
And, you know, funny the final thing how you were saying Jamstack has really been around the whole time. It's interesting to see that the new cord cutting cable alternatives are just re bundling again anyway. They're just trying to bring it at a lower price and make it more available in a wider swath of people. Yeah. All right. Well, guys, this was great. A little bit of a longform chat more than our five minute ones. But I think we got a lot of good stuff out here between headless CMS, composable DXP and Jamstack. I think I understand a little more. Awesome. Glad I was helpful.
If you have any questions, please get in touch with me. @akshaysura13 on Twitter or on Slack.
Yay to Konabosing in style! Content tagged with the Konabos handle is produced by two or more Konabos team members.