BPM.com
  1. Peter Schooff
  2. BPM Discussions
  3. Tuesday, 09 January 2018
  4.  Subscribe via email
Lately I've come across a few articles stating the importance of low-code/no-code development to a company's digital transformation. What do you think?
Max Young Accepted Answer Pending Moderation
Blog Writer
NoCode is the next evolutionary step, and not having it is a non-starter. The challenge is, how do create NoCode solutions that *link forward* to the next generation on complexity that our customers require, and don't box them into a vendor or capacity solution?

That, in my opinion, is the heart of the matter.
References
  1. http://www.capbpm.com
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 1
John Reynolds Accepted Answer Pending Moderation
I agree with Max.
Without truly effective environments that allow business leaders and SMEs to rapidly implement rules and process changes "on the fly" - "as soon as needed" there's no lasting transformation.
Founder at John Reynolds' Venture LLC - Creator of ¿?Trules™ for drama free decisions
Comment
Sure. You aren't going to get there with C++ though.
  1. E Scott Menter
  2. 9 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 2
David Chassels Accepted Answer Pending Moderation
Delivery of digital services requires the UI to be intrinsically linked to back office support in a dynamic way to ensure all data correctly collected and processed to deliver on the required outcomes. This includes delivering new data to the relevant UIs for other users. This requires custom build and this is where no code capability is vital for that Adaptive delivery where the UIs are dynamically created for the authorised users with the right data ready for use. The key requirement for Adaptive is the ability to readily implement change; an inevitable requirement at the sharp end of business.

With no code will come transparency as to how the digital service works and understandable by all users. This significantly speeds up build working direct with users and gives confidence that change can be readily supported. This where the BPM discipline will play important role understanding requirements. Nothing should be off the agenda as new ideas emerge and users can become empowered with real-time feed back. Full audit trails who did what when ensure accountability for all.

The challenge which we have experienced has been and still is disbelief and huge vested interests in the existing vendor supply chain which has thrived on complexity resulting in the legacy mess. This mess cannot be ignored so important the no code Digital Business Platform can orchestrate its use and data extraction as required. Do not even think of trying to use existing legacy UIs!

This is going to be a significant change to enterprise software with consequences for many in the supply chain but at last the customer will be the real winner; a true signal of enterprise software at the start of commoditization and maturity.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Kay Winkler Accepted Answer Pending Moderation
Happy new year to all!
I truly believe it is important and yes, it has to be done right. And also, no, its not the magic bullet to achieve everything the easy way.
With being done right, I specifically refer to the possibility of accomplishing the whole implementation cycle of putting an improved and automated business process into production, being able to measure and improve upon it. Of course, being aware that a low/no code approach will naturally limiting the user to rather simple processes - which on the other hand make up a large portion of a companies process universe.
"Low coding" only on a flowcharting and simulation level, in my opinion, doesn't manage to shorten the way towards the magical land of Oz and its wonders of digital transformation it beholds :)
NSI Soluciones - ABPMP PTY
Comment
Kay Just to let you know with the right DBP complex process are readily built and maybe that land of Oz is closer than you think.....!
  1. David Chassels
  2. 9 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Dr Alexander Samarin Accepted Answer Pending Moderation
I remember an informal definition of a good programming language - "simple things are simple, difficult things are possible". Thus in your digital business toolkit / platform simple things should be doable without coding and such a platform must simplify coding as well (dreaming about robots and microservices).

Thanks,
AS
Comment
well said
  1. Scott Francis
  2. 9 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Rachel Accepted Answer Pending Moderation
Low Code and No Code are going to be fundamental to the digital business transformation... but I am having a feeling of deja vu.

There isn't going to be a single magic bullet to solve every problem this time around either. Business Analysts and their IT friends will have to look at the complexity of what they are tackling before picking a solution... this all sounds so familiar. :D

Just like the BPM tech market did, the low code market will start to segment out as adoption increases. No code vs Low code certainly appears to be a good starting place. I think no code solutions will be used for the tactical things that just need to get done (that IT doesn't always have time to get to), and the more robust low code platforms will be used to implement, maintain, and change the more sophisticated processes at the core of the digital business transformation.
Comment
>There isn't going to be a single magic bullet to solve every problem this time around either.

100% agree. But it's not the bullet. It's never the bullet. It's the marksmanship. The idea that we can make adjustments for our environment and still get something effective going is the key.

I think that NoCode is taking a shot at the target. If we're fast enough and light weight enough, we get to take a lot of shots at the target. The more shots we take, the higher the chances that we'll something, *and*, we'll definitely improve our marksmanship.
  1. Max Young
  2. 9 months ago
except that there are some problems that can't be addressed meaningfully with no-code solutions (why you likely pointed out you need a progression to solve more complex problems). no amount of marksmanship will turn a pistol into a tank (nor vice versa).
Also: sharepoint. :)
  1. Scott Francis
  2. 9 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Scott Francis Accepted Answer Pending Moderation
