​Low code development is coming: Welcome to the future

Cloud components. Software as infrastructure. Silicon Valley's enterprise software companies are changing the way we think about and build applications.
Written by Simon Bisson, Contributor

The Uber method of adding its own business model to ready-made services is the wave of the future.

Image: Kai Pfaffenbach, Reuters

In charting the rise of the API economy and the effects it is having on developers, it's often easy to overlook what's possibly the most important aspect of these changes: the rise of the low code application, and the transfer of development away from IT department to business units.

I'm just back in London after a couple of weeks of meetings in Silicon Valley, where I've been exploring just what this new world is starting to look like -- and who the key players are going to be. The builders of tomorrow's enterprise software don't have the flashy campuses of Google and Facebook; they're in sensible looking office blocks. Sure, they have touches of the glamour of Silicon Valley, but it's all about delivering the software businesses need.

Perhaps the best place to start understanding how the worlds of enterprise software and software development are changing is with one of those big-name consumer services that are what we think of when we think of San Francisco and the Valley.

In a conversation with Box's chief strategy officer Jeetu Patel, he brought up the example of Uber. Whatever your feelings on the ride-share giant might be, it's made a set of interesting decisions about how it builds and operates its software. Where in the past we might have made infrastructure decisions about servers, storage, and networking, Uber's infrastructure is Box's storage, Google's Maps, Braintree's payment services, Twilio's messaging tools, and SendGrid's email, among many others. It hasn't had to build those services, it's bought in the APIs, and added its own business model.

That's a significant shift, treating what we might have in the past called 'software as a service' as infrastructure. Patel suggests a new name: functional platform as a service. Functional PaaS is the set of the APIs we can consume to add tools for managing content, for communicating with users, for email, for identity: it's software that's hard to build, running on expensive, complex infrastructure. By buying in functional PaaS, we're able to amortise that infrastructure across a hundred, a thousand, and more different organisations, allowing massive economies of scale and the ability to buy services for pennies or even less.

In switching to this model, we're also amortising expertise. We're already throwing away our internal email servers in favour of Google's and Microsoft's, so why not turn to Box's storage and content management, or to Salesforce's CRM? Those services can become the foundations of our new applications.

With that shift, the cloud and cloud services are rapidly becoming critical business infrastructure. If a cloud service can run a service more reliably and more securely than we can, should we even consider rolling our own, if we're not constrained by regulations? If running a service internally doesn't add to the value of a business, differentiating it from its competitors, shouldn't it be treated like the commodity it's become?

At its heart that's a huge change in how we think about the technologies we use. We're no longer building on hardware, we're building on services and on APIs. That means we're taking on risk, in order to simplify application development and to abstract away from our old physical infrastructures. Even if Salesforce can show us just how reliable it is, it's still risk that we can't control and that we need to consider as part of regulatory compliance.

The result is what Salesforce's EVP Adam Seligman is calling "low code development", something the company is showcasing at its Trailhead DX event. Here the service provides the backbone for an app, and reusable components in the shape of Salesforce's Lightning development tooling can be assembled to build the mobile app that's needed right now.

Low code is often seen as being about building a tool for the moment, solving a specific problem, with users building their own apps. That citizen developer element is certainly important, but it's also a tool for the rest of an organisation, especially where speed and agility are key, where IT needs to keep up with the rest of the business.

That's where the Uber model comes into play -- where services can be updated and deployed quickly and where developers can concentrate on the key business logic that embodies the heart of an organisation.

Using low code techniques, it's possible to quickly reconfigure apps, modifying logic flows and delivering new UI elements as needed. Meanwhile, developers can also take advantage of new features and APIs from their service provider partners, getting better performance and more functionality without needing to invest in infrastructure and software.

We're not limited to service APIs as we assemble our new applications. We can also take advantage of services to implement elements of infrastructure: pulling in network security and DNS from Cloudflare, or identity management for users from Okta. Again it's a matter of handing over the services we don't need to run to third parties.

With it's big 'Ask your developer' billboard off the 101 in San Francisco, Twilio is an excellent example of this trend. By offering APIs that allow you to build voice, video, and messaging into your applications, it's turned the skills needed to build, configure, and manage telecoms services into a set of REST commands and a set of SDKs. With its new mobile offerings, it's taking that beyond the traditional telecom switches into a set of APIs that will allow your apps to work directly with cellular connected devices (ideal for the Internet of Things).

For a company that's just a set of APIs, it's quickly become a poster child of this new world, with a vision of decentralised communications that rips voice out of the phone and into the app. You can find it embedded in many apps and services, like Uber and WhatsApp. But it's also a powerful tool for social good, allowing organisations to punch well above their weight. By building on APIs, the Crisis Text Line is able to manage and route messages to its crisis counsellors, using machine learning to understand context and deliver the right message to the right person -- handling over 18 million messages in less than three years of operation.

Twilio CEO Jeff Lawson talks about "the maturity of the cloud component model", and points to ING's adoption of Twilio as the core of its communications platform. That platform is another example of API-driven low code development, delivering a suite of components that different parts of the bank can pull together to build the applications they need. "It's a kit of parts," Lawson says, "They're agile software building blocks, with networks replacing hierarchies."

A world where we buy the components we need to build the software we want is a very different one. It's no longer one where we have to choose between expensive custom developments or buying commercial software off the shelf. Lawson has a name for it. "It's BABS, Build And Buy Solutions." But where everyone has access to the same kit of parts, how do companies differentiate? Lawson sees the point of differentiation as a simple one: making things better, inside and outside a company. "It's the network of connections that's the key to innovation," he says, "It unlocks the flow."

That shift to building software like the networks we build it on is key to understanding this shift. It's not only a software trend, it's one that (like Conway's Law) maps the new shape of business. Lawson suggests that it's "the intersection of the two things that make us human: building things and communicating". In fact, he goes on to point out, "We're re-humanising business."

What started as a set of hacks to make Outlook work on the web is now the accepted future of application development. We've come a long way since the first XML/HTTP implementations, and from the mashups of web 2.0. But the technologies and techniques they've spawned, like REST and JSON, are the foundations of this cloud-powered, distributed, componentised software world. Now they're also how we're building our businesses.

By taking dependencies on external services we're adding risk, but we're also reducing the risks associated with running those services internally. A company like Twilio or Okta has an entire business model based on that service; it's not a server somewhere in your data centre that gets a few percent of an engineer's time. Instead it's a cloud service where it's the focus of hundreds of people, and where backups and failover are built into the architecture from day one. In practice that means even with the additional issues of consuming cloud services, your overall risk is reduced.

So welcome to the future. Everyone builds code and we pick and choose the bits and pieces we want to use; with just a few local and cloud services providing the infrastructure that powers those new, relatively ephemeral apps. We all can't be Uber, but we can build our software the same way.

Read more from the 500 words into the future blog

Editorial standards