Last week we talked about the first key consideration when selecting a low-code development platform – Application Frameworks. This week we’ll continue with two additional key considerations which are Any-to-Any Integration and Unlimited Depth and Reach.
Any-to-Any Integration
On the surface, applications appear to be singular programs that serve a particular task or job function. But the reality is, under the covers, applications are a series of multiple integration points, communicating with databases, internal and external APIs and connected devices.
Certainly, you’ve heard the phrase “a chain is only as strong as its weakest link.” Well, the same can be said about low-code development platforms – they’re only as strong as their integration capabilities. The success of any low-code platform relies on its ability to integrate with anything and everything, whether the objects are located in the cloud, on-premises or on a local device, server or workstation.
All low-code platforms will claim to integrate with all of your existing infrastructure, so you need to investigate deeper. Most low-code vendors require your integration points to be wrapped up as RESTful APIs in order to integrate with their solution. While RESTful APIs are great, they are not the be all and end all when it comes to integration, especially when you need to communicate with legacy applications.
Most companies have legacy applications with EXEs, DLLs and .NET components (just to name a few) that contain code that runs their business. Not everyone has the means or time to wrap all of these integration points as RESTful APIs, so having more options is important.
Unlimited Depth and Reach
In other low-code platforms, developers are constrained by numerous limitations. In the worst-case scenario, developers need to modify the platform-generated source code to meet their business needs. This is a tortuous situation because once modified, the source code cannot be put back into the low-code platform for on-going maintenance and extension. So, thousands of lines of (often rather ugly) source code have now been dumped onto your team. This is a fast way to encumber your already overtaxed developers with even more technical debt.
In even the best of the other low-code development platforms, when developers try to reach beyond the capabilities of the platform (for example to implement complex business logic) the only remedy they have is to drop down into another IDE and code extensions in additional scripts and languages that are integrated with the other generated code. This is troublesome for a number of reasons.
The additional code needs to interface through specific low-code platform extensions and/or APIs which confine and add to the complexity of the development.
The additional code artifacts need to be externally version controlled and configuration-managed to coincide with the versions of the generated low-code application(s) for which the added code was written.
You would be introducing technology-standard version interdependencies between the additional code, the generated low-code applications and the low-code platform itself.
These all sound like typical software engineering problems that can be managed and solved by developers as they often are thought of as the normal course of software development practice. They are indeed. But they are not without significant cost and consequence. And you end up with more technical debt, challenging software deployments and managed complexity. Maybe low-code platforms will get better to help solve these issues? One of them has.
What Makes a Low-code Platform Special?
In today’s world of highly specialized programming skills and segmented development teams, companies purchase low-code platforms because it’s nearly impossible to find full-stack developers that can quickly work on any aspect of an application. But what happens when developers need to go beyond the reach of a low-code platform? They have to drop down into Visual Studio or Eclipse and revert back to traditional application development. This is the last thing you want to do. It negates the benefits and promise of low-code. It’s what we’re trying to get away from.
When it comes to building, maintaining and extending applications, the best low-code platforms never require developers to leave the low-code environment. The more often your developers are forced to work outside the environment, the less “low-code” you become because you’re back doing tradition application development.
The most common tasks you’ll find developers exiting their low-code platform is to redesign screens, modify code, debug the application and deployment.
Redesigning Low-code Screens
Verify the low-code platform includes a modern, drag-and-drop, WYSIWYG screen designer. When low-code platforms auto-generate your screens, they generally do well at guessing how the content is going to be presented. It’s nearly impossible for them to guess right every single time, so developers need an easy way to modify the screens that were created.
If the low-code platform’s screen designer is powerful enough, your developers will never have to code a single line of HTML, JavaScript and CSS again to design responsive web interfaces. If it’s not powerful enough, they’ll need to exit the platform and modify the screens using the same old tools they used before.
Modifying and Extending Low-code Source Code
The same holds true for modifying and extending application logic. Business process complexities, multifaceted information eco-systems, multi-enterprise value-chains and complex transaction processing are just a few high-level scenarios that may call for complicated source code logic. If you’ve already coded it somewhere, be sure your new low-code platform can access it. (See Chapter 2 on Any-to-Any Integration.)
If you will be encoding such logic into the new applications that you want to deploy with the help of a low-code development platform, then you should understand how you’ll go about it. Will you need to drop down into Eclipse and bang away at auto-generated PHP, .NET or Java to add your complex logic? What if your low-code platform of choice enabled your complex business logic without having to write more with traditional coding? If you did find such a platform, then you could reduce the number of separate artifacts involved in configuration management, lessen the burden of skills breadth on your team, reduce software component version interdependencies and potentially avoid added intra-project API complexities. The last thing you want your developers doing is exiting the low-code environment and using their old IDEs to modify auto-generated PHP, .NET, Java, etc.
Debugging Low-code Applications
Sometime your apps will not behave the way you want them to, so make sure your low-code platform provides built-in interactive debugging capabilities without dropping down into another IDE. The better low-code platforms can debug applications running locally or on a remote server, interactively or in batch, from within the platform. Verify all of the expected debugging capabilities are available: stepping through code, setting breakpoints, changing runtime values, etc.
Deploying Low-code Applications
Today’s applications have a lot of moving parts so deployment can be tricky. The best low-code platforms provide some sort of one-click deployment option. You want to be able to simply choose your application and the target platform and let the low-code platform handle the rest – for both cloud and on-premises.
Stay tuned for another blog post on key considerations when selecting a low-code platform, where I’ll cover the importance of leveraging a Business Rules Engine.
For more help on selecting the best low-code development platform, download The Five Key Considerations When Selecting a Low-Code Platform white paper.
0 Comments