On this special episode of the CMO Series Podcast, we hear from Mikkel Keller Stubkjær, Head of Development at Novicell UK, who joined our recent CMO Series Webinar to uncover the world of composable architecture and the benefits to professional service firms.

Mikkel shares fascinating insights on:  

• The differences between composable architecture and the traditional monolithic approach
• How composable architecture can transform your website development and operations and make you stand out in the crowd.
• How harnessing composable architecture can help achieve marketing objectives and enhance the client experience.
   

Transcription: 

Charlie: Welcome to our first session. I'm Charlotte Knight. I'm the Marketing Communications Manager here at Passle. This is our first CMO Series Webinar. So it's a pleasure to have you all on. And today we have the pleasure of speaking to Mikkel Keller Stubjkaer who joins us from Novicell UK today. So I guess before we kind of dive into what we're gonna be talking about today on the series, we aim to kind of address some of the hottest topics in professional services marketing today,  looking at some of the latest trends, the insights, and developments in the space, both to help you succeed as professionals, but also to take the industry forward. So the series comes off the back of the CMO series podcast, which you may be familiar with. We've now published 100 and 16 episodes of that series plus specials. 

So, I'd like to welcome Mikkel today.  Mikkel joins us from Novicell UK. He is Head of Development there and is an expert in composable architecture, which is today's theme - Composable Architecture and why it can benefit your firm. So, Mikkel has lots of experience in doing this for professional services firms and he actually joined us at our CMO series live conference in the summer. And he took to the stage to discuss the benefits of the composable approach to website builds. So he's gonna join us today to kind of delve a bit deeper into the subject and for those who obviously didn't make that session, hopefully, it will be kind of, you know, interesting and insightful to you as well. I think, you know, the feedback we had from that day was that this felt like quite a new concept to lots of people. So we're hoping that we can kind of help kind of spread the word and inform more people about how it could be game-changing for firms like yours. So the session today will cover composable architecture and the differences between that and the kind of traditional monolithic approach to website builds. We'll look at how it can transform your uh website development and operations and give your firm a competitive edge in the market. And we'll also look at how marketers can harness composable uh to align it with their marketing objectives and also exceed their client expectations as well. So the session will last around an hour and as mentioned, include plenty of time for Q and A. So please feel free throughout to drop us some questions in and Mikkel will happily answer those.

Mikkel: Thank you for having me and thank you everyone for joining. I always welcome the opportunity to talk about this topic. It's a topic that I'm very passionate about and I've been spending quite a few years with this technology. So let me share my presentation.

Here we go. So today's topic is user-centric composable architecture and how it can benefit your business. This topic has two sides to it. There's the user-centric part, which most people understand, and then there's the composable architecture, which is new to a lot of people. And today I will speak about both and then try to bridge them together to see how the composable architecture actually can be an enabler for a user-centric approach. So for the agenda of this webinar today, I'll just give a short introduction to Novicell. I am the Technical Director of Novicell. Of course, it makes sense to just explain briefly what it is that we do. And then I'll go into user-centric composable architecture. On the back of that, when we understand the principles, I will speak a little bit about composable enablers, which are basically things that are required in order to go composable. And then that translates into the user-centric nature of all of this with seamless user journeys. I'll also look at what the investment profile of a composable project looks like. And I'll speak about the benefits and then finally, some key takeaways and questions.

