BPM.com
  1. Peter Schooff
  2. BPM Discussions
  3. Tuesday, November 10 2015, 09:53 AM
  4.  Subscribe via email

A point raised by John Reynolds in [url="https://www.linkedin.com/pulse/low-code-answer-john-reynolds"]this blog[/url], where he writes it's a fallacy to believe that: "If you make it easy enough for people to build their own applications, they'll build their own applications." What do you think?





Craig Willis Accepted Answer

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.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Patrick Lujan Accepted Answer
Blog Writer

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.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 2
John Reynolds Accepted Answer

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".
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Walter Bril Accepted Answer

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...



Comment
@Patrick: Ah, that's another thing indeed... I was thinking: When you aren't a "maker" in general as John says, you won't quickly create stuff, both at home AND work :-).
  1. Walter Bril
  2. 1 year ago
Yeah, but now we're talking about 'work,' not 'home.' Corporate grunts aren't usually that motivated.
  1. Patrick Lujan
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Geoff Hook Accepted Answer

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.
Comment
sharepoint effect :)
or, in the late 90's : VB effect :)
  1. Scott Francis
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Scott Francis Accepted Answer
Blog Writer

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 ;)
Comment
@JohnMorris, oh he will, don't worry about that. ;)
  1. Patrick Lujan
  2. 1 year ago
Please let us know about your blog post when it is available!
  1. John Morris
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Gary Barnett Accepted Answer

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.



Comment
How do you US people say that? Something with drop a mic.
  1. Emiel Kelly
  2. 1 year ago
CLAP! CLAP! CLAP!
  1. Patrick Lujan
  2. 1 year ago
@Gary, you should get an award for compelling metaphors! Situational apps as "asbestos rats"; Low-code as "morphine, but the leg is still severed" . . . and not only nice metaphors but absolutely true.
  1. John Morris
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 7
John Morris Accepted Answer

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
[u]know for software development[/u]
and also has
[u]deep domain knowledge[/u]
, is
[i][quote][b]unaffordable [/b]
[/i][/quote]for most organizations.


How many programmers are
[u]really good at normalized data models[/u]
? Or
[u]even agree[/u]
you need to start with a strong foundation of properly modeled data?


Or how many programmers are good at
[u]security[/u]
? Or a half dozen other deeply important and difficult topics?


And on top of that,
[u]who really needs custom software anyway[/u]
? How many ways are there to organize shipping and logistics? Is your business really so special?


[u]On the other hand[/u]
, drop in an ERP system or a COTS specialty app and you're on
[u]a level playing field with the competition[/u]
-- and have just succeeded in pouring cement all over yourself.


[i][quote][b]So I can understand that executives want to do business "their way" -- and thus RAD and low-code may be attractive.[/b]
[/i][/quote]


[i](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 [quote][b]COBOL [/b]
-- underestimates the complexity of software development, except for comparatively trivial "situational applications".)[/i][/quote]


Per my comments above, most organizations can't afford to maintain a software development team,
[u]so you need to outsource software development -- but to who[/u]
?


A team that will do the
[u]same thing for your competitor[/u]
?


Thus a
[i][quote][b]proper software development outsourcing model necessarily implies[/b]
[/i][/quote] a
[u]long term symbiotic relationship[/u]
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.


[b][quote][i]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]
[/b][/quote]
Comment
Most orgs are real good on Day 1, suck swamp water on Day 2. - Me
  1. Patrick Lujan
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Jim Sinur Accepted Answer
Blog Writer

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".


 


Jim Sinur
Comment
"We'll see" said the Zen master. I'm willing to lay off the bet Brother Jim that they won't. We'll see.
  1. Patrick Lujan
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Juan J Moreno Accepted Answer

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 ([url="http://www.flokzu.com/"]Flokzu[/url]) 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 ;)
References
  1. http://www.flokzu.com/
Comment
Juan - I have looked into your project - it's laudable what you achieved so far from a technical standpoint, but you guys are betting the farm on the low-code approach while still displaying the BPMN flow.

