Our Journey to Transform OL OnPrem into a SaaS Platform (Part 1 of 4)

The end of the year is always a nice opportunity to summarize.
I looked back and wrote this blog series. It will be released bi-weekly and be a 4 part series.

When we started OpenLegacy, it was all about the developer.
We built an integration framework Java developers would love to use, leveraging the Spring framework.

So we built a product that modeled legacy backends automatically, using auto-generated Java SDKs (software development kits), and enabled building simple APIs on top, all with a powerful Eclipse plugin. Point and click experiences generating standard and flexible Java/Spring code, with easy deployment as microservices exposing REST, SOAP, Kafka, or other interfaces.

The sales cycle was long since we had to sell the value to the development team first and then explain the need to management. But we managed to penetrate tier-1 financial enterprises and other industries. Once everything is set up, clients love our platform.

We had a modest R&D team, and responded to opportunities and client requests, and slowly but surely enhanced the platform.

Following a large investment round at the end of 2018, we set a new goal: to build a SaaS solution.

We ramped up the team since 8 R&D engineers were no longer sufficient to actively build a SaaS product. We thought about how to enhance the team:

• A full-time R&D manager, to build and grow the team.
• A chief architect to focus our efforts
• Product managers for better planning and work with UI/UX teams.

Lior, the R&D manager, joined us, with vast SaaS, Java, and DevOps experience. Lior started building five different teams, instead of the existing two, focusing on building the OL Hub and maintaining the IDE. The product team responds to lots of product enhancements and builds connectors on a regular basis.

Tom moved from a team leader to be a full-time architect. He focuses on refactoring the platform. We also brought in experienced product managers who helped focus our product planning efforts.

But still, the value of a SaaS platform in the legacy integration space was not so clear. The biggest problem was access to the legacy. Easy SaaS onboarding isn’t possible if a client can’t connect to their backend without setting up a secure connection, which requires security approvals.

Other problems we wanted to solve in designing our new SaaS platform included how to:

• Keep (and improve) the DNA of the OpenLegacy platform of high flexibility in development, security, deployment in highly regulated and slow-moving enterprises
• Maintain existing runtime connectors & IDE stability
• Provide a first-class UX for our users
• Enable full DevOps automation from backend transactions to deployed APIs
• Minimize the onboarding & setup so “citizen” developers can leverage the platform
• Use predefined APIs and common backends artifacts
• Enable non-Java developers to use OpenLegacy
• Support for a variety of new technologies (serverless, Kafka, etc) and ongoing demand for new connectors, without affecting the platform installation
• Let clients manage dependencies between their APIs and backend systems
• Create complex integration scenarios without coding
• Simplify our migration process with a high level of backward compatibility
• Add more value in integration based on APIs, web services, and DB queries
• Let enterprise clients install the platform easily either in their on-prem environment or their preferred cloud platform
• Create reverse APIs use cases, cases that start in the backend, and invoke an open system (REST/Kafka/SOAP/DB).

The next blog in our series will show how we achieved these results by building the OL Hub.