So let me proceed. First of all, my name is Mikkel. I'm from Denmark. I moved to the UK some 3.5 years ago now with my family just before COVID. Interesting times. I am the technical director of Novicell UK and before that, I worked with Novicell in Denmark as well. I've been in the internet industry for more than 25 years. And that means that I've seen everything from when it was very, very simple and easy to today where we have this complex landscape of a lot of different responsibilities and capabilities with our web platforms. And then of course, being present from the early days of the internet, I have a lot of all things digital and briefly about Novicell. We are a full-service digital consultancy and we like to say we combine strategic creative and technical skills to help companies optimize their business online. So business online is important here. That is what we do. And to dive a little bit further into that in a second. First, I'll just mention that we have a presence throughout Europe, originating from Denmark, but also offices in Spain and Norway Sweden, UK and the Netherlands as well. So, we pride ourselves on being a full-service agency and that means that we deliver entrance solutions. We don't necessarily do all of these things for all our customers. We like to say we have a mix-and-match approach. So whatever makes sense in a given context of a client. We help our clients with digital strategies, we help them with user-focused design. So that's user journeys and personas and audiences and measuring or looking at what success looks like. We do architecture and technology advisory. That's among other things. My role, then of course, is the development of website platforms. We also have a data value team that will review those KPIs that were decided in the digital strategy phase of the project and make sure that we measure and continuously review the numbers as the website makes its way into real life and production. We do ecommerce and we help our clients host the platforms that we build. And then finally, but most importantly, we have a digital performance team that enable our clients to get better performance. And here we're not talking about response time or how quick your website is here. We're talking about the business performance, meaning will help you optimize search engine optimization, paid media, but also content or video strategies depending on what can help you drive more traffic to your website. We have a number of clients in the professional services and legal services. These are some of them. Also, we like to think that we are thought leaders within this field. So we also do seminars on a regular basis. We have industry insights as white papers, et cetera. And then we do this thing called Suite Talks, which are exclusive dinners for CMOs where we discuss different aspects of websites and how to go about your digital business. Enough of the sales pitch about Novicell and me, so let's go on to the topic of user-centric composable architecture. 

So most people engaging in a big website project have the expectation that everything will go fairly straightforward - A to B. Those who have tried this know that that's not actually the case. And by making that an upfront observation, then we can take mitigating actions against the risk that we know will be there. So, the reality is filled with legacy systems, technical debt, and broken dreams, especially if you have a fairly advanced setup with multiple different content sources or systems that need to be integrated and speak together. This is the premise of any project. I've done this for 25 years and I haven't seen a single project that went straight from A to B anywhere anytime. And I like to think it's not because I don't know what I'm doing, but this is just the premises of a project because it's so complex nowadays and there are so many moving parts. So building a new website from the ground up is a complex and challenging task and it requires careful planning and execution, especially when it revolves around platform selection or services or whatever systems you need to utilize. We often see companies select platforms based on personal preference or existing legacy systems or for other historical reasons. But when a business requirement is unsupported by that platform, it can quickly become complicated and expensive. And the decisions are too important to be taken lightly. Making the right decisions early on can help you avoid getting locked into your choices for many years to come.

And this is probably the most important sentence of this entire webinar.

How do you avoid getting locked into those early choices and end up in a situation where you have to rebuild from scratch every time a bigger change happens in your business.

So, the most important thing initially is to go about your platform selection in a strategic manner and basically high level. There are three different ways you can build your platform.

You can either go and choose a boxed suite, which is what we call a monolith. So that's a single platform or system that can do everything you need or you can go with the composable strategy where you can mix and match best-of-breed, you can find different systems for different responsibilities and and compose them together into a single platform.

And then finally, there's a custom where you get whatever you need. So box suite, best-of-breed, or whatever you need. I kind of like that. OK. So for the Boxed solution or the suite, it's typically one platform vendor, it's difficult to customize and few options from different vendors. This is for simple use cases. It has a low effort to build and a high effort to customize. And that's kind of the main point in this entire webinar as well. Then we have composable. So that's mix-and-match best-of-breed pieces that have been professionally built by a number of vendors. And you can buy some, you can build some, you can use existing legacy systems, et cetera, and compose them together into a single unified user experience.

It has a medium effort to build but a low effort to customize on the other hand again, because things are not in one big system but distinct small smaller responsibilities. I will go more into detail on this. And finally, you can build by hand from scratch, with a full ability to customize every small detail to your business requirements. Of course, this is for very complex cases; high effort to build, high effort to customize. So the strategic platform selection process, first of all, is about evaluating whether there's a single platform out there that fits your needs and your business requirements. If that's the case, then that's by far the most cost-effective way of going about doing your work platform. However, that's rarely the case. Oftentimes there are a few integrations or few different subsystems that needs to be included into the website. The important decision is here that if you choose the boxed solution, then you stick with the functionality that is available as soon as you start customizing or changing the functionality that are in the box and then the challenges and the troubles start to appear. So when there's no box solution that actually fits the business requirements, then the next thing to do is to compose best-of-breeds, SaaS services platforms or legacy systems into this unified platform. And then finally, if that's not applicable,

