Citizen developers can work with business leaders to develop real software solutions on low-code platforms

Will low-code/no-code tools and automation lead to fewer developer jobs? My guest today doesn’t think so, and he’ll tell us why on this episode of Dynamic Developer. The following is a transcript of this interview, edited for readability.

Bill Detwiler: I’m your host Bill Detwiler, and I’m joined by Malcolm Ross, VP of product strategy and deputy CTO for Appian. Malcom, thanks for joining us.

Malcolm Ross: Thanks for the time, Bill.

Listen to the podcast version of this Dynamic Developer episode on SoundCloud

Malcolm Ross: Thanks for the time, Bill.

Bill Detwiler: Before we get started talking about automation, and low-code, and no-code citizen developers and the effect that that’s having on the software development industry as a whole, for those who don’t know Appian, give them a little rundown on what Appian is, what it does, and what you do there.

Malcolm Ross: Sure. Appian is a low-code development platform, and we specialize, of course, in automation, workflow, RPA, those other areas. So, if you think about what that means is, it’s a new paradigm for building applications using more visual, declarative drag and drop tools to rapidly deliver solutions that customers are expecting and of course, in a cloud native modern architecture as well.

SEE: Business leaders as developer: The rise of no–code and low–code software (free PDF) (TechRepublic)

I’ve been with Appian for over 16 and a half years now. So, several roles, but my current role is I lead product strategy, which is the long-term roadmap direction of the company, but in several roles as far as leading product management, product marketing, other aspects of the company as well. And been in the automation space myself before Appian for about 22 years now. So, a lot of experiences in enterprise software and building workflow BPM processes for a variety of companies over several decades now.

Bill Detwiler: I think that’s a great segue into my first question. Because you have so much experience in automation, and one of the fears that software developers, engineers, full-stack developers have when it comes to low-code and no-code tools is that it could be, I guess, limiting their career prospects, right? It could be by making it easier for more folks to develop enterprise software without the fundamental traditional software engineer and training background. Does it make them less needed, right? Are there going to be less developer jobs because now you don’t need a developer to build software?

So, pulling on your experience in automation from the past and now translating that into not automation per se, but actually just reducing the barrier to entry to creating enterprise software, what do you say to those concerns? How do you address them?

Malcolm Ross: Really, there’s so many ways to unpack that, and I’m one of those myself: I got my degree in computer science and information science a few decades ago and consider myself a developer. But with that regard, it’s a look at the global backlog of digital needs, it’s humongous. The reality is, there’s not enough people to satisfy the demand, to digitize all these businesses out there. And things like the global pandemic have just accelerated that need as we need to work more at a distance, as retail stores need to do online shopping and digital pickup more, the demand is just simply not stopping–it’s growing and growing. So, there’s no fear as far as software developers losing jobs, because speaking from a software company, we can’t hire enough people with professional software development experience.

Low-code tools, though, are a direct response to this trend of what we’ve seen over the past 10 years of the need for agile development, agile growth. So, as we saw in the mid 2000s, there was a big shift from, say, Waterfall development to agile development and doing rapid one-week, two-week sprint cycles and showing results quickly and having more agile development methodologies that adapt to business change while the methodologies of how you build software change, the tools themselves did not and didn’t really allow people to build quickly and with agility because of the high-code experience, because of the numerous tools required. You think about a Java developer, right? If I’m building in Java, fine, I have spent time learning that high-code experience, learned how to build all these interfaces, but Java’s just oftentimes is a service layer.

If I want to, say, build unit tests on it, I need to use J units. If I want to start to merge that into a CI/CD architecture, I need to learn GitHub and scripts, I need to learn Jenkins or Bamboo. If I need to build integration or user experience testing, I need to learn Selenium. Oftentimes, I want to build that UI layer, I need to learn Angular or React or other languages. So, it’s immensely complex to be a full-stack developer and to build all these elements; you have to learn a lot of tools, not just to build what you want but also to get it through an agile CI/CD pipeline. And that’s complex, and it’s difficult to train people and it’s also difficult to do it right.

Low-code tools really aren’t about displacing developers. It’s about facilitating that process more elegantly. When you think about low-code, you often just think about that composition layer. So, the composition, like, how do I declare what I want from coding to drag-and-drop? Well, anyone who’s familiar with the SDLC knows that that’s probably just 20%, 30% of the entire software development process. There’s testing developments, there’s pushing things through, there’s branching, there’s diffing, there’s merging, there’s deployment cycles, there’s testing. All these things need to come together to produce high-quality software.

Low-code tools, or at least the ones like Appian, address the full lifecycle. So, it’s not just about declarative tooling, making it easier for non-coders to build stuff but it’s also about facilitating the entire agile lifecycle to build things quickly and deploy them quickly and iterate quickly and change quickly as well.