Blog Writer
I think we're putting cart before the horse. Are low-code and no-code important? Well, speed and agility are important, and they're not the same thing. They're important because we are taking as an assumption that the world is changing, and our businesses are changing. Therefore we need to quickly roll new solutions, and adapt the ones we have, to those changes.

Speed + Agility means that our learning cycles are shorter, or potentially shorter, and that our pivot points are increased in terms of how often we can react to what we learn.

If you think Low-code or no-code solutions improve speed and agility, then you probably want them. FYI, Sharepoint and Lotus Notes were low-code solutions. So was Hypercard (no-code?). Let's try to keep it in perspective.
Comment
Not sure I agree that SharePoint was ever a "low-code" technology (at least as far as workflow goes), but sure: I'd agree you want speed, agility, and, you know, actually useful functionality.
  1. E Scott Menter
  2. 9 months ago
@patrick - I'm afraid to ask how many workflow systems you've seen on Lotus Notes :) A number less than infinity...
@scott - sharepoint was a no-code solution to content management more than workflow. My point is that no- or low-code solutions to lots of things sound interesting and then don't work out. And then they work great with other things. Medium and Wordpress both work great - one of which is no-code and the other is, arguably, low-code (but you can code like crazy if you want to). I just use these as analogies so we don't forget that no-code isn't automatically good or bad just by being no-code. And a bad no-code solution doesn't improve your speed. And some no-code solutions are fine for prototyping but 2-3 years down the road it is hard to make changes (no software development lifecycle, dependency analysis, etc.) so you lose agility.
  1. Scott Francis
  2. 9 months ago
@Scott Francis: amen!
(You brought shivers down my spine thinking about all those workflows I had built on Lotus Domino while working for P&G. Low-code your work life into a Lotus Notes twistie hell!)
  1. Bogdan Nafornita
  2. 9 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Karl Walter Keirstead Accepted Answer Pending Moderation
How about we get on the same page here . . . .

No-code or low-code development for what?

1. Does this mean vendor development of a process mapping environment?
2. Does it relate to end users in functional departments using the mapping environment to build workflow steps/data collection forms/ rule sets?
3. Does it relate to vendor development of a compiler to carve up mapped processes/process fragments for role-based performance at the RT platform?
4. Does it relate to vendor development of a run-time workflow/workload management platform capable of hosting instances of plan-side process/process fragments
5. Does it relate to BA/IT development of interfaces to/from run-time workflow/workload management platforms?
References
  1. http://www.kwkeirstead.wordpress.com
Comment
I suppose I need to add user-interface development?

Our folks have a new app where run-time end users only see
+Crime Scene
+Victim(s)
+Suspect(s)
+Witnesses
+Investigative Protocols (200 workflows, 300 forms)
+Messaging (breaking news, questions/responses to questions)

Before rolling out this new product, I would have said one screen with tasks on the left and a calendar on the right would suffice for b2b. This app is not b2b..

The problem here is we have highly skilled resources using, in some situations, pen/paper "investigator notebooks" for 40 years and we are trying to drag them kicking and screaming into the future.
  1. Karl Walter Keirstead
  2. 9 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 8
E Scott Menter Accepted Answer Pending Moderation
Blog Writer
Let's turn the question on its head: when is low/no code NOT the right solution? We've got plenty of experience in that department, as we've all been relying on either packaged or hand-coded software for decades.

And where has that gotten us? Virtually every medium-to-large enterprise contains within it another medium-to-large enterprise whose mission appears to be generating mountains of code that rapidly become catacombs. When packaged applications are desired, the edematous software procurement organization lumbers in to ensure the process is as slow, expensive, and contentious as possible. In neither case is the enterprise left with software that can easily be enhanced by SMEs, again and again, in response to changing market and regulatory conditions. One might begin to suspect that digital transformation is substantially driven by these very challenges.

Not every problem is solvable with a single tool—if it were otherwise, what would we all spend our time on this Forum discussing? But our experience with both writing our own code, and buying software off the shelf, has shown those options to be expensive, inflexible, and unresponsive. Low/no code addresses these pain points while providing the integration, analytics, and mobility that are critical to effective digital business applications.
http://www.bplogix.com/images/icon-x-medium.png
-Scott
Comment
And lots of orgs have piles of lotus notes applications going stale as well. low code! no-code! :)
and when a no-code vendor upgrades their platform and abandons your solution - boom. you have no real recourse. I'm not saying you're going to do that or the other guy is going to do that, but it can happen. And it has happened to people before. none of my thoughts are an indictment of a specific tool, just pointing out :