then we can build custom and it goes without saying that risk and complexity goes up and the time spent on the budget will also go up as we proceed through this ladder. So that's the strategic platform choices that you have to make. Then comes the customer-centric part. So you want to stay relevant and there's two sides to the benefits of the composable architecture. One is the strategic choices and how you can avoid getting locked into your choices in the future. But also, now you have a more complicated setup. So how do we actually enable that customer-centric approach?

So when businesses fail to meet the expectations of the customers, the competitors are just one click away. So I like to say this because people tend to forget that as a private person, you know, exactly when you're browsing the internet if a website fails to deliver what you expect, there's always another website just around the corner and in this digital age, you're no longer unique. There's always another option with better usability, better performance, or a better user experience. So you basically need to work hard to stay relevant. So I like to bring up Charles Darwin here because that's of the essence of most composable architecture. And what he said is still true. It is not the strongest of the species that survive, nor the most intelligent, but the ones that are most responsive to change. So this responsiveness to change is a key factor in composable architecture. So the first observation here is that you need to stay relevant by being responsive to change. So that basically means changes in your business, changes in your organization, changes in the way you conduct business or how you engage with your audience. 

So on to the more technical part of this presentation. In order to understand the future, the composable architecture, it's important to understand the past. For this segment of my webinar, I usually like to bring in Lego Bricks. Being from Denmark, I happened to grow up in Billund, which was where the Lego brick was invented. So this is a toy that is very close to my heart, but it also is a very good way of describing what we're actually talking about here. So imagine this is your monolith with different responsibilities. You might have CMS functionality, and personalization functionality in here.  Talent acquisition platform integrated into this search, email, marketing or marketing automation, et cetera. And then you have your front end, which looks very pretty and neat. It is a boxed solution with the functionality out of the box without any modifications. So this just does exactly what's advertised and if that fits your business, great, that's by far the simplest approach. But what we see typically is that that monolith gets customized, modified, and changed with new functionality and new capabilities. So now we have different colored bricks here and those colors represent changes or customizations that have been done to the monolith. And over time, these tend to increase. So you might start by changing just one bit or adding another bit,  trying to substitute how the platform does a specific thing. For instance, you might actually end up starting to build on the side and trying to add something that didn't fit in the first place. So, now you have a modified monolith and that's basically the worst possible position you can be in. And again, here, I'm talking about the strategic nature of having a platform. This means that when this monolithic platform, is time to upgrade it or when it's end of life, then you basically have to throw it all away because you've modified it so much that there's no direct upgrade path or the upgrade path is very costly. And that leaves you with few options on how to proceed and it will be expensive. And so imagine instead of having this monolith with all of these different pieces, what if the monolith was not a monolith? What if this was a composable architecture where each of these different responsibilities was an individual system that was then composed together through a unified experience. So having a dedicated system for your talent acquisition platform, having a dedicated system for content, having a dedicated system for insights, maybe having a service for search and personalization and so on and then combine it all in a seamless integrated front end. This is the general idea that we break up the monolith into the individual responsibilities. And then we compose these responsibilities together by utilizing different services. So that's the second observation from today, there's no single system that does everything well. And this is a known fact, there's never a silver bullet of course. So tackling all of this complexity can be challenging to maintain debug and scale. But simplicity promotes efficiency and agility and ease of use. So how do we tackle this complexity? The solution is to divide and conquer and break down the complex problem or task into smaller more manageable parts. And here we like to speak about the concept of a digital business capability that clearly defines the skills, resources and digital assets required to effectively execute a core business function in an online environment. So this is a means of looking at the different responsibilities and breaking them down to individual paths. And then a packaged, digital business capability is a single core business function that can be effectively managed, supported, developed, deployed and stays in isolation. So this is the legal brick we discussed just before. It has a clear interface to the outside world, you can put bricks on top, you can put bricks on the bottom, but you cannot do anything on the side. This has a clear responsibility and a clear boundary and it does exactly what is required.

So the composable architecture is about breaking down your entire website platform into distinct components aligned with the packets and business capabilities. Again, this could be your search personalization, marketing automation, your people, bio information from your CRM system et cetera. Each of these are regarded as separate responsibilities. And then the composable architecture fosters the ability to change any one of these components at will.

