Low-Code: Why It’s No Longer Just an IT Tool

At Siemens’ RealizeLive 2024 event, several examples were shown about how manufacturers can use Mendix to access data from Teamcenter (Siemens’ product lifecycle management software). Beyond use of Mendix with Siemens software, how are you seeing low-code apps being developed for manufacturing operations and engineering activities? 

 

With Mendix you can build tailored application experiences for very specific roles and users. The use cases with our clients show that there's a big variety of applications being developed. Sometimes it’s things like speeding up a certain operational task like quality management, where somebody wants an application to be able to quickly record defects on parts so that if they need to be reworked, there's documentation as to what the rework items are that need to be dealt with. But I’ve also seen applications for a shift leader to be able to see in the morning in real time who showed up to work, or to quickly reschedule who needs to be at which station.

 

Another important aspect is Mendix’s connectivity to core systems. We’ve obviously been focused on Siemens digital twin solutions, but we’re also seeing customers connect Mendix to other tools, like MES (manufacturing execution system). Jabil (a global contract manufacturer), for example, has built a series of Linux applications on top of their homegrown MES. This is an example of where customers who may not be ready to start upgrading their systems to new technology levels are, instead, layering Mendix on top to update the functionality. At Jabil, they've kept their core MES system, but then they built a series of apps on top of it with Mendix to provide a much more modern experience for their users. 

 

In logistics operations, there's typically an interaction between the logistics system and the scheduling and manufacturing execution systems. For users who want to have blended views where, if you're in manufacturing operations, you want to see if you need more material for a specific production run, you can see if there is enough of that material available so that you can plan ahead. This gives a manufacturing operator a view into the logistics system and, based on the schedule that they're running out of—for example, SAP— they can get this composite view where, otherwise, they’d get siloed views. 

 

So, with Mendix, you can bring these data sources together which is particularly helpful with legacy systems to not only provide more applications but also give the interface with those legacy systems a fresh look and feel.

 

It seems like a lot of the focus on Mendix has been on its low-code capabilities and how that can democratize access to data, but it also seems like you’re also focused on creating customizable user interfaces to all these legacy systems or new data sources to create user experiences for different personas. Is that correct?

 

Yes, that’s in the right direction but I would say it's not just the user interface (UI) aspect. When you think about a Mendix application, it has all the major components you would expect in an app. So, when you build a Mendix application, there's a UI, which is the first layer. The second layer is the business logic and the third layer is data persistency and data connectivity. So, when you build a Mendix application, you can choose how much of each aspect you need. When it comes to modernization of legacy systems, it’s mostly about the UI. But maybe you want to inject some new logic into the application. For example, in quality management, if a user takes a picture of a part, they might want to rework the picture a little bit before submitting it for issue tracking. With Mendix, you can build full-fledged applications [for detailed operations] or just use a few layers needed to modernize legacy systems.

 

Who's really using Mendix typically? Is it still the IT group even though it's more than an IT tool or are more operations and engineering people beginning to use it?

 

It's a collaboration and to reflect that we came up with a term for this called a fusion team. What a fusion team means is that it’s not just used by IT in a silo to build an application. The interesting thing about low-code is that business stakeholders can participate in building the apps too. What we typically see is IT owns the tool. So, access to Mendix is owned by IT, but building applications is very democratized. For example, I was working with a client in Germany where the logistics team was working shoulder to shoulder with a couple of representatives from IT to build 20 to 30 applications. That shows the power of Mendix in that it facilitates that kind of collaboration. There are places where IT would still do some heavy lifting. In this case in Germany, they needed an integration to their legacy logistics system, and that's not something someone on the business side of the operation would do themselves. Here, IT made sure the connectivity to the logistic system is in place. But the nice thing is that, once that’s established, it becomes reusable for building other apps. And that's what low code is about—once the operations side has IT set what’s needed, they can be on their own to build apps for their day-to-day needs. It's not like the traditional way of business going to IT with hundreds of pages of requirements and then leaning back to see what happens.

 

Since these apps can be developed by anybody, even though IT owns it, how do these apps get verified before they're instantiated for use?

 

If you look at the Mendix platform, there are state gates where you start in development, then you go into pre-production and then into production. And IT is typically in charge of this to determine if this application uses the right connectivity, if the data model is what it should be or if the user interface is right. Then there's an add-on module in Mendix called QSM (quality and security management). With clients that go beyond 50 applications, QSM becomes the key. What this module does is run quality control checks on your apps. It looks at how your application is structured to determine if your data model is structured correctly. More importantly, it can tell if there are vulnerabilities. For example, are there holes in how users get access to the app? That's why we have those add-on capabilities in the Mendix platform for users building apps to make sure that it's easy for them while keeping the applications secure. 

 

Are you seeing typical types of apps being developed in industry?

 

Yes, there are patterns and that's why we started building templates out of these. When you visit the Mendix marketplace, you’ll see that we've templatized a lot of the use cases that we see with our clients so that other businesses can reuse it. A good example is a plan for every part, which is a typical use in manufacturing pre-production where you figure out if you have all the data needed to successfully produce a part. It’s a typical practice across all manufacturing industries. So that’s why we made a template for it that’s about 80% complete. So, as a manufacturer, you simply pull that template out of the marketplace and you can tweak it so that it fits exactly with what you're looking to do. Other typical use cases for templates are OEE (overall equipment effectiveness) and quality management control. About two years ago, Mendix didn’t have that level of industry-specific content. But we're much further along with that now in terms of core platform capabilities. It helps our clients a great deal because if you can give them these little starter kits with four or five use cases, it’s way easier for them to get started.