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.
Op woensdag 25 en donderdag 26 maart 2020 vindt in het Van der Valk Hotel in Utrecht voor de zevende keer de Data Warehousing & Business Intelligence Summit plaats. Dit onafhankelijke congres wordt wederom georganiseerd door Adept Events, en heeft oo...
8 april 2020Praktisch 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, autonomie, u...
4 juni 2020Workshop met BPM-specialist Christian Gijsels over business analyse, modelleren en simuleren met de nieuwste release van Sparx Systems' Enterprise Architect, versie 15.Intensieve cursus waarin alle basisfunctionaliteiten van Enterprise Arc...
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...
26 en 27 november 2020 Praktische tweedaagse workshop met internationaal gerenommeerde spreker Alec Sharp We horen regelmatig over het belang van "alignment" in het bereiken van succes bij het werken met bedrijfsprocessen, maar alignment m...