Software development engineers in test (SDETs) have historically relied on coded test automation as the go-to approach for quality assurance. However, coded test automation calls for extensive coding that’s resource-intensive and challenging to maintain. Although it’s based on free, open-source frameworks, coded test automation requires skilled labor that’s scarce and costly — constraints that hamstring overburdened tech teams. 

Fortunately, not all testing requires coded automation. New advancements in test automation are emerging, and codeless platforms present a key opportunity to streamline software testing.

Coded automation not the only option 

Coded test automation still plays an important role in scenarios like unit testing and component-level testing. But the development arena has changed in the last 20 years, underscoring the fact that coded test automation isn’t an optimal approach to quality assurance for certain use cases — like functional testing.

Coded test automation requires skilled SDETs or software developers to not only write hundreds of lines of code, but also maintain them. That’s increasingly difficult to accomplish with engineers stretched thin and employers facing ongoing talent shortages. As a result, many development teams lack the resources to maintain copious amounts of code once an application is deployed. Supporting code for coded test automation is also expensive, especially if the test framework requires regular updates or modifications.

It’s clear that new testing approaches are needed to maintain software quality and keep pace with technological advancements. And codeless test automation is gaining momentum — fast. 

Revolutionize testing with codeless automation

Codeless automated testing platforms are now available in the commercial marketplace, eliminating the need to write code for automated tests. With these tools, quality assurance (QA) professionals who lack coding skills can develop automated tests alongside SDETs and developers.

Some developers may hesitate to lean on codeless automation. After all, many developers have spent the lion’s share of their careers writing lines of code. But coded test automation isn’t going away — it’s just becoming one of several approaches developers can turn to. In fact, coded automation remains critical in many testing scenarios. 

However, for functional testing, end-to-end testing, data validation, and regression testing, codeless platforms offer a streamlined approach for both user interface (UI) and application programming interface (API) testing that can cut costs and reduce time-to-market.

Consider the benefits that codeless automation can provide:

• Reduced reliance on technical expertise: Codeless testing platforms enable developers to shift testing responsibilities to QA teams, who can focus solely on testing rather than coding and debugging. Codeless platforms also help free up developers’ time and empower them to focus on new technologies and complex software development.
• Accelerated development cycles: Codeless platforms enable QA teams to use pre-built and visual components to develop automated tests, which is a much faster process than writing net-new code. This enables testers to create more test cases in a fraction of the time, which increases test coverage and results in higher quality software. An added bonus? Shorter development cycles also reduce costs.
• Easier maintenance: Codeless testing eliminates the need for programming skills that are typically required to maintain and update coded test suites. This makes maintenance faster and easier when an application changes. Some codeless automation platforms even have self-healing capabilities that enable the testing tool to automatically fix test scripts or test cases when a test fails or the software changes.

There’s always a learning curve when adopting a new approach. But the barrier to entry is low and the rewards are high when it comes to deploying codeless test automation tools. In the current no- and low-code era, the swift pace of innovation demands agile and efficient workflows.

Consider all the factors when determining whether codeless automated testing is right for a specific use case, from resource availability to the category of testing required. But when you discover codeless is the right fit for a use case, your entire team can test faster with greater efficiency and coverage — ultimately reducing time-to-market for new products while maintaining product quality.

The post In the low-code era, codeless testing tools deliver the efficiency and profitability coded test automation can’t appeared first on SD Times.

Low-code and no-code tools enable development teams to speed up their time to market by reducing the amount of code that needs to be written, enabling reusable code blocks, and automating things like testing and security.

Though we at SD Times primarily cover the software development industry, low-code cannot be confined to just one department. In fact, Gartner predicts that by 2026, 80% of the user base for low-code tools will be non-IT users. These days, you can find low-code tooling in the hands of accountants, HR professionals, business analysts, and more. 

Clearly, low-code has proven its worth. That’s why, for the third year in a row, we’re hosting Low-Code/No-Code Developer Day, a free virtual event taking place on 4/12 where you will learn all about how you can apply these tools in your own organization.

The event will kick off with a keynote from Jason English, analyst at Intellyx, who will first attempt to break through all the marketing buzz and get down to what functionality you should be looking for in tooling. 

Other sessions will focus on: 

