9 Best Practices – InApps Technology 2022

Low-code and no-code tools — ones that use “drag and drop” or similar interfaces to allow users to accomplish technical work without coding skills — are gaining rapid adoption in enterprises, for a number of reasons:

There’s no doubt that these tools and platforms are helping to speed up software creation and delivery. But how do you make sure the tools your organization chooses integrate well with the APIs you need to be productive — from Slack to Salesforce — and serve your users and customers?

As with any other type of software that serves cloud native architecture, the low- and no-code market is crowded with products, and not all of them will survive the competition. Or, the most popular low-code startups get acquired by tech giants. Either way, vendor lock-in can leave your organization stranded.

“The problem quite often in the past has been, low-code tools get to a certain level, and they just disappear,” said Mark Boyd, founder and director of the consulting firm Platformable.

There’s another possible pain point with low-code/no-code tools and APIs, said Boyd, who researches best practices for API technologies. “When you dig down and try to do something a little bit outside the box, that’s not as simple as you just pull this data from here into here,” he told InApps Technology.

Some of the tools get complicated when you try to customize them. Before you know it, he said, you’re rolling up your sleeves and coding anyway: “It can be a turn-off.”

The Challenges of APIs and Low-Code Tools

Security can also be an issue when low-code or no-code software connect to your APIs and your critical infrastructure. Giving “citizen developers” the ability to create applications can create new vulnerabilities.

Organizations that use low- or no-code tools want to empower their employees to innovate but wish to avoid “app sprawl” — the creation of applications that no one is taking responsibility for.

“Some of these platforms, they created thousands of applications that are just sitting in the ether — governance either doesn’t exist or takes a lot of calories,” said Marcus Torres, general manager and vice president for app engine business at ServiceNow, which produces a low-code platform and tools. “Trying to understand what they’re doing or the value to the business isn’t very clear.”

Every customer Torres talks to, he said, wants to reduce app sprawl: “They don’t want to wake up one day and see thousands of apps with no governance, no purpose. And we’ve seen some pretty public issues with this, where certain applications have essentially surfaced sensitive company information.”

9 Best Practices for APIs and Low Code

Before adopting a low- or no-code tool and integrating it with your APIs, consider the following nine best practices, as recommended by Boyd, Torres and other experts.

1. Take an inventory of your current APIs — and their users.

For starters: What do you already have, and who needs to use it? In addition to needing this information to base your decisions about adopting new technologies, you also need to know for two reasons: security and data issues.

Take security. Unless you know what you’re already running, Boyd said, “you don’t really know where your perimeter is, and you don’t know what’s possibly been exposed, where data might be vulnerable to being shared, or if there are other entry points into an organization’s tech stack via an external API.”

Also, if you’re not sure exactly which APIs you have and who’s using them, you could run into issues with data duplication, privacy, or storage. “For example, Germany has laws around health and finance data: it’s got to be stored in the country,” Boyd said. “So if you’re using some SaaS tools, and some German residents are using them, there may be some concerns.”

To find out where you stand, he suggested building a catalog of all the APIs your organization is consuming, and who’s consuming them. As you do that inventory, Boyd suggests, get your organization’s security, regulatory and data protection specialists involved.

2. Prioritize collaboration.

One of the best things about low- and no-code tools is their potential to get non-technical users involved in creating applications. But unless your non-technical colleagues understand what they can get out of using these tools — and unless they can use the tools without coding skills — it doesn’t matter which ones your organization adopts.

“It’s all about users at the end of the day,” said Leonid Belkind, co-founder and chief technology officer at Torq, which provides a no-code security automation platform, “How many tools have you seen in your lifetime become shelfware? The organization bought it and nobody uses it. That’s the biggest risk.

“How do you avoid it? Find out the motivation and goals people have and match the tool to it,” he added. If you put user needs first, “the chances of it becoming shelfware are significantly lower.”

It’s important to not only find out users’ needs but ask them to explain how they now complete the tasks you’re trying to automate, Belkind said.

Why is it important to identify who is going to work with the tool? he asked. “Because of the way people can explain their processes and break them down into steps.”

3. Align with business strategy.

If the tool doesn’t easily integrate with your organization’s most commonly used and crucial APIs, it will clearly be a non-starter. If, however, it does, and solves some of your current pain points, you’ll want buy-in — literally — from the people who hold the IT purse strings.