Citizen developer programs

Bill Detwiler: That’s the sentiment that I’ve heard from lots of people, is there’s so much work out there that we’re not running out of work for full-stack developers anytime soon; this really is about broadening that base. And I know one of the ways companies broaden that base is through citizen developer programs. Talk a little bit about those, how organizations can use these low-code tools for that percentage of the process that you just talked about and bring more people within their organization into that process.

Malcolm Ross: Yeah, that’s the multiple layers, too, because expanding the number of people who can participate in application development is naturally going to be beneficial. And you do that by both hiring more professional developers as well as simplifying the process of development, which is the low-code side, which then gets into citizen developers and who is a developer, who is non-developer.

So, when you think about more citizen developers, we often have these already. We’ve actually had these citizen developers for 20, 30 years now, ever since the Microsoft office suite came out and allowed you to write macros in Excel, right? We’ve had citizen developers, and they build things in the Office suite.

I myself spent time in the ’90s building FoxPro and Microsoft access databases in the business line for mortgage companies. And I was a citizen developer: I wasn’t an official IT but I was building things that were used for daily operations for in that case mortgage rates notifications to lenders. So, we’ve had this realm of citizen developers for a long time, and the spiral of Microsoft access databases in complex Excel spreadsheets has just been growing and growing.

So low-code tools do give you an opportunity to expand both what system developers can create beyond just the realm of the office suite. They can now create mobile applications, robotic process automations, workflows, web applications. They can expand more, but as well, a low-code tool like Appian gives you more centralized control of it rather than sitting on everyone’s client desktop and people doing whatever, you can have a governance lifecycle on top of it, I can still have IT run a center of excellence to manage the citizen developers. I can enforce policies, consistency, so I can have a more managed approach, I can empower people, citizen developers, as well as make sure I’m still maintaining my information security and development best practices as well.

SEE: Hiring Kit: JavaScript Developer (TechRepublic Premium)

So it’s the best of both worlds. One of the other things that low-code tools also focus on is that business-IT collaboration. So, you have pure citizen developers, so you just let go, but then you also need a realm of where I align business and IT more closely. And this often is a journey as we evolve from Waterfall to agile. One of the biggest challenges of that is getting the business to engage.

Business users have been spoiled or used to Waterfall where they just tell you my requirements upfront and then say, “I’ll see you in four to six months when you finish my magical application,” without talking to you on a regular basis, and we of course know that doesn’t work. And the key to agile is really having that regular communication with the business where I demonstrate as a developer what I’ve built, validate with the business constituents that this is what they want, and then plan and change the backlog to meet the next set of criteria.

So, it’s that constant communication. Low-code tools, since we’re providing a mechanism that the business can understand better. So, instead of looking at code of a logic, maybe they have a specific tax calculation rule, instead of looking at the tax calculation in Java code and say, “Hey, is this what you want?” They’re not really understanding what they’re looking at. You can show them a decision table. You can show them a process flow or decision tree, you can show them something visual that the business users understand better.

So a big part of what low-code tools is, is still empowering IT as well to build applications but have a development framework which bridges the communication cap with a business so that they can look at your work and understand it and also validate it and participate better in the Agile development process. So it’s both fronts, low-code is not purely a citizen development tool, it’s actually more commonly adopted by professional IT, and the benefit is actually the business-IT collaboration of having the common language framework.

Adopting an agile culture is an evolutionary process

Bill Detwiler: Yeah, I think that’s interesting. And I like the Microsoft Access FoxPro analogy there. I remember doing those same things back in the ’90s too, and that’s the way I liken the low-code and the no-code tools to the same rise that you saw with business productivity suites during the ’90s and the 2000s, right? It made even things like word processing and Excel spreadsheets didn’t suddenly mean we don’t need CPAs and we don’t need people to use those tools, but it gave more people access to those tools, which allowed businesses to be more productive and to produce whatever they were using to produce, whatever they’re producing in a better way to broaden that base.

And I’d like to key on something you just said there, which is the interaction between the business and between IT, because you were talking about how there needs to be as part of the agile process, this back and forth. How do companies do that successfully that maybe haven’t done that in the past? I’m not sure, most folks that I talk to have moved to agile development process. And as part of that, they’re involving product managers or they’re trying to get the business constituents more involved in the process, but that can be a little tricky, as you said, for companies that maybe have been spoiled or they don’t have that as part of their culture. How have you found companies do that successfully?

