Rapid Application Development: Know The Right Tools

27 Open Source DevOps Tools In 7 Easy Bites

In all the talk about different development methodologies and frameworks, one software dev trend is gaining traction, if the exhibitors and attendees at the Gartner Symposium ITxpo are to be believed. That trend is rapid application development.

Also known as low-code or no-code software development, rapid application development uses visual interfaces to allow people to drag symbols around the development environment, connect them in specific ways, and create an application with little or no coding required.

The appeal of rapid application development is easy to see. Since the code itself is automatically generated, delays and bugs due to typographical errors are minimized. Because the visual interface can open application creation to non-developers, "citizen programmers" in business units can take an active role in creating their own task-specific apps without involving the IT department.

If you're at the point of beginning to look at rapid application development tools, you should know that there are similarities as well as vast differences among the tools you'll see. In common is the fact that every tool involves manipulating icons on a screen to control the code that is generated. Also, most of the final code will be generated by the application, rather than at the direct hand of the programming.

So how do the tools differ? Broadly speaking, the tools will be divided along two axes: starting point and ending code. Let's look first at the differences in the starting point among the options.

Let's Start at the Very Beginning

Nearly every application written for the enterprise has three huge components (though many applications have more). Applications will have, as a rule, a user interface, a database holding information, and business rules that connect the two.

Rapid application development systems will begin in one of these three places and then add the features and functions of the others to the application.

What does that mean?

Interface-first: Interface-first development systems are often focused on apps with mobile endpoints as the primary user interface. Individuals building the app can create an ideal user interface, test it against a virtual mobile device (or series of virtual mobile devices) and then apply business rules and a database to back up the application interface.

[See 10 Strategic Tech Trends for 2017: Gartner.]

Not to overgeneralize, because each type of low-code platform can be used for many different applications, but I talked with several people involved with this type of rapid application development system who spoke of single-function, "app-style" applications as the frequent target of development efforts using these tools.

If your development philosophy favors the single function app, and especially if most of your users are based on mobile devices, then this kind of tool could be perfect for you.

Database-first: Designing and programming a database can be incredibly complex, so some rapid application development systems begin with a graphical representation of a data structure and then build a workflow and a user interface around it.

In many of these platforms, you don't really manipulate anything identified as a database. You simply move named boxes for data into place, and the database is created for you.

Workflow-first -- If you've ever flow-charted a process, you've done much of the work required to build an application in a workflow-first framework. In these systems, you design the decision points, the processing functions, and the outcomes. Then you build the interface and any necessary database. This type of platform can be the easiest to work with if you're building IoT or physical process applications that don't need a traditional database.

Once you've given thought to where your rapid application development platform began, there's one more thing to be aware of. It has to do with the platform's output -- the kind of application or app it delivers.

Going Native?

The technical question is whether the application code that results from your work will be compiled or interpreted. It's whether, say, the resulting app will be a native app on your chosen user system or a JavaScript/HTML5 that runs in a browser or wrapper on each system.

From a functional, workflow perspective, it doesn't make a great deal of difference. From a user experience point of view, though, the difference can be huge.

There's one more thing that you should think about with your rapid application development system. That thing is how little code your application developer will have to write in order to create a working app.

Some of the platforms require (or even allow) very, very little direct code writing. Others use the framework as a rough outline into which considerable code must be written.

The difference between the two types will tell you a great deal about whether a particular platform is suitable for both professional and "civilian" developers, or should only be used by your dev team to speed their work.

Rapid application development is growing as an option for app creation in the enterprise. In some organizations, it might be an option that becomes the only development tool required for enterprise app creation. In others, it could be a useful adjunct to the other development systems in place.

In either case, consider rapid applications development tools if you're looking for new options for your next app development project.