In part 1 I reviewed the claims that Low-/No- code platforms for building (d)apps make. In this part I will elaborate further on what it takes to be able to develop quality (d)apps and the technical limitations of Low-/No-code platforms that need to be kept in mind doing so.

Domain knowledge and defining what you want is crucial

Low-/No- code might seem the ultimate solution to our development challenges but as with all development or even selection of “Common Of The Shelf” (COTS) tools the key to success first is to have domain knowledge.
Look at it as an offering to develop a transport vehicle, e.g. a car, with repositories of engines, gearboxes, axels, wheels, etc. etc. How do you know what fits on to which? You have to know about car construction and about decomposing the overall use into requirements of all components, their interdependence and their interaction. And what if you want to build a truck and all that is offered are Ferrari engines. What if that engine is just described as "engine" and you don’t know if it’s a Ferrari or a Scania engine or even worse a Rolls Royce Jet engine and you can’t tell the difference?

But even with power users/product owners (a trained and knowledgeable end user) there is a significant risk. Having the power to design, change and improve your application quickly, and without having to put in a change request to IT and wait for the site to be updated, is an almost intoxicating vision. Changes can be made quickly in response to any negative social media or app store feedback, rapidly resolving issues by continually iterating and bettering the customer experience. However, here-in lies the problem. Being able to make changes rapidly means that users/ product owners will do this, but in the pursuit of perfection they can fall into a cycle of tweaking and fiddling with details rather than considering them holistically. Eventually, the pursuit for perfection becomes a costly and futile circle: it not only loses its appeal but ends up just becoming another costly chore that delivers no real business benefit.

Multidisciplinary approach

Domain knowledge is crucial but also the method of defining exactly what you want and determining the sources/processes of information that are needed. Last but not least is to select the right tools to use derived from what you do with it. To select the right one it’s nice to have an overview on what tools are available, their pro’s and con’s. I’ve seen many companies developing custom code for things that were already built into their COTS application but didn’t know about that. I recommend making use of the knowledge and views of others, colleagues, specialists in the domain as much as possible.

This may seem trivial but let me explain what this really means by sharing an experience of my own.
A manager of a large manufacturing company once asked me to develop a dashboard for tracking the monthly percentage of non-conformant and rejected products delivered per supplier; the rejection rate. To him this seemed a simple question because all the data (deliveries, non-conformances/rejections) were already recorded and the math is simple. The calculating of the rejection rate is simply the outcome of the number rejected products in particular month divided by the number of delivered products in that month. It can even be done with Microsoft Excel, right?
Think again:
The time-span between delivery and receiving inspection date of the product and the date of rejection could be several months (as in most heavy machinery manufacturing companies). In this company the supplier products are built into components that are built into modules that are assembled into systems that are assembled into final products that undergo final testing. In every stage supplier products can be found failing or non-conforming. In this case it could (and recurrently did) take 9 months from delivery to final product testing. Therefore, taking the delivered batches of these products in that month and calculating the percentage of the rejected parts of these in that same month wouldn’t make much sense. The conclusion was that the dashboard needed to consist of an accumulated rate over production stages and an end result when all parts of the batches delivered in a particular month were built into final products and tested. Of course, we made a more granular setup, so you could drill down to a certain batch and a certain production stage and even individual products. We also made it actionable by the selection, documenting and tracking of the corrective and preventive measures.
This case shows that you may be offered a simple and obvious solution to your question but look again and beware because this might not be the solution you need. This has nothing to do with the platform but depends on your insight in business processes and/or of the challenging questions you get from the ones/specialists that define the solution with you.
In nearly any case the development of (d)apps needs a multidisciplinary approach. As I said in part 1, the narrative of the Low-/No- code blockchain platforms that no IT or other skills are needed and that end users can build anything they want is misleading.

Technical limitations

Besides the overrated advantages and the challenges they bring, there are a number of significant limitations to using the Low-/No- code software development platforms available today and they may be unable to satisfy the high expectations they are creating. Speed and ease in development is great, but keep the following disadvantages in mind to avoid getting stuck due to unmanageable technical legacies:

• Limited integration options and lack of customization
  You can’t look at Low-/No- code platforms in a vacuum. Whatever platform you are going to use you are bound to use it combined with other platforms. And even when you want to replace all systems for that one platform, in most cases you can’t do this all at once. In both cases you’ll start to run into integration problems (especially with legacy systems). For systems that are core to your business, you can’t sacrifice custom integrations just to move quickly. This as hard as with COTS applications (such as SAP, Salesforce, Dynamics 365, etc.) and may even be harder.
  Data integration is one thing, but the modular components of low-code platforms limit application customization as well. At some point in time you want/need to have a competitive edge (and who doesn’t), you want tasks automated that nobody has automated yet or you want it done in a better way and/or want to be able to adapt it fast to changing circumstances and needs. In that case you depend on customization.
  Most Low-/No- code platforms allow customization but this usually results in dramatically complicated upgrades or even make it impossible to upgrade.
  So instead of customizing the system, although basic capability is possible you’ll quickly be forced to change your business to meet the capabilities of the low-code platform or you have to implement the new upgraded version from scratch.

