Are you struggling to resource projects that require specific technical knowledge? Continental understood they would not be able to resource their legacy migration work with custom development and needed to find a way for their IT team to move faster and release apps quickly for their enterprise. With an aggressive timeline to move apps built on Lotus Notes and Domino as those platforms approach end-of-life, Continental needed one platform that allowed them to address a wide variety of use cases.

In this episode of Make/Shift, hear from Sven Fleischer, Global IT Lead, as he discusses legacy modernization and how that effort lead to a groundswell of citizen development that has extended well beyond the initial use cases. Learn how IT program and application owners, developers and employees across the company are using low code to deliver business solutions.

Apps built on Mendix include an internal capital request workflow for approval processes, a mobile compliance app, and tracking for delivery, supplier and customer information. In addition to their expanding portfolio of use cases, Continental has also been able to tackle unique challenges during COVID-19, with an app enabling them to communicate with a newly-remote workforce, built in just 5 days.

/ Mark Manning /
Welcome to Make/Shift. Mark Manning here, customer evangelist at Mendix. We’re here to explore how your peers have adopted low-code, and the pain points they’ve addressed with the platform. We’ll take an authentic, unfiltered look at the solutions our customers are building to digitize their processes, to deliver much-needed solutions to market more quickly, and to cut down on the cost to develop.

Today we talk with Sven Fleischer, the global IT team lead at Continental and how his team tackled their end of life plans for Lotus and Domino, their methods of improving collaborations within his org, and finally, how Continental solved their unique communication challenges during the COVID-19 stay at home orders.

How’s it going, Sven?

/ Sven Fleischer /
Perfectly fine. Just had a lovely and sunny weekend.

/ Mark Manning /
Beautiful, beautiful, and can you share a little bit about who you are and your background?

/ Sven Fleischer /
Sure. So my name is Sven, Sven Fleischer. I’m based in Germany in Hanover, working for Continental IT, which is an automotive manufacturing company. Me, myself, I’m working in the IT space, started in HR, HR-IT, introducing and doing a couple of HR-related IT projects, then eventually moved onto to finance, into the finance space, and doing projects there. Eventually, we discovered the technology there. We started to use Mendix for development work that eventually cost or resulted in some reorganization. I moved into a new department, a new team that was formed that is now governing those, well, as we say, future strategic technologies and platforms. So that’s the team, that’s the area that I’m currently working in. So my background in general is business administration and computer science, and I’m with Conti since 2012.

/ Mark Manning /
Very cool stuff. Historically speaking, I think you mentioned you were in finance IT. Can you go into what you were tackling specifically as you worked for that?

/ Sven Fleischer /
So in finance, what we did with the projects and the applications that we build is primarily focusing on either global or local finance processes. So there’s some policies that we need to automate, some processes that need to be automated, stuff that is, in first place, not covered by large enterprise resource planning systems, like SAP or what else we employ. So there’s a lot of smaller side processes, sometimes even larger processes, where we use all sorts of different technologies.

So there’s a lot of projects that we do or that we did every year. There’s a lot of different technologies that we introduce every year. We tend to use technologies that serve a given purpose, but there’s really a lot of different applications and technologies that we eventually introduced into the company, into the finance IT space, and that we also have to keep up to date, that we have to maintain, and this is a bit of the struggle and a bit of the pain that we are coming from.

/ Mark Manning /
If I recall correctly at least, around the edges, sort of historically, finance IT used Lotus, Domino, those sorts of technologies. Can you go a little into, maybe, why they were used and sort of, as they approach end of life, what your thoughts were as you were trying to look for sort of the next thing?

/ Sven Fleischer /
Absolutely. So it’s actually, I mean, IBM Notes and Domino, we’re not just used in finance IT. That was something that we used as a messaging and collaboration system across the entire enterprise and the entire company. IT also used that as an application development platform, and there was maybe when you, I don’t know, go some decades back, there was probably what Mendix is today. So that’s a platform where you could, with reasonable effort in a short amount of time, could build an application that is automating some business process or supporting some business process.

That historically we have been utilizing heavily, not just within finance, finance IT, but within the company and IT in general. A couple of years back, we took a strategic decision to move from that IBM platform into a Microsoft ecosystem. So we transitioned already two years back from using Notes into using Outlook and Exchange for messaging and email in general and adopting more and more of the Microsoft Office 365 collaboration suite.