I think you guys took an important step towards making a process platform more palatable, but it's still not scalable - you will get some enthusiast citizen developers but I don't think in its current form the project can cross the chasm. I really hope I'm wrong because you are moving into the right direction.
  1. Bogdan Nafornita
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Maria Paz Accepted Answer

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 with[url="http://www.flokzu.com"]Flokzu[/url], 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.
Comment
Yeah, but will the workflows they build themselves scale? Unless you put up guardrails around them I think maybe not.
  1. Patrick Lujan
  2. 1 year ago
^ this.
  1. Bogdan Nafornita
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 11

I interpret “low-code” as that you need to specify/touch formally
[b]only [/b]
your-application-specific artefacts.


The following techniques can help to build your own applications:

[list]
[*]
DSLs
[*]
Experimenting with published patterns (similar to cooking recipes)
[*]
Guided-coding based on your previous behaviour
[/list]


Thanks,

AS
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Tim Bryce Accepted Answer

"If it's easy enough?" If they do it for their own personal use, fine, but if they do it for corporate systems they will likely compound the data redundancy problem and make the integration of systems impossible.
References
  1. http://timbryce.com/
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 13
Peter Hilton Accepted Answer

They already do, in huge numbers, but 99 per cent of the time they call their applications ‘spreadsheets’. Now if only some of them could make process-centric applications instead of data-centric applications…
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 14
Ian Gotts Accepted Answer

The question is not can people build their own applications, but
[i][quote][b]should[/b]
[/i][/quote] 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


[url="http://jatig.files.wordpress.com/2010/11/021265-it-dept-fall-from-grace.png"]http://jatig.files.wordpress.com/2010/11/021265-it-dept-fall-from-grace.png[/url]
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 15
Bogdan Nafornita Accepted Answer

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.
Managing Founder, profluo.com
Comment
All this discussion concerning the need for app-dev is increasingly important as technology continues to infiltrate daily life.

And Bogdan your paean to the citizen developer is almost lyrical! But at the same time we rue that art is not scaleable. (I especially liked where you asked your staff to surface the business rule, rather than bury it.)

Here's a suggestion. I have often compared business process management to accounting, in terms of the development and governance of a body of knowledge and practices -- and which are both central to business.

Maybe the 'citizen developer' is not scaleable, but when you have the steep BOK demands, and risks too, the answer is professionalization and even guilds.

Every so often you see ideas around a "guild of programmers", but the domain is too wide. I rather think however that business process management technology itself could become a distinct and valuable domain of theory and practice, and separate from accounting and separate from IT generally. Volker Stiehl's vision of pure logic BPM separate from interface questions is an enabling development.

Imagine boutique BPM shops (per my comment earlier regarding BPM and trust) in long term symbiotic relationships with corporates and a cadre of BPM specialists that are "at the table". And the cognitive demands on BPM-only technology (including data models and rules, but no SOA or code) are low enough that BPM specialists can also be, as they must be, domain specialists. Just like accountants who "know both accounting and supply chain".

And for commercial software vendors, the sale is now to the very large number of smaller BPM shops, world-wide. Hey it's a whole ecosystem! : )
  1. John Morris
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 16
David Chassels Accepted Answer







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
Comment
Bogdan, "volatile and unreliable", very nice systems model of the problem. And good on the "formal motivation" question, which can be called "governance" too.

I'm reminded of the quote attributed to English writer Oscar Wilde, such that "socialism takes too many evenings".

In other words, people work all day and don't have time to administer production quotas after dinner. It's a kind of magical thinking to imagine that time is infinitely elastic. Someone always pays the price for magical thinking.
  1. John Morris
  2. 1 year ago
That's what I also meant by citizen developers lacking formal motivation: it's not their job to develop apps - at any point in time their primary job will kick in as priority.

The efforts of a citizen developer will always be like renewable energy with no permanent storage solution: volatile and unreliable.
  1. Bogdan Nafornita
  2. 1 year ago
Very good point about "it's not their job" -- regardless of how productive the software is knowledgeable staff are always 100% committed (in successful enterprises) and pulling them out of line for (either for sustaining or disruptive) development is usually difficult. Who are we selling all this great software to anyway?
  1. John Morris
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 17
  • Page :
  • 1


There are no replies made for this post yet.
However, you are not allowed to reply to this post.