• Security concerns
  When you build a custom platform, you know you can rely on it because you know it inside and out. With Low-No- code, you take on certain risks because you aren’t in complete control. This is also true for COTS applications, but the low-code platform can be configured and changed by users who have not been trained in cybersecurity counter-measures and practices, your platform may just become even less secure over time. This is a risk you can’t take when the system is part of your core differentiation.

• Maintainability concern: Software architecture
  In general Low-/No- code platforms are focused on speed, ease and flexibility in the development stage at the cost of performance and maintenance during the life cycle of the application. As user requirements, businesses and technologies change over (an increasingly shortening) time is extremely important to build up an information system in a logical and physical (tiered) multilayered architecture. The aim of a layered architecture is efficiency/performance combined with maintainability i.e. minimizing duplicate code and database calls and reducing the impact of changes in one layer on the other layers. Therefore, redevelopment will be confined to only a small part instead of the whole system. Example of a common logical layered architecture is: Presentation layer, Application layer, Business (domain) layer, Data access layer.
  Example of a common physical layered architecture is 3 tier client-server pattern: user interface (presentation), functional process logic ("business rules"), computer data storage and data access are developed and maintained as independent modules, most often on separate platforms.
  On the Low-/No-code blockchain documentation there is little information about the physical layers and little to nothing on logical layers and this could be a writing on the wall.

• Compliance and accessibility
  Businesses have to comply with a growing set of regulations such as GDPR. Certainly, the financial services industry has to keep track on meeting the ever-growing compliance terms. Give the tools to someone who is not an expert in translating these into actual digital steps, including data control specifications, this can end in the creation of a non-compliant offering. Accessibility, equally as important, is also widely misunderstood. We might think we know the rules, but making even the simplest changes to the UX can break its cognitive comprehension, not to mention undo the seamless support for accessibility tools such as screen readers and “eye gaze”.

• Labyrinth of and/or incoherent) pathways
  It is unlikely that a Low-/No- code development platform given to the hands of several different business users and teams will be operated by a single user. There will be several products, several channels and no doubt many business services, offerings of marketing campaigns running concurrently. Empowering individuals working in isolation, or even in the same team, to be able to make changes that apply to themselves will likely unbalance the overall holistic experience from the end user perspective. Changes to flows in one part of the system may not be applied throughout (as one user applies their latest iteration to their part of the customer engagement), leaving inconsistent and incoherent user journeys for customers to have to navigate and stumble over.

In fact, the real question you have ask yourself is; will the benefits, that I think this Low-/No- code development platform will bring, outweigh the compromises that will have to be accepted, both from a capability and security perspective?

Despite these challenges and compromises, Low-/No- code development can play an important role in digital transformation. They excel in proof-of-concept scenarios because you can execute an idea quickly before diving into more intricate development. If you need a short-term answer to a business problem, Low-/No- code can give you a solution as long as you understand that you may most certainly need to tailor or redevelop this custom app to business needs down the road.
When you need a differentiated system, using agile methods of custom development is the better path and that doesn’t mean this is a slow process.

Sources:
https://sparkster.me/
https://appinventor.pevest.com/?p=192
https://www.crowdmachine.com/
https://www.metavine.com/
http://agilepoint.com/low-code-mythology-forresters-big-three/
https://computerworld.nl/development/96159-wat-zijn-low-code-platformen
https://en.wikipedia.org/wiki/Low-code_development_platforms
https://www.techopedia.com/definition/30968/citizen-developer
https://www.phact.nl/documents/forrester-low-code-and-mobile-low-code-wave-report-q1-2017.pdf https://app.cdn.lookbookhq.com/lbhq-production/10213/content/original/dbf8fd0a-b4c8-4b99-88e7-f033f99f6586/Customers_Illuminate_The_Benefts_and_Challenges_of_Low-Code_Dev_Platforms.pdf
http://partnersinexcellenceblog.com/if-a-fool-with-a-tool-is-still-a-fool-why-do-we-keep-giving-them-tools/
https://hosteddocs.emediausa.com/new-forrester-lowcode-development-wave-report-2017.pdf
https://www.pcmag.com/roundup/353252/the-best-low-code-development-platforms?
https://codeless.com/blog/2017/05/29/5-beloftes-low-code-platforms/
https://www.intelligentenvironments.com/the-pitfalls-of-adopting-a-low-code-development-platform-part-1/
https://www.linkedin.com/pulse/pitfalls-adopting-low-code-development-platform-part-2-kevin-phillips/
https://medium.com/back-to-the-napkin/the-risks-of-low-code-for-digital-transformation-f7a4981c9f38
https://www.linkedin.com/pulse/building-blockchain-enabled-app-outsystems-rui-barbosa/
https://ao.gl/approaches-to-software-reuse/
https://en.wikipedia.org/wiki/Scrum_(software_development)
https://en.wikipedia.org/wiki/Model-driven_engineering
http://www.bmc.com/blogs/n-tier-architecture-tier-2-tier-3-and-multi-tier-explained/
https://smarticoinvestor.com/sparkster/