“In order to be successful with low code, you need not just say, hey, the intent is everyone wants to innovate and be empowered,” Torres said. “You have to really think of low code as a business imperative that’s really going to drive agility and value and ultimate scale within your  organization.”

4. Understand your data structure.

“The process you will be building will have data manipulation at its core,” said Belkind. “APIs are like doors through which you can deliver data or pull data.”

Make sure you understand where your data goes, whether it can be combined or filtered, which users have access to it — and how the new tool might affect all of that.

5. Tally the costs.

After security concerns, the cost of using a low- or no-code platform — not just the initial purchase but the server and running costs, as well as maintenance over time — must be considered.

Boyd pointed to Bubble, a popular no-code app development tool. With Bubble, he said, “the running costs can quickly scale out of hand, more so than maybe serverless applications or some other sort of solution might.” Using it might require paying for it out of a different budget in your department or organization.

“It’s all about users at the end of the day. How many tools have you seen in your lifetime become shelfware? The organization bought it and nobody uses it. That’s the biggest risk.”

— Leonid Belkind, co-founder and chief technology officer at Torq

Ask yourself also how the tool would be used, Boyd suggested. “Are you using it just for proof of concept or ideas? In which case, that might make great sense. But if you’re then going to turn it into production use, then you’ve got to think of these longer-term costs.”

6. Consider re-use and scalability.

In the very recent past, the websites for automation tools included a page listing all the APIs they supported.

“The thing is, it’s a never-ending story,” said Belkind, of Torq. When he confers with enterprise customers, he said, “they talk to us about hundreds of various Software-as-a-Service tools in their arsenal.”

But, he added, “I don’t think this race after dedicated integrations can ever be won.

Open API, he said, is the way to go: “I think the only viable strategy here for organizations is to define that the tool has to be open to anything supporting standard API and enabling people who are not necessarily programmers to do that. And that is possible.

“And then your strategy is future-proof, because whatever tool gets adopted has to have an API. And you will be able to add it to this same ecosystem.”

7. Seek end-to-end visibility.

Ask about scalability constraints when discussing a new tool or platform with its vendor; not every product is architected in a way that allows it to scale at enterprise level, Belkind said.

“I don’t think it’s a bad idea to check the architecture of the software-as-a-service standard,” he said. “Many vendors will be happy to talk about that.”

They should also be willing to connect you with other customers whose organizational size and use case is similar to yours. Ask questions like: How many business processes did they automate? What was the response time? What were their investments in infrastructure to accommodate the new tool or platform?

“In order to be successful with low code, you need not just say, hey, the intent is everyone wants to innovate and be empowered. You have to really think of low code as a business imperative that’s really going to drive agility and value and ultimate scale within your  organization.”

— Marcus Torres, general manager and vice president for app engine business, ServiceNow

Belkind calls this kind of intel “a great insurance policy” for the organization that’s buying a new low- or no-code tool. “I would be very worried about the vendor offering that does not allow this kind of information exchanged between customers.”

8. ‘Divide and conquer,’ for security’s sake.

Belkind, a pioneer in the zero-trust approach to security (he was a co-founder of Luminate Security), warned against using low- or no-code tools to put too much control in one place in your architecture.

“You really don’t want to create a single point in your enterprise architecture that can do everything,” he said. That is dangerous, because if somebody abuses that, it has a lot of power.

He advised a security approach that includes role-based access and authorizing least privilege for tools that connect to third-party systems. “It is perfectly fine that me in HR and you in the security department are using the same tool,” Belkind said. “It does not mean that we have the same domain and all of our social integrations are in a single huge pile.”

9. Start slowly, by automating a common workflow.

If you’ve taken all the previous steps and are ready to start working with a new low- or no-code tool, Boyd suggested starting slowly.

“I would start by automating some of your common workflows, where you can turn the boring daily things into something that you don’t have to think about,” he said.

And then, Boyd suggested, API strategists should start thinking about opportunities to bring the technical and business teams together, and using low- or no-code work for some tasks that have traditionally required their collaboration. “Enable drag-and-drop or low-code arrangements that enable your business and technical people to communicate better.”

Together, he said, they can “design what the business need is for an API. And business people can feel like they’re involved in the conversation because it’s not just technical mumbo jumbo. They can visually see, ‘OK, this is how it all pulls together.’”

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Torq, Bubble.

Featured image by JJ Ying on Unsplash.