at the end of the day - speed and agility. if you think low code or no-code gets you that short-and-long-term then great. if you don't, great. but also, different tools within each will give you different mileage on those fronts. e.g. i'm using that awesome no-code platform and hey, what's this - no APIs? how do i extend it or integrate it to system xyz? none of these things live in a vacuum. now i have to pull in some RPA to integrate my low-code systems to each other. ugh :)
  1. Scott Francis
  2. 9 months ago
No workflow/workload management platform hosting background BPM should hold customers hostage via whatever user interface or user interface builder they include in their platform.

A standalone generic data exchanger (GDE) solves the problem of linking to/from APIs i.e. the platform outputs to the GDE, the platform imports from the GDE, each trading partner needs to be able to export its data to and import data from local and remote systems and apps to/from the GDE.

The key contribution of the GDE is that it allows each subscriber to the GDE to read/write using their own data element naming conventions and if the protocol at the GDE is push for export and pull for import, "standard" data envelopes for data transport are not needed.

Registration at the GDE solves "need-to-know" - if I publish "abc" and you want to read this as "def", fine.

If you don't tell me the name you want to use for "abc" the reader at the data exchanger skips over "abc" and you have no access.

Pull-import solves the problem of the timeliness of data - the exporter can easily export in real time and the importer effecting pull-import can read at whatever frequency they like. Each importer will reasonably expect the DGE to maintain a last-read pointer.

The problem is many buyers of platforms lack the ability to properly evaluate platforms so they get on the vendor’s slippery slope and have to stay there.
  1. Karl Walter Keirstead
  2. 9 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 9
David Chassels Accepted Answer Pending Moderation
Karl. Here is my response to your questions
1 fact easy to draw a map of processes I was doing it in the 70s with great results! Today that map now can be the no code build environment which then declares throughout to pre built database where application created automatically.
2 relates direct with users any where with workflow inbuilt with rules and forms as required
3 vendor just supplies this "tool" up to customer how used and has complete control. Very suited for Business Analyst skills set working direct with users and thinking BPM. Roles allocation built in to architecture and no compiling in build
4 vendor supplies the tool the business builds the workflow and work load management in allocated task types ...some human some machine and required orchestration.
5 the UIs created in the vendor tool allowing for customer to design as required. The data feed by the vendor in built process engine utilising all workflow and outputs from workloads.

Nothing off the agenda for business in this no code build environment this puts emphasis on the detailed business process requirements with direct input from users. Managers have real-time overview of activity to take any action such as to reallocate tasks if required.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Scott Francis Accepted Answer Pending Moderation
Blog Writer
Can we get a throw down at bpm next between jakob (camunda) and scott menter (or someone at bplogix) ? : ) could be fun! :)
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Bogdan Nafornita Accepted Answer Pending Moderation
I would like to draw a parallel between software solutions and machine learning (bet you never saw that coming LOL) in terms of fitness for purpose (i.e. solving a variety of business problems, both existing and emerging):

Complete custom / bespoke software - this is an overfitting ML algorithm - you code for the task at hand and whenever you need to change something you need to re-code a lot of it.
Standard, COTS, software - this is an underfitting ML algorithm - you take a highly generalized model that doesn't learn anymore from fresh data (or its learning cadence is way to slow for your needs, think product releases) and try to fit your business reality back into it, or spend a lot to get it to work for your business problems.
Low-code / no-code / RPA - this is again an overfitting ML algorithm - you custom-design a power tool for each of the individual business problems that you have. Whenever the business problems change, you have to re-design the corresponding tools. It's faster to build, faster to deploy, but slower to debug (except for RPA, which has a rather fixed problem domain, so bugs are less frequent).

Hybrid solution - fast code (reuseable, model-driven architecture, with custom coding environment) - this is the optimal balance between standardizing / productizing on previous knowledge and developing new, re-useable artifacts to solve new, emerging business problems. In terms of ML, it trains decently but generalizes excellently.
It is slower than Low-code / no-code for existing problems, but much faster to integrate new knowledge, because it is architected to ingest new business models. So it also matches the great definition of Alex: "simple things are simple, difficult things are possible"
CEO, Co-founder, profluo.com
Comment
May be to add DSL to your hybrid solution architecture.
  1. Dr Alexander Samarin
  2. 9 months ago
