Posted on

Security Automation’s Next (and Best) Evolution Is No-Code and Here’s Why

The biggest challenge I saw in my 15 years as a security practitioner and overseeing security teams was analysts' time consumed by mundane, repetitive tasks that were taking them away from doing the work their skills suited them for, leading to burnout and human error. That's why automation has the potential to help reduce the load of overworked teams by automating low-value tasks and freeing up those analysts for more high-impact work, like improving an organization's security posture.

However, that potential hasn’t been realized with traditional approaches to automation — but it is with no-code automation, which brings increased value, productivity, and efficiency security managers teams are looking for.

Posted on

Low Code and No-Code Considerations

Low-code and no-code development platforms have been the trending IT topic for some time now. Experts in this field speculate as to how they could change the future of the industry. Some publications predict the gradual decline of traditional IT, as low-code and no-code products continue to reshape the very approach to solutions development. But, before we get into a discussion on the future of low-code and no-code, let’s define what these terms actually mean.

What Is Low-Code/No-Code?

Low-code and no-code tools help scale and maximize software delivery. The grid below explains, defines, and differentiates low-code vs. no-code tools.

Posted on

No-Code: An Emerging Technology

COBOL was taught to me as a programming language that can supposedly be used directly by businesses, rather than businesses contacting programmers to write the code. For people who have never tried COBOL, you write programs called “Essays” with “Paragraphs” with a lot of capital letters and with whitespace margins on the left. The software industry always has this fascination with no-code technology. They want businesses to be able to create software that is not lost in the translation. This clearly proves the point that building software is not a technology problem, but rather a communication problem when it comes to actually using the technology.

The closest anyone has gotten to success with a no-code tool is none other than with the infamous Excel sheet. Why is it so successful? — because the data, formula, and outputs were close to each other, and the software required users to overcome only a very small learning curve. Business people who started using it turned it into a personal software that does a lot of things for them but is not useful to put to use even in simple production scales or to customize it for others. I have been given Excel sheets during the requirements phase and asked to transform that into software that can be used and extended as well. So though it worked, it could not scale to be a full-fledged software.