(this article originally appeared in DZone and was written by Aleksey Stukalov)
The modern software development landscape has dramatically changed over the past few years. To me, it looks much like the accelerating expansion of our Universe. At the beginning of the second millennium, the industry didn’t look very fast but was progressively moving. Now the complexity and variety of technology faster than the speed of sound, faster and faster, bringing new programming languages, development tools, methodologies.
Technology becomes more comprehensive and complex for an obvious reason —to meet growing requirements for building global solutions like Uber, Facebook, Google, and so on. Outstanding complexity is the price to be paid for the ability to build global monstrous systems. But should we pay the same price for creating relatively typical applications for business automation?
Subject for Automation: Line of Business Applications
The beginning of the 2000s was the time of extensive business automation under the motto: “If something could be automated it should be automated.” The result of such automation is called Line of Business (LOB) applications. It is quite a general term that describes a set of very important (mostly custom) applications developed with the only ultimate reason — to run business more efficiently.
In general, LOB applications have the following distinctive features:
- Domain-specific — Targeted on professionals in a certain domain area and not mass market
- Data-centric — Hugely rely on relational databases, which plays a crucial role in the application
- Transaction-oriented (OLTP) — Represent CA class of systems (highly consistent and available) assuming ACID compliance with each transaction
- Extensive Business Logic — Contain a massive block of custom business rules and data processing algorithms
- Rich User Interface — Introduce hundreds of functional interactive screens with relatively standard widgets (text fields, checkboxes, buttons, tables…)
Functionality-wise, LOB applications also share a common list of requirements:
- Authentication and support for industry standards like SAML and LDAP
- Role-based access control
- Row-level security
- Data changelog (aka data audit)
- Interoperability, an ability to consume third-party APIs and provide an API for integrations
- Business process management engine and support for BPMN as an industry standard
- Reporting and business intelligence capabilities
- Integrations with frequently used services like emailing (SMTP and IMAP), file storage (Amazon S3, WebDAV), search engines and so on…
- Scalability, so a solution can grow along with business growth
High demand in LOB applications formed a market of so-called Rapid Application Development tools, which were ultimately focused on making the development of LOBs way more efficient.
The Evolution of RAD Platforms
In the mid-90s demand for business automation started to grow exponentially. Hence, many RAD platforms emerged in response, providing a fast track for the development of LOB applications. RADs combined easy-to-learn programming languages with productive development tools, so virtually anyone could create a basic LOB application in record time! Microsoft Access, Oracle Forms, FoxPro, and, of course, Borland Delphi (a trendsetter of those days) supported the automation boom. So, by the end of the first decade of the 2000s, a huge number of LOB systems had been developed on RAD platforms.
What RADs missed back then was the oncoming web era. The web user interface turned out to be an essential requirement accompanied by adjacent requests for scalability, availability, and more. These factors ruined the popularity of Delphi and other RAD tools as they were not able to fulfill the outstanding requirements or evolve fast enough to comply with the new reality. After a few years of stagnation, hundreds and thousands of applications turned into hardly supportable legacy. Even the term “RAD” itself became an offensive word meaning not “ease of use” and “joy of development,” but outdated stuff with no future. This situation raised a high demand for modernization.
The desired migration to the mainstream enterprise stack appeared to be surprisingly costly. The same functionality could take a day for a Delphi developer and a week for a web developer! Obviously, new technology is good for building fully custom and unique applications, but produces a huge overhead for more or less typical LOB systems. Such imbalance showed a gap in the market of software development tools, which is now occupied by the new generation RADs. The new generation has risen from the ashes of its predecessors. This means that the majority of the representatives of the modern RAD market are not direct descendants of the legacy ones, but were developed from scratch, mixing best practices from the past with mainstream technology.
The Foundation of RAD Platforms
First, let’s highlight the main principles of the RAD platforms. In other words, let’s see what exactly makes them that efficient in comparison to the traditional development technology stack.
Architecture and High-level API
Modern RAD platforms address the complexity of mainstream technology by integrating them into full-stack frameworks with a higher level of abstraction. Such high-level frameworks define a SOLID architecture of all applications built over them. It is very important to understand that nearly all limitations of your application originate here. How scalable your application can be? Will it be modular? What data stores can be used? Where can it be deployed? What about backward compatibility?
In return for the introduced limitations, this pre-defined architecture enables the fast development of LOB applications by introducing a higher-level API that lies closer to the business needs. Simply put, it abstracts developers from the underlying technologies, so they can focus on solving the business tasks.
Such an approach to raising the abstraction level is heavily used in the modern RAD frameworks. The five most notable players taking this path include: Ruby on Rails, Grails, Django, CUBA Platform, Zend Framework.
Typical Functionality
As was already mentioned, RAD platforms are primarily targeted at LOB application development. This class of applications has a list of common requirements, such as auth, data access restrictions, audit, file storage, full-text search, business process management, and so on. The RAD platforms deal with such requirements by introducing the corresponding reusable out-of-the-box features and/or add-ons.
This approach is also widely used among modern RADs. So, for this purpose, the CUBA Platform features its marketplace of add-ons, Ruby on Rails has their gems, Grails use plugins and Django introduces their packages.
Development Tools
Development tooling is probably the most important part that ensures not only high productivity, but also lower barriers to entry, shorter learning track, and, of course, joy of use. This turns out to be possible because these tools are narrowly focused on the pre-defined architecture of the platform: programming languages, used libraries and underlying frameworks, the structure of the application (modules, add-ons, packages), and so on.
Leveraging the vast knowledge about the used architecture enable RAD tools to offer the ultimate convenience for developers. To give an idea of what exactly they bring to the table let’s outline the most common features:
- Intuitive visual designers for the new project bootstrap, project configuration, domain model, UI development, and more
- Extensive source code generation to automatically scaffold most used and boilerplate snippets
- Smart prompts to avoid error-prone use of the elements, including hot-fixes
- Advanced navigation for application parts and configurations
- Guided version upgrade procedure to facilitate migration to the latest versions of the platform
- Distributive preparation to make the solution ready for installation
Probably the most vivid example here is the RAD Studio by Embarcadero (former Borland Delphi). Another, but atypical, member for the RAD family is JHipster, a command-line interface tool that mainly takes care of the project bootstrap with a big variety of different options for the initial Java project configuration. CUBA Platform in its turn offers two RAD instruments: CUBA Studio and CUBA CLI, where the first one is a full scale and very powerful IDE and another one is a lightweight command-line interface tool.
Low-Code Development Platforms
If you keep an eye on the modern RAD market and follow its evolution, you couldn’t miss the huge buzz around the so-called Low Code Development Platforms (LCDP). The whole idea behind low code was expressed in their original slogan — no professional developers will be needed in the near future. They engage not software developers, but business executives. This is the reason why I deliberately didn’t mention any of them in the previous chapter. However, we cannot skip over LCDP when talking about RAD as they form quite an interesting phenomenon — development tools against developers.
Being sold to business executives, they appeal to the main business values: cheaper, faster, and with higher quality. Yes, you need to pay hundreds of thousands of dollars annually in licensing, but at the end of the day, you win by having no professional developers (who are very expensive) and no maintenance for the local infrastructure. They amaze non-technical people by a demonstration, where a sales manager creates a trivial business application with just a few mouse clicks. It makes the impression that business users (aka citizen developers) will be able to automate their own business needs.
From the technical perspective, LCDPs are based on the same foundation: predefined architecture and high-level API, ready-to-use typical functionality, and development tools. The biggest difference here is the range of applicability of such platforms. To enable non-professional creating enterprise-grade software LCDP vendors narrow down the development process to drawing a flowchart, sacrificing a lot of capabilities in exchange: familiar collaborative development flow, source control, customizability, extensibility, interoperability, compatibility, performance, auto-testing. As a result, LCDPs are only suitable to build very basic systems.
Nowadays, Mendix, Outsystems, and other LCDPs vendors are trying to build warmer relations with professional developers. But it seems to be a long way ahead, as many professional developers do not take low code platforms seriously.
Conclusion
Some would say that “Rapid Application Development Platform” sounds pretty old-fashioned, referring to the outdated technology — I agree that it has a strong negative connotation. To freshen it up, Gartner came up with new buzz words: Enterprise Low Code Application Platforms and Enterprise High-Productivity Application Platforms. However, drilling down, we still see the same principles used to speed up the development of the same class of applications and sharing the same limitations. It looks like a witness protection program for the old-good RAD Platforms, which now live a happy life under their new names.
The modern market of RAD frameworks, tools, and platforms is widely diverse, mostly offering fast development of web applications. There is a clear division between two groups: adherents of the traditional path targeted at professional developers and low-code pioneers, engaging the audience of non-professional developers (aka citizen developers). The first group leverages speed and joy of software development mostly by providing higher-level API and code generation — developers simply are kept away from writing boilerplate code and typical functionality. The second one provides a powerful runtime environment and visual tools, loved by business users not even for speed of development, but for simplicity they provide — just draw a diagram instead of coding.
The is no ultimate advice or algorithm to find the best RAD tool — it heavily depends on the functional and non-functional requirements for your project. However, I would like to draw your attention to pricing and licensing. With some of the products you are doomed to be paying a fortune — prices may vary from nothing to hundreds of thousands of dollars annually. With low-codes you easily can end-up with six digits numbers in your bill — made worse because you are unlikely to be able to go elsewhere because of vendor lock-in.
