Low-/No-Code for Inclusive Contribution

Abstract: Ideas for Enabling Problem Solvers
Low- and No-Code systems are about more than reducing time-to-market for application delivery. They also explicitly open development to a new class of solution contributors — those with only some, or maybe even no, formal programming experience.
I started programming as a hobby when I was about 11 or 12, and I’ve been slinging code ever since. I solve a lot of problems with everything from little scripts on my workstation to big, multi-regional, 1000s-of-users applications. In my brain, I don’t really differentiate programming tasks on scale, language, distribution, or any other technical factor — for me, it’s always been about fit. Anyone who knows me even a little will have heard me say, “Use the right tool for the job,” and I truly believe that. Armed with my “right tool” mantra and available skills, I’m pretty well equipped to solve a lot of problems.
I’m also a firm believer in federation: I believe problems are best solved by those who are closest to the issue — the front-line people whose very job depends on quality solutions to problems. Oddly, not all those people have the same love for deep programming topics as I do. Or, maybe they do, but they don’t have the time or base-skills necessary to explore alternate techno-solution paths. I started to understand this issue in my late 20s and I started to program for it right away. For a many years now, I’ve been developing application platforms with the express intent of involving contributors of varying technical interest and expertise. Below is a description of my approach.
Anatomy of Inclusive Contribution: Extensibility
Abstraction
Abstraction is a core concept for programmers — we live and breathe it. Without getting too technical, abstraction is simply the ability to talk about things on a sliding scale of very-generic to completely-specific.

Extensibility
Extensibility is incorporating abstraction with the defined purpose of accommodating future use-cases, some of which may not be known now. For programmers, deciding where to incorporate abstraction is a function of expected growth patterns; essentially, “what things are likely to evolve and expand past what I know now?”
Typically, extensibility is introduced within various strata of an application. Also common, developers with differing expertise will contribute where capable.

Inclusive Contribution Models
In building inclusive contribution models, we’re making decisions about where to incorporate extensibility, specifically under the design pattern of lower-in-the-stack equals more involved in solution design, and higher-in-the-stack equals less involved in the design itself and more involved as a consumer of the design.

Integrating Low- & No-Code Design into Your Solutions
With a well-designed, extensible, low-/no-code system, everyone can participate in solution creation and maintenance. Think of this as an opportunity to involve multiple classes of solution contributors and also as an enabler to DevOps models.


Put the solution implementation to the person closest to the problem. In a business solution, that’s the analyst conducting the transaction. In an application architecture, that’s the junior- and mid-level devs building on base configuration systems, extending middle-tiers, or extending the UI.

Involve everyone from less technical folks to the highly technically inclined. In a business app, you can pair the analyst with a dev to augment a no-code solution with new capability. In an app architecture, you provide scope to junior devs so they can focus on productivity, and senior devs can rest assured innovation occurred only in the right places.

Put 5 IT people in a room and ask for a DevOps definition, get 12 answers. I am not here to litigate the ‘proper’ definition of DevOps, and I fully admit to taking a liberal interpretation here: I suggest only that by embracing applications built as an extensible frameworks, you offer yourself the luxury of reducing your workload and worry-scope to the problems you care about most, whether it’s enabling people, solving a logic bomb, or eliminating one more email+spreadsheet-attachment disaster.

A quick note: Synapse is an open-source tool of my own making, but I’m not pitching the tool, I’m discussing architecture and methodology. If you’d like to know about the tool itself, see the code, docs, or articles.
Synapse Overview
Synapse is a tool I wrote to make creating APIs around task execution fast, easy, and accessible. Synapse runs workflows, called Plans, with are comprised of Actions (workflow steps). Each Action invokes a Handler, where a Handler provides a specific technical implementation, such as for copying files, running apps, or accessing databases, other APIs, or cloud resources. In Synapse, each Plan is exposed as an API endpoint and can be configured to accept runtime execution parameters.
Synapse extensibility is organized as follows:

Layer 1 Contributor: No-Code, Optional Low-Code
- Create/Configure Plans. Extensibility: New workflows with existing Handlers, configure runtime parameters, configure Plan security.
- CommandHandler, ScriptHandler. Extensibility: New API endpoints with any command line utility, such as OS or vendor tools, or any script from any scripting language.
- Custom API-1. Extensibility: Use a Synapse utility to generate vanity URLs for Synapse Plan execution. A little knowledge about how APIs work is recommended here, but not required.
Layer 2 Contributor: Low-Code
- Custom Handlers. Extensibility: Author a new, code-based Handler to provide new technical capability to Synapse Plans.
- Custom API-2. Extensibility: Edit the custom API code for precise control of runtime parameters or for adding bespoke API capability.
Layer 3 Contributor: Full-Code/Core Tool Modification
- The core Synapse web server exposes several runtime hosting models, and the execution engine itself can be embedded in other applications. If you’re exploring these options, you need to know your way around a compiler.

Low- and No-Code systems are Inclusive Contribution Models in action. The whole intent of these systems is to provide an implementation for all the “hard stuff” so content contributors can focus on solving the actual business problem at hand. Two stand-out examples of market solutions for this are:
- ServiceNow is a low-code platform as it provides massive efficiencies with built-in database capability, a workflow engine, form generators, and more. ServiceNow expresses extensibility by allowing customization of almost everything.
- Salesforce offers no-code solutions, approaching “clicks-not-code” paradigms, which are designed to heavily emphasize solution productivity.
Conclusion
I hope this article helps you understand low-/no-code solutions, a bit about how they’re built, as well as some use-cases. If you’re interested in learning more about these paradigms and where they can fit into your space, feel free to reach out to me anytime.
