[Transcript] Low-code: The solution for agile platform development in Process Excellence – Interview with MatsSoft’s Nigel Warren

Craig Sharp: Hello, and welcome to Process Perspectives, a podcast series produced by the Process Excellence Network. PEX Network is an online and event community for process professionals. I’m your host, Craig Sharp, editor of pexnetwork.com. Coming in today’s programme, we’ll be talking to Nigel Warren, head of marketing at MatsSoft Ltd, who will be talking about one of the newest up-coming trends in PEX tech, low-code, a user-friendly, quick-to-market development approach that puts test and learn, and customer-centricity, at the heart of your multi-channel platforms. Nigel, hello, and thank you for joining us.

Nigel Warren: It’s my pleasure, thank you.

Craig Sharp: Recently, we’ve been seeing increasing coverage of low-code development platforms in media articles and analyst’s reports, it’s clearly a topic of relevance to the PEX community but, as yet, it’s not well-understood. Nigel, could I start by asking, what is the phenomenon, and is it something new?

Nigel Warren: Well, Craig, I think it’s like most technology developments; it’s evolution, rather than a complete bolt from the blue. But I think it is new, and I think it will prove to become very important, as far as the Process Excellence community is concerned.

Essentially, the idea behind low-code development is that you can make it easier for business people to achieve what we could call software-powered business improvement, without needing to code or, in other words, without having to program.

Moreover, thanks to cloud - or private cloud - deployment, a business is not dependent on their IT department to install servers and software before a project can start, so that means, for example, if you’re a process improvement professional with a pressing deadline to achieve some kind of automation, you’ve now got a choice as to how you get that built. You can go and talk to your IT department and see how they can help you, or, alternatively, you can turn to a low-code development platform and build it yourself. Now, that may sound daunting, but there’s very little or no programming involved, so it’s not that difficult, and you can learn how to use a low-code platform very quickly, nowadays.

Craig Sharp: Why would a process improvement person want to get involved in low-code development?

Nigel Warren: Very often, it’s the need for speed, and what I call jumping the IT queue. For example, you might want to approach your IT department for help, but then find that everyone is busy with a long-term ERP project; they’re unable to help you for, perhaps, six to nine months.

Supposing you waited for nine months, that quickly becomes 12 months, after a period of analysis, before progress really starts to be made, so when you’re faced with delays like this, the need for speed, you know, becomes the mother of invention, a do-it-yourself approach starts to have real appeal. And the other reason is lowering the risk of software development.

Craig Sharp: Lowering the risk? You mentioned DIY. Now, I’ve had some experience with DIY, I wouldn’t normally associate it with lowering the risk, so can you explain how the two marry together?

Nigel Warren: Yes, I’m not surprised to hear you say that, and certainly my DIY efforts in the home are not to be witnessed, but a way to explain this is that many of your audience have set up a blog or a website of some sort, and 99% of them will have turned to a cloud solution – like WordPress, Blogger, Tumblr – hardly anyone, nowadays, would learn to code HTML to do this sort of thing. They turn to an off-the-shelf system like WordPress, because it comes with lots of templates, navigation style, publishing, revision and all that sort of thing, built in, so, you know, it really takes the strain.

You can create a beautiful customised blog or website, without learning to write HTML, and you can produce something that looks really good in very little time. The learning curve isn’t particularly steep at all. So if you take that, sort of, paradigm and apply it to the world of software development, you know, that’s, kind of the same, with a platform like ours, the MATS platform. It’s just like WordPress, it’s got lots of wizards and templates built in, so you can create workflows and databases, user interfaces and so on, without having to program the system at all.

Craig Sharp: I must admit, I have used WordPress myself, for a number of years in the past, so I think I’m beginning to understand. You’re saying that it’s lower risk because you can configure a solution by filling in forms and selecting options, tick the box here, drag that there, as an alternative to the hard coding?

Nigel Warren: That’s precisely it. But actually, I think there’s more to it than that.

We’re reducing the risk in a completely different way, as well, I’m sure that most of your audience have heard of the Lean Start-up, it’s also sometimes referred to a test and learn, and the idea here is that you create a minimum viable product, and then you test it with customers, to see what they think. What do they like? What would they like different? The brilliant thing about this is that you can build something basic, but very, very quickly – perhaps 20% of what you think is needed overall. So having just invested that small amount of time in building something, you can then get user feedback, or customer feedback, and by doing that you get a much more accurate view of what the next 80% needs to look like.

