Extending an enterprise resource planning (ERP) solution in a low-code/no-code environment has evolved significantly in the past decade. Before multi-tenant cloud, companies had the freedom to build whatever they wanted, in any manner they saw fit, because they were responsible only for their own system. If something ran too slow or too long, organizations could add more memory. Furthermore, if something held too much history data, they could go buy more space. However, with the evolution of SaaS solutions where your ERP is one of many in a shared space (think a tenant in condominium complex), being able to "do what you want" is no longer an option.
More than ever, low-code/no-code environments need to ensure that the process by which you build an extension will run performant to maximize the resources allocated to you as a tenant and not impact any other tenants in your SaaS environment. Those tools also need to cater to everyone from citizen developers to professional developers.
So how do you know if your framework is built with those ends in mind? Let's start by defining what makes a successful extension. First, it needs to solve a particular business need. This could be as simple as mashing up data from various systems of record, all the way to complex modules that require tables, forms, business logic, and could impact how the ERP processes information. Second, whatever the solution is, that uniqueness must not sacrifice upgradability of the ERP. Third, it must accommodate various authors. This means, extensions can come from various sources like the software vendor, partners, and even customers. All these sources need to work in harmony with the ERP.
Achieving Extension Goals: What to Look For
Now, let's explore what you should look for in a framework to achieve your extension goals. When you build an extension, the developer should not have to worry about whether their strategy will work in a SaaS environment. The framework should be configured to only allow safe development and integration for their solution. Those guardrails are essential for building a consistent, reliable solution.
Examples are:
- Templates for forms that allow extensions to be viewed as part of the natural ERP solution
- Governors in place to aid in the retrieval of large data sets or for when processing large complex sets that result in numerous data rows being created
- The framework should be accessible to all skill sets — from professional developers to citizen developers
A framework also should not penalize you if your initial extension was built with a no-code option but needs to evolve beyond that. The framework should allow you take that no-code solution and evolve it further using low-code and even full-code capabilities, rather than having to start over.
Extensions Are Upgradable
Depending on the ERP, the framework you are using for the extension could either be the same as the ERPs or it could be different. If it is the same, your extension should benefit from the same future features as the ERP. If the template for the ERP evolves, so should your extensions. If new attributes are added to the ERP, your extensions should also be included. If the extension framework is different from that of the ERP, it should still ensure that any updates to the framework are accessible to the extensions without the developer having to perform any unnecessary steps to adopt them.
Focus on the Goal of the Extension
You need your extension to enhance the way you run your business, and having a framework that takes certain basic needs into account by default (examples include record navigation and FCRUD [Function Create Read Update and Delete]) allows you to realize your ROI for the extension quicker because of the reduction in development time. Other features to look for in a framework are its built-in authentication interface and security modules. These features are vital to ensuring the right people are looking at the right data. If they do not exist, that means many hours of effort are needed to create those interfaces and modules, which reduces your overall ROI on your investment.
Built to Scale
Many extensions start out small, either in functionality or in the number of users accessing it. It is inevitable, however, that the extension will evolve. Either the functionality will expand or the number of users will grow. The framework it is built on needs to be able to adapt to those changes and growth without developer intervention. If the framework has the proper pieces in place, it will be able to expand and contract with your extension's needs. If the solution needs to pull back millions of rows for a unique ask, a good framework will have features that allow for record retrieval batching to limit the stress on the cloud farm as well as have the ability to scale up/out so as to not affect other tenants while that request is on-going.
Evolution vs. Revolution
Technology is evolving at a rapid pace, and low-code/no-code frameworks need to ensure that as new features are introduced (e.g., ChatGPT), previous extensions do not have to be rebuilt to allow those features to be leveraged. Otherwise, your low-code/no-code framework is costing you time and money due to unnecessary rework. In today's fast paced, competitive market, that can severely affect your profitability.
About the Author:
David Heffler is a VP of Product Management with over 30 years of experience in software development. During his time at Infor, he's been responsible for evolving Infor's extensibility framework from an on-premises to a multi-tenant cloud offering, and is currently focused on the next generation of that framework. His understanding of what customers require of extensibility and comparing that to what the market is currently offering results in Infor providing a true no-code, low-code, full-code framework that serves both the UX and the server-side processes. Prior to joining Infor, David was an owner at RSVP Business Systems (an Infor ERP channel partner), which was acquired by Infor in 2011.