But what that did to our application landscape is that everything that was eventually built on IBM Notes, Domino as an application that I think to do with messaging itself was somehow left behind. We had for all of those applications, at least within finance IT, that we had under our control, we had to find a new home, a new technology where we can port those applications to.

For each application, eventually, we had to start that evaluation process over again and see what the best suiting technology is and then move or port that application onto that new technology. This, obviously, if you did it for one application, that is okay, maybe also for two or three, but then if you start doing that for five, ten, a hundred applications, that’s highly inefficient. Across the company, we have hundreds of Domino applications, and we have to be done by 2021. That’s when we’re going to switch off the last Domino server.

With that little time that we have, with those many applications and very limited resource and capacity, we needed a technology that does not just fit one or cater for one application, that eventually serves multiple applications and purposes, and where you can really gain some speed, where you can implement processes quickly and efficiently and release them into production. This is eventually how we started looking for alternatives to Domino and where we came across Mendix and then had a very successful headstart, I would say.

/ Mark Manning /
Certainly makes sense. Is there anything particularly that tipped you off to low-code? Would you say maybe it’s inertia and your team was comfortable with teams that sort of abstracted already, or was it some other motivator for you?

/ Sven Fleischer /
Until we started looking for a Domino replacement in general, we did not know that low-code exists. So we eventually came looking at certain domain-specific applications that you can get off the shelf and then just configure, and we liked that, because that in itself gives you a lot of speed already in your projects, but it’s obviously limited to that domain, to a certain process or area. Then on the other side, if nothing from the shelf fits, then you need to build something custom. The thing is there’s certain, well, downsides with custom development, and I think one of the biggest downsides for us is that as finance IT group, we are a bunch of project managers and application owners, but we are not developers.

So if we want to do something ourselves, if we want to make something ourselves, we need a technology that is easy for us to adopt, where we can easily build applications or automate processes without having to have that deep development experience in a given programming language or technology. This is eventually what we found and what we liked about that idea of low-code, no-code where exactly that is not required. That deep IT background is not required. You need to have a solid understanding, obviously, of your business processes and your business requirements. You need to have a good understanding of how web applications and applications in general work. That is sufficient, basically, to build those applications, to design those applications.

If some more specific, deep technical knowledge is required, like for interfacing with some backend systems or solving specific technical problems, then, very punctually, you can rely on some experts that solve those technical problems, but you don’t need a large group of developers, which we don’t have anyways, right? So that is how we came across low-code, and what we liked a lot about low-code is really enabling our IT team, our IT organization to move faster, to move quicker, to get more things done, and to do more things ourselves before eventually also providing technical means for resolving problems to our business organization.

But this was not our primary aim or focus. It was really getting something that we can move quickly with at a high pace, with a high speed, within the IT organization.

/ Mark Manning /
It sounds as if there are a couple of burning problems at least that had to be solved, but this also sort of served as a conveyance for sort of a grander ambition about how Continental develops. Am I right in at least editorializing there?

/ Sven Fleischer /
I mean, the target audience or the people that we were aiming at is all the application owners within IT. So the people that we have in mind is primarily our own IT organization. That is not a lot of IT developers. It’s project managers, It is application and service owners, and those people don’t have that deep IT background, because, historically, they have been responsible for many applications and a whole variety of different technologies. They can’t be as deep of an expert in each of those platforms.

So that’s where we wanted to provide a benefit to our IT organization and give them something in hand, which is easy for them to understand, easy for them to use. It’s easy for them to make something themselves and eventually also providing a new home for not just one, but multiple Domino applications. But not only that, I mean, historically, obviously, that is where we are coming from, replacing those Domino applications, but people quickly understood the benefit of that platform as well, and they figured that they can also automate and implement processes and applications that are not coming from a Domino application today, so which today don’t exist. They just simply realized the potential of that and eventually then picked a process that they never liked the way it currently or it ran in the past. They started thinking about an application that is making the process more efficient.

/ Mark Manning /
So transitioning a little bit here, the decision was made, the technology was brought onboard, and you had an initial slate of applications, at least, I imagine to prove that it worked, to test out a new way of working, to begin providing business value. Can you go through a few of the applications you’ve built so far and the impact that each are having on your organization?