So it’s also known as test and learn. When you show people something that’s working, what it looks like, how it behaves, you suddenly get a huge amount of feedback. You get ideas and excitement. Can it do this? Can it do that? Can this work… this bit work a bit differently? Can we move this field? Can we add this field? And so on. If you get that kind of feedback, if you get it early on in a project, it’s not scope creep; it’s just a more accurate understanding of requirements. And this reduces the main risk, in my view, that’s associated with software development. That risk is the gulf between business people and developers, and the difficulty of communicating your requirements. That’s just not easy to do and if that explanation of your requirements doesn’t go well, you end up with a lot of things coming out in the wash, very late in the project, and that leads to re-work, it’s what causes projects to run over time and over budget.

Craig Sharp: That makes a lot of sense, and it sounds very promising, but what’s stopping all projects from working this way? Why is everybody not using this approach?

Nigel Warren: Well, I think, actually, a lot of software development companies are working this way themselves now, particularly internally. They, can release new features and put them online, available through the cloud, extremely quickly, and they can put a kind "health warning" on the user interface, they can invite customers to try it and to provide feedback, and they’ll very often put a feedback link on the web page of the system you’re using, so that you can say what you think and provide feedback really easily.

The methodology has a name: Scrum, or Agile Development. It’s a very iterative approach, and really, at its heart, it recognises that customers struggle to elicit their requirements 100% correct, up-front. They have a habit of changing their minds, so this iterative approach, basically, kind of, takes that in your stride.

To answer your question, what’s stopping all software development from working this way, probably the main constraint is the commercial constraints of two or three parties having to work together.

So if you think of just an internal development, where you had an IT department, clearly it pays for that IT manager, or the CIO, to know how long a particular project is going to take, and that leads to you needing to analyse the requirements in a fair amount of detail, so you know how many people you’re going to have to put on the project and how long they’re likely to be working on it. So that leads you towards needing to do a fair amount of up-front analysis.

Now, imagine you’re a company that has outsourced your IT. Scoping of requirements now becomes, even more critical, because you’re paying for development by the man-hour. Change requests have to be approved each step of the way. You can see how an agile, Scrum approach to development and this traditional IT model have a hard time getting along together.

Craig Sharp: A lot of what you’re saying about low-code sounds very familiar. Isn’t this what the BPM software industry have been saying they can deliver and have been promising to help address for years now? What’s this difference?

Nigel Warren: Yes, absolutely, I think that - to some extent - BPM has been successful, for example, for ourselves, where customers are documented and understood, their processes, before we engage with them, they’re in a much better place. They’re much better able to explain their requirements from automation, and that really accelerates development, in my experience.

So business process analysis tools that bridge the gap between business stakeholders and IT are definitely well-proven. It gives you a common reference point, it gives both sides, the business and IT, a common language to understand requirements, but when you come to BPM suites that promise greater agility, I think that’s true, they’re probably more agile than ERP systems, like SAP and Oracle, and they’re certainly fit for placement in your business where there’s a benefit to getting something that’s more customised and, perhaps, more agile.

That’s certainly the theory, but the reality is that these are really very technical products still, and I think they’re very ill suited to a do-it-yourself paradigm, the sort of thing I was describing a few minutes ago.

I mean, I think it’s very easy to get a measure of this. If you just go to the recruitment web pages of these BPM Suite - type companies, you’ll quickly realise how technical these products are. I was just looking at one the other day - a junior application developer needed, two to three years of Java-centric application development. They needed to know things like J2EE and various databases like Oracle and SQL Server and so on. You know, if that’s what you need for a junior application developer, heaven help people that want to do this in-house!

So from what I’m seeing, a lot of BPMS developments use a lot of external consultants – people that are really very highly trained – and that really just leads us back to this paradigm of the need to get an accurate specification up-front, to scope the project really accurately, because you’re reliant on external consultants, and you need to know how much that’s going to cost. And that just leads to this paralysis of "okay, well, you didn’t tell us that this is what you needed, now you’re telling us, okay, that’s a change request", etc. So I just think that the heavyweight BPM Suite products are going to have a really hard time satisfying this more federated, self-service kind of approach to IT.

Craig Sharp: Where are you currently seeing low-code platforms being used?

