The Enterprise Dilemma: Building vs. Buying AI-native CX Solutions

In today's every changing and evolving business landscape, enterprises face a critical decision when it comes to implementing AI-native CX solutions: should they build custom solutions from scratch, or buy existing platforms?

The Traditional Build Approach to AI in CX

Building custom CX solutions offers enterprises complete control over their implementation: the can fully customize their implementation, perfectly align with specific business processes, maintain proprietary intellectual property, and have direct control over feature development.

However, this approach comes with significant drawbacks: building custom AI solutions comes with significant challenges including high development and maintenance costs, extended time-to-market, and resource-intensive updates and improvements. Plus: whether you like it or not, there’s quite a bit of complexity to creating a solid AI solution - which is only to be met with significant skill!

The Traditional Buy Approach to AI in CX

Purchasing existing CX solutions provides several immediate benefits. Companies can deploy these solutions rapidly, leveraging proven functionality that has already been tested in the market and that has been engineered by highly specialized staff with very specific skills. These solutions come with regular updates and improvements managed by the vendor, and typically require a lower initial investment compared to building from scratch.

However, this approach also comes with notable limitations. Organizations often find themselves restricted by limited customization options and become dependent on the vendor's roadmap for new features and improvements. Additionally, there's a risk of misalignment between the pre-built solution and specific business needs, which can impact operational efficiency.

DevRev’s Hybrid Solution: A New Paradigm, validated by the industry

Modern platforms like DevRev are pioneering a hybrid approach that combines the best of both worlds: lots of out-of-the-box functionality that relieves you of the boring infrastructure related tasks, combined with extensive customization capabilities to tune the platform to your needs.

This innovative approach offers several distinct benefits: core functionality is available immediately while maintaining the flexibility to customize and extend the platform according to specific business requirements. We can summarize this like this:

This is not just DevRev saying this: McKinsey's 2024 "State of AI" survey shows that 75% of enterprises prefer solutions that offer both out-of-the-box functionality and extensive customization capabilities. This confirms the trend that we have seen: it aligns perfectly with the hybrid approach offered by modern platforms like DevRev.

Conclusion

The traditional build-vs-buy dichotomy is becoming obsolete. Modern enterprises need AI-Native solutions that combine immediate functionality with the flexibility to adapt to specific business needs. Platforms that offer this hybrid approach, like DevRev, represent the future of enterprise CX solutions.

By choosing a hybrid solution, enterprises can accelerate their digital transformation while maintaining the ability to differentiate their customer experience - truly offering the best of both worlds.

Let me know if you have any questions or comments. Would love to discuss.

All the best

Rik

Podcast Interview with Axel Morgner, Structr

Here's a podcast episode that was long overdue: I finally got to speak to a long time evangelist and community member, Axel Morgner. We met a long time ago in front of an illustrious London Pub, and have been working together on a number of projects, activities and ... stuff. Over the years, Axel always impressed me with his unbelievable achievements on Structr, his fantastic enthusiasm and just sheer impressive expertise on all things Neo4j. Listen to the story here:

Here's the transcript of our conversation:

RVB: 00:02 Hello everyone. My name is Rik, Rik Van Bruggen from Neo Technology, and here we are again recording yet another episode for our Graph Database Podcast. Today I'm joined by someone that I should have invited a long time ago. It's probably one of the first people that I met in our wonderful community:  Axel Morgner from Germany. Hi Axel. 

AM: 00:24 Hi Rik, how are you [chuckles]? 

RVB: 00:25 Hey [chuckles]. Again, I need to apologise. I should have invited you a lot earlier, but you know how these things go, right [chuckles]? 

AM: 00:32 No worries. I think now it's the perfect time for a podcast. I have some news and I'm relaxed after vacation. 

RVB: 00:42 [chuckles] Super. Axel, we've known each other since I think FOSDEM in Brussels two or three years ago. That's the first time we met each other. But many people might not know you, so do you want to introduce yourself a little bit and tell us who you are and what do you do? 

AM: 00:58 Yes, sure. But I think we met in front of a pub in London after a meetup. 

RVB: 01:05 [chuckles] That sounds likely as well [chuckles]. 

AM: 01:10 [chuckles] Yeah. I'm Axel Morgner from Germany. I'm living and working in Frankfurt, and I'm the founder of Structr, our software project and also our company. 

RVB: 01:25 And Structr, that's been around for quite some time. I remember the days when people thought it was a content management system. But it's much more than that now, isn't it? 

AM: 01:37 Yes. Yes, it has become more a graph application platform. That's what we call it now. It has started out as a content management system when we first had the idea of creating something new based on a graph database on Neo4j in 2010. The first attempts were made back then. But over time, we saw the potential in graph databases and Neo4j in particular to create much more. So the short story of the evolution of Structr: It was we wanted to build a content management system in the first place. Then we saw that we could do a lot more stuff if we make the back-end very flexible. 

AM: 02:32 And then we came up with this flexible schema or data-modeling tool, which was just added for our own projects - to gain speed in the projects - and then we just generalised that into a-- yeah, we called it Data CMS and now we call it Graph Application Platform because you can do a lot of things in terms of application programming without having to code as much. So you just put the data model in the graph as well, and there's components in Structr which create a [restful?] API and all the stuff out of it. So we have a lot of things that make your lives easier. 

RVB: 03:22 Well, I've seen you do the demo, and there's a couple of recording even, aren't there? How to build an application in a couple of minutes. It's really impressive actually. I'll put the link to that on the publication of the podcast as well.

AM: 03:38 Thanks. 

RVB: 03:39 So how did you get into the graph story, Axel? And why did you get into it? Can you tell us a little bit more about that? 

