I was going to answer no, then changed my mind to yes! If it's easy enough to build your own app then yes you will build it. But what does it mean 'easy enough'. It's easy when everything falls into place, you know what you want/need, you know how to get it and you have the resources (time/tools).
Will everyone be building their own apps? No, I don't believe it will ever be 'easy enough' for anyone to do it.
Inflection is "easy enough," the qualification and quantification of that versus something that has tangible, return value. Just ask @Pega and the "dumbing down" of Pega PRPC 7 'lite.'
My answer? "No." Users luv that menu-driven, turnkey interface that holds their hand and walks them through it from 'A' to 'B.' Only power users may be interested in build your own, but they're in the vast minority.
Just my tuppence.
I agree with John Reynolds :-)
On a bit more serious note - Not everybody is a "maker", but some are.
"Makers" want to build their own applications, and because they want to build their own applications they will expend a non-trivial effort to learn how to do so - this is born out by the number of people who somehow learned how to create really cool "applications" with Microsoft Excel.
These are the folks tool vendors should focus on serving - not "everybody".
I actually think John Reynolds is right here. Take some more or less regular domestic examples: How many people love to re-program their TV/Audio sets, rebuild their PC's, or paint their house... So... if there is an app store that already contains "close enough solutions," people will rather do that. If the solution is really worth it, they will even want to pay for it.
IMO Low code is an interesting development, but the audience is definitely not the average business user...
There are Applications and there are Applications.....the risk comes when people believe its easy to write their own, the chance that there will be a proliferation of poorly thought out Applications under the BPM umbrella. I am all for Agile and Empowerment, but there is also the need for a level of consistency and coordination.
I think it runs the risk of being like the market for autonomous driving harley davidson choppers.
Well, its' bigger/better than that market - but point being that while all the technical pieces may work fine, the people it is targeted at may not want it, and the people who want a development platform may want more power.
I have an alternate theory but i'll save it for a blog post ;)
Don't really know where to start with this one. Like most bold assertions, there is an element of truth, but at the top level it's utter nonsense.
Of course more people will develop applications if you make it easier for them to do so. I mean... sheesh I'd say it was pretty silly to say otherwise.
Of course not everyone will. As has been rightly pointed out, most users simply want "an app" that does what they need it to do, but we have all seen enough feral ms-access and ms-excel "apps" out there to know that a sizeable number of people do build their own apps. And what a bloody nightmare that turns out to be. These home grown apps are like rats that are made of asbestos. They breed like crazy and are really difficult to eradicate.
Now we can continue to ignore feral apps (and the nasty mess that very often arises as a result of their toxic existence), or we can provide a framework within which we can set about domesticating them; and here is were (decent) low-code solutions have a really important role to play. Rather than allowing Johnny or Sally "power user" to squirrel away their code on their personal laptop, we should be providing them with a safe, audited and governed environment in which they can do their awesome stuff.
The thing that bugs me about the movement towards "low-code" by some in the BPM world, is that it completely overlooks the most important "bits" in BPM and goes straight for the technical/implementation issue. The challenge in BPM isn't around tooling, or developer productivity, it's down to our monumental failure to manage change.
Low-code is to BPM what morphine is to a severed leg. It probably feels awesome, but the leg is still severed.
Where to start? The economics of software construction is terrible!
Especially when you factor in all the domains you need to know -- and probably don't.
Maintaining a team that knows what you need to know for software development and also has deep domain knowledge, is unaffordable for most organizations.
How many programmers are really good at normalized data models? Or even agree you need to start with a strong foundation of properly modeled data?
Or how many programmers are good at security? Or a half dozen other deeply important and difficult topics?
And on top of that, who really needs custom software anyway? How many ways are there to organize shipping and logistics? Is your business really so special?
On the other hand, drop in an ERP system or a COTS specialty app and you're on a level playing field with the competition -- and have just succeeded in pouring cement all over yourself.
So I can understand that executives want to do business "their way" -- and thus RAD and low-code may be attractive.
(The idea of the business manager or business analyst who does their own development -- which interestingly enough was the original vision of the developers of COBOL -- underestimates the complexity of software development, except for comparatively trivial "situational applications".)
Per my comments above, most organizations can't afford to maintain a software development team, so you need to outsource software development -- but to who?
A team that will do the same thing for your competitor?
Thus a proper software development outsourcing model necessarily implies a long term symbiotic relationship between software shops and customers -- and restrictions on who the shop can work for. (Consider the implications of this model for very large consulting organizations . . . )
As a sales person with experience selling RAD (Magic, six years) and BPM (which should be the core of custom app-dev), it's interesting to see the inevitable return of RAD as low-code.
Low-code or RAD is a good idea, but there's no free lunch.
Figure out all the reasons why you shouldn't do software development, and if you still need to do it, then work hard to make a sustainable programme, a programme that makes sense for your business model. And then build your custom software first of all around BPM (and rules and data).
I don't think the average citizen will be dealing with coding applications (big applications or little apps on mobile devices). What I believe is that many people in organizations will configure, change and guide applications using model driven approaches. I also believe that the average citizen will customize their own experience with applications therefore extending them (not creating them out of the ether). They may get the feel of creating their own applications, but not really. With that stated. "low code" approaches will grow in influence and appear to be creating applications even from the "average Joe".
If you look at Moore’s curve for technology adoption, you find different profiles have different timing and attitude towards disruptive products. I think that this applies to the question. The “easy enough” is the key, but what it is easy enough for an enthusiast it is not for a late majority. So, the product should be more and more “easy enough” as time passes, reaching more customers while it moves through Moore’s curve.
Another interesting thing that should be considered is the balance need/help. If this relationship is near 1, probably users will build their own apps, or automate their own processes. If they don’t REALLY need it, no matter how much you help him with online chat, videos or FAQ, they will not build it. And if they need it, and it is “easy”, but don’t have anywhere to get help, they will quit soon.
I have been working in a project (Flokzu) which its main obstacle is just this one: how to get business user to automate their business processes without consultancy services or complex tools. And we found that focusing on the previous balance; joint with an “easy enough” BPM tool makes miracles on business users ;)
Couldn't agree more with Jim.
I don't think the average user will learn how to code and build their own application from scratch, just like a non BPM professional won't learn the meaning of all the BPMN symbols.
I do think, however, that with the right amount of help and of interest, users will be more open to learning and customizing ready-to-use apps that will help them design and model their own processes. The keyword here is the INTEREST.
Just like elderlies don't have interest in managing the latest tech-devices, people who cannot recognize the benefit in creating an app won't be willing to spend more than 5 minutes learning how to do so.
This is quite a challenge and it has a lot to do withFlokzu, the beta app that we launched a couple of weeks ago. We are still trying to find the balance between leaving everything to the user for him to create what he wants and guiding him. It has been a really interesting journey and we're still adding features and making changes, but we do trust that those who are interested in building their own workflows can do it in a matter of minutes.
I interpret “low-code” as that you need to specify/touch formally only your-application-specific artefacts.
The following techniques can help to build your own applications:
The question is not can people build their own applications, but should they.
The uncontrolled citizen developer is a security, compliance and reputational risk. However, it is important to make it easier for the right people to be more responsive in application development, so the citizen developer does not take it into their own hands unaware of IT strategy & security.
I think this image sums it up
I agree with what everyone said so far. Anyone can cook, but that doesn't mean anyone should.
I can only add my personal experience. I am a weird animal: a citizen developer (a maker) under a CFO skin (a manager). I cook my own VBA code for Excel apps (including error-treatment, LDAP-login etc so relatively advanced). I cook my own QlikView code and some SQL scripts for BI. I cook my own Tasker scripts (the Android super-app) for work automation on the mobile. I terrorize my BPM consultants by having them develop my process apps while connected to the projector in my conference room, bombarding them with questions and comments: what does this Java class do? you forgot to link this object to the data model. this Groovy script does not call the webservice correctly. don't use that XOR crap, make a business rule and attach a boundary non-interrupting intermediary event to it.
So I am a happy maker. But a sad manager. Because when I look back, with a sense of pride and achievement, at everything that I built, I realize it's not scalable and maintainable. I am training people alongside me to pick up the stuff I build and have them improve it. But people with exact same interests as me are in short supply. This is just a way to get by and try smart stuff with quick returns. It's okay to have it as a madman's lab (my case). But it's not a way to build a sustainable #entarch change management program.
Building apps is tough. For citizen developers it's even tougher as they lack formal training, formal motivation and they operate in a heavily customized business environment. BPMS's can make business app building easier, but I can't see this getting "easy enough" anytime soon.
Interesting discussion so here is my take based upon real experience with early adopters using declarative (prebuilt code no code generation or compiling) build direct from the model of business logic and rules; I am talking enterprise level requirements. First users really like as they can see their processes coming to life V quickly not just the theory the real use to test play with before deployment. Do they want to do the build? No it’s not their job and remember any process involves collaboration with colleagues and very likely "managing" use of legacy data so a business analyst is well placed to do all this.
As build takes place areas are indentified that will likely need "change" and here capabilities built to allow users to implement within approval process if required. Always remember compliance will have a view….! So for the foreseeable future I do not see users building their own applications. However 10 years out as next generations become more empowered, the current legacy “problems” are contained and the build capabilities evolve yes I could see such a move being practical and welcome