/ Sven Fleischer /
Sure. So given the fact that we started all this, that low-code initiative in the finance space, the maturity applications that we’ve built so far is exactly in that area. So the biggest one that we started with is a capital request workflow, where all of our project managers worldwide, all of our plant managers worldwide, everybody that wants to spend money somewhere in either, I don’t know, doing a project, buying software, or building a new tire manufacturing plant. They all have to go through that process. They have to request for their money. They have to justify their investments, and eventually that is being approved in multiple stages. This is a fairly important process and a fairly important application. That is where we started from, and that was a very successful project.

Then the other applications were like what I mentioned earlier, were coming from that Domino replacement bucket, if you will, where we said, “Okay, we have a couple of Domino applications lined up here that we want to have replaced.” Now, we showed nicely and neatly what you can do in that context with low-code, with Mendix specifically, and then we started porting the next applications. We have an application that’s called Desto, which is short for delivery stop, where we track certain supplier or customer information, and eventually if the financials are degrading, health check is not looking so good anymore, we risk not getting our invoices paid, we have a process in there that’s then saying, “Okay, well, those companies will not get any goods delivered from us anymore.”

So that’s a fairly small, also request-based approval workflow, but it solved the problem that we didn’t have a good future technology to solve it with. Another application that we had is from the compliance and departmental space, where we usually, when we receive gifts from suppliers, from customers, or from somebody else, the question is always, “What can one individual accept? What’s allowed for them to accept? What is an appropriate gift? Where are the certain thresholds? Who do I need to ask in order to seek such an approval?”

But what they build is they wanted to build an application that answers all those questions, that people can use still on the mobile, so they wanted to make it mobile-ready and easy to handle, and they built it also fairly quickly, within a couple of weeks. Again, what you have there is a simple request form, where you capture the gifts that you have received, and then there’s some logic implemented in the application that checks, well, firstly, where does that request need to go to? Given the description and the details provided, is that something that qualifies for automatic approval, or does somebody else need to take a second look at that and then ask some questions back and then eventually manually approve?

Within a couple of days after go live already had hundreds of requests in it, which also nicely showed how quickly those applications and how … I mean, how quickly they are adopted, how well they are received and being used. But after a couple of months, also, we started building applications outside of the finance space, other divisions, the other divisions, the other departments, the other competence centers eventually also started looking into that technology, which is also important to understand that we cannot and we don’t want to enforce low-code and Mendix as a specific technology, top-down, in the organization. We want to give people a new technology and new option and alternative to all the other technologies that we have available in the company and make it, for them, easy to use so that they can adopt it. They can consider it and adopt it if they want to. But we don’t force it over them.

So the other divisions and competence center also slowly started looking into that eventually started one or the other project or prototype, and we now have one, two, three other applications and other spaces lined up that are soon to go live. It’s now just because of the corona crisis that the go lives were, well, passed or pushed back a little bit, because there’s obviously certain dependencies on people being on-site for trainings and stuff like that.

The maturity of applications still, the application that is live to date is from the finance space, is finance applications, but we’re also working on quality applications, on HR applications, on communication applications, and so on and so forth. So there’s a whole set of ideas, a whole range of ideas and applications that’s now slowly arising since the technology was introduced last year, and then hopefully we’ll also see more of those applications going live outside of the finance space shortly.

/ Mark Manning /
The whole concept of bottom-up adoption I think is sort of fascinating. It sort of reminds me, when I was over in Germany and speaking with your team last. I recall that you’d put together an application with I think what Gartner would call a citizen developer, at least, someone who was an analyst, who had some expertise and process related to materials, if I recall correctly. Could you go a little more into that?

/ Sven Fleischer /
Sure. Yep. That’s true. So although I said initially that the idea of having citizen developers is not our primary goal or not what we are striving for, but, obviously, if our business department, if they are IT-savvy and themselves, they want to have some technology that they can use to solve their problems, then we make it available to them.

