In today’s highly competitive environment, it can be challenging to fulfill the development and operational demands needed to keep your businesses running while also continuing to expand and enhance your digital capabilities. This is where “citizen developers” can help — and where “low-code/no-code” (LC/NC) solutions shine. In a recent webinar, Cutter Consortium Fellow Greg Smith and Senior Consultant Michael Papadopoulos explored how enterprises can leverage the LC/NC solutions that have relatively low learning curves and provide tools to easily create software to grow and transform the business. In this Advisor, we share some of the answers to questions participants asked about LC/NC solutions.
Q: What's the best LC/NC platform, and how do you choose?
Michael Papadopoulos: There are a number of LC/NC platforms, and from an extremely high level, they offer very similar capabilities and functionalities. It’s difficult to choose the correct one. You will have to ask several questions before selecting the right tool stack for your development needs. There are many factors to consider and their relative importance depends heavily on what you already have, and what you are trying to achieve. For example, if you are a deeply Microsoft house, and you're going for operational efficiency applications, maybe Microsoft Power Apps is the perfect choice for you. If you're on Amazon Web Services (AWS), maybe Amazon Honeycode is the answer. During your discovery phase, you should prioritize your requirements. Figure 1 shares a non-exhaustive list of questions to ask before making a final selection.
Greg Smith: The fundamental principle we want to apply is to unleash the wider capability of the organization. Thus, one of the most important things you should think about when choosing a platform is: What is the context of your organization? What is going to facilitate the widespread adoption of a platform? Because, ultimately, the best platform is the one that realizes the potential of the widest cross-section of your organization to develop their ideas in a safe and predictable way. We always believe that you should look at the starting point and the context rather than making an abstract decision based around “Is Platform A better than Platform B?” The answer to that question almost invariably is, “It depends where you started from.”
Q: How does a culture of DevOps and LC/NC mix?
Michael Papadopoulos: Generally, LC/NC tools fit together in a culture of DevOps because you can have one-click deployments, and you can easily use them for automating tasks through your workflow automation. DevOps with LC/NC generally complement each other because you can build on each one’s strengths. Most of the LC/NC platforms have single-click deployment. That’s a very strong aspect of DevOps. Plus, with the workflow automation part, you can start building your finite-state machines and decision engines using your workflow automation. You can even start to manage your IT and your deployments using your LC/NC tool.
Greg Smith: I think this goes back to the wider predicament that there are far more challenges that can be helped and sorted with software than there are capable software developers within an organization, or within the budget constraints. So the question is not so much, “Is it one against the other?”; it’s “How do you use both to maximize the potential of your organization and to address the most challenges with pragmatic software?” As Michael said, you’re not going to eliminate the skilled software craftsman; the goal is to augment, enhance, and extend the software capability of the business using LC/NC. I think the key is: how do they coexist rather than how do they clash? This is what we should be looking for.
Q: Hacking and nefarious behavior can destroy a company. In the LC/NC paradigm as you described (without much standards and distributed individualized development without oversight), how do you detect criminal behavior?
Michael Papadopoulos: By having the right architecture in place. This is why we are strong proponents of having a tiered architecture installed. The system application programming interfaces (APIs) are what allow access to the data, to both read it and edit it. If your system APIs are done correctly, there should be no data leakage. Users should not be able to connect to the database directly; they should only be connecting through the available system API, and that system API can limit the data provided to the users as necessary. You shouldn't allow users to fetch all rows from your database, but you should allow them to create aggregate analysis sets from your database. Editing data should only be allowed when necessary, and of course, everything is logged and audited. You can have automated approval processes in place so when an edit request is sent, you can ask a human in a sort of augmented decision making, for example, whether that edit is allowed.
Greg Smith: One addition to that is the LC/NC deployment should be consistent with the responsibilities and the access of the person generating that code. We often think about the risks posed by the software process in terms of security and data protection, but of course, we have that risk anyway; we have that risk in the human factors and in the human ability to breach those rules. So, I think the principle we should always look to follow is: do not introduce additional risk through your LC/NC deployment. But by the same token, do not lose the potentiality of LC/NC by applying a different risk framework than you would to the human factor. The two need to be consistent. It's citizen development; it's an extension of the existing sort of rights and privileges of the individual. As long as the two remain consistent, then you should be keeping a similar risk profile.
Q: How do you handle things like CCPA (California Consumer Privacy Act) and GDPR (General Data Protection Regulation) to ensure there's no data leakage with LC/NC?
Michael Papadopoulos: The answer is similar to what I said before. You basically make sure that everything is logged; all data requests are logged, and data requests are only allowed if they are necessary to the business function and load, since the system APIs act as gatekeepers to any data access. Plus, you can build it as part of your workflow. You should do that regardless of whether it's a LC/NC or a standard bespoke application. Whenever there is a data request, there should be some automation in place to make sure that no nefarious things are happening. You should have automated alarms and automated auditing in place. It's easier to build those, I think, with LC/NC.