1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Thursday, 21 September 2017
  5.  Subscribe via email
As Jason Bloomberg writes in this post, "such innovations (low-code/no-code) are too disruptive – so disruptive, in fact, that many different constituencies are resisting, each one sticking its thumb in the dike, hoping to hold back the ocean." What do you think?
Accepted Answer Pending Moderation
Certainly over past couple of decades way too disruptive for the powerful vested interests in the IT industry and that includes internal self interest. What we have experienced is hard to believe. Ridicule then ignored...but now the landscape is changing as we prepare for the battle to win. Read our story in attached link in context of responding to UK Government failures. But I have managed to secure the technology and linked to innovative approach to funding and distribution we will see change ...not just for us but other disruptive technologies which can bring significant benefits for humanity which have been held back by large corporate self interest.
  1. https://publications.parliament.uk/pa/cm201314/cmselect/cmpubadm/123/123vw09.htm
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
If we stick to the definition of "disruptive", then no. "Disruptive" is when newcomers displace market leaders and their value networks.

Most start-ups, once they have achieved scale, usually sell out to incumbents. Even in consumer businesses, there's very few independent holdouts.

The recipe is standard: incumbent (old money) chooses to ignore new market (new money) until proven successful --> incumbent eyes successful start-up --> incumbent uses old money to buy new money (for a premium) --> new money gets old --> back to square one.

When was the last time any real disruption happened in enterprise? I mean, look at the market darling, RPA - most players are getting gobbled up (or earmarked with exclusive partnerships...) by large, old BPM / BPO players.

Nothing wrong with that, to be clear!
CEO, Co-founder, Profluo
Ok, but no harm assessing internal impact and calling that disruptive as well.

Many fails come purely from allocating funds to initiatives that take too long, cost too much, or fail to meet objectives.

Silos, and staff in general in certain types of industries resist ANY change and some actively try to sabotage.

Facts are any change is "disruptive" and one key strategy is to implement such that it is easier for the user to get on board with the new than to try to stick to old ways.

In the area of software apps, people absolutely hate having to climb up, down, across menus.

I suppose if you are outsourcing development / programming a certain amount of $$ should be deducted from the fixed price contract for each menu item, icon, button.

Only problem is it is very difficult to make things easy.
ref: "any change is disruptive" - not really agree with the semantics (but it may be due to my English not being the mother tongue). I don't believe there's many truly unchangeable things in the world. But most of the change is incremental, evolutionary. I don't equate that to "disruptive" just because people may resist it.
@Bogdan. . . Agree that there are few things in the world that are unchangeable.

Evidence that any change is disruptive can be found in physics where great care must be made during attempts to measure to avoid changing what we are trying to measure.

As Kay points out below, disruption can have a cultural component i.e. one person may view a certain change as disruptive whereas another may not.
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
Disruptive to the legacy folks identified in the article (consultants, IT, enterprise... ) but not to the functional department end users who are now in a position to own, manage, & control their own processes and their data.

Except that end users do need help from consultants, IT and enterprise staff with rules, with data sharing in/out and let's not forget that some functional entities do not have even one person capable of "thinking process" - they know their work but for some reason are incapable of mapping it out even in user-friendly mapping environments where you don't have to take an 8-week course on how to map. (Here there is a role for a facilitator to at least get things going).

Small warning . . not easy to make changes to even a simple process where you have steps 1-2-3-4-5-6 and you need a change at step 2 that impacts step 5.

Instances before 2 have no worries, nor do instances at 6, but any instance at step 3 or step 4 can have issues on arrival at step 5 (e.g. new field added at 2, change to an algorithm at step 5 that relies on the new field, failure at 5 to handle the eventuality of null data at the new step 2 field).
  1. http://https:\\kwkeirstead.wordpress.com
A better dramatization in the 1-2-3-4-6 process is the addition of a new part at step 2, with a corresponding change in assembly at step 5 - here, it may be necessary to backtrack steps 3-4-5 and then effect a loop back to step 2.