So whenever a package business capability needs replacement, it can be done without affecting the integrity of other systems or processes, or data. So, by choosing a composable architecture, you avoid getting locked into your choices for many years to come, because when something is end of life or needs to be substituted, you don't have to throw away the entire monolith, you actually only have to throw away that one break which again, brief longevity and return on investment on your entire web platform.  OK. So moving on to third observation here is the composable architecture allows effectiveness through evolution, flexibility and longevity for maximizing that return on investment, I will come back to the investment profile of a composable platform again. OK. So now I promote best-of-breed and selecting the services - the best of services that you can find out there. But this requires a strong focus. The ultimate platform of service, of course, varies for each organization as there are no silver bullets. A great example from my everyday life here is that I used to do this presentation with small Lego bricks for big crowds, which is not optimal because of the size. Of course. So I requested someone from an organized from my organization to get me Duplo bricks, which are these bigger breaks.

But what actually happened was that the person in charge of that didn't know the best-of-breed. So I got this copy product from China which says it's compatible. It is compatible with most other brands. But this is a good example of best-of-breed yet again, because it's probably not what everyone thinks is the best uh toy out there or replacement. But for this specific purpose that I have to explain a concept for you. This is the perfect brick. So that kind of showcase that best-of-breed is not the same for every use case. The best fit depends on your requirements and your organization's skills and bandwidth. So you do need to consider best of need. What do you actually need? Best of capability. And what are you capable of driving in the organization? Is it a tool that requires you to have 10 dedicated people to drive the service or is it an automated thing that just does its job by itself. So, before deciding on best-of-breed,  these are things that you need to also consider. So for someone, it might be system A, for someone else, it might be system B OK. So that's composable architecture. So now talking about composable, then of course, you need to think about how to stitch all of these different services together. And one of the core concepts of that is Headless.

So let me move on into an underlying principle within composable architecture, which is basically this acronym called MACH. And the first letter is M for microservice. Again, instead of having a monolith as a one single system, we break down the system into microservices, those services that we employ needs to be API enabled. API means application programming interface is basically a way for two systems to speak together in a loosely coupled manner. So an interface between two systems without human interference, we like systems that API first, meaning that the the vendor that built the service or platform made sure that all functionality not only public facing or extracting content, but also management can be done by an API. Because that means that we can utilize functionality about creating different assets of dramatically. For instance, a campaign can be added by a system rather than a person utilizing a graphical user interface to take a word from the days of old. C is for cloud native, which means that this is typically something that is hosted in a serverless cloud fashion. If we talk about SaaS services, that's of course the responsibility of the vendor. But typically, this is something that also scales depending on the requirements and how much compute is needed. And then finally, we have headless, which is basically uh a concept of subdividing one system into two systems. More about that in a second, there's a global alliance of companies and software vendors that adhere to this way of building called the MACH Alliance. We are very proud members of that alliance as one of the few consultancies, most of the members are actually software providers, CMS providers, commerce providers, et cetera. So one very important enabler here is what we call true headless. So how to achieve this composition of platforms and services to enable at the end of the day, because this is what it is important that technology is not at all important, but to enable that seamless and fully integrated user experience. So in order to understand headless, which basically is not the same as composable to answer the question, but it's an enabler, it's something that needs to be present in some way or another in your platform setup. And with true headless, which I will explain in a second, that's kind of where the glue between all the subsystems live. So what does not a system that is not headless look like a system that is not headless is one system that both has the interface for managing the platform. In this example, it's a content management system. So that basically means that you have the editor area is the same box, the same system as the front end. So here you those two things are tied together. The CMS system is built on a technology. And that means that the front end inherits that technology. If you need integrations, those integrations will be heavily built into the CMS system ending up in a situation like this. What you want is headless. So this means that separation of concern, we separate the single system into two separate systems. So now we have a content management system that is only that, it's just content management, but not the website, not presentation of how that content translated into a website. And then we have a dedicated website built on modern internet principles like html, Javascript,  clean, no technical depth, no technical dependencies on your actual platform. This is headless in its true nature. That was a little bit confusing. I used the two words. 