yes, i called everything re-useable artifacts (could be horizontal process fragments or vertical DSL)
  1. Bogdan Nafornita
  2. 9 months ago
BPM process tech, especially with "horizontal process fragments", is an example, yes? Hybrid "fast-code" ("it trains, it generalizes!) is fast in part because the concepts of the work of business are first class citizens of the technology.
  1. John Morris
  2. 9 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 12
David Chassels Accepted Answer Pending Moderation
Bogdan raises good point about speed of build. This is where no code changes the game of cost. A custom build with no code including the UIs with correct data layout is estimated at the number of UIs equals the number of man days to build ready for first run. There is so need for a detailed spec as change easy handled A broad outline of the process being addressed with direct contact with users with detailed knowledge gets things moving quickly, this saves a lot of wasted time drawing up detailed spec. This also minimises risk to the business customer in being an other "IT" failure where within days it will be clear if vendor claims are deliverable! To give idea of scale of savings comparing perhaps the most inefficient environment Government where a project to distribute grants cost over £300m using custom coding where as similar exercise using this no code total cost just over £1m over 15+ years including constant change. That's what "disruptive" is...!

Is this no code approach the "silver bullet" that has been the dream or as Bill Gates described as the holy grail of software for so long? Well the bullet maybe ready but firing needs a gun which is context is money and a workable plan to for globalisation. Failure allowing this technology to be "buried" by vested interests is not an option........
Comment
A partial quick check to determine within one 1/2 hour rather than days whether "vendor claims are deliverable" is for the customer to book a session with the vendor and instead of having the vendor drone on powerpoint style, ask the vendor to give the mouse/keyboard to the customer

If the latter cannot, with minor coaching, get a small yet representative workflow mapped, compiled and processing data at the platform, the wise thing for the customer might be to move on.
  1. Karl Walter Keirstead
  2. 9 months ago
"Holy grail" of software? Architecture, of course.
  1. Dr Alexander Samarin
  2. 9 months ago
Karl Agree!
Alexander Gates talk here http://www.infoworld.com/d/developer-world/gates-talks-declarative-modeling-language-effort-386 Bill Gates saw it in 2008 when he announced plans to build a declarative modelling capability reducing the need to code calling it the “holy grail of development forever”, “the dream the quest…. but would be in a time frame of 5 to 8 years.” Yes architecture key but the outcome the driver....anyone know if Microsoft made it....or just more vendor hype...?
  1. David Chassels
  2. 9 months ago
David, "declarative modelling" is also coding in a more powerful or specialised language which is machine-readable and machine-executable. I used such languages and wouldn't rewrite all my code in "declarative" way. Maybe only some parts - horses for courses!
  1. Dr Alexander Samarin
  2. 9 months ago
Alexander Interesting as we use declarative technique from model to pre coded set of generic tasks covering all business logic but not using a code language to configure in the model. Yes I suppose machine execution to build as all automatic.... opps maybe Robot in software context?... Not really sure what we should call it but it delivers!
  1. David Chassels
  2. 9 months ago
David, is a typical flow-chart descriptive or prescriptive ?
  1. Dr Alexander Samarin
  2. 9 months ago
More descriptive using the prescribed as pre coded tasks and links covering as all business requirements. Just configure tasks and links as required. All very simple reflecting business is simple...but can handle the complex.
  1. David Chassels
  2. 9 months ago
More prescriptive because it defines a sequence of execution and creates placeholders for some code. Let us agree on our concepts, first!
  1. Dr Alexander Samarin
  2. 9 months ago
It shows the sequence of execution as required. Not sure what what "creates placeholders for some code" means?
  1. David Chassels
  2. 9 months ago
Alexander
Boris gives interesting summary of "code" We have core programming code covering business logic which never changes. In the Graphical interface each task type opens up to allow operational information to be set up who info required etc. calculation task as non human can be as simple as spreadsheet type calculations readily handled by BA skills or complex algorithms where programmers instructed on requirements.


  1. David Chassels
  2. 9 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 13
John Morris Accepted Answer Pending Moderation
Amazing we can have yet another discussion about no-code/low-code and still uncover terrific new insights! Because they are real.

When I hear the word "code" though, "I reach for my revolver". What is this business of code? Who is coding or not coding? And why?

We keep saying there's no free lunch, but the reality of coding as the stack gets built out is that the technology is very complex. A good technology is not had just for the asking. And any technology stack is so much more than code, even if it all starts there. So the savings on "coding" only account for part of overall technology costs. And importantly, the interface between business intentions for transformative software and technologists who can implement is as much of a gap as ever.

So, as the inevitable evolution of software technology to ever more powerful, low-code and no-code products is terrific. But only in the same way that COBOL and FORTRAN were terrific advances on Assembler. Saying low-code/no-code is essential to business transformation is the same thing as saying software is essential to business transformation.

In other words, it's not saying much. Unless . . . one notes two differences with hyper-productive software manufacturing technologies. I say manufacturing because that's the important part. RAD, 4GL's, declarative tools, frameworks, low-code, BPM, even COBOL, are all software technology artefacts which assist in the manufacturing of other useful technology artefacts. The fetishization of the fact that all these things are based on code obscures the difference between software manufacturing software and production business software.

Here are the two distinguishing features of new hyper-productive software manufacturing technology.

First, newer software manufacturing technology presents -- for the first time really -- business concepts as first-class citizens of the technology. BPM is the best example of this, where work and process and artefact manufacturing are all first-class citizens of the technology. Of course business concepts have been instantiated in technology before, as in ERP. But ERP, although minimally customizable, is not "software manufacturing software". It just "is".

The second difference is the expanded role for business analysts, who can be expected to directly use hyper-productive software manufacturing software. And not some of the time or exceptionally. But as a major component of their job descriptions and roles. And such work will not be limited to situational applications, but will be part of core business transformation software. (Such work would be performed along side IT software and architectural specialists on one hand, and business leadership on the other.) The business analyst, like the accountant, is a specialist in deep, even formal, understanding of both general and specific domains. By definition, the job of the business analyst is to build and maintain the technology of enterprise in support of the mission of the enterprise.

This process of moving software construction out of IT to business analyst cadres has not really happened yet. Low-code and no-code makes it possible. It is a viable model for future enterprise, for business analyst careers -- and for the technology vendors which can orient their evangelism in this new direction. As for digital transformation, low-code/no-code is just the software of the future. It's the only way forward.
Comment
RE "hyper-productive software manufacturing software" - this reminds me a role "locksmith-toolmaker" who made new tools for other locksmiths. But, the need for new tools was based on some engineering work done up-stream.
  1. Dr Alexander Samarin
  2. 9 months ago
+1 @Alexander the analogy with lock technology and the lock value chain, from metallurgy and lock engineering design, through locksmith toolmaking, through lock-making itself, through actual use of locks.
  1. John Morris
  2. 9 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 14
Boris Zinchenko Accepted Answer Pending Moderation
BPM solutions are commonly associated with low-code / no-code approach in IT management. But what exactly means the word "code" in this widely spread acronym? Programming code used by software engineers is just a technical language utilized to express business logic in a form understandable for IT systems. It is more relevant to speak not about a single language but about a large family of languages with different levels of abstraction or detalization.

As any language, technical language is expected to be clear and laconic in its target domain to allow technical experts write their software logic in a clear and concise way. Is programming language low-code solution for a programmer? It definitely is because it allows writing complex system logic using minimal amount of code. Is the same language low-code solution for a manager? Definitely not because manager looks at the same IT system from the different, higher level.

Therefore, the notion of low-code is not universal but entirely depends from the audience. Low-code solution is such solution, which delivers minimally necessary and sufficient level of details to specific problem. It also explains objective abundance of programming languages. One best language for all situations does not exist because every language best satisfies low-code requirements only for its target domain.

High code systems appear when low level technical code penetrates and impacts higher level business logic. It happens for various reasons but in most cases it is associated with poor decisions on enterprise architecture or inefficient IT management.
BPM as such does not have any relation to amount of code behind business systems. Rather, BPM approach allows to harmonize enterprise architecture in such a way that business processes on each level optimally exist and run in their respective low code environments. Importantly, the nature of this low-code niche is entirely different for each process. However, put together, all these dedicated low-code environments assure drastic decrease of the total code in the enterprise ecosystem by delivery of relevant level of abstraction for each business task.

BPM implies a union of optimal low-code solutions to ensure simple, transparent and manageable enterprise architecture.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 15
Adeel Javed Accepted Answer Pending Moderation
Low-code platforms are extremely useful, they provide the much-needed speed and agility.
 
I like examples, so attaching a link to my whitepaper that provides details about how our team is using a low-code platform to automate simple-medium complexity processes in a single day, we aptly named this initiative "Build An App Day" :).
References
  1. https://www.appian.com/blog/low-code-build-app-in-a-day/
--
Adeel Javed
Intelligent Automation Specialist (BPM, RPA, Rules & Integrations).
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 16
  • Page :
  • 1


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