NoCode development platforms have been on the rise over the past few years, but – thus far – their popularity has been mostly relegated to enthusiasts, startups, and small businesses, therefore leaving the NoCode enterprise space mostly untouched.
As with any new technology, enterprises have been very slow in their adoption of NoCode systems. There are certainly clear advantages of using NoCode in the enterprise marketplace. Application development and maintenance is one of the largest operational costs in any enterprise, so delivering applications faster and more effectively is a key priority for any CIO. However, there are also a variety of risk factors that enterprises should be aware of when identifying potential projects for NoCode integration. It is equally important for NoCode vendors to understand the common requirements of enterprises before targeting this challenging but also highly rewarding segment.
Data Security is Paramount
Enterprises have very strict security requirements. Often, there are data security standards that they must comply with in highly regulated industries. Hosting their data and applications on a cloud platform poses a serious challenge. There is a risk that the business users may unknowingly host sensitive data that is otherwise subject to regulations, like HIPAA or PCI-DSS, at non-compliant NoCode servers. Even some data that is not subject to these regulations may be exposed in the hands of business users that have only a limited familiarity with the data security standards that are implemented and enforced by their enterprise security teams.
Most enterprises, especially in regulated industries, prefer to host applications in-house. This allows security departments to impose their standards and ensure that no data is exposed outside of the organization. However, the vast majority of NoCode platforms are designed to be cloud only. On-premise deployment is not often an option. This means that enterprises must do their due diligence to ensure that any utilized NoCode hosts possess data center security certifications like SAS 70, SSAE 16, SOC, and HIPAA, PCI DSS. However, achieving and maintaining these certifications are time consuming and expensive processes for most NoCode vendors.
On-Premise deployment options also allow enterprises to deploy the application on their Intranet, which will alleviate many security concerns since the servers are never exposed to the Internet. If external-facing applications are required, then additional security measures are required to ensure that they are meeting the requisite security standards.
Support and Training
Enterprises must rely on software vendors for implementation and ongoing support. At a minimum, they want to be able to talk to knowledgeable support engineers over the phone during regular business hours in their local time zone. Considering most enterprises have locations spread over multiple time zones, 24/7 (or at least 24/5) support becomes a practical requirement. They often need dedicated support staff that are familiar with their requirements. Most NoCode platforms tend to offer online support via chat or email. While some may offer phone support, it may not be at the same level that enterprise customers demand.
Service Level Agreements (SLA) are a good way to handle the technical support requirements of enterprise businesses. But each enterprise has its own requirements and contract terms, which are binding legal documents that NoCode vendors will have to negotiate through their legal counsel. This can be an expensive and time-consuming process for NoCode vendors, especially if they are startups and must rely on outside legal counsel.
Response and resolution times are important terms that are included in SLAs. There are also penalties tied to these SLAs, which may put NoCode vendors under financial strain in the case that they fail to meet the requirements.
Integration with Inhouse Tools and Databases
Most enterprise applications are not stand-alone tools: they are often dependent on other applications or data sources though some form of integration, either synchronous or asynchronous. These types of integration requirements can come in a variety of different levels.
One of the most common integration requirements for enterprise businesses is Single Sign-On. Standards like SAML and OAuth make it easier for vendors to develop extensible integration points within their products.
Another type of integration is connectivity with in-house data sources. While NoCode vendors can develop features that connect to standard data models, the primary issue is that generic implementations will often require an enterprise business to expose their database in order to connect with the vendor’s cloud. Considering the strict security requirements in most enterprises, this type of exposure is not advisable and can prove to be a long and challenging process to bring this to fruition with sufficient security restrictions.
The third type is a direct integration with an existing application in the company. This is typically done though exposed APIs. Since these APIs are typically proprietary, the enterprise developers would have to provide access and adequate documentation to allow the vendor’s NoCode platform to consume the API. This means that the NoCode platform must support developing some form of third-party add-ins or hooks for custom code execution; otherwise, they will have to generate some form of concrete dependency on the client’s service.
Application Development Lifecycle
Regardless of the type of development (Code, LowCode or NoCode), every application goes through repeating cycles of analysis & requirement gathering, development, testing, release, and maintenance. Regardless of the methodology, companies need to facilitate and design their own application development lifecycle.
For enterprise businesses, the application development lifecycle is a well-structured and highly controlled process. Most applications require separate development, testing, and production environments. Different teams are responsible from handling operations on each environment. They typically have well-documented processes that moves the application from one environment to another to eliminate any issues. Enterprises use various software suites to automate the application development lifecycle. These can be complex systems, touting full integration with IDEs, testing, and deployment platforms.
Applying these principles to NoCode platforms is challenging. NoCode platforms are still in their infancy. As a result, most platforms don’t include utilities to automate the application development lifecycle, meaning that it would be up to the users to implement these processes manually. One of the challenges that enterprises will face with NoCode is that these platforms are typically used by business users outside of IT department control. Thus, applying any of these well-established procedures will be very difficult without the actual NoCode platforms incorporating them. The lack of these controls may lead to various issues when attempting to work these models into a company’s existing application development lifecycle.
Uptime and Disaster Recovery
Many enterprise applications are considered business critical. Even non-business critical applications must comply with fairly high standards when it comes to uptime and disaster recovery. Enterprises will also expect NoCode platforms to comply with these requirements.
Uptime and disaster recovery are especially important when considering cloud based NoCode platforms. Enterprises will review their SLAs carefully to ensure their expected business outcomes. Most enterprises will dictate their own SLA terms like performance benchmarks, which may be challenging for some NoCode vendors to meet. There are penalties, called service credits, that are enforced in the case that the vendor fails to meet those benchmarks. These penalties are typically a percentage of their monthly fees and the amount is determined through negotiations between the vendor and the enterprise.
Enterprises require NoCode vendors to publish their uptime data in real-time, as well as providing historical data. This allows them to check if the SLA terms are being met and if there are any service credits due.
NoCode vendors are also required to have third-party audited disaster recovery plans. These plans incorporate terms like Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) that enables the enterprise to understand expected downtime and data loss in the case of a disaster event.
An on-premise deployment option is a preferred approach for most enterprises, since it allows them to bring these applications into compliance with their existing uptime and disaster recovery standards. If the NoCode application runs on a standard server configuration with few dependencies, it can also be incorporated in the enterprise’s standard data center operations.
Continuity and Vendor Lock-in
Long term viability of the platform is a key factor for enterprises. Many NoCode platforms today are startups. Considering the recent popularity of NoCode, more investments will flow into the space, which will lead to even more startups. One of the risks with startups is the longevity of the product. If the vendor goes out of business or can no longer support the product, the cost of migrating a NoCode application to another platform can be extremely high for the enterprise. Often, this reason alone will prevent enterprises from considering NoCode solutions.
The ability to deploy the platform on-premises and not rely on a vendor’s cloud infrastructure is certainly an advantage as a short-term solution in the case of a vendor’s discontinuity. This will give the enterprise ample time to migrate those applications to another platform.
Another approach for enterprises to ensure continuity is the source code escrow. Some enterprises may require NoCode vendors to deposit their source code through a third-party escrow agent to mitigate their risk. The release is typically triggered in case of the vendor’s bankruptcy, acquisition, or failure to meet the requirements of their agreements.
There is also the Open Source approach, although there aren’t any Open Source NoCode platforms on the market yet. This may certainly change with the growing interest in NoCode platforms.
What Makes a NoCode Platform Right for the Enterprise?
Introducing a new development stack whether, its Code, LowCode, or NoCode is a long-term and costly commitment for any enterprise. So, what does it take for an enterprise to invest into a NoCode platform?
One of the most important factors is the capacity and willingness for NoCode vendors to offer strong SLAs or custom SLA terms to enterprises clients. This includes the ability to provide timely access to a knowledgeable support staff, resolve issues within certain timelines, and meet overall uptime requirements.
The ability to deploy a NoCode platform on premise is a very important factor in the decision-making process. This eliminates many concerns around security, uptime, and disaster recovery. This will also make it easier – and in many cases, possible – to integrate with inhouse applications and databases. In absence of providing on-premise deployment, maintaining data center security certifications is critical to meet enterprise security requirements.
A track record of working with other enterprises or large organizations can also be important. The way application development is managed in larger organizations can be vastly different than it is with smaller and mid-sized businesses (SMB). It is important for a NoCode vendor to have experience working in enterprise settings. Since enterprise engagements are typically multi-year commitments, this type of experience also ensures a certain level of history, provided that the NoCode vendor has been around for some time. This will help convince the enterprise that the platform is stable.
Clearly, these are not the only factors. Each organization can differ greatly in their decision making and investment priorities when it comes to new development platforms. However, these are certainly some of the most important factors.
Is the NoCode Enterprise Segment Worth it for the Vendors?
Selling software to an enterprise is financially rewarding. These are big ticket sales that are signed for multiple years, and, once you become a vendor, it becomes significantly easier to cross-sell to other departments and subsidiaries. Being able to include a few enterprises on their client list also provides a huge marketing advantage for NoCode vendors.
In turn, selling software to an enterprise is very hard. This is not only due to the stringent requirements defined above, but also because the process can be extremely long and expensive for the NoCode vendor to undertake. It requires numerous meetings, signoffs from multiple stakeholders, contract negotiations with legal teams, and more. The entire process can take months or even years to complete. It is not uncommon to dedicate months towards negotiating an enterprise deal to see it fall apart due to reasons that have nothing to do with the quality of the product or how good of a match it is for the project.
In the end, it is a key decision for NoCode vendors to even consider the enterprise segment since it can require a significant amount of effort to make the product compatible with its rigorous requirements, as well as to proceed through the exhaustive sales process. Many NoCode vendors prefer dealing with small and medium sized businesses instead of changing their business model or retooling their product just to be able to complete in this segment.
