Low-Code Platforms and the Rise of the Community Developer: Lots of Solutions, or Lots of Problems?

Low-code platforms are the hottest enterprise software category right now. In addition to hundreds of startups, over the past 24 months, each of the big three cloud providers has launched its own low-code platform. With this level of investment, it’s hard to imagine a future that doesn’t feature lots of bespoke business apps being built by non-IT staff for use by their teams. 

To help you understand how this trend will impact your IT organization, we discuss the types of low-code platforms available and the type of staff in your organization who will be attracted to them. We then look at how low-code platforms fit into your IT architecture and, finally, provide our views on optimal strategies for managing IT in a low-code world.

What are low-code platforms?

You can think of low-code platforms like you think of Excel. They are just software tools in the hands of your users that are useful in a wide variety of business scenarios. With these tools, they can create solutions or problems. 

We group low-code platforms into three different categories. Each category will attract a different type of user in your organization. 

1. UI generation software
   
   Retool  and Bubble are perhaps the best-known examples of this type of low-code application. Users can quickly create user interfaces that interact with data stored in tables on the platform.
   
   The competing products from each of the big three cloud providers are:
   1. Powerapps from Microsoft
   2. Appsheet from Google 
   3. Honeycode from AWS 
       
2. Integration software
   
   Zapier is the prototypical example of this type of low-code application. Users create connections between software applications and triggers to move data through those connections.
    
3. Transformation software
   
   This is a broad category of software whose main purpose is to add value to data as it moves between applications. This category includes machine learning tools such as AWS Sagemaker, data extraction tools likeSypht and RPA software like UIPath.

Click here to view a sortable list of low code platforms.

What is a community developer?

Community developers are staff in your organization who use low-code platforms to create solutions for themselves and their teams that solve a particular business problem.

These users have always existed. Today, you can see them creating masterpieces in Excel. Excel users can be grouped into the same categories we use for low-code platforms.

1. UI creators: These users create tables in Excel and format the data to make it easier to read. They may use techniques such as a VLookup formula to link data across worksheets in the same way that a low-code user creates related tables in the low-code UI application.
    
2. Integrators: These users build more sophisticated Excel applications that operate on larger datasets with data they have imported into Excel or using data linked to Excel from a database or API.
    
3. Transformers: These users create sophisticated formulas that accomplish a wide-range of data transformations. Some users will create functions in VBA to perform more sophisticated transformations.

How community developers might use low-code platforms in your organization

Most community developers will progress through three stages as they become more capable of using the low-code platform. Many community developers won’t progress beyond the first or second stage but some will go onto the third stage and build full-featured applications used throughout your business.

Stage 1—UI Generation: Initially they will create applications with nice user interfaces with data that is keyed into the application. For example, they may make a meeting notes application that allows users to jointly add meeting notes as a meeting progresses. This is the UI Generation stage.

Stage 2—Integration: As users gain experience, they’ll move to the second stage where they start pulling in data from external systems and data sources. For example, they’ll enhance their meeting notes application to pull calendar information from Outlook and email attendees after each meeting with a copy of the notes. This is the Integration stage. 

Stage 3—Transformation: And, finally, they’ll start creating applications that perform increasingly sophisticated transformations. For example, they may run the meeting notes through a machine learning model to tag and store the meeting content so that it can be searched by topic. This is the Transformation stage.

What motivates a community developer?

Community developers are building low-code applications because they aren’t able to use your enterprise systems to accomplish certain tasks. You can think of your enterprise system stack as a mosaic. Your goal is to make your application stack look like a well-tiled wall with each application connected directly to adjacent applications.

Photo by Wengang Zhai on Unsplash

But the reality is that mergers, acquisitions, historical anomalies, and changing business requirements mean your stack overlaps in some areas and has gaps in other areas. It’s these gaps that drive community developers to create Excel spreadsheets or use low-code platforms to fill the gaps. Your users may view your IT stack more like the image below than the image above.