So now on to true headless. So what happens with true headless is that we introduce an intermediate storage between the content management system and potentially other systems between the website front end and introduce yet another microservice in between, which is basically just an API. So this means that now we can accumulate the content from the CMS and potentially other sources into this intermediate storage and then expose all of that content through an API to a loosely coupled website that now only depends on the API. That means we have a contract between the two systems. Again, there's an API and there's a front end and there's a contract. So it becomes easier to maintain your CMS, upgrade your CMS or change your CMS in the future or vice versa. It becomes easier to do a big rebrand or build a new website because the responsibility of the content is now solely with the CMS, not how the branding or website looks. So you can embark on building content strategies on more longevity in your content strategy. So building a sound information architecture that doesn't change as often as the user expectations or the brand. It even means that your content management system and other systems doesn't need to be exposed to the public because now the website only runs on top of the API and the intermediate storage and that basically means that you can secure and lock down your CMS system entirely, which means that it's secure by design. But you can also take it down for maintenance without actually affecting your running website. So true headless is an enabler. I have had a lot of great experience working with a platform called Enterspeed. So this is not supposed to be an advertisement for Enterspeed. I just want to mention what that intermediate storage could look like. So Enterspeed is a secret product out there that few people know about because you can basically compare it to a database except it's built for ingesting data and content. So imagine that you can send in data content from any system into a United content pool. This will never be your master data, but this is all your public information. So you might have your people bios for instance, flow in from one angle. You might have your inside pieces from ple flowing from one angle and your content from your content management system, even your job postings from the talent acquisition platform. And then in Enterspeed, there's the option of what is it's used for is for aggregating that data. So you can grab your navigation from the content management system, put it together with your article from Passle and grab the photo from your CMS system as well. You can even add, relate the people from your bio information or related jobs from your talent acquisition all of that can be aggregated inside Enterspeed. This is a development test. 

So it's not something that is minded for the marketing team. But that's something that will be tailored as part of building a composable architecture. Again, that's where we built the content and models that will be exposed through the API to the CMS system. So it's a headless technology agnostic infrastructure. And for me, this or something similar is the centre piece of a composable architecture again because it can aggregate and transform and test the data from multiple sources, which makes it extremely fast. If you were to do real-time integration of your existing data sources, then of course some of them might be not built for modern internet users, so they might not be fast enough. And then it's the lowest common denominator, you know, that decides the performance of your website by doing this, everything will be ready and aggregated. So what happens here is as soon as a source changes. So let's say you make a change to a Passle article or a biography that is included on multiple pages. The platform will understand that this change has happened and then it will rebuild all dependent models so they are ready.  So as soon as that change happens, the rebuilding of the models will occur. And as soon as the rebuild is done within milliseconds, the new data is actually available at a very fast performance. And it's also more sustainable than what we used to do because data is not persisted on, it persists on change but not on the request. So we don't compile the data together whenever somebody visits the page. It's done when changes occur. True headless. This might be a little bit technical. So I'm conscious if there's any precedent revolving around this part at this point in time.

Charlie: Mikkel we've had another question come in and you may have kind of answered it in the last section, but maybe you could kind of go over this in as simple terms as possible. But how is this approach different from using WordPress and plugins?

Mikkel: Yes. OK. So, using WordPress and plugins makes your content management system the centerpiece. And that means that everything will be tied to WordPress. If you're happy with the functionality and there are not a lot of changes in the future, then that's basically fine. But I know there are a lot of plugins for WordPress, but that's not necessarily a plugin for your specific purpose. And then it becomes a little bit complicated. So again, this is trying to divide and conquer. So looking at different responsibilities, you have each system. Each is not dependent on the other systems. So your insights, activities and your talent acquisition and your content, for instance, those are three different sources and none of them own your website presence. That's all done in this data layer and aggregation. So that means that you can change your WordPress without changing all the other bits. Whereas if you use plugins in WordPress and you integrate everything directly into WordPress, you'll never be able to change WordPress, then you'll have to rebuild the entire thing. And of course, depending on the effort that you put into this and the cost and budget then that return on investment is decreasing rapidly if you have to uh change the entire platform. But I'm conscious of time, so I need to proceed here because I do want to address a few other things. I can always really tell that I won't be making it through everything, unfortunately. But let me quickly proceed here. 