• The specifics of low-code for developers, with Joyce Lin at Postman
• How to correctly set up your low-code environment so that you don’t have to redo things later on, with Kevin Lewis from Directus
• How low-code can be used to abstract away the complexity of cloud native, with Jonas Bonér of Lightbend
• A real world example from the IT director of a manufacturing company which has built 28 apps using low-code tools to automate manual processes, resulting in app maintenance time being reduced from 50% to 10% of time, 4-10x faster development, and $350k/year in savings.  

And you won’t just leave the conference with abstract thoughts to ponder on. We’ve also got two hands-on sessions planned. You’ll have the opportunity to learn how to better master your data with Microsoft Power BI and how to use the open-source low-code programming language Ballerina. 

Join us on April 12 for this free event by registering here. 

The post How to level up your low-code game appeared first on SD Times.

Low code is one of the solutions that can be utilized to combat some of the challenges that may be arising as a result of the current economic climate. 

According to Gartner, the low-code market will grow 20%. By comparison, Gartner also predicted a 5% increase in the IT sector as a whole in 2023.  

Gartner defines the low-code market as being made up of a number of different technologies: application platforms, robotic process automation, integration platform as a service, and citizen automation and development platforms, to name a few. 

The largest market segment within low code is application platforms, but citizen automation and development platforms are the fastest growing segment; they are expected to grow by 30% in 2023. Low-code application platforms are those that minimize the use of coding needed to create an application, while citizen development platforms are used to enable people who are not formal developers, such as an accountant or HR representatives, to create applications, according to Gartner. 

By 2026, Gartner predicts that citizen developers will make up at least 80% of the user base for low-code platforms (in 2021 it was 60%).

“The high cost of tech talent and a growing hybrid or borderless workforce will contribute to low-code technology adoption,” said Jason Wong, distinguished VP analyst at Gartner. “Empowered by the intuitive, flexible and increasingly powerful features of low-code development tools, business technologists and citizen technologist personas are developing lightweight solutions to meet business unit needs for enhanced productivity, efficiency and agility — often as fusion teams.”

John Bratincevic, principal analyst at Forrester, has seen that a lot more companies are investing in citizen development, and he expects this trend will continue. At the end of last year, he published a case study on how the oil and gas company Shell Plc has scaled its citizen development program to over 4,000 employees.

Making DIY a priority

One of the keys to their success, according to the report, was that they have a centralized Center of Expertise and hundreds of distributed DIY coaches.  Cultivating small communities of citizen developers throughout the organization was important to their success. 

In the next phase of their citizen developer journey, Shell plans to double the number of citizen developers and make DIY a priority in IT budgets. 

“It seems like a lot of companies have gotten much more serious about citizen development, as I described. So I expect to see more of those programs actually hitting scale,” said Bratincevic. 

He recalled a recent conversation with a financial company where they had 10-15 accountants using low code to create applications. He asked why they didn’t just hire a consultant to come in and build something for them and the response was that they “didn’t have $5 million lying around for so-and-so to come in and do this for me.”

“To her, it made a lot more sense to have her subject-matter experts to build these very important sophisticated applications, rather than pay consultants a bunch of money to do it on whatever product coding or logo,” said Bratincevic.

When low code first started gaining popularity, it was common for citizen developers to use it to create a simple app to automate part of their workflow. 

Now, it is being used to create a wider range of application types. It’s not uncommon to see it used for customer-facing applications, Bratincevic said. 

“They’re increasingly a general purpose replacement for coding for a range of application use cases,” he said.

People will expect AI in their low-code platforms

The emergence of ChatGPT showed people what’s truly possible with AI. Bratincevic expects that users will now demand AI capabilities in their low-code platforms. 

“You and I actually have AI features in our normal tools that we don’t even think about,” he said. “So for example, when you’re using PowerPoint, and it suggests a layout, that’s AI.”

According to Bratincevic, examples of companies who are vocal about having these capabilities in their low-code offerings are OutSystems and Microsoft. 

“I think it’s like anything else, it’s just going to make people more effective and faster, and help them learn things more quickly, right? Just like developers go out and grab code off the internet. Now they’ll grab code from some kind of feature the platform has, and I think it’ll be practical and useful,” said Bratincevic. 

Market forecast

• Gartner predicts a 20% increase in low-code spending in 2023
• They also predict that citizen developers will make up at least 80% of the user base for low-code platforms by 2026
• Forrester predicts more low-code platforms to incorporate AI features to make development easier

The post Low code spending to increase in 2023 appeared first on SD Times.

Users can use it to build complicated front ends without any experience in React, CSS, or event HTML. They can also drag and drop over 35 built-in UI components for more complicated frontends. 

