Productization of the SaaS Platform (Part 4 of 4)

Blog #1 in this series focuses on our journey

Blog #2 focuses on how the OpenLegacy Hub is the result of the journey

Blog #3 focuses on low code and no code support

The final blog in this series focuses on production. After realizing we could support load times and other things our customers need, we had to productize. Building native connectors on a scale was a challenge. We created an AWS Node.js Lambda generator (later also for Azure & GCP), using connectors and flow libraries, as native libraries.

We saw a gap in adding code entry points in Node.js (the core is still written in Kotlin (a cross-platform Java-compatible programming language compiled to native). So we wrote Javascript logic in an event triggered by Java. Nice challenge :)

We then researched .NET. In the past, we qualified out of many opportunities when C# was an enterprise’s only architecture. Yes, C# and Java are very similar but .NET shops call their libraries and want everything a C# code. Since we have all the connectors and the flow engine available, it should not be a big effort to consume it from C#.

We took the same route again as a node.js, entry point interoperability was challenging again, but we made it happen.

Now any orchestration done in the OL Hub can be enriched by the preferred generation language. We plan to add other languages in the future. This future proofs our low-code process.

The last key component to mention is the solution center. The solution center supports predefined contracts and backend modules (core banking, API specs as open banking for example), created by our content team.

A rich solution center will enable us to be an iPaaS player and ease integration with common SaaS products (e.g Salesforce) by predefining their APIs in the solution center. We also leverage the solution center as a repository for backend connectors, generators, and deployers plugins.

Now the true challenge began. Rollout and Adoption.

Our customer success (CS) teams over the past years became experts and highly independent. Now we have a SaaS platform with a CLI, flow engine, no-code, low-code generation. The biggest gap was the Java-generated code. Our CS team were skilled Java developers, and now we generated minimum code, and it’s much less Java.

We pitched internally, using the demo center, which was a big leap for PreSales and Training, and presented OL Hub in any prospect opportunity. Slowly our Sales & CS teams got engaged and comfortable with the new platform.

Demoing OL Hub is a big wow factor, especially when showing automation, UX, no-code, and deployments. Feel free to start your own 60-day free trial here.

New POCs started to come in, and existing clients started to try it. R&D responded quickly and handheld the first POCs. The results were fantastic.

Within six months, OL Hub became the primary platform in the company. The IDE is now an extension of OL Hub as the “full code” offering for highly customized projects. OL Hub is now in general release, with a very aggressive roadmap. It’s on its way to becoming the best enterprise integration platform.

I’m pretty sure I missed some of the other challenges we faced along the way, but overall, we are very proud of our R&D, Product, Support, QA, Demo, and CS teams who made it happen.