So I just want to show you an example of how all of this fits together. And this is what I promised the most technical slide that I'll present and I'll do it a little bit quickly. So in essence, we subdivide the website platform into three different layers. We have a publishing layer, we have a true headless layer and then we have a presentation layer. So your publishing layer will of course revolve around your content management system. The content management system will ingest all the content. So whenever you publish or save an item, it will be updated inside this true hitless layer. The true headless layer can then actually push that information into a search engine as well, which means that whenever things change, we change the search index. So now search is also updated in this intermediate layer, then what we like to do is to build a static website on top of this content. Because again, as I said before, things only get updated whenever they change. So, that means that if you don't publish a page or an article for a very long time, you don't have to regenerate it on every single visit. As is what's normal practice by doing static site generation, we basically build a single HTML file for that page and then publish that onto the website. And then if there are no changes to that page, that page never changes, then for protection and scalability, we like to put a platform called Cloudflare in front, which basically is a global CDN delivery network.

And then, of course, there are a few dynamic parts to the website. So, for that purpose, we introduce a back end for front end API to which is basically a content delivery API enabling us to do real-time search and to display related content. So, of course, your related articles are not static. So on a bio, you'd want the articles to update whenever there's a new article from that professional. So that cannot be statically generated, we'll bring that in on demand and the same with content So this at this point in time, it's still just a simple content management system with a head responded with an immediate layout. So think about introducing Passle into this mix. So now the Passle inside articles can throw flow into speed and when they hit Enterspeed, we can generate the same pages on the articles. So now enter this seamless unified user journey because the user will not know that this article is coming from Passle or CMS. They don't even know what kind of CMS is behind it. They will have a seamless integrated experience with your main navigation, your photo and other pieces of content around the article seamlessly displayed, which is the main point here, but this also enables Federated search. So now, in Enterspeed, we can push to the search index your articles to as well. So the site search can now search across these multiple sources and that goes for platform or any system that you might want to include into your composable mix. So now, whenever a change occurs here, you can substitute any of these subsystems and flow the data into your true headless layer and then you change the aggregation that happens in the true headless layer. So the contract for the content API is the same, which means that that's where you localize the change to that single component rather than your entire platform. Hope that makes sense. A fair bit technical. Any questions at this point in time?

Charlie: There are no open questions at the moment, but if anyone has any please pop them in the Q and A.

Mikkel: So I was about to go into um search a little bit more. I kind of explained the high level of this. So maybe I'll do this a little bit faster with an example from our own website. So basically an important thing here is that every page can be or every piece of content, whether it's from the CMS system or anywhere else can be represented by a search tile doesn't necessarily have to be graphical as in this case, but there's different ways to showcase a search result. And then taking that to the next level, we'd like to differentiate the different sources. So we actually have the opportunity to create search models that are distinct for each of the source platforms. So in this case, I have three different things. There's an inside piece on an article from our own website. There's an event and there's a profile of our global CTO from Denmark and add a content type indicator to your search result. And this is content from Passle, this is content from an event platform and this is content from a bio from some source. In our case, it's a CMS but again to separate concerns, it would make sense to actually have a distinct platform just for managing your bio information. So again, imagine that when someone searches for something, we can bring in a seamless result across all of those different sources and present in a single search functionality. And for me, as a user, this is a user-centric nature of composability. Now everything has been composed together. So, as a user experience, it's seamless and integrated. I don't see the difference, I just see what's relevant for this search. And then I can’t even tell the difference between the different search results. 