With ToolJet, developers can also verify the current properties of components, queries, and global states of applications. In addition, every app can have multiple pages linked with one another.

“We were looking for a low-code platform to migrate our team processes previously based on worksheets. By using Tooljet, we have been able to shorten significantly the design and development time of our tools and enrich their functionality. Moreover, the Tooljet team has always been reactive and keen to address our requests on the fly,” Francois Xavier Lecarpentier, head of research production management at Orange said. 

The solution is enterprise-ready with audit logging, permission and access controls, air-gapped deployment, priority support, and the ability to integrate with Okta, AzureAD, Google

or OIDC for a seamless authentication.

The company behind ToolJet (also named ToolJet) recently raised $4.6 million in a Pre-Series A funding round.

The post SD Times Open-Source Project of the Week: ToolJet appeared first on SD Times.

What is no-code?

Simply put, no-code and no-code platforms allow non-developers to participate in the application development process through visual drag-and-drop tools. Users can visually compose the forms, workflows, and data needed to build an application without understanding a programming language or having formal software development training. 

This has the potential to vastly expand the supply of talent by enabling millions of non-developers with the ability to address application backlogs. Though no-code approach requires knowledge of the business process or domain, it does not require formal training in software development.

No-code development framework

While no-code shares some learnings with traditional software development, such as Agile or DevOps practices, it would be a mistake to simply treat no-code the same as other ways of development. With no-code, it’s important to tailor the development practices in a way that builds on the unique strengths of no-code platforms, which automatically take care of many technical details and spare you many common troubles associated with traditional development. 

Furthermore, the fact that no-code brings non-developers more directly into the app-building process also means that you should expect a different set of skill sets and backgrounds to be part of a no-code team.

Therefore, Creatio has developed a step-by-step methodology – described in Creatio’s No-Code Playbook – to organize the no-code development process by business-led and fusion teams. The No-code Playbook helps organizations embrace an efficient, lean, and iterative development process by empowering non-technical professionals to deploy business applications without deep technical and coding skills.

The 3 phases and 12 stages of the no-code development lifecycle

The no-code development lifecycle consists of 3 phases, which in turn include 4 stages each. Phases represent logically distinct domains of a no-code project and happen in a sequential manner, while stages within a phase are more interconnected and can even happen in parallel in certain circumstances.

The 3 phases are the following:

1. Design phase: covers defining the business requirements and success criteria of your app, envisioning its broad design, and scoping the MVP.
2. Go-Live phase: addresses building and releasing your initial app.
3. Everyday Delivery phase: covers the process of measuring the performance, delivering ongoing enhancements, and managing the evolution of your no-code app.

The 12 stages, which are described below, can therefore be easier understood as 3 logical blocks: stages 1-4, stages 5-8, and stages 9-12.

Stage 1: Business Use Case

The Business Use Case stage can be the most important part of the entire lifecycle because it helps identify your target and how you will measure success. Resist the temptation to skip or rush through this process. Instead, thoughtfully identify as clear of a definition as possible — this will act as the “true North” that will keep the team on track throughout the project and the evolution of the app. 

At its most simplistic level, the business use case should define the following: no-code stakeholder, business process, process use case(s), process consistency, and success criteria.

As you start turning the business use case into a high-level architecture for your application, you’ll need to start making some key choices. How do you pick the right components? These are tackled at the stage 2.

Stage 2: Options Analysis

In the traditional software development, options analysis is, typically, a choice between “buy” and “build.” In most enterprises, there is a mix of both as each option helps optimize for slightly different outcomes. Packaged applications (“buy”) help you accelerate your time to market but may constrain you to fit within a defined process or UX provided by the application vendor. Custom development (“build”) will help you meet even the most demanding customer requirements, but the process will take you longer as it comes with the inherent risks of building from scratch.

When you use no-code development for building software, you can have the best of both worlds in many cases. On one side, you can accelerate your time to market by using configuration tools, prebuilt components, and templates. On the other side, you can also meet and exceed even demanding enterprise-grade requirements by leveraging the extensibility of the platform.

Therefore, in the no-code development, the basic idea is to strive for “composability” — using as many available no-code building blocks as possible and further customize them for perfect fit. Usually, prebuilt components – as well as connectors to third-party solutions – are provided by the no-code vendor or its community via a marketplace. 

Now that you’ve selected the right approach to your solution components, you’re ready to start actively designing. What no-code design best practices should be followed and how “deep” do you go? This is the purpose of the stage 3.