Another possible scenario might be to leave in place the old step 5 and have a branching decision box that figures out what step this particular instance was at when the changes at step 2 and 5 were made.and route the instance through one of the old or new step 5's.
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
For *ever* it's been the case that the market opportunity for 'model-driven' tools of one stripe or another (all the way back to the first 4GLs) has been constrained partly by pushback from broader professional software development, QA and IT operations populations.

What's more interesting to me is the dominant element of business value that's pushed in each new wave of 'low-code' software tools. For a long time it was about cross-platform portability; the challenge with that proposition was that it wasn't a real problem for the vast majority of organisations.

Now, the key part of the value prop is a combination of a need for speed, and a war for talent. Orgs want to deliver fast, but they struggle to meet even yesterday's demand. This is basically where the hook into 'digital transformation' comes in.

Personally I think this value prop piece has real legs - and vendors that can successfully navigate between three things: the need to continually enable new application interaction channels / deployment models etc; the need to keep tools simple and accessible; and the need to foster a large community of skilled (enough) people who can use the tools well - stand to make a lot of money and help a lot of customers. (Of course it's the last bit that is really quite challenging).
"Of course it's the last bit that is really quite challenging". Amen!
Yes I go along with those 3 points but add the skill set already in existence with business analysts who would pick up in hours. As ever the necessary communication with legacy is the human and technical challenge?
"business value" - direct execution of the business ?
Neil nails it, as usual. There is already a large community of skilled *programmers* -- but not large enough. And the barrier to joining that community (remember, we're talking "skilled" programmers here) is relatively high. Those elements translate into scarcity, which in turn makes finding, hiring, and retaining great programmers an incredibly difficult thing to do*.

The promise of Low-Code is *not* that EVERYBODY is going to build things; the promise is that we can expand the perimeter of those who can to include subject matter experts in the areas targeted by the solutions they create.
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
The general rule is: more your “code” is close to business (or more abstract) – more gains from its automated optimisation. Thus, there is no less-code or no-code tendency, but there is a tendency for moving up-stream to business-problem modelling and execution. An organisation can be defined by its business architecture which is executable. Of course, some coding is always necessary, but its scope will be very well limited and not creative.

Ideally, processes are algorithms to execute the business.

@Alexander. Fascinating.. 'processes are algorithms to execute the business"
Why not?
They are encapsulations of knowledge, experience, know-how, protocol, with augmentation, reduction. etc. capabilities.
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
The disruptiveness of low/no code greatly depends on the user culture, and I would as go as far as stating "region". In places where BPM usage and maturity (e.g. BPMM) is generally still low, low code will have a positive effect on the level people will embrace BPM as a discipline AND technology.
Additionally, real low code offerings in the world of BPM are still rare and often limit themselves to the process-diagram-end of things, with notable exceptions such as Flokzu. So, even by technical standards, there still are innate inhibitors to be overcome, before low-code offerings will be able to carry a real punch. Ultimately, I honestly think "mass adoption" of BPM due to the lowering of technical skill based entry barriers is a bad thing, at all!
NSI Soluciones - ABPMP PTY
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
Low-Code or No-Code primarily creates a herd of "citizen developers" or "tool jockeys".

It shadows the pro-developer mode of working - by getting dirty with code, tailing through never-ending log files on a command prompt, debugging and troubleshooting itch-scratching error or exception.
There are pros & cons to the low-code / no-code adoption by an enterprise:

  • The complexity of the implementation is masked and encapsulated by the fancy looking visualization tools with drag-n-drop features, pre-built components and configuration palette made available as out-of-the-box offerings
  • Business gets a feel-good-factor, with some confidence to incorporate the change
  • One-Stack Development Platform providing ease of maintenance / single pool of likely skilled team / one touch deployment (fast & quick with improved TimeToMarket - if all the needs are fulfilled by the platform)


  • Adopting a low-code / no-code platform creates a single point of dependency on the part of enterprise to live forever with the product
  • Flexibility is less compared to bespoke ways of implementation (low-code platforms primarily demand living within the defined boundaries created by the platform)
  • At times, creating custom plugins or custom code adhering to the configurations/features/limitations provided by the platform - demand for additional effort

In summary, low-code or no-code platforms are like "Lego Building Blocks". If all the model/shapes are available to meet your business functionality - that's great. Else, additional effort needs to be considered to crafting and creating a block to fit with other building blocks in terms of design/shape/polish/color.

In a way, Low Code / No Code platforms reduces the bridge between the IT & Business stakeholder (which is also the same goal/objective BPM as a principle has been advocating & rattling for more than a decade).
So, it is not too disruptive with regards to BPM. But YES as a terminology it is catchy! And going by the buzz in the wild of disruption, it becomes important for enterprises, to innovate and differentiate addressing the C-P-Q (cost-pace-quality) factor and building solutions (faster, better & cheaper) enriching the customer experience.

Finally, whether to use or not to use a low-code/no code BPM as a launchpad for the enterprise depends on multiple factors and key ones being - vision, future architectural/functional roadmap, maintenance, cost, enterprise landscape, customer experience, customization effort (if any) etc. It's unfair to consider Low-Code / No-Code as "one-taste-suits-all" kind of an offering for Enterprises (some may like it a bit tangy and spicy - customizations are inevitable) :-)
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
I don't mind if things or disruptive or not, I mind if it adds any value. In the case of low coding you offer the process executors the possibility to create their own tools. But does (s)he really want that?

Do you think:

- A truck driver wants to build his/her own truck?
- A carpenter wants to build his/her own power drill?
- A radiologist wants to build his/her own Rontgen scan?
- A pilot wants to build his/her own plane?

Of course there might be some exceptions, but I think for most the answer is "no". They just want to do their job. And yes, they want good tools to support that. But build them self?

So do you think an office worker wants to build her/his own tools? I'm not sure. Yes, I think they want to express their needs and frustration. But that's good old development. And if you do it iterative and fast, it's agile.

And I can imagine that end users want to be able to adjust the tools to their specific needs. Could you call that low code configuration?

So, for the end users, not so sure if there is a real need to build everything their self.

But as a tool builder; why not? The easier things are, the more I like it. That's why I like any initiative that enables easier building of tools.

Think about 3d printing for physical tools. And maybe low code for software.

And if someone like to call that disruptive, I'm fine with that.
Sharing my adventures in Process World via Procesje.nl
Right: the goal isn't to give each receptionist the tools to build their own "guest sign-in" application. The goal is (or should be) to make it a LOT easier for somebody else to do it; say, somebody who knows a lot about what receptionists need to do their job, and less perhaps about the differences between BGP and OSPF. The problem with the phrase "citizen developer" is that the term "citizen" implies a certain amount of equality. But not every "citizen" needs to know how to do this stuff for the organization to enjoy the benefits.
Oops . . . This is a new twist I would never have thought of.

My concept of low/no code was the minimization of coding for process owners/executors dragging and dropping BPM tasks on an electronic canvas and linking these via directional arrows (with the occasional complex constructs such as rule sets, branching decision boxes, pre-/post - processors, loop backs with counters, etc where expert assistance is required).

Now, here, it seems we are into process executors (i.e. silo dwellers) "creating their own tools".

None of the tools our folks develop/support were built without coding (i.e. our code set has 1,500,000 lines of code).

I suppose any "citizen developer" capable of building the next generation Ferrari in his/her garage would have no problem but, otherwise, I don't think so.

If mapping out BPM processes is not the objective of low/no code, the question "Is Low-Code/No-Code BPM [by citizen developers for the purpose of building tools] Too Disruptive?" needs an answer of NO.

It has not happened, it is not happening and it will not happen.
  1. Emiel Kelly
  2. 2 years ago
  3. #4533
Scott, Karl, Thanks for noticing the twist. I did write this to create some awareness for the vague "citizen developer" term .

I've been dragging blocks and arrows all my career to create some process supporting tools. I've been label a "process loser" by the cool C## guys. I didn't care, because my friends were the people on the shop floor. "Thank you Emiel, I really like your help with building the truck that serves my need as a driver"

So to me, everything is still process. Good understanding of what is needed to support a (useful) process, close contact with the people in the process. I still love it. I build processes, not tools.

Happy processing!
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
Jason's point isn't that LC/NC is “too disruptive” to be useful—quite the opposite. His point is that it's too disruptive for its own good. BPM and its descendants and fellow travelers simply represent more of a change than technologists of my generation seem ready to accept. (And, to be fair, we've seen this type of promise come and go before, so some skepticism is certainly appropriate.)

But I say to my computer science degreed, baby-boomer colleagues: nay! Nay, I say! In our day, programming was a combination art and science, and we did it because we loved programming, not because we loved insurance, or accounts receivable, or any of the other million things programmers spend all their time thinking about. Sure, those fields present us with knotty problems to untangle, and we're all about the untangling. But if we limit our scope of inquiry to narrow business areas, our value as general-purpose knot removers will surely diminish over time.

All of which is to say: low-code/no-code frees programmers to work at (or start) software companies—firms in which they are top-line contributors, rather than bottom-line dead weight. And it frees non-software companies to hire people who are subject matter experts in the areas in which they operate.

Let the bankers work for the banks, and the programmers work for the software companies. We'll probably all be happier that way.

Happy first weekend of autumn (or spring, for my antipodal amigos)!
Scott's opinions only. Logo provided for identification purposes only.
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Max J. Pucher
Blog Writer
Accepted Answer Pending Moderation
Low-code or no-code platforms are nice tools but they are not disruptive. Some will love them and some will hate them. Some will solve a current problem and others will become a new problem. I do know that business staff who executes has no interest to create models (flow or others) no matter how easy it is because they are not employed to do so. Ontologies and business models are created by architects who are employed for this purpose only. Compliance rules are created by the compliance office(rs) who are employed to do so. IT interfaces to backend systems are created by IT staff who is employed to do so. All business staff will do is to perform the work that they are employed to do. Given the right technology and based on the previous they can do just that ... but how does that translate to an application? It doesn't! It is the application ... and therefore there is no disruption either. There is just an utterly natural evolution from old style IT glasshouses to digital customer interaction.

If you haven't figured out what technology will allow this you are simply too focused on BPM ...
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
Disruptive is long overdue in enterprise software. As Bogden pointed out it is likely will not be "permitted to happen" as threats taken out as they emerge as serious. The consequences of no low code allowed to happen will be profound not just the price of software solutions being fraction of current (10-20%) but the distribution model will change. SaaS becomes history with no lock in to allow software and data to be hosted by any infrastructure supplier. Solutions become effectively future proof with business able to implement changes as required at very low cost.

This is not about uncontrolled build. Enterprise software will always require to be transparent and link to use of existing systems. All this well within business analyst skills working direct with business knowledge workers. Sure where appropriate and anticipated workers may be able to quickly implement simple changes but they will never build an end to end process system....it's not their job never mind the chaos that would quickly emerge!

The question has been raised how could this possible happen.....it is good question when you think of the powerful interest in the industry! Operationally it will take serious investment with a global distribution model ready to implement. This will require sharing of the core code in recognition it is the use which creates sustainable revenue for a much "smaller" supply chain.....and the existing one know that hence the size of the challenge! It is only a question of time but does need spread of knowledge and this forum just a start. Interesting to see "industry analysts" joining in....many who over 10 years ago ridiculed and ignored what we had pioneered and proven! They know who they are! Maybe now is the time they work exclusively in the interests of end user customers and do real research on how such no low code actually works to deliver on those front end business process needs driven by BPM thinking. Interesting times........and I encourage believers and those with such capability "never give up".....it will happen......
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Accepted Answer Pending Moderation
Yikes! NC/LC is "too disruptive"! Gr8 question -- and the whole original article by @TheEbizWizard is worth reading.

As for disruptive, this gets to the whole Innovator's Dilemma -- Prof. Clayton Christensen's original book was built around the very question of resistance to change -- and the insight that successful change will only work in a spin-out. So disruptive is usually seen as concerning markets, but there's also the "disruption-of-internal-stable-business-and-social-relationships" question that any organizational theorist -- or CEO -- will tell you will doom a programme.

Low-code/no-code is both a challenge and an opportunity, and that challenge crosses both technology and business. In a nutshell, low-code/no-code is the best technology that we (a) must have and (b) can never have.

We must have LC/NC because new business models and business transformation demand the work automation tools that will support such work processes. And LC/NC is the the most efficient, indeed the only way, that the volume of such new business tools will get built.

But we can't have LC/NC because . . .

(a) SOFTWARE CAPABILITY AND DIFFERENTIATING BUSINESS NEEDS -- the LC/NC technology isn't good enough yet -- just as with application generators, you can get 80% of the way you want to go faster than lighting, but that last 20% is non-standard and your LC/NC technology isn't up for the job -- oh, and the first 80% of the job is the commodity space and the last 20% is where you make all your margin.

(b) OPPORTUNITY COST OF EXPERT BUSINESS LABOUR -- the business folks who own the knowledge concerning how to do the work are already working 100% -- there's no time for them to master new disciplines let alone devote sustained effort -- to think otherwise is magical thinking.

(c) SOFTWARE TECHNICAL KNOWLEDGE -- and even if your business side staff could be tapped -- permanently -- to support software development (!), the learning curve is steeper than we imagine. LC or NC or not, you still need to understand relational database, BPM and business rules engines, network latencies and performance, application design, ontologies (maybe), application maintenance, DR, security, UX etc. etc. etc. Unless you limit yourself to "situational apps" or toys.

(d) BUSINESS TACIT KNOWLEDGE / SHARED KNOWLEDGE -- part of the genius of shared software development (i.e. traditional COTS model enterprise software) is that the (admittedly high) fees one is paying for the software is compensation for shared software development costs. The cost of good software is enormous; we've all see or used home-grown software; it's rare that the experience is pleasant. It's very expensive to translate tacit knowledge into usable technology artefacts, and this expense is very much around business analysis and software design, costs not really ameliorated by LC/NC.

Let's focus on what we want, which is the technology tools to support our new business models. So, if we accept that direct software development using LC/NC by "citizen developers" is problematic, how do we satisfy our need for more software, faster and better?

My answer is "boutique", meaning "boutique software firms". Systems of Record (and Systems of Engagement, etc.) are in place for our commodity processes. But we want to differentiate, beyond commodity, in the market now. And not being software professionals, we don't want to take on the role of citizen developer. But also, we cannot trust the software development of our most critical and sensitive differentiating automation tools to huge vendors -- because it's an issue of trust. It's OK if BigCo shops the SAP analyst down the street to our competitor, because nothing they did was of any strategic significance. That's not OK however if the software developer is working on our unique dealer management system.

We are beginning to see the rise of firms that some are calling boutique software firms. If such firms use LC/NC tools, they do so as experts. And work very closely with client domain experts and business analysts. And typically such firms have stable long-term relationships of trust with their clients. Such clients are typically non-competitive.

As LC/NC software technology research and development continues, the category will no doubt be successful. And enjoyed by citizen developers of situational apps for sure. But the most important use of the technology will be by size-limited specialist consulting companies that are built around the importance of the trust model with clients. It's a case of governance meets economics meets technology.

And insofar as BPM process automation technology is the core of any work automation, BPM will likewise be the core technology and core expertise of that growing cadre of boutique automation specialist shops.
see "Beyond The Wall of Resistance (2010 by Rick Mauer, Bard Press, ISBN 978 1--885167-72-9)

John "LC NC not good enough yet"... and that is the issue no body has properly investigated and where industry analysts have failed their end user customers. There is really nothing we can't do indeed we learn from customers about issues then realized we could fix. Nothing is off the agenda and once business realise they can truly take control of the software to allow build exactly what is needed the game changes....sadly old IT feel threatened and few business managers will take on "IT" ! So who is doing real research on this cutting out the marketing BS ...?
  1. John Morris
  2. 2 years ago
  3. #4541
Thanks Walter and David. The "intersection" of technology and organizational behaviour is a crazy space. There's a world to win for those who can figure it out. : )
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Accepted Answer Pending Moderation
I started my career automating workflows using Java, then moved on to various iBPMS platforms (current count 11). Right now I am using a low-code application development platform to automate process-centric applications within our organization. So far, we have had a good amount of success.

From my experience, I can safely say that the time to market for a good low-code platform is phenomenal. As a developer, there, of course, are times when the lack of control does get frustrating, but overall the experience has been good.

One other noteworthy point that takes a while to get used to is that not every application that you build has to be long-term if you can implement something in a few days that can help you solve an issue for even a few months then that is acceptable, and that's what these low-code platforms allow you to accomplish.

As far as Citizen Developers are concerned, we have stayed away from that idea, but only because we need to define a governance strategy to make sure there are certain checks and balances.
  1. https://adeeljaved.com/2017/02/11/why-use-low-code-application-development-platforms/
  2. https://www.forbes.com/sites/jasonbloomberg/2017/08/07/this-is-how-the-options-clearing-corporation-transformed-to-a-risk-oriented-culture/#1ae8b503434c
Adeel Javed
Intelligent Automation Specialist (BPM, RPA, Rules & Integrations).
Your vision is exactly ours at Profluo, Adeel. We see such tools as incredibly instrumental for professionals, not for the general public.
That's why we don't call it low/no-code (which implies "no development thinking required"), but actually fast-code (since this is mostly about "time-to-market").
Agree low/no code it is not the right tag. We call it a 6GL.....a term that someone applied to us over a decade ago! It is long overdue move for business software....and certainly not for the general public!
May be we have to call this approach - "only code unique for the problem to be solved" ?
It's got to be simple and that's why I liked Digital Business Platform "DBP". This is intrinsically linked to Digital in Business and needs to be a comprehensive Platform. The "how"needs to be transparent and easily understood by business and time for industry analysts to do their job......?
@Alex - well, not really, because you can choose to employ unique code for a specific problem, then you see that problem emerging elsewhere and then you'd want that code (as a stable, re-usable solution) to be merged back into the trunk.
@Bogdan, sure, not immediately, but when everything is stabilised then a small refactoring will be useful. Like the letter A in the PDCA cycle (plan-do-check-adjust).
  1. more than a month ago
  2. BPM Discussions
  3. # 13
Accepted Answer Pending Moderation
It would be an error to say that low-code platforms are an exclusive prerogative of BPM systems. In a wide sense, any modern platform already is low-code. Computers do not operate on a level of programming languages. They just execute sequences of binary commands. In this sense, any programming language, even low-level one, such as assembler, already is a low-code platform, which compiles high level human readable programming code into native binary command flows of computers.

On a higher level, for at least past 20 years, all modern development environments dedicate to graphical IDE simplifying routine code writing. Nearly every modern coding platform is low-code platform. The trend is especially evident in GUI design in its most wide sense. Therefore, in vast majority of programming tasks low-code platforms are not a disruptive innovation but long established and commonly accepted mainstream.

BPM brings low-code platforms to the next level of abstraction where they operate not on technical aspects of implementation but high-level business logic. The success of this mission crucially depends on elimination of disruption introduced by the platform. Successful low-code BPM platform must ensure guaranteed compatibility of widest technology set utilized by modern enterprises and complete transparency of transition from high-level BPM view to low-level programming access. Such an adaptive platform reconciles contradictory views of versatile stakeholders in an organization.

Alas, many real BPM platforms pay too little attention to transparency and integration. This largely explains a compromised reputation of BPM as of disruptive technology. If low-code platform is too disruptive, it just indicates low quality of the platform in question and in no way generalizes to typical and universal case.
  1. more than a month ago
  2. BPM Discussions
  3. # 14
Accepted Answer Pending Moderation
Boris ....A few points of disagreement...first BPM is the discipline in thinking what is required supporting people at work and the no low code platforms needs to handle ALL requirements without any coding sure maybe need for algorithms for special data manipulation but not a Coding platform! As for high level BPM the supporting platforms must address the low level business logic that is the key to removal of coding! Whilst agree transparency and integration v important which adds to the disruptive nature of the BPM supporting software.....disruption is not within the business (other than the IT dept) it is in the existing supply industry ...big time!
  1. more than a month ago
  2. BPM Discussions
  3. # 15
Accepted Answer Pending Moderation

Looks like we have going here two rather different interpretations of "low-code".

My understanding in the context of BPM is "low-code" means "less coding", the closer to "no-code" the better, providing this does not hobble functionality. For sure, programming of rule sets, algorithms and data exchange coding is needed and this cannot typically be done by "end-users".

Our platforms accommodate workflow within cases and workload across cases.

BPM processes sit in the background of each case - the only evidence of their presence at a case for most users is that 'to-do' tasks pop up in their in-trays.

Supervisors, on the other hand, have a horizon that extends from tasks that are current to pending tasks.

Except that supervisors are unable, contrasted to a Critical Path planner, to view the future forward to closure of any Case (other than one that features an end-to-end process) for two (2) simple reasons:

a) forward tasks typically don't have assigned durations in most business processes,
b) supervisors cannot anticipate what ad hoc steps (processes of one step each) may be loaded into the case.

