How Continental swapped Lotus Notes and Domino for low-code
Mendix World 2019 featured over 20 stories of organizations implementing Mendix. One such story was told by Sven Fleischer, Global Team Lead Finance IT, at Continental. Most people know Continental for their tire business. However, their organization has evolved over time to become a multi-national automotive manufacturing company with 240K employees worldwide, 44 billion in sales in 2017, and 554 sites across the globe. Beyond just their tire business, they now offer any type of machinery that cars need, from the engine to the electronics, to the software that runs those electronics.
Continental made a strategic decision to not just be a pure hardware manufacturer, but to also evolve into an IT company that provides the software on top of that hardware. To take it one step further, a key strategy for the organization is to be able to provide services to their customers that leverage both their software and hardware.
This company evolution goes to show that every organization needs to become a software company to survive and thrive.
In his presentation at Mendix World, Sven detailed Continental’s journey to becoming a software company and migrating away from Lotus Notes/Domino legacy apps and traditional development methods towards an agile methodology using low-code.
A driver for change
One major driver for change within Continental was the need to adapt to ever-changing markets and environments with speed and new ways of doing things. Not only are Continental’s customers changing how they behave and interact with technology, but their internal employees’ expectations of how to build apps are changing, too.
Within the organization, they are beginning to see more and more people seeking technology to solve problems and yearning to understand how to do it themselves. The culture of the organization is moving towards a self-service environment not just in using and consuming technology, but in building it as well.
Gaining speed requires change; change of culture, change of behavior, change of technology.
Until now, Continental’s time-to-market was one to three years, depending on the complexity of the technology, to go from idea to rolling out a solution for clients. This lag was a major challenge for them and did not allow the organization to be flexible enough to quickly adapt to change. Not only was Continental lacking the tools that would provide them with the speed and capability to adopt and adapt to ever-changing environments, but they also lacked the culture that allows for dealing with uncertainty and the imperfection that lies within software.
We were lacking the tools that would provide us the speed and capability to adopt and adapt to ever-changing environments.
A second driver for change was Continental’s challenges as heavy users of Lotus Notes and Domino legacy applications. As Sven describes it, “it became a burden that is killing us softly.”
With the couple of hundreds of applications, they have running on Domino, the major burden was not only developing those apps but also maintaining and enhancing them. After moving from Lotus Notes to Office 365, they attempted to introduce a new working style that would allow for more agility in both network and culture that would eventually aid in the speed of development. The project that they completed to address this culture and technology change somehow left a void for all the Domino applications. This gap and the need to replace all of these applications drove Continental to find Mendix.
Why not just stick with Domino? Here are 5 reasons:
Fleischer discussed at length the issues that arose when using Domino as their primary development tool. He broke it down into five reasons.
- Latency and bandwidth
One application that was running on Domino was facing latency challenges in remote locations in Asia because of German hosting. Therefore, users had to purchase separate laptops and machinery because clicking a button in that application took around 10 minutes. The application would sometimes freeze, and people could not continue working. This caused the entire process of work to either slow down or halt completely, causing severe challenges for their business and user experience.
Continental has steady demand for new features that they want to implement, but, with the Domino applications and the complexity that they have gained over time, it became more and more difficult for them to add a simple feature. Maintaining and enhancing those applications became very challenging, and they would run into issues where if they added one feature, they broke another 10 features without knowing it, despite all the testing.
Continental wanted to gain speed in software development projects by building reusable components. With Domino and all the code developed, it is very challenging to reuse the things you have already built.
It is important for Continental to ensure quality in the applications they build. This is not only challenging with Domino, but it also requires an immense amount of effort and investment.
When adding features to one application, it took more than a year just to get those features tested, identify bugs, fix and repeat until the quality was where it needed to be.
Domino is not a database in the relational sense, and the storage within the applications was becoming limited. With over 10 years of collected data in a given application, the storage space was reaching its limit. The cycles for cleaning up the database have become shorter and shorter, and the company is facing the need to archive and free up space, ultimately impacting Continental’s business process.
It became clear to the organization that, while Domino may have been a sufficient solution while they were a tires manufacturing company, as the company has grown, the issues with Domino became significant obstacles that they needed to address.
Who is driving the change
With the need to modernize all of the company’s Domino applications by 2021, it became evident that the organization was about to undergo a significant change, not only in technology but in mindset and culture as well. This change has so far been driven by Corporate IT, and Sven explained that this is especially important because they are closer to the business.
As they were evaluating solutions, the Corporate IT organization came to realize that their technology stack was lacking a general-purpose platform that allows for fast time-to-market. They knew they needed a fifth pillar alongside their already existing ERP/CRM, Office 365/Sharepoint, Domain-specific apps, and custom code. The requirements of the new technology they would add into their stack were:
- it had to be easy to use and understand by business users,
- it had to be fun to use,
- it needed to enable reusability with common protocols and structures,
- it needed to ensure quality of outcome.
Why low-code and why Mendix?
Continental had an ad-hoc process of specifying requirements, and the requirements were created in a way that the business did not comprehend. They knew they needed one platform for requirements through deployment, and it was also critical to enable communication with the business.
Continental evaluated many options but ultimately decided on Mendix as the solution to the gap in their technology stack. Sven reviewed each of the options they evaluated and why they chose not to go with them:
One of the findings that they had is that there will not be a one-size-fits-all approach. There isn’t one single technology that would work for all applications that they have, because those applications are quite diverse in how they are built and how they are used.
- Re-use existing technologies
After realizing that a one-size-fits-all approach wouldn’t work, Continental tried to cluster the applications and technologies that they have in their stack. They realized that there were some use cases that were closely related to their systems of records, like SAP, where it could make sense to use SAP as the back-end and Fiori as the front-end. On the surface, this solution does the same thing, but the quality is low. Performance is ok, but speed to delivery and maintenance costs are not optimal. If it’s not a core SAP process, it’s not a good fit for SAP.
- Off the shelf
There were some applications that were better suited to buying something off the shelf, where processes are specific to a certain domain, to a certain business use case, which have fairly complex business logic and are medium effort to build or configure. The idea is to take a product that is addressing exactly that need, as opposed to building something themselves or just trying to re-use an existing technology. There are many domain-specific applications in Continental’s portfolio, where there’s enough justification to basically have this application sit there beside all the other technologies. But this solution wouldn’t cover all of their use cases and examples.
- Custom build
And then if everything fails, you can always have it custom built with .NET or any other programming language. But the issue with this is that its high effort, and it’s not a solution that enables the organization to apply changes quickly and rapidly, similar issues that Continental currently faces with Lotus Notes. Another concern with this method is that by continuing to write custom code, business users will continue to be left out of the development process and won’t be able to understand a solution written in .NET.
Landing with Mendix
After looking at the market and trying to identify the technologies, the products and the vendors that could fill their technology gap, they turned to low-code development as the solution and invited vendors on site to build an application in order to evaluate how the technologies stood up to their requirements.
And after evaluating low-code vendors on things like:
- how applications are built,
- ease of configuration,
- the amount of custom code or required add-ons you need to eventually purchase,
- how well the technology covers the original requirements around user and access management, integrations, request and workflow management, automation, search, monitoring and reporting, and
- how the data model is built, how the business logic is decided,
Continental chose Mendix.
What they built
Continental started with Mendix in September of 2018 and began by rebuilding a 400-story application, Electronic Capital Request, in just 12 weeks. The app is a budget request and approval tool that has 10,000 frequent users, which is a throughput of at least 10,000 requests per year that are being raised, approved and handled in that application. Every year, the app sees around 20 Gigabytes of file attachments being added within the application. As you can imagine, when the app was built on the Domino architecture, it very quickly reached its storage limit.
Prior to Mendix, an initial rebuild process took more than a year. Not only did Continental speed up the process significantly with Mendix, but they also dramatically improved the user experience for end users.
Early in the process of working with Mendix, Continental has learned the agile methodology is key to success and delivering maximum value over time. Continental’s success with agile within this project opened the doors for discussion around implementing the methodology across the entire company. They see tremendous room for improvement especially in the rollout process, which took longer than to build the app itself.
One way they are preparing for this change is to have dedicated project teams alongside the Mendix developers in order to ensure the speed and quality is up to standards.
We have the Ferrari waiting in the garage, but we can’t drive it out because the roads aren’t ready yet.
Continental is currently in the process of adopting the Mendix Digital Execution practice, which guides organizations through the start, structure and scale of app development, piloting an app development project, setting structure around it, and scaling it out.
Continental has a goal that by the end of the year, they will have a solid structure in place with a formalized team and strategy. With their next platform project, they aim to build a capability team and build structure, process, resources, and to establish guidelines to follow for the projects to come. They have currently built up a team of internal Mendix developers that they expect to grow each year. They are also planning to create 2-5 pilot apps that will show success with the new agile way of working and fast results, which will help enable the organization to move towards a more agile way of working and will highlight the need for organizational change even more.
The goal for the organization is to be in a position to scale in 2020 and 21, and to continue to get closer and closer to the business, where they are not just another customer, but where they can enable the business to build parts of their applications themselves, build the entire application themselves, or at least use Mendix as a platform to specify what they need before they hand it over to IT.