Stage 3: Design and Prototyping

Instead of putting the functional requirements into an intermediate document and then translating it into code at a later stage, the functional requirements and design process in no-code development are much more efficient and streamlined. A no-code architect should define an application with all the needed parameters using the no-code tools (e.g., fields, dashboards, UX/UI, and workflows) and make changes on the fly when presenting and evolving a prototype. Unlike traditional prototyping, with no-code, you’re building the software itself. It’s not a simple low-fidelity wireframe or some type of “throw-away” clickable prototype — you’re building a working iteration of the final application.

The Design and Prototyping stage should be performed using the no-code platform visual tools themselves. This allows for rapid ideation cycles where the design effort more directly and immediately can be tested with end users.

If used correctly, this powerful approach to no-code design will help you prepare for the “unknown future” by allowing you to experiment, collect feedback, and iterate rapidly to ensure alignment with the business vision. As soon as you’ve validated this vision, you can change gears in the stage 4 and begin to define the successful steps that will get you to your destination.

Stage 4: Project Assignment

The Project Assignment stage defines the target scope of your no-code app that you will be building in the next 4 stages. At a high level, it includes the following activities:

• Decomposing the business use case into smaller use cases.
• Selecting and confirming which of these use cases will be included in the initial Go-Live scope.
• Ensuring that the scope aligns with any timeline constraints established by the business function.
• Defining the necessary roles and participants in the project.
• Preparation for enablement of the release (including identification of power users, scheduling of governance checks, planning enablement, selecting the right set of environments, etc.).

When you focus on perfection and completeness, you risk trying to “boil the ocean” by including too much in the first release. It’s key to mitigate this risk by staying “on target” and focusing on an MVP that delivers “just enough” features to test value early and adopt an incremental approach to adding functionality over time. Yet, you can’t build incomplete feature sets — each step of the journey must still be incrementally valuable, usable, and delightful. That is the art of defining the MVP release, which is the goal of the stage 5.

Stage 5: Prototype to MVP

The Prototype to MVP stage starts by focusing on the rapid delivery of the initial Go-Live release, which was defined by the prior Project Assignment stage.

Unlike traditional software development, we aren’t starting from scratch. First, no-code platforms provide a significant amount of the underlying infrastructure. This allows you to focus on the business functionality that you want to build, rather than worrying about building technical and application frameworks. You also accelerate the process by “inheriting” the working prototype that was built during the earlier Design and Prototyping stage. We start by extending the available prototype, which allows us to save a lot of time and minimize the risks of misalignment.

The most important thing to take away is to stay focused on releasing the MVP as quickly as possible. It doesn’t have to be perfect — it shouldn’t be because the quest to find perfection will distract you from the core mission. Instead, it would help if you embraced the power and speed of no-code platforms — take advantage of them by adopting an efficient, lean, and iterative approach that fully uses its unique strengths in accelerating development. Now, concurrent with the MVP development, you should also be collecting feedback.

Stage 6: Feedback Loop

Rather than delaying feedback to the end, no-code allows you to take advantage of a more continuous feedback model. Instead of feedback only happening at one point in time, we collect constant interactions and approvals by the stakeholder to ensure alignment throughout the development process. This may happen as often as a few times a day! So, this stage actually runs concurrently with the prior “Prototype-to- MVP” stage.

In no-code development, gathering feedback should be an ongoing and continual process. This allows you to respond to feedback more readily and ensures alignment with stakeholder needs. You won’t know for certain what the user wants unless you ask — and the sooner (and more often) you ask, the more successful you will be! 

You’ve finished development and revised it with a continuous feedback loop — you’re almost ready to release. However, before you deploy, it’s important to ensure the app has met the required governance and compliance reviews.

Stage 7: Governance checks

This is a critical step of the review process to ensure your app has successfully passed the applicable checklists and is ready for production release. This typically includes reviewing the following:

1. External compliance checklists to assess compliance with external laws, guidelines, or regulations imposed by government institutions, industries, and organizations. 
2. Internal compliance checklists imposed by internal audit teams or committees to enforce adherence to rules, regulations, and practices as defined by internal policies and access controls.
3. Security checklists to protect your corporate information resources from external or internal attacks.
4. Data governance checks to assess how sensitive corporate data is managed and secured.

Stage 8: First release

