Over the past few years, there has been a lot of chatter around low-code development. Forrester predicts sales of low-code development platforms will grow by 68% to become a $15B+ market by 2020. But what is low-code development in the first place? Who would want to use it? And why is it growing so fast?
Don Schuerman is the CTO of Pegasystems, which plays in the low-code development category. He is also a practitioner of low-code development within his organization. In conversation with TCV General Partner Kapil Venkatachalam, Don shares his perspective on the space and helps cut through marketing jargon to uncover real benefits. Topics covered include:
- The business case for low-code/no-code development
- The tech trends behind it
- Why it’s essential for users to be hands-on
- “Think big, start small, move fast”
- The alternatives and lock-in challenge
Kapil Venkatachalam: Let’s start with the basics. Don, how do you define low-code development?
Don Schuerman: Simply put, low-code development is taking a lot of the same automation and intelligence capabilities that we’re applying to various parts of our business and applying them to the way we develop software. The idea is to automate more and more of the software development process.
On a day-to-day basis it means moving away from using code, say from using JS or Java or another programming language and instead using visual metaphors to define portions of your application – whether that is what you want a user experience or a data model to look like, or defining a business process.
Kapil Venkatachalam: Does this have an impact on the speed of app development? Is there evidence for that?
Don Schuerman: The idea is that if I can focus on defining the business logic of the problem I am solving, using software vs. focusing on the actual code itself, I can move faster and create better software for the user. We did a study with Cap Gemini, and they found that you could release an application almost seven times faster using this approach versus coding it. More importantly, you can directly involve the business user and the technical developer in the actual creation of the software. In the traditional approach, requirements or a user story goes to a developer, the developer codes and that comes back to the business person, usually triggering changes. In the low-code approach, the act of writing the user story triggers the generation of the software.
Kapil Venkatachalam: I often hear the term no-code development thrown in with low-code development. What is no-code development? Where do you draw the line between low-code and no-code?
Don Schuerman: There is a degree to which the industry is playing buzz word games with itself. Forrester coined the term low-code development about three years ago. Gartner calls the category hpaPaaS, i.e. High Productivity Application Platform as a service. I think all these different terms can confuse the business.
A number of vendors have said, ” What’s the point of low-code? We should be able to go completely code-free — or no-code.” I think what’s inherent in these buzz word battles are two fundamentally different ways of looking at this problem:
- One way of looking at these solutions is they act as development accelerators. They are designed to give developers faster ways of building things, which is great.
- You can also look at this as a more fundamental change. You sometimes hear the term “citizen developer”, or the “democratization of software development”. And this is really about how to bring non-developers into the act of building their own applications. How can I allow a business person to make the applications do what they want instead of building Excel macros or having an Access database that I can’t see or control? This is at least happening in a place where it’s governed and central.
Ultimately, I believe the real promise of this model is not one or the other, but it’s both. It is how I further tighten the relationship with technology – because IT isn’t going to go away. There’s always security. There’s always going to be data management inside of large organizations and legacy systems that need to be orchestrated and managed. There will always be needs to think about, such as re-use and making sure that I’m not building new business silos every time I deploy an app. There’s always going to be an IT role.
Kapil Venkatachalam: That’s very helpful context. Over the past 10+ years, we have seen things like Visual Basic, 4GL, BPM, and others, which claimed to help improve application development productivity. What is different with low-code and why is it here to stay?
Don Schuerman: Good questions. The first thing I would say is I don’t think low-code is unique. It feels more like the technology industry recycling old technology under a new name. Everybody is talking about AI. The vast majority of the AI that’s actually in use is predictive analytics and Bayesian machine learning which, in some cases, are built on 250-year old math. There’s a lot of rebranding and renaming in the industry. Low-code, I think, is a bit of the same thing.
However, I do think we’re seeing a convergence of three factors shaping this space. One technical, one demographical, and one business imperative driven, which makes this more exciting.
- The technical one has to do with cloud services and platforms as a service. Previously with 4GLs, I still needed to solve a huge amount of infrastructure issues before I could get the thing I built with 4GL working. I still needed a database. Now that we have application platform as a service, I can solve some of my infrastructure matters on my own. I can even begin to solve some integration, and there is a whole movement around citizen development integration.
- The second factor is demographics. Today, anybody coming into a workplace is entering with a level of technology understanding that you didn’t see 20 years ago. The vast majority of millennials have built a web page or designed a world in Minecraft, so there is a natural sense of “programmatic thinking” entering the workplace at a rate we haven’t seen before.
- The final factor is the business imperative. I think the quote that “every company is a software company” has pretty much been universally accepted — at least at most of the enterprises I talk to. Every bank gets that they are a software company that moves money, every insurance company that I talk to gets they are a software company that underwrites risk. People understand that.
The challenge for many non-tech companies is that great software engineers want to work for Amazon or Google, or that cool tech company. There’s a huge need in non-tech companies to turn their legacy knowledge of the business space into elegant, powerful software at a speed they don’t have. This technology provides an opportunity to jump in and plug an app and start taking and connecting some of the SaaS applications that drive different parts of the business in new ways.
Kapil Venkatachalam: That’s a nice segue to talk about the customer perspective. As a CTO, is there a trigger point when you start thinking about low-code development?
Don Schuerman: Interestingly, more often the trigger point – or person — is not the CTO or CIO. The trigger point is the owner of the business operation. The trigger point is somebody who has a business problem, which they can’t solve through their own IT department or through an off-the-shelf SaaS product. For example, an ops manager at a manufacturer who deals with complicated order fulfilment that he or she can’t get that out of their ERP or connect to their sales force automation system. Or a marketer who wants to take AI and apply it to retaining more customers, so it’s not just embedded into one channel but crosses all channel touch points with customers. They can’t just go and buy a marketing app to do that. They need to build something that connects the business and the customer.
Kapil Venkatachalam: Are there typical uses cases for low-code development?
Don Schuerman: Our whole business is built on use cases in two areas. I’m either helping the company save money by automating things sitting in their operation in ways they haven’t been able to do before. Or, I’m helping the company make money by allowing them to engage with customers. Within those two buckets, when you start slicing it by industry, the use cases run the gamut from order fulfillment, to investigations, to complex servicing requests, to moving a telecommunications customer from one location to another and dispatching multiple field service people to get that done.
Kapil Venkatachalam: Can you elaborate on that? That’s a very wide net you can cast, so maybe you could bring it to life with a specific case study?
Don Schuerman: I’m going to use an example from the public sector. The state of Maine is a relatively small state with a relatively small IT organization. If you’ve ever been to Maine, it’s an incredible place to spend a week on the water, but not the kind of place that makes you think of fast-paced organizations. What they have though, is all these government agencies that do various types of licensing. For example, I need a fishing license, I need a dog license, I need a hunting license, or I’m a manicurist so I want to get a manicuring license. And every single one of these different licensing organizations will string together their own processes by “duct tape email and baling wire.” Maine is using low-code technology for what they call 40-hour apps. Previously, they would fly in a tech person, recruit a business expert from the licensing agency and spend a week to build out the licensing app for that agency. Then they would put it live, take the things they had done and repeat with the next agency. With low-code/no-code development, they were able to go across different agencies and turn what was manually painful work into accelerated processes that had a fit for purpose app against each one. With limited IT resources and a very limited IT investment, they were starting to fill in major gaps in the application landscape for the state.
Kapil Venkatachalam: That’s neat. To balance some of the benefits these customers are seeing, what are potential pitfalls or reasons why a customer might fail?
Don Schuerman: There are two big anti-patterns that I’ve seen in this space. Anti-pattern one is treating low-code/no code purely as an IT accelerator. If you don’t have accountability from the business function – literally somebody sitting in the room hands on keyboards building stuff – all you’ve done is given your tech guys another cool tool. There are lots of cool tools you can give to tech guys in terms of IDE’s and open source software, but your results end up being relatively incremental. If you want to fundamentally change the speed of your business, you need to commit to pulling the business function into the development work.
The other thing I remind people to do – it’s the mantra we tell customers: Think big, start small, and move fast. It means to run quick projects. In many cases, we go into pretty big enterprises, and many of whom still think waterfall. We almost need to shock the system a bit to get them out of that mentality, but you also want to be thinking of that short small project in the context of what’s next. I like the Maine example because somebody said, “Aha, not only can I build a bunch of licensing apps, but I know that once I build one, I’ve probably built 40% of the next one. And once I build that one, I’ve now got 60% of the third.” It’s about not only getting one thing done quickly, but being able to re-use it in other areas of my business. I’m not just building a bunch of siloed apps that are access databases in the cloud, but are part of a connected and holistic system I can manage. I can put central governance on that system when I need to, while still giving a degree of freedom to my business units to solve problems they need to solve quickly.
Kapil Venkatachalam: Right. One of the pushbacks I’ve heard from developers is losing control and vendor lock- in.
Don Schuerman: My view as a software vendor is lock-in is inevitable: you are going to lock into something, so you want to pick your partnerships. What I mean by that is back when JEE and databases came around, the message was: We’ll standardize in SQL, and if you build and write SQL, you’ll be able to port things between databases. How many people have tried to port an application across databases? It’s not as easy as simply pulling the SQL from one database to another. When JEE came around it was like, “We’ll just write to the JEE standard and you’ll be able to pick up this application and move it from WebSphere to WebLogic to J-Boss to whatever you want.” Of course, we’re not going to do that, because WebSphere provides a whole bunch of value-added services, and now you’re locked into WebSphere and you’re going to going to be able to easily port that application. What I’ve seen recently is that cloud is now leading us to the same sort of infrastructure. How do I build something that doesn’t lock me into AWS, Azure, Google, or any of the cloud providers, making me unable to move my infrastructure?
The benefit you get from a low-code perspective is you’re not locked in at the infrastructure level. In fact, you’re also not locked into the code implementation level. For example, the UI world has been moving incredibly fast. 12 months ago, I would go to meetings with UX teams and they would tell me, “We’re building everything in Angular — the only way to build UX. If you’re not building in Angular, you’re an idiot.” And then, I went in six months later, and the same guys said, “We’re building in React.” The code stacks are changing so fast. As an engine vendor – if you model the user experience as a picture, the engine can generate the code.
The concern is, “Now I’m locked into the low-code platform, right?” But the nice thing about low-code is the business logic isn’t buried because everything is visual. If I want to know my business process, I just look at the picture. If I want to know my business rules, I can look at readable decision tables and decision trees. In fact, in most of these platforms there’s a degree of auto-documentation so I can make the system tell me exactly what it’s doing. I’m locked in a little bit to the platform, but my business logic is always transparent to me. If I needed to go take that and move it somewhere else, I’m not going through the exercise of trying to figure out what this code is doing.
Kapil Venkatachalam: One of the TCV companies, FinancialForce, is built on Force.com, and ServiceNow also has a platform. Are there other alternatives companies can go explore?
Don Schuerman: Yes. If you look at market and analyst reports in this space, you’re seeing vendors coming out of heritages.
There’s a box of vendors that used to be in the process management, BPM space – and they tend to be very good at building apps that have processes built-in, because that’s what they came out of. There’s a group of vendors that came out of the MADP mobile application development platform space. They tend to be great at building responsive user experiences that have mobile backend features like notifications and device management. Then you have vendors like Salesforce that came largely out of the CRM space, so they tend to be very good at doing CRM management. Then there are a couple that came out of the rapid development space, and they tend to be super-charged IDE tools.
Kapil: Thank you, Don. This was very insightful. We really appreciate you taking the time.