So we had that one project request coming from the purchasing space, where they wanted to automate also an approval process for sinking the materials and the master data around materials across all the different SAP systems that we have worldwide. So that’s a fairly complex process, and there indeed, from purchasing, we had a business analyst that had fairly good IT understanding and had capacity and was willing to dig deeper into that new technology, into Mendix, and then eventually also became part of the project team that built the application. So that lady also had a relevant share in building and successfully completing that project, and she eventually also transitioned from that business analyst position into our IT team, where she’s now being responsible for some of the Mendix applications that we’ve built as well.

/ Mark Manning /
I guess an open question, too, is in a lot of our conversations out there, it’s just what do you do, project-wise, with someone who’s a little less technical? So what would you say your role in the project is? I know there’s sort of meaningful contributions, but what part did she play? What was that collaboration with IT like? How do you manage that collaboration, that contribution to a project?

/ Sven Fleischer /
So, usually, if you look at IT projects like this, we usually say they have a dual project management role. So we always have a project manager from the business side, and we have a project manager from the IT side. They form one team, one function, one project management function, if you will. One of their tasks is to involve the relevant stakeholders on the business and on the IT side and making sure that IT can properly speak with business and vice versa. The lady in that purchasing project that we were just talking about, she was the business project manager at the time. So she eventually facilitated the communication with business, but then also towards channel or translate the requirements from business to IT.

But she also had a good IT understanding, and she was keen on building some IT stuff herself, and that’s when we said, “Oh, yeah. Okay. Then let’s take a look at that. We don’t want to hide it from you. Actually, we want to enable you and provide it to you as well, that if you’re interested, you can use it yourself.” That’s what we did, and she really liked that. I think that was also beneficial for the project team, because the application itself was not built by the usual suspects on the IT side, but eventually she also could contribute successfully from a business role into that project, which naturally, if you look at how we define projects, how we define the different roles on the business and the IT side, would not be one of her responsibilities, but it worked out perfectly fine.

/ Mark Manning /
It’s just sort of interesting. The competency with low-code started with the most practical reasons, that there were end of life concerns with Lotus and Domino. There’s finance applications that we need to modernize and move over to a modern stack. You sort of have this burgeoning practice of citizen development and sort of a maker culture that maybe from outside in, we wouldn’t expect that to happen so quickly. Could you talk about that culture that’s beginning to be created, at least, that bottom-up sort of groundswell?

/ Sven Fleischer /
So the idea of establishing a maker club, so when we saw the first applications successfully coming to an end, the interest of people, not only from the IT space, but also from business people arising slowly, we said that eventually it makes sense to establish the platform, a format where those people, beyond their projects and applications and their day-to-day job and responsibilities, can get together and work on something greater that contributes to the technology, to the platform, and eventually also produces something relevant for the people that want to adopt the technology.

At least within Continental and maybe within larger enterprises in the automotive space, that is maybe not an unusual concept. We did that a couple of decades ago in the research and development space as well, where it just had a different name, but where experts from different domains were pulled together to look from different perspectives on one problem or multiple problems and solve that in a joint effort.

This is, I think, the best that we can compare it to when we talk about that make club and that maker culture. So we want to do the same thing within the IT space, together with our business people and obviously also with our IT experts. The only prerequisite that we defined for people to join that club is that they had some exposure to Mendix and to low-code before. So either they have been on a training, so they have some basic knowledge about how to build applications, or they’ve had their first application project successfully done so that they also know what we are talking about and that they can also contribute something to that maker club.

We had a couple of meetings so far. We kicked that off in December last year. We had a couple of meetings since then, where we identified whole lots of ideas and things that the team, that club can work on. It’s now just a bit slowed down because of the crisis, and some of the activities obviously require people to come together and work on those items on-site. But generally, it was really well received, and this concept is now also being adopted for other technologies. So it’s not limited to low-code and to Mendix, but we’re also adopting and transferring that concept to two completely unrelated areas. That’s, I think, also nice to see that something that stemmed from that, well, Domino replacement, low-code introduction, is now also being adopted in some completely different areas, and it’s also creating benefit there. So that’s also nice for us to see.

/ Mark Manning /
It’s funny, you might think for an industrial organization that’s sort of process-driven and everything that that citizen development may not come naturally. But if you think about engineering more broadly and how you collaborate and experiment and create great products, it sort of rhymes, and why not IT I guess?