This stage is where the application is released to production to end users. The release process is typically straightforward in modern no-code platforms — they adopt the “continuous deployment” philosophy and use automation to deploy features quickly and seamlessly across environments in an on-demand fashion. However, there will be variations in the number and type of environments as well as in the specific steps of the continuous deployment workflow. The scale and complexity of the release will be driven by the Application Matrix – a tool for application complexity assessment used throughout the no-code development lifecycle – which helps define the appropriate level of sophistication needed. Finally, there are associated operational/support readiness activities and end user onboarding/enablement activities that will be needed for the first release of the application.

The previous stages of the No-code Lifecycle have ensured the application has met all of the stakeholder, user, and governance requirements. However, there are still some final steps to prepare the business function to use the application, including the following:

• Documentation and application guides
• Deployment
• Validating environments
• Final user acceptance
• Support and monitoring
• User onboarding and enablement

As end users are onboarded, there is also usually some associated enablement activity required to support effective adoption. Besides traditional training and enablement techniques, it is recommended to adopt a model of continuously retraining the users based on the “Everyday Delivery” approach. Also, it is suggested to use certifications and testing to confirm their ability to fully utilize the system specifically for complex enterprise-grade apps.

Stage 9: Feedback collection

Feedback is an important stage as this is the first time when the no-code app will likely start having daily usage by real end users who are fully vested in the app working because it enables them to perform their job function. They will let you know when the app isn’t working right! View all types of feedback — even if it is critical — as a good thing because it will help you continue to improve and enhance the app.

Feedback collection is essential to evolving your no-code app, but it’s important that you’re gathering the right feedback — through a combination of stakeholder, user, and system feedback — while taking a varied approach to input collection.

Stage 10: Incremental improvements

It’s tempting to focus on achieving perfection all at once — but that is an unachievable goal. Instead of trying to address all requirements, expectations, and suggestions, it’s better to strive to continuously improve daily based on real-world feedback. This allows you to make progress toward your goal while also continuously learning and adapting along the way. 

In this stage of the lifecycle, you should focus on the following simple steps:

1. Analyze and decompose use cases.
2. Prioritize and approve micro use cases.
3. Review design considerations.
4. Build/test enhancements.
5. Review governance checks.

Stage 11: Everyday Delivery

One of the key principles behind Agile is the notion of continuous delivery of value. Yet, too often in traditional software development, we get stuck in having to conform to defined release sprints or iterations. A key differentiation of the no-code approach is accelerated time-to-market. The modern platform capabilities empower no-code teams to deliver sufficient outcomes daily to end users. 

The spirit of the Everyday Delivery stage is striving to provide rapid updates to the end user and maintaining a high velocity and ongoing improvement cycle. The deployment can be based on a specific feature or set of features without a need to connect it to a specific sprint deadline or other formal milestones. To establish this mode of continuous delivery, it’s critical to appropriately decompose and scope your work items so that you can rely on the higher degree of deployment automation provided by no-code platforms. This allows for quick, small updates to be pushed to production frequently (perhaps daily) while maintaining higher levels of quality than traditional “big bang” software releases.

Stage 12: Application Audit

Initially, the Application Audit is likely performed by the no-code team and is reported to the no-code stakeholder. However, as the number of no-code apps increases and as you develop more business-critical apps, the audit function generally will become part of the responsibilities of the Center of Excellence, which is an internal team whose mission is to maximize efficiency through consistent adoption of best practices for no-code development across the organization. This will help look across the organization to measure and improve overall levels of efficiency, effectiveness, and business impact. It will also help identify reusability opportunities (a key concept we’ll address shortly). However, regardless of who performs the audit, it’s important not to miss any key steps:

• Auditing app performance
• Auditing feature obsolescence
• Auditing organizational changes
• Auditing governance changes 
• Auditing component reusability

These final measurement steps are key to any continuous improvement cycle, and the Application Audit stage ensures that the app stays relevant to the business.

Final touches

Many organizations are looking for the best ways to define and operationalize their digital transformation strategy. Don’t think of no-code as a separate or distinct agenda, instead, connect it directly to digital transformation. No-code can operationalize and scale the building of digital applications across your enterprise. While it’s possible to pursue digital transformation with traditional custom development techniques, you will find that no-code can dramatically accelerate your ability to bring new ideas for digital innovation to the market. Explicitly advocating no-code as part of the digital transformation toolkit will help you achieve quick wins. It can also help build momentum and add additional resources to support the adoption of your no-code platform and tools.

The post The phases and stages of the no-code development life cycle appeared first on SD Times.

