Business ChoicesLow-code/No-code
This very interesting post discussing implementation of low-code/no-code in IT departments:
https://www.finextra.com/blogposting/18994/low--and-no-code-platforms---will-it-developers-soon-be-out-of-a-jobAny organisation that uses excel and BPA, CRMs to organise itself is a candidate for low-code/no-code. This is the next level for them and enables the implementation of a more consistent, standardised approach. This is not to say that spreadsheets and mainstream applications will not be used, just that they are specialists at what they do and low-code/no-code is far better at what it does than trying to extend these tools to provide multi-user process flows. What low-code/no-code can do for an organisation or a department it to rapidly implement in scalable software, a reflection of the work processes of an entire organisation along with it's exceptions and quirks which give it a value in the market in a way that off-the-shelf software rarely can to such a degree of accuracy.
Best known low-code providers include:
- Mendix
- OutSystems
- Microsoft PowerApps
- Salesforce Lightning
- Thinkwise
- Zoho Creator
- Appian
Best known no-code providers include:
- Airtable
- Appy Pie
- AppSheet
- Unqork
- Open as App
- FileMaker
- Kintone
- Webflow
- Zapier
How to make low-code/no-code work
Some form of implementation methodology needs to be evolved around these platforms which can ensure key business requirements of any system, such as security standards, release procedure, professional standards which are no longer coding quality control but which are abstracted application flow standards. These include knowledge of when to allow certain queries and to who and how often, how heavy a load they place on the system, when to asynchronously batch tasks and when to execute immediately. GDPR standards, data access. Issues such as vendor lock-in and single-authentication across systems have to be considered
A good low-code/no code platform will provide:
- Less testing requirements as all of the components and their permutated interactions are already tested. Issues which can come up then are from mal-configuration
- A standard security infrastructure which ensures tight control over the way information is transferred and rendered and limits potential for security breaches
- Standardised mechanisms for tracking changes in all critical data changes and being able to trace through any prior set of transaction and who did what when forensically
- A standard design both internally and front-end which enables maintenance of applications easier for any team member to manage or the change-over of technical roles than in-depth specialised code
- Due to the extendibility of low-code/no-code, there is a significant potential advantage in that they can scale out laterally across a wide range of functionalities. In this sense one 'master system' for an organisation can be built without necessarily having to plug multiple different components or applications together with integration
Abstracted systems
A key principle which should be considered for any low-code/no-code application is to what degree to balance-off the automated nature of application build with complex exceptions and logic flows which inevitably crop up. One solution to this is the concept of 'default but override' whereby an application is built rapidly with standard mechanics and only in the case of exceptions is the configuration drilled into and overridden
How will this sector evolve?
Given that there are highly configurable existing enterprise applications already available, it is possible to see a symbiotic evolution of the two. An application such as Salesforce which allows third-party plug-ins and access to its API provides potential for low-code/no-code to be specialist components within that environment and swapping them out in future becomes relatively easy. This does however place a heavy emphasis on the binding application choice as this becomes correspondingly harder to replace
An alternative is an industry-wide or organisation-wide standardised integration channel with a single point of authentication. In this case then it would also require standardisation of data structures (object definitions, structure definitions, rules) such that an ecosystem of systems can talk seamlessly and securely with each other regardless of whether they are vendor-specific or not
What's the take-away?
Low-code/No-code will continue to evolve in order to fulfill the need of rapid and standardised development and implementation of systems. It is likely that a wider blurring will be seen at the edges where there is a gradient between coded in-house applications, low-code, no-code, and off-the-shelf business applications. All of these are and will be required and the balance will be organisation by organisation what equilibrium of trade-offs are most appropriate for their environment.