OK. I'm gonna fast forward a bit because I do want to go into another thing which is the investment profile, which is quite important here as well. So is composable architecture for everyone. No, that's the straight answer. Again, there's no silver bullet, there's no single approach. It depends on the complexity of your business model or your it landscape. And it also depends on the scale of your business, of course. So things to consider is of course the total cost of ownership. And again, this is relevant if you know that changes will happen in your organization or in your business or if you want to or if you bring in or integrate multiple systems, then changes are more likely. So the total cost of ownership here will be lower with the composable architecture, but it will have a more initial cost more about that in a second, you also need to consider time to market. Do you really need a complex solution or can you fit into any standard? You also need to think about what is your desired customer experience? If you're perfectly happy with having your insights and your website is two different pieces, then that's definitely also something that can be done. And for some use cases, it's fine. But the more sources you have, the more data you want to bring together and create this faceted search. What you need to know of course, is that the implementation of a composable architecture is initially a little bit more expensive than a monolithic platform because there's more moving parts of a little bit more complexity, everything needs to be tailored together. Whereas the box solution just need a configuration if you stick to the functionality that's in the box. But on the longer run, you'll see that the total cost of ownership for the monolithic platform will go above uh your composable platform. And to put that a little bit into perspective here, the implementation will be more expensive for your uh composable architecture license cost. May or may not be the same depending on the choices if you choose open source components, then of course, it will be less than if you choose a commercial content management system. For instance, your infrastructure cost would typically be less as well because now you don't have to host that entire monolith and scale that entire monolith. But if therefore one of the microservice can be hosted individually and thereby use less computation, you can scale one aspect. You can use a live C as a service, which means that hosting is cheaper and then the real benefit starts to occur. The change cost is significantly less because you have fewer dependencies and fewer things that are tied together. Scalability is one of the hidden benefits because you can scale parts of your application. You don't have to scale the entire thing. And with the separation that I've just showed you where we have a dedicated web website, front end as a static website. The scalability is extreme because it doesn't require any compute, the flexibility is there and the performance is there. So to recap on that, the cost and the time to market of a monolithic platform is shorter than if you want to go headless because you need to build two systems. It's not double the time, of course, but it requires a little more effort. And then if you go composable time to market is a little bit higher again, and the cost is also a little bit higher and then to reiterate on the total cost of ownership in year one, you'd spend more on building your composable MACH based solution. But already from year two and year three, you'll see significant cost reductions in changes and adding new features or new responsibilities. So that's kind of what the investment profile looks like.

And then now I'm almost at the end, the benefits of going in this direction because I already saw what the not the benefit. What's the downside to doing this is the cost and time to market of course, initially, the benefit is on the long run. First of all, you have a platform that is decoupled and flexible, meaning that you can introduce new things into the mix as they occur in the market or as the opportunities arise. This next thing for me is what I usually advise as being the number one benefit is the longevity and independent platform life cycles. It means that you don't have to throw the entire monolith away when big changes occur. So they have individual lifespan. So you can keep your CMS system around for a long time even after end of life because it's tucked away and it's secured by design. So it's never accessible from the outside. No one would even know what content management system drives your website. But most importantly, the return on investment in your platform is not something that live and die together over time. You can slowly exchange or change individual components for other components, meaning it's more agile and it's less costly to do. Then of course, side effects are high performance and global scalability, it's secure by design, and it's also platform agnostic. So again, you can mix and match any technologies, and any platforms together in this approach everything is based on APIs. And at the end of the day, what this is all about is creating that seamless integrated, unified user experience where you bring together content from multiple sources into a single user experience. Those were the words that I prepared for you uh today. So, these are of course the key takeaway of this approach that these are the benefits and cons associated.

Charlie: Thank you, Mikkel. That was very interesting and yeah, hopefully all of you on today's webinar found that insightful, we did have another question come in from Jeff, who said he would like us. It's a request, I guess he would love to see a live example of a true headless and composable architecture site. Could you share one with us?

Mikkel: Yes. So I don't like to put our clients in front of one another. Currently, we are building a very ambitious website for a client, a global client, which is true headless, composable and so forth. And our own website is built based on all of these strategies as well. So novicell.com or co.uk is an example where there's a Federated integrated search, the screenshots that are shared for search during this presentation are from our own website. So I'd like to showcase that instead of actually highlighting any specific clients, also, I need permission to actually do that. But again, this is something that we don't only apply within legal and professional services. This is also something we apply within commerce, and big retail clients in Europe where we've built composable architectures as well. Everything ranging from an online retail company to a paint manufacturer and so forth. So there are plenty of examples, but novicell.com is a good example. But the thing is that you will not recognize that that's the case because it's fast and because you don't see the change in where data come from.

Charlie: Thank you. And we just have another question come in. That says, I'm not sure if I understand this, but is the product Enterspeed or is it Novicell? 

Mikkel: Enterspeed is a SaaS service. So it's not Novicell. That's a SaaS service that we utilize. The search engine that I displayed here is something called Algolia. That's another SaaS service. So, in my opinion, these are best-of-breed currently. If you are embarking on an ambitious website, the rebuild Algolia is a fantastic search engine and serves as a service where you, as an owner can go and edit the search results, you can pin things and do other kinds of things. Enterspeed is exactly the same. It's an external SaaS service. You can compare it to a database or to a cloud hosting provider in the fact that it's not something that you as a website owner, will get your hands on. It's something that powers the website underneath, but it is a SaaS service external to Novicell. Netlify has something similar and also the content management system, Contentful, and another one called Uniform has similar capabilities of aggregating data forms. But the difference here is that the CMS is again the centerpiece of your platform. So this is one of the true platform, agnostic ways of composing data and content together.