ODC combines an architecture based on Kubernetes, Linux containers, microservices, and AWS native cloud services with CI/CD, enterprise-grade security, and the productivity of low-code. 

It utilizes AI-augmented development through AI Code Mentor, which helps contribute to productivity as well. 

According to OutSystems, customers can achieve High-Performer DORA status when it comes to DevOps and CI/CD practices by using the platform. 

OutSystems hopes the platform will enable IT leaders to continually develop solutions that are based on their goals and requirements, facilitating a “continuous innovation cycle for business growth, scale and competitiveness.”

“Our new OutSystems Developer Cloud will be familiar to our existing customers, and mind-blowing to those who have ever used traditional low-code or not left the traditional development lane,” said Gonçalo Gaiolas, chief product officer at OutSystems. “Kubernetes, cloud-native and microservices are technologies that customers struggle mightily to master. It takes months to years and millions of dollars to implement a typical application platform – all before developers can even begin building their first application. With ODC, we’ve done all the hard work for customers so they can take advantage of these state-of-the-art technologies and begin writing their applications on day one.”

The post OutSystems expands low-code platform with cloud-native development offering appeared first on SD Times.

It’s not that low code is more risky than traditional code, but the same risks are there, Jeff Williams, co-founder and CTO of Contrast Security explained. These include things like authentication, authorization, injection, encryption, logging, etc. 

Even developers who spend their whole days writing code have very little security training, for the most part, and often they don’t even have much communication with the security team. One main difference between the two groups is that citizen developers might be more likely to accidentally introduce a security risk, explained Williams. 

RELATED PODCAST: Low-code and the relationship between citizen developers and security

“I would expect citizen developers will make a lot of the basic mistakes such as hard-coded and exposed credentials, missing authentication and authorization checks, disclosure of PII, and exposure of implementation details,” said Williams.

According to Mark Nunnikhoven, distinguished cloud strategist at Lacework, access to data is also a big issue to consider, especially when you’re giving citizen developers access to data in systems they hadn’t previously encountered. It’s important to both restrict access to only what is needed and teach citizen developers the appropriate use of the data connections they have access to. “We don’t teach you like, ‘hey, you’ve got access to all of our Salesforce information and here’s what appropriate use looks like.’ We just say, ‘oh, you’re in sales or in marketing, and you should have access to that, so here you go.’” 

Nunnikhoven explained that this is a huge problem in low-code development because suddenly low-code developers have the ability to access and manipulate data and connect to other systems, and if they don’t understand the appropriate use of that, they won’t understand the inappropriate use of it either. 

“I think that’s the real challenge with these platforms,” said Nunnikhoven. “It’s exposing a gap in our information management or our information security programs that we don’t often talk about, because we’re so focused on the cybersecurity and the nuts and bolts of how we secure digital systems, not the information in those systems.”

Jayesh Shah, SVP of customer success at Workato, also advises customers to develop a certification program specific to the low-code platform that will be in use so that the people who will be working with it understand the capabilities and can more easily stay within the policies and guardrails laid out by the company. 

Process of security doesn’t change much

Even though the way of building the application is different when you’re talking about low code versus traditionally coded apps, the process of security should be the same. 

“Fundamentally the challenge for companies of all sizes is to define their specific level of security, test against that definition, and fix problems,” said Williams. 

He recommends that companies set guidelines for exactly how they will use the platform. For example, how should users be authenticated? How is input validated? How are credentials stored?

After setting these guidelines, it’s important to test to ensure that developers are implementing them. These tests can be automated using instrumental application security testing (IAST), which analyzes the entire application as it is assembled. Methods like static application security testing (SAST) and dynamic application security testing (DAST) might miss real issues and report false positives, Williams explained. 

In addition to having good policies within your company, the low-code platform itself can also minimize security risks. For example, according to Shah, the platform can incorporate its own security controls, such as requiring citizen developers to work in sandbox environments or limiting their options.

According to Shah, one area in which low code may have the edge over traditional code is that when a new vulnerability is discovered by the security community, custom software isn’t likely to be updated in a timely manner, while a low-code platform could be updated by the vendor to minimize or remove that vulnerability, Shah explained. 

“The low-code platform can ensure that the platform components it provides do not have security vulnerabilities and are patched and updated as necessary to benefit all users globally,” he said. 

Shah added that while traditional development might offer greater flexibility in terms of what can be created, that freedom also brings a broader level of responsibility. Custom software often incorporates third-party or open-source components, which are notorious for being weak points for vulnerabilities, he noted. 

