I recently sat down with Nick Laughton, one of our senior Partners, to discuss the class of popular software development tools called Low Code. You can listen to that discussion here or read the transcript below. <subscribe on iTunes>
Low Code is the latest iteration of a long search for development tools that make it easier for traditional developers (in the podcast we refer to them as hardcore developers) and non-programmers who have extensive business knowledge and/or a desire to become programmers. It's a hybrid product that, properly implemented, extends your developer base and allows for more people to contribute to software projects.
Who uses Low Code?
- Subject Matter Experts with minimal coding experience
- Hardcore Developers with extensive coding experience
- Enthusiastic amateur coders with a desire to improve their skills and help the company
- IT Departments trying to build more innovative projects without hiring
- IT Departments trying to reduce Shadow IT
- Hardcore Developers seeking relief from dull and repetitive parts of coding
- Legacy coders who want to leapfrog into new languages while leveraging their old skills
What factors should I consider when selecting a Low Code platform?
There are many companies selling Low Code tools, and they vary quite a bit. What they have in common is that they provide a framework for software development projects to be worked on collaboratively using common libraries and shared workspaces. Some Low Code solutions will require you to run your applications on their proprietary Run Time stack. Some Low Code tools have expensive licensing per user. We think these are some key factors that you should consider in selecting a Low Code tool:
- Per-seat licensing fees
- Language/syntax for code
- Portability of code (Can this run outside of the Low Code environment?)
- Scalability for both the development environment and developed applications
- Will developed applications run on any platform?
- Depth of API and Library catalog
How does Low Code work?
Low Code platforms work by abstracting many of the more complicated parts of the Software Development process away from writing lines of higher level languages, and instead packages those common pieces up into visual tools. Some platforms use WYSIWIG tools, others use various graphical techniques to show the mid-level contributor how to create or change an application interface without directly coding. A good Low Code tool will enhance the mid-tier contributor's powers without sacrificing the ability of hardcore higher-level developers from getting under the hood to craft more complicated parts of the application.
The output of such a collaboration will be working applications that combine all of the parts, regardless of who developed them, into a cohesive software solution. We'll be talking about Low Code a lot more in upcoming posts as we introduce Apex Designer, our own entry into this exciting business space.
We hope you'll enjoy listening to our discussion about this topic on the Accelerate Business Transformation podcast, but if you prefer to read we've also provided you with a transcript below.
PODCAST TRANSCRIPT FOLLOWS
Introduction (Blake Smith):
In the mid-1990s several products tried to create a middle way for people to craft bespoke business tools. Excel had its spreadsheet capabilities extended from just formulas with Visual Basic Macros. Microsoft Access continued a small database revolution that had started with FoxPro, and the Lotus corporation introduced Lotus Notes. The Rapid Application Development movement tried to get revolutionary improvements in development out of the same old Waterfall style projects. Graphical tools were being applied as skins over old midsize and mainframe terminal interfaces. But this quiet confederacy of innovations did not turn into a revolution.
A lot has changed since then. Operating systems have become extremely stable. Programming languages have changed. Agile development practices have introduced a world where continuous improvement is more important than major releases. And a new generation of Low Code tools seeks to engage the subject matter experts directly into the development process.In this interview we'll discuss how Low Code can potentially change your company's development lifecycle and help reduce the backlog of automation and improvement that is keeping you from reaching your vision for your business.
Blake Smith (00:00):
Welcome to accelerate business transformation. I'm Blake Smith.
Nick Laughton (00:05):
and I'm Nick Laughton.
Blake Smith (00:06):
And today we're going to explain the power of low code development platforms and talk about citizen developers as part of a culture of agile development. So Nick, I keep hearing about low code. I mean I hear about it a lot. What is low code? Is it new?
Nick Laughton (00:24):
Um, not really. I think a low code is an evolving idea that gives people tools to enable them to build applications without necessarily getting into a complex programming language to do that. So it's certainly not a new concept. I think the idea of Rapid Application Development (RAD) has been around for many years, but I think as the various layers in the application stacks that we work with day in, day out have evolved, I think the concept of low code has evolved.
Blake Smith (01:03):
But what is it? What does it look like if I want to be a programmer or I want to contribute to a project, what does a low code platform look like versus a pure code or I've heard about No Code. How are these things different from each other?
Nick Laughton (01:19):
I think the whole idea behind Low Code is there's less code involved. So typically they're the, let's call them the author of an application, in a Low Code platform would be dealing with an abstracted view of the code. So they'd be dealing with maybe a sort of drag and drop user interface editor or perhaps some kind of a graphical model for their for the data that's in their application that enables them to, to work with these abstracted views of the concepts that they're building and then generate all of the code that is needed to provide that functionality on the backend. Kind of like, you know, sketching an outline of the, of the application that I want and the data that it's going to work with and then being able to generate the code to make that work.
Blake Smith (02:13):
So it automates some of it and it makes some of it where you are not required to literally type in lots and lots of commands.
Nick Laughton (02:21):
Exactly. Yeah.
Blake Smith (02:23):
Okay. I know people who do programming in Excel for example, but their program only works inside Excel. How does, how does low code handle, like that portability factor is, are you locked into a platform when you use it?
Nick Laughton (02:38):
Um, it depends. I would say typically, yes you are. Um, many low code platforms do only work in their runtime. Um, but some of the newer Low Code platforms, including our own apex designer platform does give you more flexibility and can generate code that doesn't lock you into a specific runtime. We can talk a bit more about that later.
Blake Smith (03:02):
Yeah, let's do that. And then it's low code. It's different from No Code. What's No Code?
Nick Laughton (03:08):
Yeah. So I would say again, that's a bit of a blurry line definition, but I think a No Code means that we really try to get to the point where a user that has really very little experience of the underlying code to build an application can build a fully functional app just by configuring and dragging and dropping widgets on the screen.
Nick Laughton (03:37):
You know, somebody that could design a PowerPoint slide could build an application. I think that's the idea there behind No Code.
Blake Smith (03:43):
Yeah. That sounds about right. I was thinking about terms like some examples that people might be familiar with. I wonder if to an extent if "If This, Then That" (ITTT) is a kind of low code because it's mostly dragging and dropping interfaces to various platforms. I mean it only works within that context, but it's really easy to use.
Nick Laughton (04:06):
Yeah. I would say that's probably, you could call that no code cause I don't think,
Blake Smith (04:11):
yeah, you don't need you really, it just, you put in the values and it sort of works. I mean it's very limited in a lot of ways, but it is already example I guess so.
Nick Laughton (04:22):
Well and that I think you've hit on one of the key trade-offs there. That to make something completely no code, you are by definition limiting the flexibility that you have in order to make it user friendly. You've really got to limit what it can do.
Blake Smith (04:42):
It's kind of the difference between working with Legos versus working with concrete and steel. Right? I mean you can make things but you're limited by the shape and the blocks themselves.
Nick Laughton (04:51):
Yeah, exactly.
Blake Smith (04:52):
So why should individuals or corporations care about Low Code?
Nick Laughton (04:56):
Yeah, I think there's a few good reasons. For one, a lot of companies are finding these days that they're essentially getting developer limited. Their backlog of development tasks is exceeding the capacity of the development teams. And so you could look at Low Code tools as a way of both increasing the productivity of the developers that you have by automating some of the more mundane aspects of their job. Um, but also by engaging some of the more technical business people, typically they're subject matter experts that maybe would in the past have been spending time writing a requirements document or something for the developers to work from. They can actually get engaged in the, in the development process itself using these low code tools.
Blake Smith (05:42):
How do you think the best way to get buy in from those subject matter experts that they want to be part of the development process? Not just contribute to it with information. How do, how does one build a, where they recognize their innate developer within them and become part of the system?
Nick Laughton (06:06):
Well I think through experience is the best way. I think if you if you have a project where you give them some uh, training and some time to get up to speed with the tool and show them how productive they can be in a relatively short period of time and show them that in a way by putting them in charge of their own destiny, you're making them more efficient and actually maybe taking some of the feedback loops out of the development process by letting them see for themselves how their initial ideas for maybe how a particular user interface should work, can evolve on the fly as they start to actually try and implement that user interface with the, with the building blocks that you described earlier. As they start to see that they can contribute more effectively that way and the team as a whole becomes more productive than then. That's when you get your buy-in.
Blake Smith (07:02):
We've talked before about this concept of the citizen developer someone who's working at a corporation or, or wherever. It doesn't even have to be there. But let's talk about corporations for now. They work in a corporate environment. They see a place within their business process that that could be helped by automation. Maybe they're doing a repetitive task or maybe they have complex calculations and they say, you know, we don't have to do it this way. We could automate it. And then they go into the arduous process of trying to convince someone to fund a project, but then they think, well, you know what, I could just do this myself. I mean programming tools are out there and that puts a fork in the road. You've got people who figure out how to contribute from within the system. And then you've got people who sort of want to contribute in spite of the system. And that becomes what we've been calling Stealth It. And there's kind of a distinction there. How, in a healthy corporate environment, how would one harness these citizen developers?
Blake Smith (08:11):
Yeah. Well, I think that's a very good point. And one of the challenges that those types of developers have had in the past is that as you say, there's sort of a two track it process is like the real it that does the big projects. And then there's the, the Stealth It that's maybe working with platforms which citizen developers like but may not be scalable or may not be secure. And they start to run into issues where, you know, we've all seen plenty of places where they have a really cool Microsoft access database that perform some mission critical task but isn't really stable or scalable with a number of people that they have using it.
Blake Smith (08:53):
Or part of the backup platform, available network-wide... But it does amazing stuff and it seems a shame to stifle that level of innovation and just throw it away because it doesn't fit within the corporate standards. So like figuring out a way to take those, those innovative qualities, those creativity qualities among the business experts. It seems like a way to really, not just lower the backlog but also promote innovation in ways that probably unlock advantages that your company has over others where your business expertise and your cleverness that is just unique to your company can be made available to the entire corporate group through the proper application of these tools.
Nick Laughton (09:46):
Right. And the challenge there is to, is to give them a platform that means that their work can be deployed in a scalable and secure and a highly performant way.
Nick Laughton (10:00):
But also I think one of the challenges that we've been trying to address is allowing those citizen developers to collaborate with the more the school of hard core developers and really give a common platform so that as the hardcore developers build new functionality and maybe take on some of the more complex tasks that the work that they do can be packaged up in a way that it can be consumed by the citizen developer and used in their application.
Blake Smith (10:31):
I like that. When we mentioned shadow it or stealth it, I show you, you may have heard these things in your own company because they have a lot of different names. Uh, one of my favorites is people saying we're going to set up a skunk works. You know, they're trying to accomplish something faster, quicker off the radar of uh, governance or whatever. But with the goal of making the company better, more agile, being able to find an ecosystem and not just a, not just a software ecosystem, but like a cultural ecosystem where you're able to engage those creative types, partner them up with hardcore developers, have them work in a system that also respects the corporate security needs.
Blake Smith (11:15):
Uh, all the kind of governance around backups and availability and security, you know, software patches, all that kind of stuff that's really potentially business changing in a huge way. Like, you know, I hate the cliche of game changer, but it's a real game changer if you can actually get it to implement properly.
Nick Laughton (11:34):
Yeah, I think you're right.
Blake Smith (11:36):
So obviously we're not just talking about this for no reason. We've, we've as a company come up with a product that fits into this, this niche in the market, but what makes our apex designer low code better than some of the other products out there? Like why, why someone consider apex designer if they want to get into this low code toolset?
Nick Laughton (11:58):
Well, I think there are a couple of good reasons. Um, firstly as we've already discussed we designed it as a, as a platform to allow those citizen developers to work in conjunction with more hardcore developers. The apex design of platform generates applications that run on a completely a open source stack. So there is no sort of per user licensing of applications that you build with apex designer when you've built and generated your app. It's um, clean, open source, no JS and angular code that can run in your favorite flavor of container on your favorite cloud platform. Obviously can be a public cloud or internal to your company. I picked designer apps as I mentioned, use angular, which is a very popular Java script, a user interface frame framework. And so they're natively, they are responsive and run on all kinds of screen sizes in a browsers, on all operating systems. So pretty universal.
Blake Smith (13:03):
I really like the bi-directional synchronization so that if a one of your hardcore developers sees that a change needs to be made down at the code level, then they can secret eyes that change back up and it'll show up in the sort of abstracted low code visual side so that the people don't make changes and then get them over written and then lose all that work.
Nick Laughton (13:29):
Yes, the two way sync is is really a crucial for keeping that feedback loop between the developer and the citizen developer intact. We've seen some other approaches where the citizen developer sort of generates a first stab at what they think the application should be and then the hardcore developer takes it over and uh, productionize it. But without any feedback loop, that process can become very disjointing and not as as as being able to continue with live collaboration between the two.
Blake Smith (14:04):
Yes. Yeah, no, we spent a lot of time in our podcast series so far talking about agile development. And I think based on my experience and what I've seen, this is a cultural value in a sort of approach to software development that works very well with low code because it gives you a way to engage your citizen developers with these sort of hardcore developers in, in, in a way that they don't step on each other's feet. So by using user stories and the agile sprints and backlog management, et cetera, you can have everybody working together at the same time on the same project without potentially clashing with their development process.
Nick Laughton (14:54):
Yup, that's right.
Blake Smith (14:55):
So how do you, I'm just trying to imagine if, if, if you're wanting to incorporate low code into a corporation culture where you've already got developers, but you don't have this aspect. Like right now, let's assume that they're an agile shop, but up to this point, the business experts have only been used as a contributor steering a story, managing sessions, right? Uh, how, how do we change that culture to get everybody involved? What do you, what do you think that's gonna look like?
Nick Laughton (15:29):
Well, I think a key part of that is identifying the right people. You know, not, not every business person is going to take to this. Um, but usually you find in an organization there are those slightly more technical people that are interested in and willing to dive in and get involved. And then I think as we discussed already, you give them the proper support to build their first few applications or application components and you really help them to to get into the process of figuring out what they can do and what they can't do and what they need the help of the hardcore developer for.
Blake Smith (16:10):
I'm imagining a, a one of those uncle Sam, I want you recruiting posters. Uh, do you write XL macros? Have you written an access database? Uh, do you run a website on, you know, Wix or whatever we want you, you've got the spirit of a developer within you.
Nick Laughton (16:27):
So, yeah, that's, that's it. Yeah. So I think, and then as they get into it and they may start to structure an application in their own minds and they build out the components of that app and they run into situations where they think, yeah, this would, this would be a great place to make an API calls to that other system over there and grabs some inflammation, but they don't really know how to do that there. Then in the perfect position to write that up as a user story for a more technical developer to take on by thinking through how it's going to fit into the rest of app. I think there needs to be very clear acceptance criteria for that user story, and it's a really great way to get the members of the team working together.
Blake Smith (17:11):
So one other thing, and if I'm not a business expert, I'm a regular old fashioned hand coding developer, is a low code platform like apex designer going to make my job faster and easier?
Nick Laughton (17:27):
Uh, yeah, I would say it would. Yeah. Um, in fact we use apex designer to build apex designer now.
Blake Smith (17:34):
That's pretty funny.
Nick Laughton (17:36):
Yeah. I don't have an inception moment, but the developers on our team that work on apex designer find it easier to build the new apex designer functionality using apex designer because it takes care of a lot of of a lot of the more let's call them less exciting aspects of programming, like generating a lot of the boiler plate code and making sure that the you know, package file has all the right references in and so on and so forth. You know, a lot of that less value added work is all done automatically. So that's a big plus point
Blake Smith (18:13):
And it gives you a visual, a library management system that's kind of fun.
Nick Laughton (18:19):
That's true. And also, I think the other, another important angle here that we haven't really talked about is, um as I mentioned, the, the platform is node.JS, so it's a JavaScript based application builder. Um, but maybe you've got some really experienced developers in your organization that aren't actually JavaScript developers, but that they're skilled in some other language or technology. Um, because the the basic design and encapsulation concepts are the same across languages in, in many cases. It picks designer can be a very powerful tool for taking a developer who's very good in a different technology and getting them up to speed fast on JavaScript by allowing them to build an app using the low code tooling and as they as they get familiar with how it generates the code, it both teaches in the new language but also make some productive much more quickly than if they were just starting from scratch.
Blake Smith (19:22):
That's right. We talked about that the other day, that the idea that you could take someone who's got a skill set, maybe it's an older language or a language that's not as popular and it leapfrogs them right into using the latest tools.
Nick Laughton (19:36):
Yeah, it's a, it's a, it's a kind of an interesting angle on a legacy modernization. You know, we talk about modernizing legacy apps.
Blake Smith (19:44):
Yeah.
Nick Laughton (19:44):
Maybe you've got to modernize your team to go with your modernized app and this can be, this can be a great way to do both.
Blake Smith (19:52):
It can. And I think that's one of the strange risks of shadow it is that the apps you develop might never get updated. Like, you know, everything's running on an access 98 database that has never been updated. Probably not even portable to the latest version, but it's so important we can't afford to turn it off. So like, you know, how do you replace those? Probably most everybody has that in their corporation if they'd been around for a few years that you just, you just develop this huge EcoSys of these specialty tools that could be modernized, but it's really a challenge. And so this might give them a gateway to not only harness those skills for the employees, but also to get those under the desk solutions into the back office or into the cloud.
Nick Laughton (20:46):
Another cool of the open source stack that apex designer runs on is that of course you're, you know, through being involved in an open source project like no JS, you're actually leveraging the work of thousands of developers around the world that contribute to that. Um, the node package manager, which is where you can download... So node.JS is, I think, now the biggest open source repository or the most active.
Blake Smith (21:15):
Active exactly, yeah.
Nick Laughton (21:16):
...In the world.
Blake Smith (21:17):
Which gives you, is a huge tool set of uh, powerful free to use tools that can extend the functionality of your low-code projects.
Nick Laughton (21:27):
Yeah, exactly. Typically if there's a need to integrate to a third party product or something like that, somebody somewhere has already had a go at that and may have a library that does some or most of what you need, which can then can be a wrapped and packaged as an apex designer library to make it extra easy to use for your citizen developer and away you go.
Blake Smith (21:51):
and we've mentioned the phrase open source. Uh, we probably should talk about what we mean there because uh, having been involved in the open source community or using their products for a long, long time, it's, it's meaning has changed a little bit. Using open source tools like these do not require you to share your code with everyone in the world. Like, I think some people think because open source platforms often do require code sharing. It's part of the licensing. The licensing we have here will allow you to use your products without subsequent licensing fees. They're yours. You built them, you own them. You don't have to, you don't have to share the code because the software that they're built on is part of an open source ecosystem. Uh, so it doesn't have a bunch of licensing. That's what we're mainly concerned with here. I think the fact that when there's bugs in it, it gets fixed fast and that you don't have to pay proprietary fees and that the things you create, you can run them anywhere, that you can run a node.JS stack. So, yeah, exactly. It's more, it's, it's more about your freedom than being free itself, you know? Right. It's really liberating.
Nick Laughton (22:59):
Uh, it really, really is.
Blake Smith (23:03):
So how would this low code tool fit into an ecosystem that's using BPM or BHW?
Nick Laughton (23:12):
Um, well we would see it. Uh, we, we found in practice that it can fit very well into an ecosystem where BPM will be AWS in use. Uh, there's very often a need to have a small application maybe that fits between BPM and another system. So just as an example, a proof of concept that we did a couple of years ago was basically around uh, a sales onboarding process for a bank with, with their commercial clients. And so basically when the sales rep completed a, a sale to a commercial client, they needed to get some contracts signed and collect a bunch of information, which would then go into a BPM process, which coordinated all of the back office activities to have that client onboarded into that new service. And what we found was we needed to, we needed to build something that could be started from Salesforce. Uh, could collect some information, could generate some contracts in PDF format and send them to DocuSign for signature by the client and then collect up some other information and pull it all together and put it into that VPM process. And with apex designer, we were able to build a small application that did that, which worked around a lot of the complexities of trying to do that either in Salesforce or in DPM or anywhere else for that matter. So that was a very productive use case for apex designer with BPM.
Blake Smith (24:42):
Nice. Yeah, I think we, we've seen a lot of changes in BPM to be a w I'm wondering, I've got a lot of questions about that, but we'll probably explore those further in subsequent episodes. But I, it's still an incredibly powerful platform and being able to facilitate it to have even a, a greater scope is a good expenditure, I think.
Nick Laughton (25:09):
Yeah. I mean, we, we've really used BPM as a somewhat of a low code platform for 10 years or more. Now. You know, I think the whole idea behind the BPMN notation the business process model notation is that it's business friendly that a business person, not a, not a developer or a technical person can draw those BPMN diagrams and explain what it is that the business is trying to do.
Blake Smith (25:38):
I liked the, the new tool set. I like the, the transition to focusing more on cloud and web-based developments that have using eclipse. I like all those changes, but I think one of the things I like the very most is changing the name to BAW from BPM since BPM exists as a methodology outside of the product name. So I, I realize it's a small thing, but I really do appreciate that you can do business process management with the business automation workflow business. Yeah, there you go. It's still new to me. I like that a lot. I liked that I can talk about using the BAW tool to accomplish BPM methodology and design. So...
Nick Laughton (26:24):
Yeah, and I think they had to do that because the BAW now includes case management functionality as well. That's right. You know, and obviously case management is its own thing and has its own notation standards, CMN, I think it's called the BAW product name captures that. It can do more than just process, now.
