Part 2 of this series looked at low-code solutions in the context of their architectures - antiquated, monolithic, and unfriendly to application deployment. In Part 3, we examine proprietary toolsets vs. standards-based tools and their contrasting effect on the application development process.
Proprietary Toolsets in a Low-Code Solution — Why?
A plus of having proprietary tools bundled into a low-code solution is alignment of the tools and hopefully the platform, since they come from the same vending source. In theory, this should benefit developers and ultimately the business. However, the realities of proprietary tools include steep learning curves, vendor lock-in and an ecosystem of code samples, tutorials and community applicable only to that vendor—all of which could be spotty or non-existent.
Another caution would be that just because a platform vendor promotes their use of standard languages, that doesn’t mean they don’t have a proprietary development process.
Besides the expense and time involved in learning and integrating niche skills, seasoned developers will likely resist transition to a vendor’s proprietary tools. Proprietary code can be tough to debug with fewer resources available to find examples and address issues. It also separates developers from mainstream development communities and isn’t impressive on a resumé.
With a view now focused by the inflexibility and risk, it’s clear there’s really nothing to recommend proprietary tools.
Developers need transparency. Any low-code solution should be one where developers have full access to all source code, and they need to be able to fully see the implementation.
Keeping the entire development environment in mind—lifecycle and tool chain—compare your existing tools and skillsets with what you’re considering for a solution, so you don’t end up with an inflexible silo.
They should also have access to a wide array of open source components in common repositories, so they aren’t restricted to proprietary components designed for a single platform. They also need the option of using different frontend SDKs so they can support different project efforts with a common platform.
What’s the Key?
Mark Schafron is a Senior Copywriter for Progress.
29 en 20 oktober 2019Tweedaagse workshop over probleem-analyse door Adrian Reed.This practical, hands-on workshop by Adrian Reed, focusses on the problem-solving skills that practitioners need in order to collaboratively explore and describe problems...
30 oktober 2019Workshop met BPM-specialist Christian Gijsels over business analyse, modelleren en simuleren met de nieuwste release van Sparx Systems' Enterprise Architect, versie 14.Intensieve cursus waarin alle basisfunctionaliteiten van Enterprise...
6 en 7 november 2019 De wereld van business intelligence en datawarehousing hanteert een unieke terminologie en eigen verzameling technologieën, ontwerptechnieken en producten. Voor nieuwkomers kan dit overweldigend overkomen. Want wat betekenen al ...
13 november 2019Praktisch seminar waarin Sander Hoogendoorn u laat zien hoe u microservices kunt inzetten in uw softwarearchitectuur.Het nieuwste architectuurprincipe microservices lijkt veelbelovend: verkorte time-to-market, schaalbaarheid, autonomi...
10 en 11 december 2019 Vergaar nieuwe databronnen en benut analytics en machine learning om de concurrentie een stap voor te blijven. Er wordt gekeken hoe machine learning en advanced analytics technieken zoals tekst-analyse, sentiment analyse...
11 en 12 juni 2020 Praktische tweedaagse workshop met internationaal gerenommeerde spreker Alec Sharp over herkennen, beschrijven en ontwerpen van business processen. De workshop wordt ondersteund met praktijkvoorbeelden en duidelijke, herbruikb...