OWASP Top 10 expands to low-code

The OWASP Top 10 is a list of the ten most common security vulnerabilities in code. Recently, work began on an OWASP Top 10 list specifically for low code, with the same idea as the original guide but focused specifically on low-code risks. 

“You as an organization that is adopting low code/no code should be able to look at the OWASP Top 10 and say, ‘Here are the main security concerns, as agreed by the experts in the community, how am I going to address these within my environment?’” said Nunnikhoven. 

Here are the top 10 risks specified by the guide at the time of this writing: 

1. Account impersonation
2. Authorization misuse 
3. Data leakage and unexpected consequences 
4. Authentication and secure communication failures
5. Security misconfiguration 
6. Injection handling failures
7. Vulnerable and untrusted components
8. Data and secret handling failures
9. Asset management failures
10. Security logging and monitoring failures

In theory the OWASP list would give companies a set of items to focus on in their security strategies, but Williams, who created the original guide back in 2003, said that’s not really the case, unfortunately. He said that’s what he thought would happen when he wrote the guide, but that he’s “still waiting” for that. 

He added: “I think OWASP helps to raise awareness and understanding around risks, but it doesn’t seem to translate into a significant decrease in vulnerabilities. I think it only really works if platform vendors take the advice and build better guardrails into their own specific environments.”

The post Low code doesn’t necessarily mean low security risks appeared first on SD Times.

ABAC has low-code/no-code interfaces for building permissions into applications, which allows any team at a company to incorporate permissions, not just developers.

According to the company, ABAC includes all elements required for enforcement, gating, auding, approval flows, impersonation, and automating API keys. 

Permissions can be based on a number of different attributes, such as geo-location, subscription status, billing status, usage metrics, and relationship to the resource owner. 

“When you first build an application, setting up permissions is more straightforward: you just have a single service and a few users, and what they can do is based on their role within the organization,” said Or Weis, CEO and co-founder of Permit.io. “This is what’s known as Role Based Access Control (RBAC). But as your application scales, Attribute Based Access Control (ABAC) is necessary to fully address all of the different use cases for your company and your customers. Building and maintaining an ABAC system yourself is incredibly complex and time consuming – which is why we’ve spent the past two years building a low code platform that makes it simple.”

The company launched earlier this year with $6 million in seed funding. Along with Weis, Asaf Cohen, a former software engineer at Facebook and Microsoft, is also a co-founder. They based the company on the open-source project OPAL, which the two created. 

The post Permit.io launches low-code Attribute Based Access Control as alternative to RBAC appeared first on SD Times.

While low-code development has had varying reception and pushback from professional developers, the technology is clearly the future. According to Gartner, by 2024, 65% of app development will be handled via low-code. And just a portion of those apps will be created by citizen developers. As more people realize the productivity potential of low-code development, the number of professional developers who embrace it will continue to rise. 

In this article, I’ll detail how low-code platforms are transforming the role of professional developers and how they work. 

Low-code can automate and accelerate processes

As application development becomes more complicated and developers have even less time, low-code platforms can be a lifeline.

For example, consider process automation, which is a very well-defined application pattern. Rather than building an entire Java app or script to manage data or automate a process, developers can leverage low-code platforms to quickly spin up apps that are effective and agile. 

This approach is particularly important in situations where business customers are looking for a quick fix to a pressing problem. Of course, low-code solutions don’t have to be ends in and of themselves; instead, they often serve as capable prototypes, allowing developers and their business partners to evaluate functionality and results before dedicating resources to more robust solutions.

Low-code lets developers focus on big picture business problems

Software engineers get into app development because they want to solve complex, critical problems. But instead, many become firefighters where the job of an app developer can often devolve into building reactive, short-turnaround solutions or writing tedious, labor-intensive boilerplate code. 

Low-code platforms offer them an escape. Through these tools, developers can cut back on the time they spend working on simple programming challenges, allowing them to focus on writing more creative, complex code necessary to address bigger and more strategic business issues. Low-code enables true business agility, allowing developers to spend more time focusing on “how” and less time thinking about “what.”

Low-code empowers citizen developers

Finally, let’s talk about citizen developers. One of the reasons to be most excited about low-code development is that it puts innovation into the hands of every employee, not just developers or IT teams.

Through low-code development, employees across the business can have a more direct hand in the design and development of solutions to their biggest problems. As a result, solutions are both higher quality and more aligned with the specific needs of the business. This is especially key for more complex applications or business needs, where developers can lack the deep expertise of their business partners. 

