How Continental Swapped Lotus Notes and Domino for Low-Code
How Continental Swapped Lotus Notes and Domino for Low-Code by Danielle Goodman
Most people know Continental for their tire business. However, the organization has evolved to become a multinational automotive manufacturing company with 241K employees, $53 billion in sales in 2019, and 573 locations worldwide. 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 be more than a hardware manufacturer by evolving into an IT company that provides the software on top of that hardware. Delivering services to their customers that leverage their software and hardware became a key goal for the organization. To do this, Continental decided it had to look closely at a Domino and Lotus Notes migration.
Continental’s evolution is proof that every organization needs to become a software company to survive and thrive.
In his presentation at Mendix World 2019, Sven Fleischer, Global Team Lead Finance IT at Continental, details the enterprise’s process modernization. Sven discusses how the enterprise migrated away from Lotus Notes/Domino legacy apps and traditional development methods towards an agile methodology using low-code—and became a software company in the process.
From Domino to 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 innovation. 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.
Continental is beginning to see more and more people seeking technology to solve problems within the organization and yearning to understand how to do it themselves. The company culture is moving towards a self-service environment in using and consuming technology, as well as building it.
Gaining speed requires change; change of culture, change of behavior, change of technology.
Before modernizing their processes, Continental’s time-to-market was one-to-three years—depending on the complexity of the technology—to go from idea to deployment. This lag was a major challenge for them and did not allow for the flexibility necessary to adapt to change quickly. Not only did Continental lack the tools for rapid application development and the capability to adopt and adapt to ever-changing environments, but they also lacked a culture that allows for dealing with uncertainty and software imperfections.
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.” A Lotus Notes replacement seemed likely.
Continental’s IT team was responsible for developing as well as maintaining and enhancing the hundreds of applications they had running on Domino. After a successful e-mail and productivity tools migration to Office 365, they attempted to introduce a new working style that would 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 a Domino migration tool. They found Mendix.
Why not just stick with Domino? Here are 5 reasons:
In Fleischer’s talk at Mendix World 2019, he discussed the issues that arose when using Domino as their primary development tool. He broke Continental’s decision to migrate away from Domino down into five reasons.
1. Latency and bandwidth
One application running on Domino was facing latency challenges in remote locations in Asia because of German hosting. Users had to purchase separate laptops and machinery because clicking a button in that application took around 10 minutes to execute. The application would sometimes freeze, and people could not continue working. The entire process either slow down or halt completely, causing severe challenges for their 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 ten 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 single-use code developed, it became challenging to reuse what was already built.
Continental needs to ensure quality in the applications they build. This requirement 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 a database in the relational sense, and Continential’s access to storage space within the applications was diminishing quickly. With more than ten years of collected data in a given application, the Domino applications were 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 before when Continental was strictly a tire manufacturing company, but as the company grew, the issues with Domino became 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 by 2021.
Who is driving the change
With a process 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 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:
- Must be easy to use and understand by business users,
- Must be fun to use,
- Must enable reusability with common protocols and structures,
- Must ensure quality of outcome.
Why low-code and why Mendix?
Continental had an ad-hoc process of specifying requirements, creating requirements 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 their technology stack gap problem. In his talk at Mendix World, Sven reviewed the options they evaluated and why they chose not to go with each:
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.
- Off the shelf
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.
- Custom build
If everything fails, you can always have a solution custom-built with .NET or any other programming language, right? This option is high-effort. It’s not a solution that enables the organization to apply changes quickly and rapidly. Also, 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 Mendix
After looking at the market and identifying the products and vendors that could fill their technology gap, Continental turned to low-code development as their solution. They invited vendors on-site to build an application to test different technologies against their requirements.
Continental evaluated low-code vendors on the following criteria:
- How applications are built
- Ease of configuration
- Amount of custom code or required add-ons required
- How well the technology covers the original requirements around user and access management, integrations, request and workflow management, automation, search, and monitoring and reporting
- How the data model is built and how the business logic is decided
Continental chose Mendix because it enabled collaboration between the business and IT, allowed them to build and iterate solutions quickly, and made it possible to replace outdated processes with adaptable, automated workflows.
What Continental 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 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.
Before 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 user experience for end-users.
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 the Agile Methodology 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 the Mendix developers to ensure the speed and quality are 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 is also planning to have a formalized team and strategy by the end of the year. With their next platform project, they aim to build a capability team to help create structure, process, resources, and to establish guidelines for projects to come.
Recently, Continental created a team of internal Mendix developers that they expect to grow each year. They are also planning to develop 2-5 pilot apps to show the fast results of this new agile way of working.
Continental will continue scaling in 2021. They’ll also continue to get closer and closer to the business—to build parts of their applications themselves, build the entire application themselves, and to use Mendix as a platform for business users to specify what they need before they hand a project over to IT.
This post has been updated. It was originally published on May 10, 2019.