Organizations build applications to either make money or save money. Organizations that aren’t leveraging applications to compete will be at a massive disadvantage. Consumer Goods Technology magazine noted that only 3 percent of its 35 billion dollar growth in 2017 was from traditional, large enterprise players. The other 97 percent was from digital innovators. The problem lies in the markets ability to deliver those applications. The statistics from a PMI 2017 study are illustrated in the picture below.
Organizations have gotten better at delivering applications. But as the picture above shows, there is still significant room for improvement. This improvement will need to happen to drive innovation. This article will highlight how far we’ve come, and how we can close the gap.
The Past State of Application Development
Let’s start with the framework of an application. That will lead to the manual process by which those components are provided through a waterfall approach. The components are a network, storage, servers, virtualization, O/S, containers (optional), runtime, data, and then the application.
Waterfall works like the this- A business unit has an idea that transcribed into requirements. Those requirements are turned into specifications by a Business Analyst and those specifications are delivered to a Project Manager who initiates efforts from the user interface, database administration, and app-development resources. The product is built, packaged and delivered to operations who goes through stages of deployment, operations, and monitoring before the release. Voila, now you have an application. The problem is shown in the project plan below.
Project teams went on an expedition to deliver an application for the business without consistent businesses verification throughout. There is room for inevitable error at each step of the process. This could involve the code itself, or the applications ability to run. The result was that organizations were spending months of time, effort, money, and resources to deliver an application that isn’t valuable. Then they would start the same process all over again, with the same room for error. For the most part, that has changed.
The Present
The market has decided there are three ways to solve this problem:
- Automate tasks to make them faster: Cloud services like AWS and Azure provide automated delivery of network, server, storage, and virtualization. In the same way, there is a barrage of tools on the market to automate IT operations functions like testing and monitoring.
- Perform tasks in tandem: The delivery of these tools and the drive towards CI/CD (continuous integration, continuous delivery) are allowing organizations to perform tasks in tandem.
- More accurate delivery: Agile/Scrum development allows us to obtain business verification more often.
The third way to fix this problem is what we are going to key in on. Here is an example of a SCRUM process flow from PMI:
The problem with this is shown in the sample project plan below. Scrum provides a way to validate with the business more often. Instead of accruing 6 months’ worth of error, we’ve mitigated our risk down to our sprint length of 2-4 weeks. However, the same room for error still exists within those short sprints. That forces teams to either iterate within a timebox, iterate to an MVP (minimum viable product) or iterate to a truly valuable product. If it’s an MVP or an ideal state we’re after, that room for error will still lead to additional sprints. That brings us back to today, an age where most organizations practice agile.
The future is low-code
Truly continuous development, delivery, integration, and deployment is the future. There will be no sprints or project plans. These processes will be working in synch and in tandem to consistently deliver the fastest route to an MLP (minimum loveable product). 
The reason that can’t happen today is that business units can’t verify code. Meanwhile, DevOps team are using code to develop user interfaces, workflows, and data integration. The best option, in that case, is the sprint.
A low-code solution changes that. A low-code solution provides a visual, model-based integrated development environment. Business units can provide constant verification. For example, we can retrieve verification on whether or not the below accurately describes a process.
Can we do the same for this picture?
Mendix’s platform provides model-driven development for UI, logic, and integrations. Not only can the business unit review, but the business unit can get directly involved in development. In addition, the platform provides automation and integration for every part of application development process. As a result, organizations can achieve maximum efficiency in delivering applications that allow them to stay competitive in the digital era.