Charlie: Thanks Mikkel. Hopefully, that answers your question. We have another question here, which is a good one, I think. So if you develop a site with composable architecture with a composable architecture agency, so, like Novicell, are you then locked in with the agency, or are there other developers and freelancers out there who can take over such a project, post-development?

Mikkel: Yes. So of course, you can take your platform elsewhere. I actually prefer it in that way because as a company we prefer honesty and we want to advise our clients rather than bind our clients to us. So there are a few things here. For instance, the hosting environment that's typically a tenant owned directly by you as a business, all the SaaS services is owned directly by you as a direct ownership so that can be transferred without us. Then of course, it does require some knowledge about the different platforms out there. So a single freelance developer is probably not going to cut it. But then if that's how you run your website, then composable might not be for you in the first place because it does require a little more budget and the cost will be higher than that. But at the end of the day, it's all open tooling with extensive documentation. So anyone really can pick up and learn if they don't know already. So the last thing we want to do is again my main point here, avoid getting locked into those early choices of platforms, but also for vendors. So in being true, composable, you should also be able to compose your organization around this. And that means taking your platform to other vendors. I have examples from our own, some of our own clients where we compose together multiple systems that are developed by other agencies. So we're basically collaborating with other agencies to bring the content together on the website. 

Charlie: Brilliant. I think that the mark of a good trustworthy agency is that they're open to letting you move on and not locking you in, isn't it?

Mikkel: I'd rather you stay because you have a good experience and we're doing a good job, then I'll have to stay because I put a lock on your leg, to be honest.

Charlie: Yeah, 100% brilliant. OK. Thank you.  I haven't had any more questions come in. If anyone has any last questions, please pop them in now so we can address those before we close things off. Mikkel, thank you for that. That was brilliant and, hopefully, you've all learned something and enjoyed today's session. Oh, I've just had, there's another question here. Sorry. Professional services firms’ in-house web teams tend to focus on being experts in using the CMS. Does going composable or headless change the type of skills that firms need in-house?

Mikkel: Not necessarily, it depends on the level of flexibility if you like. So I like to say that there's two overall approaches to go composable. One is automated, which means that together we decide, us and you as the as the owner of the platform, how data needs to flow. So you can tell me for instance, that all my bios and articles are in these systems. I like them to be pages in my website in this location in the information architecture, I'd like them to be searchable, et cetera. And then we basically make that happen, then everything will be automated and you don't need an extra skill. Then what we do in the content management system is that we basically enable you to relate anything to any page to any content in your search index. So that's extending your CMS system with capabilities of searching into the search index which then makes it you're able to reference any content from any of the subsystems. So that doesn't require anything then thinking and understanding what content is available and how can I bring it to life and compose it together. Then there's a more manual approach where this is all types of platforms I mentioned uniform and constant for some of the new functions analysis. They take this to the extreme. So basically, if you are an editor, and you want to add a hero component to a website, then you can actually go and specify. I want the title to be pulled from a job posting. I want the image to be pulled from my digital asset management system and the text. I want to compose that directly in the content management system. So take this composability to the extreme where you look at each individual data item on your page. And that, of course, puts a bigger responsibility on the editor to know where to draw the content from. So I think it can go both ways depending on your organization's skills and bandwidth, which is again, why best-of-breed is not best-of-breed, it's best of need and capability. So depending on which way you're floating, we can automate all we can enable.

Charlie: Brilliant. Thanks, Mikkel and I’m just conscious of time. I think that's probably all of the questions today, but of course, you can contact and get in touch with Mikkel via LinkedIn and connect with him there. We do have another CMO series webinar coming up. So don't miss that.  It will be another interesting topic covering the war on talent and the opportunities for today's legal CMOs and that's delving into some research by the BTI Consulting group. And that'll be talking to Michael Rynowecer the President there. I just wanna say thank you all for joining. Thank you Michael again and it was a real pleasure to have you on and to hear again, in more detail about composable architecture.

Mikkel: Thank you for having me.