Malcolm Ross: Yeah, it’s evolutionary because what you’re getting at, it’s no longer a technology problem, it’s a cultural challenge inside organizations. And over the past several decades, we’ve grown in thinking here’s business, here’s IT, and they are distinctly different business units. And when you set these artificial barriers of the departmental structures between business and IT, it creates almost a natural conflict as well. I’ve been in meetings where business and IT could not literally sit in the same conference room together because of the hostility. IT would think that business doesn’t understand the complexities of managing the architectures and keeping up to date. Business is saying, “IT is not responsive enough, they’re not meeting my needs.” And there’s a hostility there.

So, what needs to happen is really a breakdown. If you look at the modern companies that are succeeding today, the Ubers, the Lyfts, Facebooks, things like that, there almost is no business and IT. They’re almost one integrated company and IT is an essential part, or the act of software development, is an essential part of how their business works. So, that’s probably the first thing, is starting to break it on those lines and moving these merged teams together that they have a shared common goal in that they’re investing, the business is thinking about software development as their business, as how they go to market.

And that’s a cultural breakdown of these hierarchal structures and bringing them together. And then centralized IT’s role, then, is not necessarily doing every project because you have people sitting with the business doing the projects, but really establishing the standards of the organization. Things like information security, making sure that the way information is handled is secure, things like user experience, having established user experience model for all applications, things like SOA [service-oriented architectures] that you have standards for which I’m going to expose information APIs so that it can be easily reused across the enterprise.

That’s shifting where pure IT’s role is not to through individual project delivery, but overseeing IT strategy across the entire company while merging IT with the business functions more directly as well. So, that’s not easily done, and especially you’re breaking down oftentimes decades of cultural hierarchies that have been established and trying to merge these business units together.

Getting developers into the field to learn the real challenges

Bill Detwiler: So, if you’re speaking to someone on the IT side and the development side, so if you’re talking to a dev stack and you’re talking to senior developers, you’re talking to team leads and to department heads, what would be your advice for them to get started in trying to break down some of those barriers? So, if I’m coming at this from that side of the table, what type of outreach or what type of processes do I need to put in place both for my team and myself to shift our role in the process to oversight and to encourage the lines of business to take on some of that responsibility themselves, but also do so in a way that meets guidance and policy requirements like you talked about?

Because I think a lot of people want to do that, and I think a lot of companies are like “Oh, this sounds really good and so we know where to start.” But if you’re coming at this and you’re a team lead, if you’re the senior director of engineering at a company and you’re sitting here going, “OK, well, how do I move the ball the first step? What are the first steps that I need to take in this process?” Is it going to executive leadership? Is it trying to make grassroots inroads with the head of finance or the head of HR to say, “You know what would be really good, is if you had this person on your team or let me identify the people on your team who can help us use these low-code and no-code tools.” How do you get started?

Malcolm Ross: Obviously everyone’s different in where they are in their journey. Some companies are very modern, some companies have legacy to deal with. I’ve worked with some companies like major utility water companies and some other big trucking companies, and what I recommend to them where you have these oftentimes not just decades, but century or more of legacy of interactions is IT needs to get out of the cube, right? They need to get out of the office. In the water utilities company for example, I said, “Well, if you’re trying to build mobile solutions for someone who’s in the field, IT, you should take the guy out of the cube or the gal put them in the suit, have them go into the sewer pipes and the water pipes and live the experience to the business users.” There’s that respect that needs to be built.

Another example, Appian has built several contact center solutions for organizations. And one of the things that when we were building contact center solutions is I was shipping my engineers to contact centers in remote areas of Kentucky and Salt Lake City and saying, “I want you to sit in that contact center and work the phone for three days. You want to handle calls, you want to live their experience.” And that doesn’t just give the IT person a perspective of what the job is really like for what you’re building solutions is for, but it also builds respect with the business. The business sees the IT person as, yeah, they’re helping me do my job, they’re here in the seat next to me, they’re here in the sewer pipe with me cleaning out gunk and they’re looking at what my job does.

Oftentimes, again, in some of these legacy industries like utilities and energy and trucking, you have people who have been doing that job for decades itself, as far as maintaining utilities, and there’s a level of respect that has to be established. And the business needs to see IT as a participant in what the mission of this corporation is. So, that’s part of the cultural side. And then once you establish that respect like, “Hey, yeah, I’m part of this business. I’m not just this outside IT organization. I’m part of you to help derive new solutions.” Then it’s also establishing COE tools. But what IT needs to do is look seriously at their stacks. And oftentimes you get in this technical debt trap, right, where you love to build new solutions but I spend 80% of my time just maintaining yesterday’s applications.

