How Continental Replaced Lotus Notes and Domino with Low-Code
How Continental Replaced Lotus Notes and Domino with Low-Code by Joe Carroll
Most people know Continental for their tire business. But the automotive manufacturing company has evolved into so much more, now offering telematics, electric motors, automated driving technologies, and beyond. Today, Continental has over 241,000 employees across 573 locations worldwide.
With the expansion of their product line, Continental made a strategic decision to become more than a hardware manufacturer by evolving into an IT company that also provides software. Delivering services to their customers that leverage their software and hardware became a key goal for the organization. To do this, Continental decided to look closely at replacing Lotus Notes and Domino.
Drivers for change
One major driver for change within Continental was the need to adapt to ever-changing markets and environments with speed and innovation. Not only are Continental’s customers changing how they behave and interact with technology, but their employees’ expectations of how to build apps are changing, too.
Continental is beginning to see more and more people seeking technology to solve problems within the organization, while yearning to understand how to do it themselves. The company culture is moving toward a self-service environment when it comes to using, consuming, and building technology.
Before modernizing their processes, Continental’s time-to-market was one to three years — depending on the complexity of the technology. This lag was a major challenge and did not allow the flexibility necessary to adapt to change quickly. Not only did Continental lack the tools for enterprise application development and the capability to adopt and adapt to ever-changing environments, but they also lacked a culture for dealing with uncertainty and software imperfections.
A second driver for change was Continental’s reliance on Lotus Notes and Domino legacy applications. The IT team was responsible for developing, maintaining, and enhancing hundreds of applications they had running on Domino. As Sven Fleischer, Global Team Lead Finance IT at Continental, describes it, “it became a burden that [was] killing us softly.” Legacy modernization and a Lotus Notes replacement seemed inevitable.
After successfully migrating email and productivity tools to Office 365, they attempted to implement processes to allow for more agility in both network and culture, eventually aiding in the speed of development. This project addressed the culture and technology change but somehow left a void for all the Domino applications. This gap and the need to replace all of these applications drove Continental to find alternatives to Lotus Notes and Domino.
5 reasons to replace Lotus Notes and Domino
Fleischer’s decision to replace Lotus Notes and Domino came down to five reasons:
1. Latency and bandwidth
One application running on Domino experienced latency challenges in remote locations in Asia because of German hosting. Users had to purchase separate laptops and machinery because clicking a button in the application took around 10 minutes to execute. The application would often freeze, and people could not continue working. The entire process either slowed down or halted completely, causing severe challenges for the business and user experience.
Continental has a steady demand for new features that they want to implement. Still, with the technical debt accrued by the Domino applications, it became more and more difficult to add a simple feature.
Maintaining and enhancing those applications became very challenging. If they added one feature, they broke another 10 without knowing it, despite robust testing.
Continental wanted to gain speed in software development projects by building reusable components. With Domino and all the single-use code, it became nearly impossible to reuse what was already built.
Continental needs to ensure quality in the applications they build. This was not only challenging with Domino, but it also required 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 exactly a database, and Continental’s access to storage space within the applications was diminishing quickly. With more than 10 years of collected data in a given application, the Domino applications were quickly reaching the limit. The cycles for cleaning up the database became shorter and shorter, and the company was facing the need to archive and free up space, ultimately impacting Continental’s business process.
Domino may have been an acceptable solution when Continental was strictly a tire manufacturing company, but as the company grew the issues with Domino turned into significant obstacles. As a result, Continental’s corporate IT team — which is close to the business — put together a plan to modernize all of the company’s Domino applications.
Evaluating the alternatives
With a legacy modernization plan in place, the organization was on the cusp of a significant change — not only in technology but also in mindset and culture.
As they evaluated solutions, corporate IT realized that their technology stack lacked a general-purpose platform that enabled fast time-to-market. They knew they needed a fifth pillar alongside their existing ERP/CRM, Office 365/Sharepoint, Domain-specific apps, and custom code.
More specifically, Continental wanted a platform that:
- Is easy and fun to use and understand by business users
- Enables reusability with common protocols and structures
- Ensures quality of outcome
In his talk at a recent Mendix World, Fleischer explained the available options and why they were not a good fit for Continental:
After extensive research, Continental concluded that one technology solution would not work for every application, as many are built or used differently.
Reuse existing technologies
After realizing that a one-size-fits-all approach wouldn’t work, Continental tried to cluster the applications and technologies. They realized that some use cases were closely related to their systems of records, like SAP, where it made sense to use SAP as the back-end and Fiori as the front-end. However, speed-to-delivery and maintenance costs were prohibitive. If it’s not a core SAP process, it’s not a good fit for SAP.
Commercial-off-the-shelf (COTS) solutions
Some applications were better suited to a COTS solution. For instance, when the processes were specific to a domain or business case, or when they required complex business logic and more time to build. A COTS solution would allow Continental to purchase the exact product they needed instead of building something in-house or reusing a technology they already owned. However, no single off-the-shelf solution could satisfy their many requirements and use cases — even with all the domain-specific applications in Continental’s portfolio that shared a language.
If everything fails, you can always have a solution custom-built with .NET or any other traditional programming language, right? Sure, but this option is high cost and high effort. It’s not a solution that enables an organization to apply changes quickly. If IT has to write custom code, business users will continue to be left out of the development process and won’t understand a solution written in .NET.
Landing with low-code
After looking at the market and identifying the products and vendors that could fill their technology gap, Continental turned to low-code development.
Vendors were invited on-site to build an application and test different technologies against their requirements. Continental evaluated the low-code vendors on the following criteria:
- Ease of configuration
- How applications are built
- The amount of custom code or add-ons required
- How the data model is built and how the business logic is decided
- How well the technology covers the original requirements around user and access management, integrations, request and workflow management, automation, search, and monitoring and reporting
Continental chose Mendix because the low-code platform:
- Enabled collaboration between the business and IT
- Allowed them to build and iterate solutions quickly
- Made it possible to replace outdated processes with adaptable, automated workflows
A new app in just 12 weeks
Continental began by rebuilding a 300-story application, Electronic Capital Request, in just 12 weeks. Before Mendix, an initial rebuild process took more than a year. Not only did Continental accelerate the process significantly with Mendix, but they also dramatically improved the experience for end users.
The Electronic Capital Request app is a budget request and approval tool with 10,000 frequent users — that’s a throughput of at least 10,000 requests raised, approved, and handled in that application annually. Every year, the app sees around 20 gigabytes of file attachments being added within the application. Built on Domino architecture, the app very quickly reached its storage limit. But with Mendix, the app is limitless.
Shifting to Agile
Early in working with Mendix, Continental had learned the Agile methodology is key to delivering maximum value over time. Continental’s success within this project created an argument for implementing Agile throughout the company. They see tremendous room for improvement, especially in the rollout process which took longer to build than the app.
Continental has begun preparing for this change by assigning dedicated project teams alongside Mendix developers to ensure that speed and quality are up to standards.
What does the future hold?
Continental’s evolution is proof that every organization needs to become a software company to survive and thrive, and they plan to continue scaling.
Continental now has a team of internal Mendix developers that they expect will grow each year. As an Agile, low-code focused team, they’ll build parts of applications and entire applications themselves, and use Mendix as a platform for business users to specify what they need before they hand a project over to IT.
This blog post was originally published on May 10, 2019 and has been updated to include the most current information.