/ Sven Fleischer /
Good question. So in R&D maybe in the past, it was the same, and then they tore down those walls and started working together. At least if I look at our businesses and at our IT organization within group functions, then we are still … Well, everybody is working in his own little or big area with very little influence between those areas. But I think it’s clear that this is not very efficient and that this is not a good way forward, and we need to also break up those structures and more network and collaborate. Otherwise, we will not get more capacity. We will not get more resource to solve all the problems that are coming at a higher pace and flying at us. So we need to find different ways of working together, and I think adopting a concept like that is just a nice way of eventually getting there.

/ Mark Manning /
It certainly has some transformative potential, if it sort of catches fire. There was a recent project that your team tackled that’s coping with how you communicate with your employees during the COVID crisis. Could you go into sort of what motivated that beyond, obviously, what’s occurring out there and how you went about solving it?

/ Sven Fleischer /
So in order to understand it, I think it’s important to know that, as a manufacturing company, we have a lot of people on the shop floor that, well, don’t have a desk. They don’t have a laptop. They don’t have a company phone or a device of any other sort. For them, it’s kind of difficult to get access to the information that we usually spread across the different communication and collaboration channels within the company. When the corona crisis started, we also started considering certain hygiene measures and eventually also thought about shutting down or locking down certain production facilities.

We realized, again, that it’s kind of difficult to reach the people in production on the shop floor. Once we started sending people home, we also had a problem that we could not reach them anymore, telling them, “Well, now is the time to come back” or “You need to be back next week, next month,” whatever. Because it was all in the crisis, we had to find something really, really quickly, and we had to solve the technical problems and also some license problems, and we had to become creative.

What we figured is that, “Well, we have Mendix as a platform, and we can build an application with very limited effort that serves exactly that purpose that can be used to communicate with the office workers alike and also with shop floor workers, and they do not need a company device. They do not need a company mobile phone. They do not need a company laptop, and they certainly don’t need access to Continental’s infrastructure, licenses, or whatnot.”

So, we thought about how we can do that, and we figured that it’s best comparable with a news ticker that you also find for all sorts of other purposes. We wanted to build a news ticker for communicating in times of crisis, but with that news ticker now being built within only five days, it’s actually not limited to that, and we can also and we plan to use it also beyond the crisis, obviously, now that it’s there.

Initially, the plan was to use that only within Germany, but once it was released and to production, the other countries started knocking on our door and were asking about, “Well, we need” … They have the same. I mean, the other countries obviously have the same problem that we have in Germany. They can’t reach the people on the shop floor, and they also want to adopt that application now. So all of a sudden, we may, with that application, reach from Germany to everybody worldwide, which is … It was a big success in first place, and I think that that success will just continue like that.

/ Mark Manning /
Tens of thousands of employees in Germany and more beyond the globe, would you say this is the first time that this sort of communication paradigm has been started at Continental? It sounds like a first.

/ Sven Fleischer /
At least that was the first time that we really took a conscious decision, a decision, and also where we build something that can facilitate that type of communication with IT means. So previously, we were always struggling with, I don’t know, security, with our infrastructure, with our devices, with certain licenses and stuff that prevented communication measures and IT means from reaching also the people on the shop floor.

So now, given the crisis, given the high pressure, given the need that we had to communicate really quickly with everybody, a lot of those or some of those constraints were let go, were relaxed, and we could think about other technical solutions and options that we could not think about before. Eventually, we did not have those solutions or suitable platforms and technologies before.

So with the fact that end of last year, we switched to the enterprise level of using Mendix, I think that was actually a prerequisite. It was important for a use-case like that that we don’t have any limitations on the number of people that would use an application like that. So with this put in place end of last year, we were in a position to really act fast now. So when that request came in, we took one day to understand the requirements and take a couple of decisions. Then the next day, we hired somebody to build the application, and only three or four days later, we had that thing available for testing and rolled that out a day later. So that was really, really, really fast.

/ Mark Manning /
That’s a remarkable level of responsiveness.

/ Sven Fleischer /
Absolutely.

/ Mark Manning /
I think that wraps it for us. Sven, thank you very, very much for your time on this. It’s a fascinating story, and we can’t wait to see what’s next.

/ Sven Fleischer /
You’re welcome.

/ Mark Manning /
Thanks for listening, and be sure to check out Mendix.com/MakeShift to subscribe and stay updated with our latest episodes.