Nigel Warren: Well, in large organisations, we’re seeing an increasingly federated approach to IT. Departments like marketing, operations and customer service very often have satellite IT departments with considerable autonomy from central IT. These really seem - to me - to be the ideal situations for a low-code development approach, because the aptitude of people in those departments is going to be much more about the business knowledge, and less about programming.

What I’m also seeing is that, essentially, the people that are getting involved in developing on low-code platforms tend to be the business analysts. These are the people that previously would have done a good job of documenting the requirements and maybe drawing the process flows, but now, really, they’re able to take the next step and actually start building the automation.

Craig Sharp: You’re talking about, I believe it’s called, Shadow IT? Do you think that’s something that’s becoming a real headache for CIOs?

Nigel Warren: I think it was Gartner that came up with the term Shadow IT, and I don’t particularly like it, because it sounds stealthy, sort of illicit, like the shadow economy, but you know, essentially, this is something that you can’t hold back.

I think that business people today are just so much more IT literate, they have this experience of using packages outside of the work situation – the example I made about WordPress, for example – so I think people are just so much more knowledgeable and empowered, at a business level, that IT can’t really stand in its way. They need to increasingly accept it, but I think there’s a need for them to govern it.

It’s not a question of throwing up their hands and abdicating responsibility for what individual departments to do, quite the contrary. I think that showing a path, putting in place some standards and maybe supporting the use of low-code platforms is entirely in their interest.

Let’s face it, if you’re the CIO of an organisation and you’ve got lots of different departments going off and developing different systems on different technology platforms, that’s going to be a real headache to support. Whereas if you were to standardise on a low-code platform, and know when a department needs to do something that’s out of the ordinary, that’s maybe on a test and learn, experimental basis, we’re much more comfortable if we know that they’re using the low-code platform that we favour, the one that has been proven several times before, within our business. So I think you’ll find that the CIO is going to become increasingly accepting of this kind of technology as part of their portfolio of software products.

Craig Sharp: Okay. Now, a lot of the conversations I’ve had around low-code, recently, have been with industry experts, business intelligence companies, vendors, from an end-users perspective, from our listeners perspective, how would they know that it was time for them to start taking low-code seriously, and to start looking for a platform, perhaps?

Nigel Warren: Well, I think there a number of tell-tale signs to look out for. If you’ve got people attempting to collaborate on spreadsheets on a daily basis, particularly if those spreadsheets are 20 columns wide, or more, you know, that may be a sign that what’s really needed is a relational database. A low-code platform would be an obvious place to go for that.

If you’ve got people using email as a, kind of, workflow system to pass tasks from one person to another, or to seek approvals, it’s definitely a case to look into this.

Where you’ve got people copying and pasting from one system to another, chances are you need to build some integration, and a low-code platform would be really good for that.

And maybe you’ve got a lot of access databases that are becoming a bit tired and old-fashioned, or you’ve been trying to build something on SharePoint, and that’s not going entirely to plan, that might be time to look at a low-code platform. So those are the some of the symptoms, if you’ve got those sorts of things going on, I would say, time to look for a low-code platform.

Craig Sharp: Again I think it’s probably something our listeners are not very familiar with at the moment – aside from the articles there are on PEX Network, of course – there is a Forrester Report, which is premium, I can’t remember the price exactly, so do you have any further information that our listeners could look at to find out more about low-code?

Nigel Warren: Well, the Forrester Report that you allude to, that’s available from the MatsSoft website as a free download. So if anyone just ‘Googles’ MatsSoft and low-code, they’ll find that page.

For anyone who’s lucky enough to be coming to PEX Week in Orlando, we’re delivering a workshop on the first day, together with Clay Richardson of Forrester, who’s the absolute expert on this topic. Together, we’ll be exploring how to apply lean start-up principles to process improvement, using a low-code approach. So I hope that I’ll get to meet some of your readers and listeners at PEX Week.

Craig Sharp: I’m sure you will. Nigel, thank you so much for your time today, and thank you so much for answering these questions.

Nigel Warren: My pleasure.

Craig Sharp: And that’s all from us today, here at the Process Excellence Network. Again, Nigel, thank you for joining us, and for our listeners, as always, don’t forget that for additional process-related resources, including podcasts, articles, webinars, white papers and more, log on to www.pexnetwork.com. Thank you very much, and goodbye!