This development should be an exciting one for IT teams. By empowering more employees across the business, low-code development has the power to transform how business problems are solved. Development is a team sport and low-code development can break down silos with its ability to broaden collaboration and expertise between IT and the business.

This, again, gets to the central promise of low-code: when employees can solve their day-to-day challenges, developers can focus on the bigger, more strategic issues facing the business. 

Conclusion: Low code, high satisfaction

Ultimately, one of the reasons why low-code development matters is that it can fundamentally transform the role of a developer. By streamlining or eliminating tedious tasks, low-code development can reduce developers’ daily frustrations and dramatically improve their relationships with their jobs. 

With surveys showing that upwards of 80% of developers feel burnt out as a result of overwork and inefficiency, low-code development can play a key role in improving developer well-being. 

The post Think low-code is just for citizen developers? Think again appeared first on SD Times.

Until recently, analysts would lump low-code in with no-code and a host of tools offering some form of drag-and-drop ease that enables ‘citizen developers’ (meaning: non-developers) the means to deliver apps. But where should you start in thinking about your own enterprise’s journey to low-code?

Looking at the rate of investment and vendor acquisition in the low-code solution space, it seems like this arena has never been hotter. But in another sense, it’s always been with us.

Ever since the first desktop applications appeared, software companies have sought a way to endow professionals who didn’t have the time or inclination to learn C with the ability to build and design functionality.

Before RAD and 4GLs appeared on the scene, there was Visio and some VB tools on Windows, and Hypercard on the Mac. Even Excel started a revolution among skilled spreadsheet wizards armed with a few macros. These early forms of low-code were pretty localized in orientation, predating the explosion of content yet to come via internet services.

Low code is on a continuum 

According to my colleague Jason Bloomberg, low code is on a continuum between no code (tools requiring no coding at all) and pro code (tools that ease developers in reusing code or leveraging development skills).

There are parallels between the low-code spectrum of ‘assisted development’ solutions and the closely related business process automation and testing spaces, which share several commonalities, including a business user-centric or ‘no-code’ point-and-click simplicity on one end, and an engineering-centric ‘pro-code’ side.

In fact, we have seen several assisted development players arise from testing or automation tools that found their stride in low-code.

What will drive further low-code adoption?

Low-code solutions arose from the natural desire of every business to get ‘all hands on deck’ and become productive in delivering on the needs of customers, given constrained IT resources and budgets.

Beyond that desire, there are several major challenges that call for a low-code approach:

Maintainability. By far, technical debt is the granddaddy of low-code challenges. The need to maintain existing systems and retire or refactor obsolete or malfunctioning application code takes up the bulk of most established companies’ IT resources.

Low-code tools must add features that are modular, interoperable and especially maintainable, so developers aren’t left trying to pick up the pieces within a muddled, object-disoriented code dump.

Integration. Many low-code tools started out from an integration perspective: allowing teams to stitch together and move data between multiple tools or services to provide new functionality that wasn’t readily available before. 

Low-code solutions should include both internal core systems and external services into workflows, without requiring users to understand how to construct their own APIs. Always try digging past the ‘wall of logos’ and make sure the CRM or OMS you already own can be effectively supported for end customers.

Security. SecOps teams are extremely resource constrained, and have difficulties figuring out exactly how to authorize conventional development teams for environment access, much less giving low-code citizen developers appropriate access.

Ideally, modern low-code solutions can ease this security management burden, with role-based access controls assigned for team and functional responsibility levels. Fail to do security right, and you will either get hacked, or get Rogue IT as teams run off to do-it-anyway without draconian oversight.

Functional integrity. Manually coded processes and rote processes hidden within monolithic silos need to be rebuilt by business domain experts inside the prospective low-code platform.

Whether the new functionality is vertical or horizontal the low-code platform should provide adequate ‘safety bumpers’ in the form of pre-flight testing and early monitoring and feedback, so owners can be alerted if any application is going off track.

The Intellyx Take

If low code was just about reducing labor costs or IT resource constraints, the space would gradually be consumed by adjacent development tools becoming easier to use, or automation tools becoming robust enough to define applications. 

Bringing the intellectual capital of business expertise to bear within our application estates might just be the biggest game-changer for the future of low code. Wherever the code road ends, a new opportunity arises.

Hey, thanks for reading! Why not watch my archive of the latest 2022 LC/NC Developer Day session now?

The post Hopping on the low-code locomotive appeared first on SD Times.