And I go and get a small sliver of my time actually building new solutions, which is often the trap that IT falls into is you’re just optimizing memory, you’re making sure CPUs stay or the computers stay online. You’re doing patches to application web servers, you’re just doing things that the business doesn’t appreciate, and it’s just janitorial work of IT. You need to look at this stack, identify all the things that you’re doing janitorial work for, just keeping the lights on, and find solutions that extricate yourself from doing that work. Cloud-based low-code solutions are exactly that, where we automatically upgrade, we automatically patch, we automatically secure, we maintain the architecture for you so you can focus on innovation, which is another benefit of low-code tools is to refocus the attention of the people who use these low-code development tools away from just maintenance and back onto innovation as far as the total amount of time you spend.

And then as you look at the architecture, then starting to establish that COE as well, once you have that credibility with business, then I can start to dictate and it’s like, “No, this is the way you need to handle information. There’s GDPR today, there’s serious ransomware attacks going on. We need to protect this company against these IT threats.” That’s the IT center of excellence’s job. We need to establish standards of IT and how everything’s going to get done. So, it’s a multilayered process and when you think about the things that need to go on, but starting with that first, the business-IT respect collaboration is probably the most important area.

Bill Detwiler: I love that sentiment and I’ll give the audience your little information, full disclosure. I started my IT career, my first enterprise job was in a public utility. And for new folks that would come in, that would say, “Well, why are these systems failing? Or what’s this hardware failing?” We’d say, “Yeah, that’s because you’ve never been to a coal-fired power plant.” In Kentucky for folks that can’t tell from my accent. But once you got out there and you saw some of the environments that the lines of business were operating in, then you understood their challenges, and I will agree with you 100%. It provided a mutual respect and mutual understanding because IT and the networking folks and engineering folks understood what people were working with on a day-to-day basis and vice versa.

The lines of business folks said, “Well, you actually took the time to come out here.” So, I wholeheartedly agree on that. Well, Malcolm, I’d like to wrap things up because I think this also leads to a really important point and something that I’ve heard many folks mention, which is bringing those software development processes closer to the lines of business, right? So, whether it’s both IT going down and being involved and walking in the shoes of the business, but it also allows those lines of business through citizen developer programs to have folks who are already intimately familiar with their situation participate in that development process.

So, for companies that have done that successfully, I don’t want to say pushing software to development down, but it’s just bringing software and application development closer to the business, are there any recommendations that you have not in process or you’ve already talked about for ways to do that, I guess, to have the right people within the lines of business use these low-code, no-code tools so that they can participate in the software development process?

Managing the process so you don’t end up covered in paint

Malcolm Ross: Yeah. Again, I think a lot of us lived through this with Microsoft SharePoint as well when the promise of SharePoint was, “Hey, I’m going to have a portal environment that’s going to let everyone share their information.”

Bill Detwiler: If you could get it to run and it wasn’t slower than everything in the world.

Malcolm Ross: Yeah. I have a whole slide I talk about the history of SharePoint where I equate it to going to Michael’s and buying the best paint set, right, and you just imagine that if I buy the best paint set and I give it to my children, they’re going to produce Van Goghs and Picassos and beautiful works of art. And then the next slide I have is a child covered in paint, right? So, with great power comes great responsibility as Spiderman’s uncle says, but that’s the challenge with low-code tools as well. Yes, citizen developers can participate in the application development process. Don’t end up with a child covered in paint.

You still need to be an active participant in the standards practices of how software is built, and that center of excellence is very important. So, it needs to be metered, it needs to be controlled, it needs to be measured while also it needs to be empowered. You need to empower the business to satisfy themselves more quickly while often having times that regulatory authority managing as well. So, that’s a really tough balance to do. How do you give people freedom while also still maintaining control in that sense?

And again, low-code tools are pretty much the core of that. It’s going to give you the mechanism to do it. It’s also, as I mentioned before, going to give you the mechanism to also not just paint yourself into a technical debt corner. As people do these things, they’re going to build up technical debt because they’re going to build applications that you rely upon and they need to be maintained. And cloud-based low-code tools again, they focus on automatic upgrades, automatic security. There might already be FedRAMP certified, PCI certified, HIPAA certified.

So, you get this architecture that’s protecting you a bit from technical debt, but the human element is the hard part, managing those expectations, giving people freedom to do development with a tool while also having a SDLC that controls how things are getting into production and measured over the long term.

Bill Detwiler: I think that’s a great place to end it because I think that is the challenge, right? Setting up those guardrails, setting up those bumpers, both technically and on the human perspective, and it’s a challenge, but it’s a good challenge because I think in the end, it gets you to a place where you can be more agile, where companies can bring software to market and respond to business needs more quickly, which as we’ve seen in the last year with the COVID pandemic and people rushing and accelerating their digital transformation plans, it is really critical to survival especially when you have a dramatic change in the business environment. So, Malcolm, again, thank you for taking the time out to talk with us. I really appreciate it and hope you’ll come back.

Malcolm Ross: Cool. Thanks, Bill. It’s been a pleasure.