Ten Things for CIOs to Avoid When Considering High-Productivity/Low-Code Platforms

Businesses demand that developers deliver more apps faster than ever and for that they need the tools and platforms to meet expectations. A high-productivity/low-code platform is a viable solution to speed development while giving developers the control they need to do their best work. But with all the noise in the marketplace, where do you begin? In this article, Mark Troester cuts through the racket with a unique tack—what not to do.

High productivity/low-code application development platforms are growing in popularity, with the ideal being a serverless cloud platform that integrates open source frontend frameworks with a low-code backend that enables out-of-the-box integrations with enterprise and legacy systems. When considering a solution, here are ten key things to studiously avoid:

1. Don’t let Industry Categories Constrain Your Technology Choice

Technology choices have accelerated to a dizzying pace—too fast for static categories. Some categories are too narrowly defined, some overlap, while the analyst community often disagrees about definitions and scope. While all these industry categories can be a good source of reference, what’s important is clearly understanding your own technological and business requirements. In addition, consider all your needs holistically. For instance, don’t think about web and mobile separately or new development vs. modernization separately, or about your CMS efforts in isolation from your development. If you take that approach, then the industry research can be very valuable.

2. Don’t Rely on Proprietary Tools or Scarce Development Resources

This second point might seem obvious considering open source, industry standards and the financial impacts of using high-priced niche developers versus affordable and plentiful talent. But just because a platform vendor promotes their use of standard languages, that doesn’t mean they don’t have a proprietary development process.

Developers need transparency, so don’t pick a solution that hides the implementation, or makes it hard for developers to interact with the code. Consider also the tools you have today and how low-code will fit with your existing investments—the last thing you need is to add a silo that runs at right angles to your current practices.

Finally, don’t get tunnel vision on a single aspect of the development environment—consider the entire lifecycle, the entire toolchain, etc.

3. Don’t Antagonize Your Developers

Low-code platforms are evolving to increase developer productivity, but there’s confusion distinguishing between low-code platforms for professional developers that streamline and simplify their work, and no-code platforms for “citizen developers,” enabling them to build functional but limited apps without having to write code.

As one developer wrote about no-code platforms in a recent Progress survey, “It’s hard to trust black boxes.” Other noted concerns were security, lack of flexibility, fit for POCs only and problems with customization.

Rather than forcing developers into proprietary and inflexible systems, capitalize on their existing skillsets. JavaScript can be a powerful solution as it remains the top-ranked language in many developer surveys. Moreover, JavaScript lets you leverage the same skillset on both front and backends, giving you more options as to how your resources are used.

When asked what tools they use in a recent survey of mobile developers, 45% noted Node.js and 65% noted some form of Angular or Vue. The beauty of these frameworks is that they’re common and standard, they make developers highly productive, they facilitate reuse across different digital channels and they’re all built on JavaScript.

4. Don’t Offload Development to the Business

There’s a limited use case to be made for the no-code “citizen developer.” For example, let’s say you were a big Lotus Notes shop, or were building apps with PowerBuilder or Microsoft Access, and you wanted new business resources to replace outdated experiences. But you need to be honest when you assess how and how often your organization might use citizen developers—I’ve yet to encounter a single business manager that wants to reallocate their own scarce resources to building apps.

The better approach is to make your professional developers more productive and enable the business users to more effectively participate in the development process. Solicit their input on requirements, quick POC efforts, and effective communication and collaboration—don’t try to make them no-code app developers.

5. Don’t Settle for a Hybrid Mobile Experience

Responsive design has become standard in all new web efforts, so that’s one way to achieve mobility. But sometimes a responsive web experience isn’t enough and should be complemented by a mobile app. Let’s look at the options:

• Develop native apps for iOS and Android with Swift, Objective C or Java. That’s great for organizations that can afford two different development teams, but most can’t.
• Take a hybrid approach using Cordova or PhoneGap, a container-based mechanism that relies on a runtime WebView to interact with the native mobile APIs. While this simplifies development efforts, it introduces performance and usability issues that result in poor mobile app ratings.

User expectations are for consumer-style experiences, which excludes using a dated hybrid approach.

One option to consider, which leverages your existing JavaScript resources, are JavaScript native technologies such as NativeScript and React Native.

Both are open source, allowing you to build truly native apps that interact directly with the iOS and Android APIs. You always have access, there’s no waiting for a third party to update the WebView container for new mobile OS releases, and you have true zero-day support with native performance, look and feel—all with a single code base. And if you use Angular, Vue or TypeScript, you get code reuse across both your web and mobile efforts.

6. Don’t Start with a Legacy Technology Foundation

When exploring solutions delivered by software vendors, the last thing you expect is to start a new initiative on a legacy architecture. Many of you may not consider app server technology a legacy investment, and it can be confusing because some of these legacy technologies have been containerized using Docker and Kubernetes.

At a recent Gartner conference, Anne Thomas spoke about how she fields a large number of inquiries from clients who want to move off WebSphere or WebLogic so they can achieve better licensing terms with RedHat. Her advice to them is, ‘Why trade one monolithic architecture for another? Consider going straight to serverless, or ephemeral functions, as well as more long-lived microservices.’ She wasn’t implying that you do 100% refactorization from the get-go, but to implement an architecture that allows you to transition over time, vs. taking a monolithic lift-and-shift approach.

