Reimagining digital transformation - with Nick Ford
Hello and welcome to this very special episode of the Trend Detection podcast. As you can see, I'm not at home and I'm not in our usual studio. We're actually in the Mendix office in London, which is really exciting. And I'm joined today by Nick Ford, who's chief growth officer for Mendix. So really great to have you on the podcast, Nick.
No, thanks for inviting me. Thanks for coming to Mendix to run it. Nice. Fantastic. Looking forward to the conversation. Yeah, and we're going to talk about digital transformation, try and get, I guess, a new angle because we talked know there's lots of content about digital transformation out and Mendix is doing some really amazing things as I experienced recently at a Siemens event in Munich.
But we'll come on to that in a SEC. But I guess first of all, be great the listeners just to know a bit more about unit, your role and bit of your background as well. Yeah, well, I've been in the software industry for about 35 years, started back in the 80s as a COBOL program. I've been with Mendix about 13 years.
I guess my expertise is really in abstracted and automated software development. And obviously the combination of that career is joining Mendix and helping to sort of promote low code as a solution for the rapid delivery of the myriad of software that we need to develop today to keep our businesses afloat. It's an old adage, but every company is a software company and therefore building more software more rapidly is very important.
So exciting times. Exactly. Yeah. Lots going on in our space at the minute, I'd say. But I mean, let's start very broad with the big question is, but it's more personal to you rather than the broader quest, but what is digital transformation to you? What does it mean to you in. Your sort of thing? Yeah, I mean, it's interesting because I think it means lots of things to lots of different people and everybody looks at their transformation agenda through the lens of their organization, through their personal lens and so on.
I think for me it's about bringing digital technologies into the core of your business and helping you to operate differently. I think transformation needs to be transformation. It's about how do we want to do things in the future, how can we use technology to help us be better? Either that's, either be more performant, efficiency, new customer engagements, whatever that objective might be. It's about using digital technologies to do that.
But it's also equally about the cultural aspects of transforming a business, which I think is probably equally, if not more important, as part of your digital transformation agenda. How do you look at both the technology aspects, which I'd argue is probably the easiest side of things, and then how do you bring in cultural change, organizational change, and then defining to you what transformation digital transformation means? I think what's interesting is it's quite hard and it's a risky business. And some people choose not to embark on a transformational agenda in that respect. So question is, are you in the race? And when you are in the race, how can you make sure that you actually come out ahead of the competition? So lots of factors involved in that. When we speak to CEOs, 60% of the people that we're speaking to at that level generally have a transformational agenda, or they're working on digital transformation as an organizational structure.
So we're starting to see that happen more and more. Do you find and speaking to CEOs as well, obviously, the agenda is at that level, but do you feel that it filters or it is filtering through to all levels of the business as well? I guess that's the challenge for them, isn't it, is that talking about it at that level, but also making sure it's like that culture change you mentioned it is. I mean, transformation happens everywhere, right? You're transforming the business. Therefore we have to touch everything from internal customers, employees, partnerships, whatever it might be. So it does, and it has to permeate through the organization. It has to be something that people understand what you mean when you see, say, digital transformation.
So there's a common agenda, common understanding. If you don't have that, then it's very difficult for people to follow the journey and to embark on that journey and participate and help you to transform without sort of pockets and isolated pockets of great things happening, but not connected to a transformational agenda. And we see that a lot, right? Organizations that are building software organically, ground up, using often low code technologies, but sometimes end up with a sprawling landscape of disconnected applications because they're solving departmental problems. And really what we'd advocate is transformation. And digital transformation is not a project.
It's something that has no end, really. You should always be transforming. So it's a journey in that respect.
You need to think about what's the intake? Who's going to be involved in solving the problems? How do you bring multiple different participants together to ensure that you converge on an outcome that's based in value and helps to move the business forward? So a lot of factors involved, which is why it's complicated and people find it very difficult. Yeah, and of course, it's not one size fits all, I guess, everything you've said so far. There's just so many different factors. I mean, what are some of those factors that come into play? Well, I think for me, we look at the lens when we're speaking to our customers, we look at the lens of digital transformation through what we call the sort of five P's, which is we look at your portfolio, we look at the people, the process, and we look at promotion and the platform.
So we tend to look at those five P's as a lens through which we help organizations think about all of the factors involved in their transformational agenda. So if we run through them a portfolio, first of all, we're generally looking at building software. So Mendix is a local platform. We help organizations to build the software that they need to drive that transformation in their organization, to digitize processes, digitize engagements with customers, historically move paper based processes into online processes, automate, all those kinds of things.
So portfolio is incredibly important because as I said earlier, what sometimes happens is the business is off building applications, they're trying to solve problems independently and that's not a bad thing, that's always happened. And I think we want to encourage the business to be part of the development process involved in building new software as part of that digital transformation agenda. But the important thing is we need to make sure we're building the right things, right? We're not duplicating effort, we don't end up with this fragmented landscape. So we'd advocate sort of taking a look at what is the portfolio intake, how do you think about all of the things that you need to develop as part of your agenda and then to decide how you want to develop them. So assess which applications or which software is right for development, perhaps which initiatives need to be combined into bigger initiatives that perhaps are taken on by it and not business.
So, portfolio intake, understanding the value of the portfolio, once you understand that you're able to place bets, right? It's all about where am I going to invest my pounds or dollars, whatever it might be, into those initiatives that move us forward on a transformational basis. So portfolio assessment we think is incredible important. Then people, I'd argue that probably in that order, or perhaps on a par, what people do you want involved in the process? Do they have the skills to get involved? How do you bring them on the journey? Continuously create methodologies for people to collaborate better. So people's really important part of it, the cultural aspects of that, then you have the underlying platform and technology that facilitates it. So I'd argue that software development and transformation is a team sport.
You got to bring all these participants together to work together with different skills and different disciplines. So collaboration is incredibly important. So you need a methodology to support that. So processes that underpin your transformation, gender from start to structures to scale. Then finally promotion, which I think is very underlooked. And when we talk to a lot of CIOs, but I think it's one of the most important factors is you need to be internally championing the work you're doing to make sure that everyone understands the value of the work that you're doing and celebrating that, promoting it internally, because that's how you sort of get this momentum that's needed to continue over time.
So, long answer to your question, but I think there's a lot of things that I think are incredibly important for organizations to think about factors, influence. And is that like a Mendix philosophy, the different points? Yeah. We have a digital execution practice, and over the last 18 years or so that we've been doing this, we've been involved in helping organizations in the early days of taking on the challenge of building better software faster, such as speed of development. How can I develop software more quickly, how can I use different skills to develop software? But more importantly, how can I create software that actually is fit for purpose? So often we think that that's about bringing business experts into the process alongside technical experts who combine forces and create software.
And over that time, we've engaged with many, many companies. Some have been in relatively tactical implementations of new software. But as the years have gone by, we've got involved with big organizations who really want to build this capability to be able to transform through software. And so as part of that, we created what we call our digital execution practice, which is a methodology which takes organizations through the five P's that we talked about, but then also through what we call start structure scale, which is how do you break down this journey into manageable chunks? Where do you start, how do you move from start into structure, and how do you move from structure into scale? And there are various aspects inside that methodology which allow organizations to really keep on pace with their transformation agenda. And I guess one of the questions I was going to ask, I think it's part of the digital execution sorry, side bits to do with your sort of digital maturity. So I wanted to talk about culture, actually in a second as well.
But you have a tool that actually. Assesses digital maturity, and it's based on those five PS, actually, the maturity assessment. You can go to the Mendix website and actually run your own personal assessment.
We'll probably put up the link at some point afterwards. But yes, the maturity assessment is based on those five key principles. So we take you through a series of questions that identify your maturity in terms of what technology you might have, what methodology. So, for example, are you agile? It seems obvious, but are you using agile principles and methodologies? What kind of people do you already have citizen development? Do you feel that business needs to be involved in development process? Have you actually moved it into the business? So there's lots of questions that we ask around the framework of those five P's, which will actually then give you a sense of where you are on that maturity scale and how ready you are for really taking on digital from the perspective of long term transformation. As I said before, we believe that there's no destination here. It's a continuous, ongoing journey.
But, yeah, you can take the assessment, I think, on our website. And does that cover sort of a cultural maturity side as well. It does.
I mean, it asks questions about your maturity of the organization with regard to things like how do you feel about business developing applications, how do you feel about the business participating more in the software development process? So it takes into account whether or not you're able to bring together that truly collaborative approach that's required to do this properly. Look, and I can't say this strongly enough, human beings come together in villages as teams, we're better together. Just general the way that we solve problems.
We're better together. So collaboration is fundamental to transforming an organization. So we look at the very early stages of maturity when we think about how organizations are structured.
Are you siloed into everything that's in software development sits in it? You can create an idea in the business, but then you need to fund it and get resources to actually create a project to do that? Or do you have a little bit more of a mature model which thinks about how ideas can permeate from business and It, and are funded perhaps in a different way? Maybe teams come together through agile fusion teams, those kinds of things. So there is quite a bit of assessment around organizational maturity, people wise. Culture is hard, right? Culture is a difficult one and it needs to be set at the very highest level within an organization.
But we certainly look at it through that lens. Is it often overlooked as well? Because I know that the temptation, especially in our senseye world as well, there's the temptations based on the cool technology, especially when you throw AI and all this other stuff or loco maybe into the equation. But is that part that often overlooked? Oh, we've got this cool technology, so let's just deploy it and massively overlooked. In fact, one of our biggest challenges when we're talking to customers that really identify us as a company that can help them in their transformational agenda, digital transformation agenda, it's difficult to try and get them out of the technology discussion mode.
It's often, can you show me your technology? How does it help me build software faster? How can I generate applications that work in these kinds of landscapes? And typically what we're trying to do is to say we can do all of that, but let's just take a step back and understand. Even if you did take the Mendix platform, how successful would you be with the structure that you have? Do you really have a clear view of where you want to go with the technology? Because there are things that we're incredibly good at and there's probably things that other technologies are good at. So let's understand the landscape, let's take a look at that. Let's try and assess the maturity upfront so we can then prescribe how the technology underpins that.
Mendix has been around for a long time. We're a great product. We've never demonstrated Mendix to somebody that said they don't like it but it's a bit of a false positive.
You can love the technology but not get the most out of it. So you've really got to understand those cultural aspects, the collaborative nature of building more software faster and what is your transformation agenda? How do you get value out of it? How do you assess value? How do you understand whether you're delivering on the value and how do you then promote that value inside the organization to make sure that everyone realizes that the huge amount of investment that's going into these initiatives actually has a payback? Because everything needs to have a payback. At the end of the day, we make money or save money somehow. So very important part that's missed an.
Awful lot yeah, and it's a word you've used already is that the collaboration? And I think sometimes with that relationship as well because a lot of things are transactional in this world so you pay your money, you get your technology and off you go. But really it's an ongoing collab in order for it to work, deployment to work and to get real business impact it's the vendor and the customer work together, right? Yeah, or they have to. Well, they have to. I mean, I said earlier, I think that's what we do as human beings, that's how we solve big complex problems.
We collaborate, we abstract and we automate. We build tools to make it easier. We build tools that other people can do complex things that perhaps they couldn't do before. I always think about sort of the manufacturing well, it's not a great analogy, but it always amazes me that something like a large aircraft can have components built all over the world, but can be assembled in one location, and it works. And you can fly that with people.
And that's a complex problem solved through abstraction, automation, standardization, all those kinds of things. But yet we haven't brought that materially to the software development world. So I think it's important to look at how we bring multiple participants together because the skills, what we want to build is often locked in the minds of the business, the people that live and breathe the processes every day. Then it can turn those ideas into software. But the translation mechanism between is difficult. So the closer you can get them together, the more they can collaborate, the better the outcome, the quicker the better.
I think collaboration doesn't stop inside the organization. I think what's important is it needs to extend beyond the walls of the business, outside the gates of the business. You need to collaborate with your customers, you need to collaborate with your partners, you need to create an ecosystem where everybody understands the rules of the game, can participate and everything works together. So I think those analogies of building these large complex machines are a great analogy because I can build the wings in, I don't know, one country and then put it onto a plane and it flies. But you can only do that when there's a clear understanding of the rules of engagement and how we collaborate together.
So we're interested in making sure that organizations can do that both internally and as part of their ecosystem of partners and customers and vendors. And how about more specifically towards It and OT? And we talk about integration, but actually more the integration. Let's call it Itot collaboration, or as we've started to call it within Senseye. It's like building one culture for Itot. Those sort of themes.
We've started, yeah, you could probably come more than me, so maybe you need to answer it from your perspective. But in our world, I think that's one of the more challenging areas because I think there is generally a sort of us and them often between It and OT, and that's historical and it's a barrier we've got to break. Right? I don't think we solve the problems that we need to solve when it comes to improving efficiencies, cutting waste, being more sustainable, when you look at the lens of manufacturing without bringing those technologies together.
And for me, where we tend to find challenges there, it's the problems we find. They're often very technical in nature. It's about bringing technology together to integrate. You've got things running on the shop floor, things running in the back, modeling data, collecting data from connected devices, ERP systems. And so it tends to boil down very quickly to a sort of technology discussion about how do we get the landscape working together, but that won't work unless the people work together. So I don't know how Senseye look at it, but it seems to me to be an ongoing challenge that we.
All have to yeah, it absolutely is. Because I think from a Senseye perspective, it's funny being person on the other side of the but from a from a Senseye perspective, I think we spent a long time focusing on maybe OT in terms of obviously marketing person, but focus on messaging towards that. But we realized it's just important to engage and bring in It, and especially early on into, let's say, the sales process or the early engagements.
So there's understanding from both sides. There's no use having a great if you go at it either way. You go from It being engaged from the start and then you bring OT at the end, or you flip it. It's just not going to work. They need to be on the sounds a bit cheesy, but on the same journey together, really and understand what that.
Journey is and what's the value of it. Right? If that doesn't happen, what happens is we solve tactical problems and then we come together for integration. So the only time we talk is because we need to integrate two systems. But actually, did we take a step back and understand what is the value of doing what we're doing? And could we do it differently? And how do we involve people on both sides of the fence to get a better outcome? When we talk a lot about Mendix's, sweet Spot really is in delivering using low code to solve complex problems. Often low code is sort of put in the bucket of departmental small, less mission critical problem solving. And that's probably driven by one of the major vendors out there that has a very specific low code offering.
But most of our customers that are working with us are solving complex problems. They're building solutions in Mendix that, for example, run parcel delivery for the Netherlands. Big complex problems and low code is I'd argue that our technology is more applicable or low code as a category is more applicable to complexity because you have uncertainty, you have lots of people, you have lots of technical challenges. It's complex by nature and therefore the only way we solve complex problems is to chunk them down, come together and try and solve them together. So we'd argue that actually transformation, digital transformation, you've got to take a holistic approach to it.
You got to think about every aspect of it and then how do you take those complex problems and chunk them down into something that's manageable? You could then get into the words of things like composable and composable enterprise, which is quite a hot topic at the moment as you start to build and reuse components across the organization. So it's an exciting place to be, but it's not without its challenges, that's for sure. I think the Mendix approach is particularly interesting because there's often this conversation about build it versus buy it and that's just technology instead. And Mendix obviously make it easier to build own applications. But how's Mendix sort of approach that argument of build versus buy, I guess. Yeah, it's at the core of what we do and I think there's an interesting view on that.
I mean, some people are happy to take software the shelf and bend their processes to meet the software. There are some people that feel that that's not what they want to do and they want to build the software from the ground up and make it very specific to their needs and therefore highly differentiated. I'd argue that there's a middle ground, there's a sort of blend approach where you can take something like a team center from Siemens or SAP as an ERP system and you can build on top of those solutions. So you can take the published APIs that they have and you can then extend outside of the core of the platform and create that differentiation through products like Mendix low code platform. So you're taking existing technology with best of bridge and you're blending it with new technology.
You're actually creating some separation. So we don't want to start building inside the core because that just creates long term problems for upgrades and maintenance. But if you can surround that with these new, very specifically developed capabilities that, you know, differentiate you from your competitor. You get the best of both worlds. We're pushing on the concept of what we call adaptive, which is really then how do you take some of those key components and distribute them where 80% of what you create is probably locked down? You can then manage 20% of that.
So there's lots of ways in which you can play with that world of build versus buy. But I'd argue that it's somewhere in the middle. There's a reason that Team Center is the world's number one PLM system, but there are things that with mendix on top of that, you can add specific differentiation for you. So I think it's a case of looking at it through that blended perspective.
Yeah, I think that makes a lot of sense after you've explained that, actually. But yeah, it's not just building. Yeah, it's sort of combining what you've got already because I guess I'm just thinking from the outside.
You approach an organization, they've got lots of different systems. They're just working. How can we make these systems work better together so we can increase operational efficiencies and things like that? The differentiation is often in the gaps, isn't it? If you've got an ERP system or you've got a PLM system, or you've got a manufacturing system, a large proportion of what you do is probably covered by those technologies. But maybe the bit that transforms your business is some idea that you have that sits in and around the gap between those systems.
So how do you address that? So I think it's important to look at those gaps and important to look at what is differentiating for you and what digital can help you achieve, and then use technologies like loco platforms, mendix, to help you to build that very rapidly. I think what's important for me in digital transformation is the ability to be able to cost effectively, test and learn. Digital transformation is about pushing the boundaries of how we operate. It's about doing things differently or you're not transforming right.
If you're doing the same with technology, you're optimizing. I think you're taking what you do and you're making it better and are more efficient. And that's not a bad thing to do. Many organizations are on the optimization route where they're using technology to just get better at what they do. Today cutting cost. Automating AI is a great example of that.
Or you've got organizations that are thinking, well, what's my new business model look like? I'm going to transform what I do, make it different so I can truly differentiate myself, maybe even create a new line of business, maybe even create a new way to market. So I think it depends on your approach. Maybe take a little bit, step back a bit. So I just want make sure for people who are sort of tuning in, so what is low code? Maybe break it down a little bit and then maybe how it I know you sort of touched upon it then, but how does that help to enable digital digital transformation, I guess? Well, at the core, I mean, low code is a way of building software without writing code. There's a common misconception that low code means you have to write some code. It's not a reality.
With our technology and with many of the low code platforms, you can write complex applications and solutions without writing a single line of code. Low code means for me that you have the capability to write a small amount of code to surround that if you really want to. So it's extensible in that respect.
There are lots of no code platforms that basically are locked in and you can build what you can build. But with low code you've got that ability to be able to build anything using low code. With our platform, that could be anything from a departmental system to, as I said, a system that runs a postal service or runs a bank or whatever. It might be a manufacturing line.
But the principles behind low code are about abstraction, automation. It's about how can we bring visual development capabilities. So for example, rather than designing screens at a low level, you can use drag and drop capabilities to build the screens. It's not only building the user interface, but it's building everything that's needed underneath that to be able to share data on a web environment, or a mobile environment, or a PWA, or across all of those environments with one skill set. So we're really about bringing abstraction and automation to the software development process from ideas that's like bringing your portfolio of application, understanding value to the development process, to building your database, to building your front end, to building all the logic, then the automation of deployment into the cloud and then the running of those applications is all part of a local platform.
Which means when you take that approach, you can bring different skill sets. So you can have people that aren't professional developers building software, you can have people that are professional developers participating in extending, creating reusable components so that non professional developers can do even more. So this ability for Loco to be able to accelerate the software development process by tenfold, which is typically what you'd expect, you're going to do things ten times faster and probably, certainly with our technology at 70% less cost. So smaller teams building more means you can drive that digital transformation agenda, really drive it right. You can push it to an extent where you know that building something quite complex, the actual ManTime or person time involved and the cost involved are at a level where you can invest in them. Sometimes with traditional technologies, organizations don't embark on digital automation because it's just too costly and too risky, because they don't understand the outcome.
They're not able to spend the time and. The money and therefore things just don't happen. So we find that bringing low code technologies and principles into an organization really allows you to accelerate that digital transformation journey, test and learn, do things in a cost effective model and then make sure that all of the participants required collaborate around one skill set, one core technology. If we're building an application in Mendix to run on native mobile, it's the same skill set as if I'm building an application to run on the web.
So we're creating a common set of the framework I talked about. Well, the rules, engagement, we're creating that with a mendix platform. This is probably more with a marketing sort of slant on it. But is LOCODE something that's very well known in the market, people looking for low code platforms? Or is it the problem they have and they're not sure? Yeah, I guess you guys are doing fantastic marketing. So obviously everyone knows what low code.
I'd argue that we've sort of helped pioneer the term low code, but I think you're right. I think it's changing. Right. The low code category is Maturing.
It's much more mature than it didn't exist. Less than what? 20, 14, 16? It was high productivity application platform as a service before then. That was never going to take very marketing.
Yeah, it doesn't trip off the tone. So I think that that worked, but I think we've done our work in trying to push that. But you're right, most of the people that we speak to come to the table with a problem to solve.
I need to go quicker, I need to develop software faster, or I need to solve a business problem that I can't solve with my existing skills that low code might be able to help. So I think they have a problem in mind. They go and research low code as a way of solving that problem.
I do think Loco has matured now to the level where it's just generally accepted as a way of automating complex problems that involve writing code. And that's not just for developing apps that's in AI and data sciences. So it's become quite a Bloated category.
So answer your question. I think our customers come at it with a problem first and the low code seems like the way they can solve it and engage with us on exactly how do we use low code to help them solve those business problems. They're not necessarily in the market to buy a low code platform. Yeah, it's just an interesting thing because again, predictive maintenance is an interesting one because suddenly for years it's been sort of like a cool technology. Now it's a bit more mainstream. But the problem when it becomes more mainstream is that everyone says they're doing predictive maintenance.
Again, I was wondering whether there's a lot of people out there, companies without going to specifics, but that say they do low code, but in reality it's not really. Yeah, there's lots of people riding the low code wave or AI or whatever. AI. I mean, there's low code everywhere, low code for AI, low code for HR, low code for so low code's actually moved now into being sort of low code for specific categories. So you can get low code for legal, so platforms that focus on bringing low code capabilities into the legal world, so become sort of vertically focused.
So it is a category that sort of become, as I say, very bloated. And sometimes it's difficult for people that have a specific problem to solve to understand which technology is going to help them solve it. And so we're pushing quite heavily on making sure that from our perspective, we're clear about that and we've sort of pioneered the space, we've been in it for quite some time. So with a leader in that respect, so we get sort of more than our fair share of the traffic that comes through, general search engine optimization on loco, those kinds of things. Yeah, absolutely. And as we've sort of touched upon it a few times, it'd be a bit remiss not to talk about it because obviously we all know AI is becoming the new well, it already was in a way, but it's now becoming even more in everyone's faces, really.
But I'm wondering how AI and machine learning, if you want to put those two together, how that sort of fits into this digital transformation story or journey. Well, it's a couple of ways. Looking, you've got AI for Ad, which is artificial intelligence for application development. So how do you apply AI to help you build better software? So, for example, within our product, we have a number of embedded artificial intelligent bots that sit alongside you.
And when you're building software in mendix, they're continuously helping you to do it better. So if you're building some logic and you drag something onto your canvas, our AI bot for logic will pop up and say, I think you want to do this next. So if you're new to the product and learning the product, it's going to be guiding you. It's a bit like a pair programmer looking over your shoulder and saying, okay, most people that did this actually wanted to do this next.
Would you like me to do this for you? So it's helping to train you and guide you, making sure the logic is correct as you go. We've got AI for security and AI for error management, those kinds of things, where they look at the model and they look at the performance of the model and say, actually, we've assessed your model, and we think that if you did this, it would be more performant, or we should fix this problem because there's a security issue there. So AI for Ad is really about how do we bring artificial intelligence into the development process.
Large language model is a great example. We're training a large language model on mendix where you'll be able to ask it natural language questions and it will come back to you. Having gone through whole myriad of sources, from our evaluation guide to our documentation, to anonymized models of application, most of our applications are metadata driven, so we've got a huge amount of information about applications and how they're built. So it will go and trawl over that and give you best practice. It'll help you to build that as you go. So AI for ad is incredibly important.
We're pushing on our performance bot, our logic bot and data bot and so on. So we have a number of different products that sit inside the platform, including the introduction of large language models. And then you've got AI for applications and AI for business. So how do you bring machine learning models into your applications? So, do you want to build visual recognition into your apps? Do you want to look at data that's captured from a windmill, for example, using IoT and do predictive planning and maintenance based on AI models? So, again, I think applying AI to the business problem is incredibly important, but also to the software development problem is incredibly important.
The combination of those two things are very powerful. We've just launched MLKit, which is about embedding machine models into your application and running them simultaneously in the cloud with your application. So that means you can train a model, deploy it once, you don't have to worry about anything else, you can deploy it with your app into the cloud and it'll run alongside the model itself. So where AI will take us will be interesting. Right.
Who thought it less than a couple of years ago, large language models? Did we really know much about them? We probably didn't. Right. So they've sort of come up very quickly. So we're looking very strongly into those areas and there's a huge amount of opportunity to marry those technologies with people. The cultural aspects, which I don't think AI is never going to address, how do we bring people together and use technologies to make them more efficient is probably the way that we're looking at it. Yeah, working together.
Because again, it's augmented, isn't it? That's probably the way looking at it. I mean, in a manufacturing environment, it's always that myth where, oh, it's going to take our jobs. But there's always I mean, we talk about in the senseye product, it's as important as the data we get.
It's also the human or the maintenance person providing input as well into why did that case open, was it correct? And it feeds back into it as well. So it always needs directing in some way. Yeah, I think the human and AI augmentation bringing those things together and making sure they're working closely together. Yeah, but it's moving.
I think what's interesting is when you look at digital transformation, the challenge is that the world moves on at such a pace. There's new technologies, new opportunities coming up almost daily. Now the question is, how do you do you and how do you embrace all of that technology? You how do you bring it in? Because it makes your landscape more complex, right? You want to solve these problems, and there's probably ten or 50 new technology that might help you do that. How do you assess it? How do you bring it in? How do you make sure it all works together? So the pace of change and the pace of innovation is a challenge in one respect. It's great that we're innovating.
On another side, it's just difficult because there's always something new to look at. What we're trying to do within Mendix is give you what we call a subscription to innovation. We're bringing all of that technology together in a low code platform so that you don't have to. So we're thinking about what AI means for both application development. Also for the end solution, we're thinking about what Composable Enterprise looks like and how you need to create underlying event management in terms of data and so on. So buying into Mendix is like buying into a subscription to innovation so we can sort of alleviate some of that burden that comes with it.
So you can focus on how do you use this technology to solve business problems while we help you focus on some of those innovative challenges and new technologies. I guess what I'm wondering now is whether things like AI machine learning, are customers demanding or demanding or asking or really intrigued about these technologies? Or do they, on the other side, find it quite overwhelming? Because there's a lot of talk about it, of what it can do, what it can't do, what it might do, and it's like all this information is like, oh, how do I apply this to my business? Like you said to what we've been saying, the business problem, it's not just the technology and how does it fit in culturally with what we're trying to achieve as well? Yeah, I mean, I said that large language models, we were inundated with questions about large language models. Can I just now have all my software built using a large language model? I just tell it in English what to do and lo and behold, software comes out the other side. Well, we had to armor our teams with an answer to that question, because it's a good question, right? I mean, if you look at the hype around it, it certainly will do that. You can certainly ask it to build software and it will build it for you.
The problem with that is that it's the actual low level coding of software that's the problem. It's hard to maintain. It's difficult to understand. It's even difficult to understand when you know somebody's written it who works for you. But when it's been completely automatically generated by a third party AI engine, it's even further away from your ability to control it, the risks involved in that, the maintenance involved in that. I'd argue that's very difficult.
I think it would be very difficult to convince a sea level executive to both automate that and then bring it inside and risk manage it and maintain it and support it. We'd advocate that actually moving away from writing code is the thing you need to do. You need to combine your skills into new technologies that help you to address and harness AI.
So we're talking about how do you do that, how do you bring that into your existing systems, how do you make it work for you? What's the value we want out of it, rather than just suggesting that perhaps it will just take away all of the hard work in building software. Because I don't personally believe that it will, not anytime soon anyway. And I guess a lot of it comes down to trust. And you could move beyond, actually AI machine learning into technology is putting trust in the technology is a key. And again, referring back to predictive maintenance, sometimes that's in backfields, is it too good to be true? Is that kind of mindset as well? Is that something that you experience as yeah, it is.
Yeah. I mean, like I said, when you demo mendix, I think I've demoed mendix over the last 13 years, many, many times. And everybody loves mendix as a product. And I think technologies like this, people love them because on the face of it, they solve lots and lots of complex problems.
The reality of life is most technology that makes it to market probably addresses a specific set of problems very well. The question is, can you make it work for you? Can you harness that technology to your advantage? And there's great examples of great technology that doesn't have the impact on the business. And that generally is because it was probably purchased for the wrong reasons. The structures around it weren't mature enough, it wasn't adopted, there was no plan for it in terms of how you use that technology to advance your agenda. And it needs a level of support and engagement for technology to take a foothold. We see that in companies that do well with mendix.
They use our methodology to encourage the business to go through this process of building something that can be demonstrably, show value. And then we give them a path to how you then start to do more of that, but in a structured and controlled way. So that over time, you move from sort of probably building relatively small application that's high impact, to understanding how your organization structures behind building more of those applications. How do you train the people, what kind of people need to be involved, what processes need to be involved, how the platform works.
And then eventually you move from building one or two apps to building hundreds of apps. But that doesn't happen overnight. So those organizations that are not prepared to sort of invest in making the most out of the technology will struggle. And I think that comes back to what we talked about earlier. Most of these things come down to whether or not you can make it work for you as an organization.
And I guess a key part of that is how measuring the success of it as well. Is there any sort of guidance you could give? Yeah, we go back to the portfolio again. I think what's important in our world, and perhaps I'd argue in the world of building software to address digitization, which is probably a lot of what you're doing, is building or using new software. You need to understand what problems are you solving, what's the value of that problem to the business, and what's the investment required to get that outcome and to focus on those things that are actually going to be transformative. Understanding the value helps you make a better case for investment, helps you understand what the perceived value was at the outset and whether you realized that value once you delivered on the solution.
It gives you a value based mentality. It surprises me, often surprises me how little some organizations think about the value of the app or the solution they're trying to solve. And I think if you can come at it from that focus, it makes life a lot easier down the line when you're trying to gather momentum. Bishop yourself, look, we set off with this particular problem. We said we'd do it in a time frame that was less than we'd done it before, which meant we would have saved X amount. We got it to market quicker, so opportunity costs we brought forward.
And then the application was accepted. Well, it worked functionally, it was working well and so on. So you end up with if you can set off with those objectives.
It's very measurable. In the technology we used before, it took us six months, and now it took us two months. That's four months of extra time of the product in the market, those kinds of things. So creating that understanding value and then assessing the points at which you deliver on it and seeing whether you have delivered is important. Yeah, and I guess it's also because, again, we said at the beginning, digital transformation as a whole is an ongoing thing. It's not a project, as you said, which usually you do have measurables for projects, but it's almost you've got to have sort of checkpoints along the way is probably a better way to discuss.
Yeah, I think you're right. Absolutely. It's got to be. Let's check in. It's using agile methodologies. Right.
It's the same kind of thing. At some point you got to come together and do a retrospective and look back at what went well, what didn't go so well, getting software out to business quickly, testing and learning better quality, all those kinds of things. So it's that holistic view and making sure that you're doing all of those things that ultimately will deliver the value. But back to what we said at the beginning. It's hard.
I'm not sitting here just saying that this is easy because it didn't it does require you to mobilize large parts of the organization behind it, but the rewards are on those companies that do it. Well, the rewards are incredible. Transformative. Yeah, exactly.
And I guess yeah, it's been a fantastic conversation. I think it'd be a really good time to sort of summarize some of our just some of the themes we've discussed. I guess key takeaways for people, if they're thinking of embarking on this journey, if you want to call it, they might be in the middle of it, they might be towards the end of it. But I guess what would your advice be? The key sort of pillars to sort of focus their attention on for successful? Yeah, I think you've got to get buy in, right? I think it's like anything in life, it's very difficult to push something like a digital transformation agenda without getting buy in. So first of all, I think it's clearly understanding what is it you want to try and achieve. You got to create some common language for talking about it so that everybody knows what you mean when you say we're transforming our business.
I think we have to be clear about whether transforming or optimizing. Are we using technology to just get better at what we do or are we actually taking on our company on a journey where we're going to explore new ways of doing things? So being clear with yourselves and the organization about what it is you want to do and both things can have significant impact on business. So I think clearly understanding that understanding from the value perspective, so ensuring that you know just exactly what you expect out of it from a business value point of view.
And then it's about winning hearts and minds. For me, it's about how do you get that into the organization in a way that you can bring people with you, that you can educate them. And I think if you did one thing, just bringing multiple disciplinary teams together, educating continuously, playing back the same narrative, ensuring that you're consistent with language and it's based in some form of identifiable business value, the technology aspects and actual making it happen will certainly be a lot easier for you as a business. Yeah. So I'd sort of start there.
You got to script the path, right? Like anything that's complex. What am I going to do on Monday? On Tuesday? On Wednesday? On Thursday? Right. You've got to go down to that level to make sure that you embark on a journey systematically and bring people. With you and that it's clear and focused.
Clear, focused, communicable. Because somebody's going to have to tell the story when if you're the CEO or the CTO, other people are going to have to tell the story. When you're not on the room, you can't be everywhere. So unless you can create that language and instill that into the organizational structure, it just gets diffused as it gets further down the organization and becomes less impactful and very difficult to manage. And again, that's what we were saying about it not just being something, it has to come from the top, but it does have to work its way down, become the lifeblood of the organization.
You could say it does. One area I would say though, is that it is quite easy to get started. I don't want to convey that you've got to spend years doing that. Right.
I think what you've got to do is to identify something that you can hang your hat on. What we typically do when we're with organizations back to the portfolio exercise, well, look, what are the things that we could do that would move the needle for you as a business that have been difficult to do in the past. They're not overly complex, but it's just too difficult to get going. So, for example, we want to integrate 15 systems all over the world and build something on top.
They're not the best use cases because they're just so mired in the technical challenges that they're often very difficult to do. So we try and identify something from the outset that could have high visibility, could have a high impact, probably is relatively complex in terms of integration capabilities. And we identify that project and then we use that project as the sort of poster child for transformation. So we say, okay, digital transformation for us in our world means we need to do more of this. Here's a great example of something we did. We did it in 30 days with four people.
It cost us X. And now that system, which we probably would have never got off the backlog before, is out in the wild. Customers using it, prospects are using it, employees are using it. And then you take that on a roadshow, you take that round the organization and you start to gather the momentum. It's interesting because I've been in the software development industry for many years, and typically when you say, I want you to be part of a software development project, people go they generally go wrong.
I don't want to be part of that. Right? But when you start to invest in the sort of process I just talked about, what happens is that they become a bit of a magnet. People want to be part of it because for the first time you're showing success in a short period of time, you're showing value. And then it might be like a snowball. It's almost a self fulfilling prophecy that if you do it properly, it gains momentum as you go.
And you can push that journey through. The organization easier and is it driven by maybe? Because again, referring back to Sensai, we talk about PDN champions within customers who drive, let's say, the rollout further and further and you're talking about within an organization, but we're talking about plants and things like that Senseye. But is that quite important, having champions? Yeah, we identify champions all the way through when engaging with customers who either have bought mendix or who haven't. Because without them very little happens. I mean, you'll get individual pockets of success, but they'll be relatively fragmented, they'll be disconnected from the transformational agenda. And whilst they're incredibly valuable, it's the sum of those things when you bring them together that helps you move the business forward.
So creating champions is important, actually identifying people who perhaps have never been involved in something like that. What I find incredible about mendix is we take people who've never built software before and they solve complex problems with mendix. And once the first time they do that and they see something go live that they were involved material in either building or participating in requirements gathering and testing and automation. So the light bulb goes on that all of a sudden, rather than suffering under the weight of the problems, I can actually be part of solving the problem.
And then champions emerge, they come out as part of the process. The question is how do you give them a sounding board? How do you get them in front of the right people? And the more you can push those champions and give them a platform at the executive level, the better it is. So execs need to sort of think about that. How do they give the opportunity for champions to be seen? Because there's nothing better than somebody who's had a problem, solved it and can now talk detailed about how they did it, what the solution looks like, what the value is. It's incredibly powerful.
So you're right, champions are very, very important. Yeah. And again, it feeds into what we said earlier about it's not just a customer thing, not just a vendor thing, it's working together.
Some of the things resonate again from a Senseye perspective where we're supporting the customer to provide the business or if they need to present internally to the vendors there to support. Yeah, we go to the extent of building into our platform this portfolio management where you can identify value. We'll push on the capabilities there to an ideation portal.
We'll give the ability for specific projects to showcase that project. So part of the platform should be that ability for you to showcase it without being in front of someone, but to least gather all the metrics and data together. But our role as the vendor is to make sure that there's an opportunity for those people to really shine and build careers and build brands off the back of it. I always find it quite humbling when you go to an organization, you find people who've never built software before, who now have taken on that challenge, solved it and wake up every day and build software and impact business with real value. It's great to see that kind of thing happening and getting the recognition and whether through promotion, absolute promotions, visibility, they're seen as a change agent, a leader. A leader. Yeah.
I wonder how many no disrespect, because from a pro developer perspective, what I'm clear here is that there's also a role for pro development in there, right? So for people who deeply understand software, deeply understand architecture, I think they have to be part of the process. They need to be part of this sort of melting pot of fusion teams because you need their expertise to help you make the right decisions. Architecturally, just putting a database together might be too difficult, but having pro developers who can then use technologies to create further capabilities that less experienced developers can use, so we believe that bringing ProDev and no developers together incredibly important. So there's also a springboard for professional developers, part of that. Because I wonder sometimes in that pro dev world, it's quite hard to shine because you're probably buried deeply in some large software development team somewhere.
And whilst the outcome may well be a successful project, it's probably a big team. Whereas if you look at a low code team, they're six to eight people, maybe ten is a big team, right? So there's an opportunity to shine in there and to showcase your skills against a specific deliverable and outcome. So champions do emerge very quickly from those environments and to use those.
So building a career is a great way to approach it with appendix and low code. I think you're right. I think organic is the right word, because if you try to trust this, you must do this. Then if it happens organic, they're using the tool and they're seeing success and they're being praised by their boss to get promoted, then it's like building the momentum, isn't it? Some people love that and some people don't, right? But plenty of people use our technology and they quietly go about their business and they add massive value.
There is that use it as a springboard. But from an executive perspective, in a business, finding those people, because they're the change agents, they're the people that make they're probably already making a difference in your business. They're probably
2023-09-11 07:13