Photo by Марьян Блан | @marjanblan on Unsplash

To assist these users, you historically have had three options to plug gaps in your stack:

1. Enhance your enterprise systems to accomplish the desired task. For example, if your operations team needs data from your core IT systems such as your Finance system or ERP (Enterprise Resource Planning) system that shows all of the products historically purchased by a customer, your IT team could enhance your core systems to show this information as part of your customer record in your core systems. 
2. Develop a custom bespoke application targeted at solving the user’s specific needs. For example, if your underwriting team would benefit from seeing the risk rating of the area surrounding a strata property, you could build a custom application that provided this information to your underwriting team.
3. Purchase a third-party tool that performs the task. For example, if your customer support team needed a way to monitor tweets for mentions of your company, you could subscribe to a Twitter monitoring service.

Each of these options has pros and cons. 

The first option (enhancing your core systems) allows your development team to provide a solution that addresses the users’ needs without adding additional systems or apps to your stack. The downside is that these solutions take time to build, test, and deploy and you are limited by the resources available on your team. It doesn’t take long for demand to outstrip your ability to provide custom solutions. 

The second option (building a bespoke solution) is often easier than enhancing your ERP system but still requires significant effort on your part to develop, test, deploy, and support the solution.

The third option (using a third-party solution) can result in a very full-featured solution but it takes time and resources to procure and integrate. And quite often the third-party solutions include features that overlap with your other enterprise systems leading to multiple ways for your users to accomplish the same task.

Community developers provide you with a fourth option to fill the gaps in your IT capability. Theoretically, your organization’s IT capability should be dramatically increased if you have a small army of community developers building applications that scratch their team’s itch. 

But the risks are also substantial. Picture your IT team as a small group of wizards who perform magic to help your kingdom. Now imagine the change to your society if suddenly everyone could perform magic. Great things could be accomplished but mistakes would inevitably occur and you might find that someone has inadvertently exposed to neighboring kingdoms the plans to your castle’s defenses.

Where are the risks?

Community developers create two types of risks. We’ll discuss these risks using examples where Excel use has created a problem.

1. Integration risk: This risk involves exposing data that shouldn’t be exposed. With Excel, this is the least common but most embarrassing risk. Community developers will inadvertently send data to places it shouldn’t be sent most commonly by emailing Excel spreadsheets that contain data they didn’t intend to send. For example, in 2017, a Boeing employee inadvertently included the personal details of 36,000 colleagues in an emailed excel sheet. Low-code platforms that move data through APIs dramatically increases the opportunity for this type of problem to occur.
    
2. Transformation risk: This risk involves bugs or miscalculations in the app that lead to bad business decisions. This is the most common problem seen involving Excel solutions with some studies showing that the majority of Excel spreadsheets have at least one error. An example of this type of error occurred last year when a spreadsheet error delayed the opening of a new hospital in the UK. Likewise, low-code platforms will contain transformation errors but we don’t expect these will be more prevalent than they already are with Excel.

Click here to see more examples of Excel risks. Reading through these will help drive home the types of risks your community developers will expose you to.

Each stage of low-code usage has a different risk profile for your organization. 

Stage 1 (UI Generation) community developers are low risk. The data they work with is typically manually entered into the application, e.g., the meeting notes application discussed above. You should manage this in the same way that you handle acceptable use for email and other forms of communication. 

Stage 2 (Integration) community developers are higher risk. They are using low-code platforms to read and write data to systems such as your CRM (Customer Relationship Management) system or external APIs such as Clearbit for enhancing prospect data or Mailgun for sending bulk emails. These types of applications perform functions such as providing field staff with job data taken from your support system or provide sales staff with information extracted from your CRM. These applications introduce user authentication risks as well as data security issues. You’ll want to place appropriate controls on what systems users integrate with and what is done with the data. 