It’s not just mainframe or AS400 apps that are monoliths—something as relatively modern as EAR and WAR files are monolithic—making it easy to see how containerizing these applications provides you limited value. While it might make it easier to deploy or move from one environment to the next, you’re still stuck trying to manage the dev, test and prod work for a monolith, minus the ability to develop, test, deploy and scale components individually. It’s a critical distinction if you have business agility goals that you need to support.

Finally, why select an approach that immediately puts you on a refactor course only to endure forced upgrades from a vendor working to retire their technical debt? It just doesn’t make sense when alternatives exist that rely on more modern patterns.

7. Don’t Overlook Backend Services and Integration

While frontend tools are incredibly important, don’t underestimate the amount of effort required to get these new digital experiences integrated with your enterprise data, systems and Auth.

Existing enterprise systems aren’t designed for modern mobile or multichannel workloads. They could be stressed beyond capacity, which could put your critical backend systems at risk, or they may simply not support the response time requirements or be accessible to your mobility efforts.

You can solve this problem with an architecture approach that allows you to intelligently cache enterprise data using a multi-tier cache—data managed by modern backend services, as well as data cached on the client, which also sets you up for offline support. It’s possible to do this today using a low-code configuration-based approach.

8. Don’t Forget to Consider Low-Code as a Modernization Option

We all want to leverage our existing investments and devote as much development time as possible toward delivering new capabilities, versus spending time on maintenance and refactoring.

One way to extend the value of your current investments is by providing offline mobile support for your legacy systems.

Beyond system integration is targeted modernization. For example, you may have a large application that has grown unwieldy over time. Analyze it to identify which of its functions are more widely used. You can benefit by turning this functionality into capabilities that can be consumed by new workloads, with a modern API. If you expand your integration requirements to think more broadly about how a platform can support a phased, incremental approach to modernization, this will likely lead you to a serverless- and microservices-based approach that relies on standard APIs.

9. Don’t Treat IoT, AI and Analytics Efforts as Silos

Also on the CIO agenda are IoT, machine learning, AI and analytics. It may be simpler to make technology choices independently, but that can lead to silos. While you may treat pilot or lab efforts in a vacuum, when you think about things in production or longer term, treating these technologies independently can wreak havoc on your organization. The first thing to consider is that AI can be a contributor to many digital initiatives, whether you are using off-the-shelf machine learning services for image recognition, speech to text, sentiment analysis, or to improve your marketing conversion rates via next best offers as part of your CMS efforts, or whether you are using predictive results to drive a business process.

Chat is a big deal right now but there’s the risk of a backlash against chat experiences if they remind people of “answering system hell.” That happens when bots rely on developers and designers to identify and then code every possible conversational flow using complex decision trees. Here’s where combining two technologies drives great results—conversational and machine learning. Instead of coding every path, use machine learning to train the bot. Not only does that eliminate the need for writing extensive code, it allows a business person to train the bot as if they were training a person, freeing up development resources.

Think also about how you can have your developers effectively participate in analytics efforts. Developers aren’t data scientists but the more they understand the basics, the better they can leverage predictive results.

If your developers are somewhat knowledgeable about analytics, it will become natural for them to embed predictive results into your apps. Imagine a field service scenario where a prediction about downtime or optimization is integrated into your mobile apps that drive action by a field technician, that is integrated into your ticketing system, that notifies sales if there is potential impact to a key customer.

10. Don’t Forget about Future Architectural Considerations

For future architectural considerations, let’s say that we want to extend our field service use case so that we manage inventory or supply chain elements using a distributed ledger to ensure that all actions and actors can be trusted.

Imagine moving beyond simple AR scenarios so your technician interacts via chat or conversational to troubleshoot the problem, or to be completely immersed using AR technology that guides the corrective action. The possibilities are endless if you start with the right architecture.

And while it may not be as enticing as the previous use case, it’s key to think about different architecture patterns that will be needed to process IoT data—for example, an architecture that handles events using a cloud-native approach, vs. event capabilities that are bolted to an existing architecture.

Something I’m watching are the advancements in microapps. We all know the problems associated with multiple applications, and we typically relate that to consumer behavior—how many games or apps do your kids have on their phones? But it’s also extremely problematic for employees to work with different mobile apps in their environment—sales and marketing apps, human resource apps, expense reporting apps, not to mention different messaging clients.

Imagine a single mobile app container for employees that’s downloaded and installed once. That application container—not to be confused with a hybrid WebView—is fed application cards based on an employee’s responsibilities. Those are personalized and tailored using an event-based paradigm, where autonomous agents can act on their behalf to minimize disruptions and allow them to focus on creating the value and differentiation that only a human can deliver.

Learn More

Progress is reinventing high-productivity/low-code app platforms to help developers and architects deliver the application innovation required to compete in a digital world. Learn more about how we do this.

Feel free to watch a free webinar where I dive deeper into everything I mentioned above. I'll also provide practical recommendations relating to serverless microservices and functions, full-stack development, NoOps, modernization, container support, hybrid cloud deployment and more. Head here to watch now.