Discover more from Impertinent
Where is the Brain of Your No-Code Solution?
Every No-Code system has an intellectual center. Where do you build yours?
In the past few decades, I worked on many location analytics projects. One was for a consulting firm in Perth, Australia. We were mapping pollutants in near-real-time for Singapore Harbor, one of the busiest shipping ports on the planet.
In my many trips to Singapore before this engagement, the harbor was typically saturated with tankers and freighters queuing up to redirect their goods to other destinations. On one trip in the late 80s, I was fortunate to take the wheel of a dinner cruiser in this harbor, so I came into this mapping project with a degree of familiarity with the environment.
The objective was simple: locate the center of harbor contamination. This location moves from hour to hour. The data and map animations provide insights for asserting pollution compliance by the Harbor Master. Real-time alerting offers the opportunity for rapid response. Often, spills are stopped more quickly.
Location science has always intrigued me because it helps to answer questions such as:
What city is the best place to reach the most of Wal-Mart stores in less than 8 hours by truck?
Where is pollution in the harbor likely eminating from most?
In location science, the center of everything matters. I think this is also true in no/low-code applications.
If someone asked you this about your no/low-code solution:
How is the heart of your no/low-code solution implemented?
… and, the data was stored and managed in Airtable; but utilized Zapier for 80% of its automations, 90% of its integrations, and 75% of all workflow processes; why would you answer “Airtable”?
In this hypothetical, Airtable may store 99% of the data, but the “brain” actually resides in an orchestration platform, i.e., Zapier.
TrackVia represents a no/low-code [market messaging] trend that I’ve been trying to articulate for many months. It’s a very subtle trend that seems to be gaining momentum.
I’ve been recently asking questions on forums and Slack communities about the use of Make, Zapier, and other adhesive tools. I’ve been trying to expose the possibility that the future of no-code development will not begin with database platforms. Instead, builders will increasingly start at the heart of the solution — the brain — where automation, workflow, and integration orchestration occur. The remaining parts of the system will be chosen and implemented from this centralized nervous system.
Data as a service is growing rapidly and there’s plenty of anecdotal evidence to suggest Airtable users are shifting to other tools like Rowy, TrackVia, and NoLoco for various reasons. Bottom line: Data storage and management is (in some cases) just another component for no/low-code makers. Increasingly, brands (like Airtable) won’t matter. UIs might matter less. And costs will certainly matter more.
Imagine how you will react when Zapier includes what is ostensibly the componentized features of Airtable - i.e., data as a service not unlike any component Zapier currently offers to integrate with other database platforms. Zapier has this now. It’s only a matter of time before Make does as well.
These early, extremely rudimentary database tools will never likely surpass Airtable or SmartSuite’s capabilities. However, a small number of solutions will fit this model nicely, and increasingly, the range and features will expand.
Soon, the tail will wag the dog.
TrackVia is leaning on the exact positioning for the future of no/low-code platforms, but they [currently] lack the underlying adhesive component infrastructure to replace Make or Zapier.
Impertinent is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
TrackVia’s positioning tagline resonates with me because it paints a better future for no/low-code development practices. Arguably, the brain of a no-code solution that may use Airtable for the database may not exist in Airtable itself; it could exist in the business logic of its workflows, automations, and integrations, which reside elsewhere.
Unless the database app framework can house and run the vast majority of this logic, the risk/dependency envelope expands by establishing the “brain” of the solution external to the no-code database app. Putting it all in Airtable or all in Make is better than fracturing it, as I suggest here and here. However, it’s impractical in most cases to safe harbor all workflows, automations, and integration in a database app like Airtable. Database platforms are not known for serving as integration and workflow hubs. Hence, the aggressive adoption of automation and integration hubs like Make, Zapier, and several others.
My hypothesis (from an economic and sustainability perspective) is to imagine what the development process would be like and if it would produce better outcomes if we reverse the polarity of the implementation strategy. To try this, begin your next project with exactly the perspective that TrackVia suggests -
Define “everything” and then design an approach that tracks and connects “everything” to meet the business requirements.
If this approach were represented as a mind map, the no/low-code database would not be at the center; Make (or your favorite glue factory) would be. Using Make’s components and tools, you could “markup” a comprehensive mindmap of your no/low-code solution, thus creating a roadmap of the workflows, relationships, and integrations that would eventually be required. This would essentially be a requirements manifest from the workflow perspective, not the data perspective.
An even higher meta-loft of no/low-code development approaches may emerge; ncScale is a good example, a thoroughly sensible approach. As a rule, we confidently lean into tools that show us the hidden side of database models through meta APIs and schemas. How is the orchestration of your no/low-code solution any different?
Embrace the Center
This idea will take a lot of rehashing and pondering if a reassessment of no/low-code development approach is viable. It might require us to retrain our thinking altogether, although I predict many of you may already be way ahead of me.
In this and other posts, I’m acting as the no-code economist looking at the costs and risks all businesses must endure when they intentionally choose an implementation approach that fractures business logic and makes it difficult to track, unify operational analytics and reporting, and fully understand the components' relationships. But I understand there’s not a lot of wiggle room - we are forced to embrace these external tools to build no-code systems that are operationally successful. I’m suggesting the label we apply to these “external” services may be central if not the center of our solutions.
I have a hunch many of you are already embracing the center of your no/low-code solutions. Let me know your thoughts.
Airtable is the dog; Make is the tail.