Stage 3 (Transformation) community developers are the highest risk category. In addition to reading and writing to your systems and from external systems, they are also transforming data. These types of applications include apps that draw on machine learning solutions such as AWS Sagemaker to deliver unique benefits to your organization. For example, a Stage 3 Community Developer may take prospect data from your CRM, combine it with data extracted from Twitter, run a topic model analysis through AWS Sagemaker, and use it to target prospects based on the topics they are tweeting about. 

In addition to the risks introduced in the integration phase, these applications also carry the risk of incorrectly transforming data. For example, if the Community Developer built a machine learning model that classified the severity of a customer support issue (and therefore the priority in which it’s handled) you don’t want their model to have a gender or racial bias that results in your organization improperly favoring one group of customers over another.

The diagrams below show how we think about risk in low-code platform usage.

Each diagram represents a stage. The orange-colored section of each stage is the proportion of apps that the IT organization shouldn’t get involved with. The purple and red colored sections of each stage show the proportion of apps the IT organization should get involved with. The red-colored section shows the proportion of apps that deal with sensitive data where there is an integration risk. The purple section shows the proportion of apps where the complexity of the app is high enough to warrant involvement from the IT team.

The first diagram shows category 1, UI Generation apps. Most of these applications are low risk and IT only needs to get involved when the type of data in the application requires some controls placed over it. For example, you wouldn’t get involved with a meeting notes app but you would get involved with a patient notes app. Only rarely would these apps be complex enough to warrant IT involvement.

The next diagram shows category 2 apps that integrate with other systems. This category contains potentially riskier applications. IT should be involved with a greater proportion of these than the stage 1 applications as indicated by the larger purple area and red areas and smaller orange area.

The final diagram shows category 3 apps that involve significant data transformation functions. This category contains the riskiest applications. IT should be involved with a greater proportion of these than stage 2 applications as indicated by the large purple area and small orange area.

Wrapping up: Managing the risk of low-code platforms

Like it or not, community developers are already in your organization using Excel and they are about to start demanding access to the new breed of low-code platforms. We see this trend as unstoppable. You can fight against it, or you can accept the inevitable and embrace it. Done right, having a small army of community developers in your organization can dramatically enhance your IT capability.

Today, most organizations are exposed to material risks from the vast number of spreadsheets used by decision-makers to make business decisions. If low-code platforms start replacing some of these spreadsheets, then the spread of low-code platforms through your organization can lower the overall IT risk in your company.

Maximizing the visibility of low-code solutions is the key to managing risk. To maximize the visibility inherent in having community developers building apps, we recommend you make available a single low-code platform for your community developers. 

Which low-code solution should you adopt? It probably doesn’t matter much. We see the feature sets of low-code platforms becoming largely undifferentiated—there’s only so many things a low-code platform can do and the level of investment in the space means that they’ll all be able to do these things. So, if you don’t have a preferred low-code platform in mind, just use the one provided by your cloud provider. If you are a Microsoft Azure customer, use Power Apps. If you are an AWS customer, use Honeycode. And if you are a Google customer, use Appsheet. 

Next, make training available to your community developers on that platform. Once they are comfortable using a particular platform they are much less likely to demand access to a different one. As long as you provide an outlet for your users to scratch their low-code itch, they will be able to accomplish what they want to accomplish.

And, finally, develop some expertise in your team on the machine learning and data transformation services offered by your existing IT stack/cloud provider. When your community developers need access to a machine learning platform they may as well use one you already have access to so you can more easily control your data.

About the Author

Doug Hudgeon is the co-author of the Manning book Machine Learning for Business which shows your users how to solve real-world business problems using AWS SageMaker. InfoQ can get this book for 50% off using the code hudgeonpc. He is also the chief executive officer of Managed Functions a company on a mission to interconnect every business application with actionable data. Once a business process becomes too complex or too risky for a community developer, you can refer your community developers to Managed Functions who assess the risk levels of the low-code application and, where the risk is beyond a certain threshold, build and maintain the integration/transformation component of the app. And, uniquely, deploy the component as a cloud-native function on your AWS, Azure, or Google cloud so your data stays in your environment.