AM: 03:48 Sure. The history or the-- my background is I'm a physicist, and for me, software are tools to solve problems. And after my studies, I started working at Oracle, doing all this relational-database stuff and so on. So that was in 2000, and just for two years. After two years, I was kind of fed up with all this, let's say, heavyweight-proprietary-enterprise-database stuff. But nonetheless, we had a very smart team in one of these projects and we decided to create enterprise content management system based on Oracle, and we founded a little company. And after some years, I thought it's too heavy and too boring and too proprietary, and I wanted to do something new. 

AM: 04:52 And there were some NoSQL databases around and I started looking around and thought, "Okay. If I want to do something with content management where we have trees - so page trees, five hierarchies, organisational trees - let's try it at graph database. And Neo4j was in Version 1.0 - this is the version I started with - was major and stable enough to give it try. And it was embeddable in Java. So I'm kind of a Java hacker. And that was the story. It was a perfect fit to just map hierarchies and trees in a graph database. 

RVB: 05:41 But as I recall it from the content management days - if I can call it like that - it was also about the performance, right, that you were able to get out of it. Because I remember you telling me that in old-style content management systems you needed caches and all that wonderful stuff and [chuckles] that basically, if you just store it as a graph, you don't need that anymore. 

AM: 06:05 Exactly, exactly. So it has turned out that it was the best decision I or we ever made, in technical terms, to go with a graph database and with Neo4j as well. Not only in technical terms; communities and the people are wonderful too. But the performance is a very important thing. So we store everything in the graph. For example, take the page tree. Normally, if you want render a webpage, you store HTML, basically HTML in your database. If you have a content management system, you split up the HTML page into small pieces. And the more flexibility you want to have, the smaller the pieces have to be. But if you then have very many small pieces of HTML and have to join them together for rendering dynamic pages, you have to do a lot of joins in a classic or a relational database. 

AM: 07:14 And we all know that this gets slower and slower the joins you have to do and [the?] more data you have in your database. If you do it in a graph, you just start at the page note and just traverse the page tree over some relationships, and you just take the [wave?] through the page tree - your requests parameters tell you - and then you just render the page output of this together and you can do that in a couple milliseconds. In a classic content management system you can't do that. You can only cache portions of your page to get a reasonable speed, but if you for example have a protected page - so you have users who log in and everyone sees different content - then you can't do that anymore; you can't cache the dynamic content for each person. 

RVB: 08:13 yeah that makes sense... 

AM: 08:15 So it's much quicker than a classic content management system. 

RVB: 08:19 Super interesting. And I encourage everyone to take a good look at Structr if you're doing content and web application development; it's really lovely. So Axel, where is this going? What's this story both from a general graph-industry perspective and from a structure perspective? How do you see the future? 

AM: 08:43 I personally see a very bright, full future for not only Structr and Neo4j as I think the best graph database on the market, but also with the graph database's space in general. Because it's my belief that graphs or graph databases are the best-- not tool, but technology to really map the reality in an electronic structure, if you want ... 

RVB: 09:23 Reality is a graph [chuckles]. 

AM: 09:24 Yeah, reality is a graph. The best abstraction of reality is graphs. And so the best tool to map this abstracted reality to software or to memory - that's basically what we're doing - and calculate on that data is a graph database. So we have an interesting roadmap. We're about to announce our upcoming release, 2.0, which will contain very interesting features. Like on one hand, we're expanding a little bit into the enterprise content management market, so we're creating a much better file interface: a completely revamped files and folder management user interface. And it comes with the possibly to use SCP or SSH to just lock into Structr and do file operations in it. We are currently implementing the CMIS: Content Management Interoperability Services, I think it's called. It's a very broad industrial standard for interacting with content management repositories. We are implementing that based on our layers. So that will put us into the-- let's say we're approaching the larger ECM vendors or systems like Documentum and Alfresco, and so and so on. 

AM: 11:07 And on the other hand, our mission, our long-term goal is to make application development much easier. So we want to reduce the friction you have as a creative person or as a manager in your company to create an application with the knowledge and the data you have. So the friction is introduced by developing hurdles like you have to choose a programming language, you have to set up the thing. Or maybe you can't program or you don't like to program; then you have to find developers, you have to pay them, and so on. It takes times and it's expensive. We want to fill the gap between the content management system and the development framework with Structr. So make it easier to create applications just by drag and drop, and put in some data, so that everyone can create mobile and web applications. That's our long-term vision, I would say. 

RVB: 12:16 I mean, that's like a wet dream [laughter]. 

AM: 12:19 [chuckles] Yes, it is. I know, but I mean-- 

RVB: 12:22 It sounds really great. And you know what? I can't-- 

AM: 12:23 --you have to have ideas like this to keep you motivated over such long time. So we won't stop [chuckles]. 

RVB: 12:31 I agree. I agree. That's great. That's great. Wonderful. Well, Axel, it's been really great talking to you, and as you know, we want to keep these podcasts digestible length so I'm going to wrap up now. I really want to thank you for coming online and talking to us. And I look forward to seeing you at one of the future events and community events, right? 

AM: 12:58 Thank you, Rik, for this wonderful podcast series and the opportunity to talk to you. I think we will see us at the latest at the graph connect in San Francisco, I hope. 

RVB: 13:08 Absolutely. We have to meet up there [chuckles]. 

AM: 13:12 Yes. [crosstalk] 

RVB: 13:13 All right. Thank you, Axel. Have a nice day. 

AM: 13:16 Thank you too, Rik. Bye bye.

Subscribing to the podcast is easy: just add the rss feed or add us in iTunes! Hope you'll enjoy it!

All the best

Rik