Even if supervisors had a crystal ball re durations and insertions, except for cases where performing resources work on one and only one case at a time, the "S" curves that result from suspending/ resuming work as these resources move from one case to another (or effect handoffs to others) can rival or exceed the sum of task durations along a process template.

I spend a lot of time asking folks why they write code instead of writing code that generates code.
  1. https://kwkeirstead.wordpress.com/
  1. more than a month ago
  2. BPM Discussions
  3. # 16
Accepted Answer Pending Moderation
Karl raised valid points all covered in our original R&D see link to research paper I was asked to write some years ago clues as to philosophy we adopted!
In summary includes in one platform
• Process engine - to ensure all works to plan.
• Rules engine - reflecting real world of compliance.
• Calculation engine - automating system work.
• State engine - Real time feed back from any point.
• Workflow - everything connected in right order.
• Audit trail, events, escalations - = control with empowerment.
• Rapid prototyping - user involvement in build no need for a final spec
• Time recording - supports activity based costing.
• Real time reporting - becomes predictive.
• Build mash ups - one screen multiple data sources.
• Linked intelligent Ajax grids - enter data only once.
• Roles and performers - people and machines recognised.
• Management hierarchy - see who does what and when to reallocate work
• MDM Orchestrating legacy with business processes as required in single environment a - 21st century approach to recognise the past
• Call Web Services - wrapped up in a process.
• User interface dynamically created linking people, roles, task type and data via forms for specific instances.- supports adaptive capability
• Content handler and in memory work capability - to ensure high performance.
• Pre-built templates for custom documents, letters, e-mails, messages etc dynamically populated with instance specific data and edit capability in browser - recognition of external communications documents etc
• Process and task versioning control – ensures minimal disruption, if any, to implementation of changes

Build takes place in Graphical Process Designer/Build configuring the tasks and links as required. At a click this is declared through to the Relational Database pre configured with data structure and ready to run. No code generation which enables quick change. Such build V quick and skills well within Business analyst knowledge working direct with business users. Any specialised coding such as algorithms can be incorporated.

We have had to learn how to articulate as we were and still are different but good to see others now "following" ....and like us seeing BPM as the driver in thinking what is needed without constraints. Also the "Digital" move putting people first has highlighted such need so maybe our time has arrived!!!
  1. https://www.igi-global.com/chapter/object-model-development-engineering/78620
  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.