What is: Jamstack, ComposableDXP, and Headless CMS?

Transcript

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?

Yeah, sure. Yeah. Hey, Matt. Yeah. So let's jump across the Jamstack. So the Jamstack kind of with the hot topic at the moment, right? Everybody is talking about jam stack and. It's a bit of a weird one, because once it's explained to you, it's like, Oh, well, isn't that what we've always been doing? And it'll become a bit more apparent to the end at the end of this, but I think that's probably where me and actually it started as well when we started looking at this and we're like, Well, it's kind of like. What we done like a long time ago, right? So the Jamstack is say it's not a new concept, I think it's been, it's finally being given a name. It is probably where it's probably why it's become much more prominent. And the name of Jamstack is to do with the pieces of the stack, the technology that fit together. So to make this happen. So it's the J is JavaScript. The A is APIs and the aim is markup and a bit of technical terms. I know not everybody will necessarily understand what those are. Some of those might make a bit of sense, but the J JavaScript, it's what runs in our browser. It's the technology from like twenty five, thirty years ago, whatever it is now, it's you know, we all three of us have been in the web for long enough and we've used JavaScript since the beginning of time for us. And at that point, it was just to do some very basic things in the browser, right? It was to provide some interactivity in the browser. So it might have been some validation or just to show and hide some things in the browser. Maybe do some form submissions. So know we're all used to JavaScript in the browser. It's just it's a coded language that runs. On the client side of the browser itself. The A do you want to say something that

I was going to say because the be a good one to come in to after this, when I see JavaScript and markup from my time working in this industry, I think front end. Is that correct? And probably you'll tell me API is front end as well, but I always thought of that as feeding into a back end. Are those how does that? Yes. Let's come into let's jump to them to the end then, and we'll come back to the to the in a second M. Again, it's mark up and you're right that both of these are frontend, right? So both of these tie the front end together, and the M in this markup is just HTML and HTML is the basic, the bare basic browser language. It's what it's the code which you write to display something on a on a web page, right? So you know that that image that you see on a web page is done using HTML. That bit of text is HTML. The heading is HTML, and it's just bits of code which you use to compose up a web page, right? Now, the J and the M, these are both like front end technologies, you can you can give that. To a front end developer, they would knock something up and, hey, you know, I open it and it loads in the browser. And so when we move into the well, actually before we go to the API, I was interested in something you brought up that Akshay, you and Akshay. When you got interested in this, specifically the Jamstack, what was it about the maybe actually I can answer this. What was it about the kind of marketplace at the time when you had been working on systems, really devoting yourself to certain systems like Sitecore You know, there's others that we have in the past, but what was it that you were seeing about this technology that made sense at that time that made enough sense to actually focus and pivot towards?

Yeah, so cameras and I come from a very .NET background and not to say that the markup and the API is JavaScript were not in that world, they were in that world as well. But you predominantly leaned on dot net, ASP, dot net or C sharp to do majority of the heavy lifting. And when we were in that world and I used to constantly see Jamstack or things related to jam stack, I'm like, Oh, that doesn't. They keep referring to one page apps to that was confusing to me when I first heard it, even though I've been in the industry for long enough. But what started making sense is for them to be able to be reused, things which are lighter or easier to use. That's a sense I got when we were first hearing about Jamstack is, oh, it seems like it's easy to integrate. It seems like it's lighter or the hosting doesn't seem to be so expensive or the deployments don't seem to be that bad. And coming from our world, it was a little bit you spend quite a bit of time on deployments, you spend quite a bit of time on making sure everything works right and it's pretty heavy. It's the easiest way I can put it. That was a heavy workload. This seems to be a lighter world. It seemed to be a lighter world, and that's what got us into looking into Jamstack. And you know, it's funny because I think our next point was going to be composable DXP. And am I right in that if we take the API the apart here, that it might make some sense in discussing the composable DXP part?

Yeah, yeah, absolutely. So A of Jamstack is API and API is just a bunch of services and that can be anything, just a bunch of services that you either retrieve data from or you send data to and from. And I'll say why, why this comes back to like almost full circle of the Jamstack. When we first started, I'm sure with your creation basic little websites and use some JavaScript and then what you do is you call some little weather service to pick up what the weather was in a in someone's local hometown, and you could then display that on a on a website, right? Just to say, Oh, it's sunny where you are or it's going to be raining tomorrow, right? I'm sure you've done that like the most basic of kind of services that you could call from your web page and kind of almost embed a little widget in, right? So that's what the API is. It's just some service somewhere that you can call and you can ask it for something or you can tell it to do something, or you can put some data there. And that's where the JavaScript comes in in this, right? So you have some HTML really basic markup language, you have some JavaScript and that ties both of these things together, the JavaScript to call the APIs to either retrieve or put some data in, which then gives you this kind of dynamic element to a page. And it's not just something extremely, extremely static. So when I mentioned earlier that we've probably been doing this for a long time, I'm not joking, right? Like the weather service was like something we were doing like 20 years ago as a little script kiddies, right? That's exactly what it was. It was Jamstack. But now, you know, we were using FTP to put some files up onto some server somewhere with a including the JavaScript, and that would go and call some sort of service. That was Jamstack. But now we have a name to give that kind of that way of working almost.

Yeah, I mean, it's evolved a lot from there, right? So like JavaScript isn't the Java. It went into jQuery. And now the other point which I wanted to make is one is the evolution of what you could do with JavaScript has changed quite a bit than what it was even 20 years ago, but the concept is exactly the same. The other thing to mention, because we're doing this series as part of making things simpler and making people understand it right? JavaScript is no longer just a frontend language anymore. You'll be able to use the JavaScript on the back end of it to do things as well.

So you're on the server side, right on the Server side as well. So you're no longer limited to, oh, it only runs on your client or on your browser. It's also running on the back end to do things. That's where this makes. It's like the Holy Trinity right here, right? All these things, three things together make a humongous impact. Yeah, I think the evolution of JavaScript has really enabled this to happen. JavaScript, like I say, it was just used for very basic things in the browser. The frameworks such as React, Angular, Vue, Nuxt, all of those things have dramatically improved the way we work with JavaScript, both in the browser. And also now, as Akshay mentioned, it is can be used on the back end and the server side. I think it's important to distinguish that the Jay and Jim Stack is to do with the client side JavaScript and not server based so I can still do Jamstack and they can still use. Dot net or dot net core PHP. Java, whatever I like in the back end to do my services and compose my. And to build my pages and as part of this Jamstack, right? All this going back in time, I'm thinking of Macromedia, Dreamweaver And Yeah, and next, you're going to tell me that. Are we going to be rereleasing Flash?

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.