1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Thursday, 19 October 2017
  5.  Subscribe via email
One question I haven't seen discussed all that much is, what would you say companies are giving up when they go to a low-code/no-code BPM solution?
Accepted Answer Pending Moderation
Reliance on IT for their operational software!
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
Customizations. Although that's actually good for them.
So wrong quite the opposite very easy to customize and supports easy change being truly adaptive
I made a mental shortcut here. What I meant as a customization is a need to deliver a custom code (e.g. Java, .NET). Being able to adjust business applications to specific business processes is of course beneficial and desired.
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
Perhaps nothing it all. It may be more economical or practical to implement something manually. Not everything has to be implemented by computer (yes, I know it sounds blasphemous but it is true). There are still a ton of manually implemented business processes out there.
  1. http://www.phmainstreet.com/mba/mbass.htm
Yes agree but reason for so many non digitised processes is that gap between people and the silo inside out inflexible legacy systems......with resultant chaos and expense....now easy with no code bringing both empowerment and accountability.
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Brian Reale
Blog Writer
Accepted Answer Pending Moderation
You can either go get your dress shirts from a custom tailor and get an amazingly perfect and beautiful fit. Or you can shop at the GAP and get a standard shirt with standard sizing. Obviously, the standard shirt with standard sizing is fine for most of the world and that's why so many people where GAP clothing -:) , but if you want true excellence then the low code - standard BPM approach often falls a little short.

I dive deeper on these topics in my blog article BPM Software Model is Broken5 Reasons why the BPM Software Model is Broken.
It's broken because analyst fail in their duty to business to research and report on how new no code actually works. Seems you do not quite get it....it opens the big door to put BPM as the driver....DO RESEARCH.
The majority of applications in any environment are packaged, third-party applications. That's pretty obviously not a "customer tailoring" job.
I'd argue that internally coded solutions are just as much a black box as a piece of packaged software. If you doubt that, ask a few large companies what it would take to make some modifications to the way their sales comp, GRC review, or return/refund processes operate.
In fact, the only thing that really does NOT qualify as a black box is an application developed and executed using a low-code/no-code platform. The rules are transparent and easy to change (if you have the right privileges). The configuration isn't trivial, but it's straightforward enough that non-programmers are making critical design and implementation changes every day. And, of course, governance and auditability are baked in.
@Scott +1
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
The question of low-code/no-code BPM is an important question - but a tricky one too.

All companies need BPM software technology -- because BPM is the software for automating the work of business (see article Revolutionary BPM ). And that automation power is all about BPM being built around concepts of the work of business being "first-class citizens" of that software. Specifically "work", "repetition" and "process artefact manufacturing" are the key concepts on which BPM software automation products are built. With BPM software, you don't have to build these capabilities yourself -- in code -- they are native, first-class, to the software.

So, what's low-code where BPM software is concerned? What would we be giving up? BPM software by definition is about empowering (especially) business analysts to manufacture and evolve process automation artefacts faster. If you need code to build process automation artefacts, then your concepts of work are not first-class citizens of your BPM product. So, the short answer is (as stated in other answers above): "nothing". If you have to give up something, then your BPM software is not very powerful as-BPM software.

But of course this isn't a complete answer, because fully automated software construction is a long way off. For example we still need code for integration and all sorts of little enhancements. And there's the affordability issue too -- the most powerful BPM software platforms are also not usually affordable by SMB. There's another tricky aspect of this question too -- specifically that non-specialist readers might only read "no code/low code" and ignore the BPM part. NC/LC by itself means "no native BPM concepts". Not a happy path to digitalization. BPM is the original no-code, by definition, and the happiest path to digitalization.
  1. John Morris
  2. 2 years ago
  3. #4626
TWEET: #BPM #process automation software: original #nocode #lowcode #happypath to #digitalization - http://bit.ly/2x9a6Ed - @BPMdotcom @PSchooff
RE " the happiest path to digitalization" but not magical one.....
  1. John Morris
  2. 2 years ago
  3. #4650
+2 @Alexander not "magical"! (as in "magical thinking" ...)
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
It really depends on the level of low to no code one engages in, when working with different platforms that go in that direction. Many modern vendors (e.g. K2, Bizagi, Bizflow etc.) have a low code entry, without giving up the traditional, coding prone venue of creating process solutions. IBM for instance has its Blueworks Live which can help folks to start designing and partially automating business processes without any code. From there, the user either stays at a low code/basic feature level or "drills down", porting the solution over to the traditional portion of a BPMS architecture.
On the other hand, you have low code pure players, where you can cover the entire process life cycle (design, automation, measuring, improving and so on) within the confines of a low code platform. There aren't too many players in that niche yet. Flokzu, in my opinion, stands out here. Naturally, for this option, intuitive, no code usage comes at the cost of tailor made features and functionalities. However, most organizations nowadays will end up with several BPMS platforms in production, at any rate. Being aware and strategic about the different strengths and weaknesses each option brings to the table, it should be perfectly possible to steer away from the trade-offs both ends of the spectrum (code intensive vs. no code) would entail.
Understanding BPM as discipline and assuring uniformity on a process asset level, notation and other standards is key, though.
NSI Soluciones - ABPMP PTY
@Kay with the right architecture nothing is off the agenda; words from early adopter! Using a true Platform no need to have several BPMS platforms? One of the criteria to be designated a Platform should supports all the operational process areas in the business crossing the legacy silos.
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
They are giving up their business agility, in the long term.
A pure low-code / no-code stack gives little consideration to business architecture (customization / personalization / integration / security --> the unique mix of factors that gives that business a competitive edge).
And the key to change is architecture. Without proper business architecture, change becomes expensive, slow - and the business agility is lost.
CEO, Co-founder, Profluo
Geebus, somebody who actually understands how this works under the hood and doesn't, hasn't drank the Kool-Aid nor purveys any. Did YOU do your research? ;)
Agree about architecture as this is the key to be able to deliver any business requirement. Our research and years of prototyping working with some early adopters cracked it by understanding the basics of how business a actually works ...and there are only some 13 generic task types that cover all to make true business architecture. They just need configured no coding required to build direct from business user input. As a result very quick and very cheap with in built agility making a future proof investment.
Sure, but the prioritization has to be a) ways and means of evolving strategy, then b) operations effectiveness (workflow and workload), then c) BPM.

Competitive edge starts with approaches like Resource-Based-View (RBV), it then requires top down and bottom up ROI/SROI requests that lead to the setup of Cases (i.e how does this particular initiative contribute to competitive edge) and here, we get to the core operational piece which is the workflow/workload platform that is capable of hosting background BPM.

Rule #1 - don't pick a platform that is unable to support workload management and workflow management
Rule #2 - don't pick a BPM "solution" that needs more than one click to compile your plan-side process maps to generate run-time process templates that can be used in/at the platform.
"the key to change is architecture" - sure and the whole IT department.
It's the architecture of the Digital Business Platform that really matters. Think communication with legacy not integration. Yes IT needed to help with links API's etc but all driven by the need of the process. This new adaptive environment only needs support from "IT" for such linking and of course secure delivery. Yes may need v clever programmers for algorithms etc but the business logic all in hands of business not IT; enabled by good architecture that incorporates all business needs.
Um, what? Yeah no. What's more "flexible": 2MM lines of dense code written by some guy who decamped last year to your competitor, or a set of transparent configuration changes that can be adjusted by pretty much anybody who knows your business and how to point a mouse?
@E Scott - As said below, you are equating my stand to another absurd statement - "2M lines of dense legacy code"... Um, what? Yeah no.
Speaking of "transparent" configuration changes... good luck in searching for the wrongly ticked box through the myriad property panels when things go south...
@Bogdan, wonderful opinion and formulation. Closest to my vision among comments on this thread.
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
I think the question should be formulated slightly different “What must Companies give up to use the full potentials of a low-code/no-code BPM?” The short answer is “their classic IT”. With BPM done correctly, practically all IT functions must be transformed: governance, PMO, enterprise architecture, business partnerships, solution architecture, business analysis, development, support and maintenance.

Welcome to the new world!

Just a question for curiosity Doc, how often have you actually seen that? Me? Once.
A few times (not 100%), however in each case I explained this in advance to local decision-taken people.
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
Wow, it was really educational for me to read these, because until now, I had no idea how little the BPM industry believed in their own product.


This question exposed the gap separating the toolbox folks from the platform folks. If you're seriously preaching that you give up flexibility when you give up code, I take that to mean that you're just selling DLLs. And hey, there's an argument to be made for code libraries, particularly for large companies that are already paying zillions of expensive, hard-to-find, hard-to-retain programmers, and can't imagine doing things any other way.

A low-code/no-code platform offers substantial flexibility where it matters most: time to value. Deploy early, fail fast, release often is the strategy that's brought us new digital leaders in nearly any market segment you can name. And that is what flexibility really means. It means being responsive to your customers' soaring (and fickle) expectations. It means easily configuring A/B tests to determine what works best for your customers, employees, and suppliers. It means not waking up one morning to find your company left in the dust by a more agile, digital competitor.

Not every problem can, or should, be solved with programming. And of course the same is true for low-code/no-code development as well. But in evaluating the trade-offs, make sure you understand what flexibility really means, and where it can be found.
Scott's opinions only. Logo provided for identification purposes only.
  1. John Morris
  2. 2 years ago
  3. #4636
@Scott -- Hey, I believe in BPM! But it's interesting how a seemingly obscure question becomes the tell-tale Rorschach blot on attitudes to a software category. You put the problem well in terms of "selling DLLs" -- which is a kind of hostage taking. My own focus is "empowering business analysts" who can then think and work in company- and industry-relevant abstractions. That's BPM. Code doesn't get you there.
And, by the way, concerning "agile", it's very easy to get distracted about agile. I have written a bit about the economics of agile -- BPM exists and companies exist because we don't want to be agile all the time. There's a world to win for software that enables you to automate the work of your business, and that software is BPM automation software.
"If you're seriously preaching that you give up flexibility when you give up code, I take that to mean that you're just selling DLLs." I know it is part of your usual discourse to belittle ideas different than yours by juxtaposing them with absurd concepts (selling DLLs? really?), but frankly I think the audience here is better than that.
In their current incarnations, most of the low-code/no-code platforms offer substantial flexibility where it matters _least_ for the overall enterprise: power/team hacks. It can make individuals or teams more flexible and more responsive to customers, but that does not equate to on-going business agility. Constantly responding to the customer's daily fickle fads means you may be hunting for local maxima - with the risk of you departing from a proper strategy and a truly flexible business model in the long term.
  1. John Morris
  2. 2 years ago
  3. #4639
+1@Bogdan re: "local maxima" [thus leading to system-wide sub-optimization] versus "strategy" [and true leadership].
For me, there are two dimensions to results deriving from the performance of work - efficiency and effectiveness.

BPM contributes to efficiency and, to an extent, to effectiveness. The source of efficiency and effectiveness is a) workflow management, b) workload management and c) success with measuring progress toward meeting Case/ROI goals/objectives.

Agility, in the main, relates to the organization's ability to steer the ship in a different direction (strategy issue).

Agility in operational workflow is a given with BPM - you can build an inventory of process fragments, present these to users in a menu and the users can thread the process fragments together with few restraints on inserting ad hoc interventions, re-visiting completed process steps, skipping steps, recording data at steps not yet current.

Agility at the workload level only requires that the Case Manager weigh the relative merits of continuing versus exiting and in respect of work-in-progress, suspending, decreasing the resource level, increasing the resource level, or doing a handoff to a different person/team.

The platform neede to support workload/workflow is surprisingly simple

See "Just one Look . . . . Is All It Takes" (2014-01-31)
  1. John Morris
  2. 2 years ago
  3. #4642
@Walter - to take your metaphor further I have trouble with the idea of describing the steering of a ship as anything related to agile.

You've tied agile - correctly I think - to operations. As for steering a ship, that's strategy. Agility can too easily substitute for good strategy, with the result that direction becomes mere opportunism.

I do agree that BPM enables efficiency and effectiveness (i.e. operations) - but also strategy, by virtue of enabling efficient manufacture of new programme automation artefacts.
@John. Sorry for what seems to have been an out-of-context comment - the problem is with the terminology.

My comment related to "business agility" (See Bogdan's comment) whereas your ". . . .related to agile" seems to refer to the "agile methodology"

"Agility, in the main, relates to the organization's ability to steer the ship in a different direction (strategy issue)." was an attempt to suggest that the ability of a corporation to quickly change strategy was important for maintaining a strategic edge.

I think my comment would have been better placed under Bodgan's response.
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation
I believe if done right, companies are gaining vs. losing anything when working with latest BPM and no/low-code platforms. At this point, it's less about the platform/tool/software, and more about the strategy of leveraging them correctly and then executing.

  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
So good to see a few others on side...something we have had for over 20 years and believe me ridiculed and ignored. Having said that we had Microsoft try to patent the core but our prior art precludes any patents...even in U.S. But big established suppliers rarely promote disruptive products....!
Cost has been raised and it is well within range of SMEs and dramatically cheaper than alternatives for larger companies which makes it unwelcome by traditional vendors and "IT". So what next.....? Needs to be distributed globally and share the code widely to truly change the market and BPM can drive this new outside-in people focused next generation enterprise adaptive software. As they say watch this space......
@David . . .
My take on "old IT" (i.e digital plumbers) is that protocols were hard-coded and the focus was on reporting as opposed to user-built workflows/automation that reduced the need for much of the reporting (i.e. by incorporating predictive analytics for real-time decision-making).

The impact of low-code is to enable end-user groups (the new process owners) to build, own and maintain their own processes (with help from IT on rule set building and data export/import)

Easy to understand why legacy vendors look down on solutions that require 1 day to do what they do in 30 days.

I am sure you get comments that what you are doing is "impossible", even as they watch you do it.

Easy as well to understand that consultants who used to go in and spend 3 weeks with a client now have difficulty with new technology spending more than a couple of days. Except that some clients are unable to "think" process, so the duration of assignments for this group remains high.

Neither group likes disruptive products.
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Accepted Answer Pending Moderation
Control of the business

Implementation of no code platform is a risky adventure. It was said a lot about glories of getting rid from an IT team. Nobody mentioned that exactly this irritating and in all ways accused IT team plays crucial role in control of the organization over its digital assets. And in contemporary enterprise digital assets often comprise lion's share of the whole business.

Going to no-code platform means de-facto outsourcing of crucial IT infrastructure to an external company, which developed no-code platform. Organization is barred then from essential access to the code itself. Ironically, more universal and powerful platform is, more power it takes away from control of its client organizations or, respectively, more control gives up a company by implementing that system. Are you ready to give up your business?

What will happen to all clients, if one day developer of this great no-code super-powerful software gets out of business? It will effectively block all business operations of all its clients and, recursively, destroy all their business. Not accidentally, no-code platforms encounter so fierce opposition from top management. They are fast and charming to start with. But, as with many charming temptations, cost health, wealth and mere existence of the company on a longer term.

It partially explains why, open source solutions recently win increasing popularity among no-code systems. At least it gives a relative guarantee of system transparency in case of accidents and protection from unpleasant surprises. However, even open source does not protect from a spaghetti code, which is impossible to cope with and maintain in critical situations. Incidentally, no-code paradigm is actually an opposite pole of open source solutions. It means not absent code but deeply hidden code.

Dream of no-code platform often expresses merely inability of companies to manage effectively their IT teams and essential business knowledge. Well managed IT team is nearly equivalent to no-code platform in terms of its ability to deliver quality business solutions and isolate business from low level technical code. Even the cost can be comparable, if we consider wide offshore outsourcing options.

Not no-code platform or open source solutions are keys to IT transparency in business but systematic throughout business modeling of processes in all IT infrastructure and consistent aggregation of corporate metadata, in other words, BPM. But in no way BPM is equal or associated with no-code platform. BPM brings control over business, while no-code steals control together with code far too often.
Implementation of no code is NOT risky for business ..it is for IT coders!
No you do not need to outsource infrastructure you get that in built in the platform the business has complete control over this.
The model to secure customers is by allowing access to the core code it's easily understood experience has shown it has never been used as it is the development in the platform that delivers. In addition The plan is to share code with suitable partners to take even further and new capabilities shared; thus your concerns are eliminated.
There is no hidden code
Believe me the cost is significantly lower than any IT on or offshore project. The inbuilt flexibility with no code generation ensures future proof investment a low-cost support for change...all proven
BPM is the discipline now supported by the new low no code Digital Business Platforms and quite to opposite to you view brings transparency, empowerment and freedom to think outside the old box and proven high levels of operational efficiency
Thanks Boris you have just highlighted the challenges that "we" face not least is getting the industry analyst to do real research on "how" which is so important......

I agree with your take, Boris, with one exception: that control over code equates control over business. Unless that organization has a strategic focus in the management of the code, it's the same old trap. I was in discussions with a major European healthcare provider that insisted they own my whole code (of course I managed to convince them otherwise). They do have a practice to own and maintain the code of their platforms. They even have a central dev team. But their codebase is 25+ years old, almost impossible to edit efficiently - no major projects can be undertaken in their old platforms, which were revolutionary cca 1973, but now are just completely out of touch with business. So they control every aspect of their code, but are unable to steer the business with it - even key master concepts such as patients, cases, appointments are hard-wired and do not represent how their business has evolved (and must evolve). This could have been our biggest project. We said no, two years ago. They are still pondering what to do :)
@David, @Bogdan, thank you. My main point here that IT value and easy management is in analysis of processes and structures by means of BPM, rather than in elimination of code. If processes and structures are well written, they will be still valid and relevant to improve / rework even 25 years after creation, no matter how many code generations changed since then. In my view, optimal are not low-code platforms but high-code platforms with rich and high level code management. It allows to emit full executable code of the system in the language client chooses and link / modify it with industry standard compiler. It ensures optimal transparency, structuring and independence in support of such system in future. Alas, in regular coding business rules are too often directly embedded into code, which makes them specific to implementation and impossible to extract or migrate. BPM should serve to eliminate such situations.
I think, we discuss "no-code/low-code" case which means that an organisation needs to write ONLY missing code which can be necessary nothing sometimes. But, parametrisation of a tool (i.e. BPM-suite tool) will be always necessary. Thus the organisation does nor give up its business. Actually, it is a normal progression to higher level of abstraction programming. e.g. for many years ago we stopped writing assembler code. At the same time, defining of your business architecture including your business processes is an example of programming in a more abstract language
  1. John Morris
  2. 2 years ago
  3. #4653
There should be a special award icon for any contribution that includes a reference to #Assembler! :)
@Alexander, thank you. Excellent point about progressive sequence of code levels and abstractions. Important difference of lower levels with BPM is standardization. While you can write a code in C# of C++ and be (relatively) sure that any developer in the world will be able to compile and run it, there is little hope that BPM scenario composed in one BPM system will run on others. I m sure we will eventually arrive to commonly accepted BPM world standard. But, alas,we are too far from it yet.
@Bogdan. Very relevant point about code ownership. It is important that the customer has control and through ownership of the Platform this is achieved. Do they need the core code no but it should be available if they want comfort for example held in escrow. Where a customer see opportunity to resell their application then that IPR in what and it delivers should be theirs. The Platform owner gets modest licence fees but the real value is in the solution. Where this happens very likely a deal done to share code and be part of global cooperation to enhance core code capability. Well that's how I see the future...any thoughts?
  1. John Morris
  2. 2 years ago
  3. #4658
+1 @Boris "BPM gives control; No-Code steals control"! And your discussion of the governance (and even sociology) of software development is spot on.
@Boris yes you are right there is that requirement to support change over many years. However does not need high level code or indeed any compiling with no code platform. We have early adopter on board over 15 years ago running case management of distribution of grants scheduled over many years. Constant change is now routine and users love it...no old IT involved! This is a national system includes means testing payment scheduling and much more; total cost of build and change implementation less than £1m with class leading rating for efficiency. Started out as client server just this year converted over half 500 UIs to web cost less than £50k. This is the future with user in control of their processes ....but always open to other ideas...?
@David, impressive record. Not many IT systems survive 15 years. If a framework evolves over this period of time over generations of platforms, it in itself is an evidence of maturity. It is often really comfortable to rely on this level of abstraction to isolate from low level caveats. However, in practice, it is a rare exception from sad experience of beautiful designs, which die in less than a year. In my experience, availability of source code was among obligatory requirements to consider software offerings even before any other aspects were evaluated. Another observation, nearly all successful modern platforms have an opportunity for low level scripting, which indicates a trend exactly opposite to low-code approach.
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Accepted Answer Pending Moderation
The question of code versus BPM implies the question of "abstraction" (word count = 3 above) and "level" (word count = 12 above). This question of abstraction is central to the whole enterprise of software technology, which concerns the manufacture of tools based on abstractions, tools which can be used by machines to perform work.

Why bother adding a discussion of abstraction on to the end of this discussion of nocode and BPM software technology?

Because the question gets to the heart of how we can use technology successfully. The successful use of software technology implies the construction of that software technology. That means knowing your business and taking responsibility for acquiring (through build or buy) the software artefacts that will help you succeed in business. So, to be successful with software-assisted business, one must also be good at software.

So, now the question is, how can I be good at software? And today's debate concerns whether no-code software or BPM software (or possibly BPM+pre-packaged domain patterns) is the best way to go.

I suggest that there's a problem though in formulating the question. And this problem is the implication that there's a continuum between no-code software (or indeed any software) and BPM. The idea of a continuum is dangerous because it allows us to devalue what is unique and important about BPM software technology.

The abstractions in BPM software technology -- indeed the abstractions that define BPM software technology -- are not on a continuum with code. Rather BPM abstractions are reifications of (1) work and (2) process and (3) process artefact manufacture. In other words, BPM software technology is emergent on top of code.

So, who cares? Do we really need to use the word reification? Does it really matter that BPM is something new and different, something uniquely important?

I suggest it is important, because otherwise BPM is just another style of software; business can take it or leave it. And to leave it is to miss using the one technology that by definition is the technology of the work of business. The abstractions embodied in BPM are the abstractions of the work you do every day! BPM is "a language of work".

Empower your business analysts! Give them the tools for the job -- the job of building the tools you need to survive and thrive. You can bury yourself in code, which really means burying yourself. Or you can step up to a brave new world where technology directly presents as business technology. The fact that BPM software technology is still evolving is a good thing. But BPM is good enough now. So, climb on board and start learning how to use BPM to win.

[The concept of BPM as emergent technology is explored here in Minimum Viable Definition of BPM Software Technology.]
@John, excellent summary. I suppose we need a common language of business, same as we have universal programming languages. BPM is a collective effort to create such universal language.
  1. John Morris
  2. 2 years ago
  3. #4661
Thanks @Boris! And for your reference to "language", which I've now added above as well.
  1. John Morris
  2. 2 years ago
  3. #4663
Ironically today (October 20th, 2017) The Register's Andrew Orlowski published "What's the real point of being a dev? It's saving management from themselves"
A marvellous article touching on various software-technology-fads-du-jour, including O-O ("Object Orientation") in the 80's all the way to AI today. As one of the commenters says "coding is hard". And a implication of the article is that "abstractions are really difficult" too. My own comments above concern the desirability of good abstractions and the risks of code. You don't get good software tools without paying attention -- and without knowing both your business and ensuring good IT governance. And good IT governance includes governance of both code and whatever abstractions have been painfully acquired.
  1. more than a month ago
  2. BPM Discussions
  3. # 13
Accepted Answer Pending Moderation
(I'm dressed up as a business analyst that's new to BPM, so you've never seen me here before. OK? )

Hey boys,

I'm asked to do some research on software to support our business processes and a good friend of mine advised me to take a look at BPM.com.

And this seems like a cool discussion, but I have no clue what you're talking about.

Is a BPM suite the same as low-code/no-code platform? Do you need to code in a BPM platform? What is no-code, actually; something like a turn-key solution?

So what's the scale, BPM wise, Code everything yourself...................................................................No code solutions?

Where can I find more information. Help!!
Sharing my adventures in Process World via Procesje.nl
@Emiel. Excellent. I was about to write a similar comment - I don't see commonly agreed (by this group of respected BPM expects) relationships between "no-code/low-code" and modern BPM-suite tools.

Let us start with the following option:
1. Modern BPM-suite tool/platform is a low-code application development platform.
Please add your options.

I am perplexed by "BPM -suite tool platform".

Is this a process mapping environment with a compiler that generates run-time-executable process templates that one can stream Case records onto (i.e. a workflow management capability)?

This would seemingly give a Case Manager the ability to have background orchestration for a Case from process template instances.

Hard to imagine how any organization would not need this.

The problem is very few knowledge workers focus exclusively on one Case and very few Case Managers manage only one Case so that leaves workload management in suspension.

The BPM I know has facilities for posting tasks to user inTrays as these tasks become current along process template instance pathways BUT BPM is silent on what I call RALB (resource allocation, leveling and balancing) which boils down to individual knowledge workers being able to micro-managing the tasks sitting in their InTrays and boils down to supervisors leveling and balancing workload across workers and across Cases.

Accordingly, RALB needs an environment that can host background BPM . If you apply a filter, you can narrow the focus to an individual Case. We don't need a filter to show the workload for a knowledge worker- their InTrays give them precisely that.

Lastly, you cannot reasonably manage a Case in the absence of a set of Case goals/objectives. Fail to include these and you have no means of knowing when to close a Case other than running out of money or when the problem that the solution supposedly is to address may no longer exist.

Fine to have goals/objectives. but if you don't have a non-subjective means of measuring/assessing progress toward meeting Case goals and objectives, you are no closer to knowing when to close a Case.

So, we have mapping, compiling, run- time process template instance execution, RALB and FOMM (Figure of Merit Matrices for non-subjective assessment of progress)

My question is what subset does "BPM -suite tool platform" take care of?
@Karl, I use the expression "BPM-suite tool/platform" because of the lack of commonly agreed terminology. Let us assume that tool includes all functionality necessary for coordination of work. via various coordination techniques including flow charts, cases, etc.
@Alexander - Thank you for the clarification.

I like "BPM-suite/platform". It precisely addresses the lack of commonly-agreed terminology.

My "must have" list is 'mapping, compiling, run- time process template instance execution, RALB and FOMM".

Add to this analytics with "soft rules" that dynamically re-write themselves based on data from a Case and similar Cases and you get close to real-time predictive decision support.

Add generic data exchange and you have the wherewithal to communicate (both directions) with IoT devices/systems.

Add consolidation of data to a KnowledgeBase that hosts KPIs (so that management can not only trend KPIs but engage "what-ifs" when they want more than snapshots of KPIs) and you have closed the gap between operations and stratgy, on the way up, at least.

Looks like I had all of the above in my "2016 Recap - Basic Requirements for Success with BPM" (10 months ago)

The big questions, of course, are how many vendors have all 11 of the listed capabilities and how many capabilities are missing from my list?

In respect of the products we have been building since 1995, the master plan has not changed.

Lack of funding has prevented us from putting in place all of the capabilities in our "BPM for success" list. We are not yet able to do weave predictive analytics into run-time process template instances nor do we have the ability to consolidate run-time Case data to our Kbase products.
  1. more than a month ago
  2. BPM Discussions
  3. # 14
Accepted Answer Pending Moderation
Below is the script (without pictures filling in the gaps!) This gives insight to "how". Sorry not yet available global launch in planning with global contract and funding. THIS IS NOT A SALES PITCH it is educational!
Anyone interested and want the 51 page build guide drop me a line at david.chassels@waterourworld.org.uk

How Declarative MDE as a Digital Business Platform Allows the Model builder to create the Enterprise Adaptive Applications driven by BPM

Solving the business “software problem” of inflexibility with poor user experience was at the heart of the original R&D that started over 20 years ago. Any solution had to acknowledge how people work and most importantly remove the interpretation gap between users and “IT” thus removing need for programmers in the build process. The plan was simple enter data only once recognize the horizontal way business actually works with one version of the truth with real time reports. It was also required to be Adaptive by supporting change as the business required and delivering the data exactly as required to support people at work.
This initiative involved few very able programmers being directed by business knowledge which had established that in reality there are 13 or so “generic” task types that addresses all business requirements that support people (and machines) at work where all data is created. It was recognized that the relational data base had huge potential for connectivity and it was established that such tasks could be stored as “data” and thus a new architecture was created
After 20+ years of research and development and working with early adopters this approach has achieved the objectives set. As will be explained generic task objects and the important links were built and displayed in a Graphical Model where build of custom applications takes place with no change to the core code, and no code generation or compiling.

This core capability was built but the challenge remained how to make it easy for business to use. A user friendly interface was built to set up the database

It was decided that a Graphical Process Designer (GPD) should be built over the core code and icons were created that mirrored established ways of mapping out work activity. It was built to allow the GPD to “declare” through to the pre-formatted database the custom requirements. This technique removed code generation and compiling allowing rapid change in build and in the future. A version control capability was added to include flexibility as to where in a process change is adopted.

The build graphical tool with traditional icons for types of task

Each task opens up a form to allow the parameters to be inserted. The core task types are as follows and proven to cover all business logic requirements
• The Normal task “halts” the process for an off-line activity. It is a very useful development aid in a process, but should be used sparingly in a “live” environment.
• The Form task is the task that the user will be mostly concerned about.
This is where data is entered into and extracted out of the database. It can be a “simple” display form or a complex interactive form. This superseded by the web report/form task below but used for quick first cut/ prototype of the application.
• The Program task allows you to “call” applications such as Word, Excel and specific program used in a process.
• The Pending task places the process into the “Pending” tray of the user concerned. This is a very useful task that is used alongside deadlines and delays in a process.
• The Report task enables a report to be generated via any report application based on a previously defined template.
• The Web report/form task is used to hold the path for Java Server Pages/forms to run across the web. Utilizes Ajax to ensure once only entry of information with intelligent grids.
• The Calculation task can contain calculations involving almost anything including dates, numbers and strings. As well as Procession specific calculations, SQL commands can be placed here to manipulate the database directly.
• The Sub-process task allows the process to move to another, or ‘sub’, process.
• The Event task bundles the same task together in multiple runs and waits for another process to action it. .
• The VB Script task allows the use of Visual Basic code. This task can have many different functions according the requirement of the developer but only used in client server environments.
• The Finish task tells Procession that the process has ended. As far as the user is concerned, the “run” of the process will disappear from the trays. At this point, that particular run will be placed into the “Process History” tray of the manager.
• The Import/Export task handles the movement of “bulk” loaded data into and out of the database. It can be both completed by the user and/or the system according the specifications.
• The Server Side Message Queue task handles communication between Procession (and therefore the database) and many other external systems, such as legacy systems. It’s more popular use is in the sending of e-mails from inside Procession. This is a very versatile and important task.

These tasks were created as “objects” and expressed as data inside a relational database. To make all work in the required order linking capability was incorporated. It was recognised such linking could be used to make decisions within the flow of work. It was designed to allow full audit trail of work to be tracked and all aspects could be reused as required.

Task Links.

Although these links are very powerful, they are quite easy to learn and understand. They contain much of the logic that drives a process application. They are the workflow of the application allowing rules to be built and great flexibility supporting asynchronous work. They are also supporting business rules requirements
A link can be thought of, in its simplest form, as a bridge between two or more tasks. There always has to be at least one Source task and at least one Target task and a link spans the two.
There are only two types of links to remember, the True link and the False link.

The links creating the workflow collaboration

A link, whether True or not, is made up of a Source part and a Target part. The Source part includes the Source Node and the Target part includes the Target Node and the Red/Blue line.
The two types of nodes or link points are where other links are joined or diverged. For example if you have two source tasks, there would need to be two links (one from each task) coming together at the source node. The target node relates to the target task. If there were to be two target tasks, there would be two links emanating from the target node, as shown below:

How one to many and many to one is built
The True/False links are the main type of link, but within these are various other types, as shown below. Each type is represented by a coloured line.
However, if all you want to do is link tasks together in a simple A-B scenario with very simple branches, e.g. a ‘Yes/No’ decision, then you would use the default ‘Normal’ link.

Simple or complex links
Now we can introduce slightly more complex parts to these links to give processes more functionality. These attributes are deadlines and delays. They are very useful in processes and are used a great deal. Further discussion is needed and will be covered in more detail later on. It is sufficient for now to explain the different types.

The deadline/delay links.

Delays and deadlines capability

As can be seen the links have different colours, representing the different link types. The default type is always the “normal” type and would be used most of the time.


If a delay value is inserted into the delay field on the target node of a link, the black line changes to a green colour. This denotes in the GPD that a delay has been applied.
Delays are handled in “days” or divisions thereof. Thus putting a delay in a process so that the process “halts” for six months would require that ‘180’ be written into the delay field on the dialogue box. In the example below, the process would delay for one day.

Applying values to delays
To access the dialogue box, move the mouse over the target node and right click.


If a deadline is used in a process, the black line (source side) turns purple, denoting in the GPD that a deadline is used. In order for the deadline to work, both the delay and the condition fields must be filled. The condition tests the delay and this brings about the “deadline”. For example, a date can be set and placed into a folio field. This, in turn, is used in a calculation, which is placed into the delay field on the “Link Details” dialogue box. A condition is then applied in the “Condition” field, whereby the delay is tested. It the answer is false, nothing happens. However, if the answer is true then the next target task is triggered. This gives the desired result of waiting for a date deadline to pass before anything else happens.
This is an automatic trigger. However, a process can be moved onto the next target task before a deadline has passed, by manual means as required
Deadlines can be ‘hard’ coded or put into folio fields or variables to increase flexibility of the process, as in this example. Here, the process waits for a deadline to pass before a target task is triggered.

Applying conditions for deadlines

 By activating and saving a process
- the Process Engine breaks down the designed process into its constituent elements
- Through a declarative technique these are saved into Oracle tables.
 At run time
- the engine interrogates these tables to decide
- who does what, when and how in the application.
 No code is compiled to enable this to happen.

The visual view of a completed application using custom icons
As can be seen it is possible to customise the icons to suit. This GPD is the deployed application and as such is the new Object Model “code”.

The User Interface
The most important task type is the user interface/form. Whilst the core Object Model Engineering remains solid and robust there was a need to recognise forms need to be simple yet handle the user requirements at work This was addressed by having a library of template forms stored in the database which are dynamically populated with data required by that user recognising the specific instance of the task being undertaken and data required to be used or created.
The arrival of the web brought new challenges and to improve functionality and performance a comprehensive a library of capabilities was built to continue the ease of build of web forms by business analyst skills. This includes;
• Information across an organisation can be used effectively by combining data from separate sources into a single form – also known as ‘mash-ups’ – supporting a Master Data Management (MDM) approach
• The use of AJAX and the built-in data cache ensures users do not need to wait for information to load, and only parts of the form that need refreshing are reloaded,
• The data cache makes data manipulation, such as sorting and filtering,

This is continuing to evolve to keep pace with new delivery technologies such as cloud and mobile.

Other Issues
One of the big challenges has been expressing what had been built in context of the industry which has seen business software evolved in a rather disjointed manner. The rise of Business Process Management BPM is a natural fit as the discipline to establish what is required. The core thinking with a data centric architecture has by default created a unified capability thus a complete Platform includes the following;

• Process engine to ensure all works to plan
• Rules engine reflecting real world of work and compliance
• Calculation engine automating system work
• State/instance engine real time feed back
• Workflow everything connected in right order and supporting asynchronous work
• Integrated forms dynamically and custom created for who, when & where as required
• Audit trail, events, escalations, real time reports supporting control with empowerment
• Roles and performers people and machines ready to work
• Management hierarchy who sees what reallocation of work as required
• Version control easy install of required changes with no disruption

The result is producing new functionality that includes the ability to incorporate intelligence into applications recognising user decisions to dynamically change future actions. It is just the start of a new journey for Enterprise Software.

@David - Excellent account of the evolution and required capabilities of a platform that has BPM its core component.

Sharing this info should discourage any who want to "invent the next generation Ferarri in their garage".

I like "...... the start of a new journey for Enterprise Software"
@David.. one question.

I don't get "... should be used sparingly in a “live” environment." for your Normal tasks.

I don]'t see any reason why your Import/Export task could not be adapted to accommodate trickle imports and bulk imports in which case any halts resulting from waiting for imports are really no different from a human who suspends a step to go and run an errand. Escalation can handle long halts.

Early on we toyed with the idea of incorporating CPM into BPM but quickly realized that in a Case run-time environment the users not only don't know what the forward durations are nor do they know what process fragments they will be engaging, so good thing we did not go in that direction.

Our approach to "long halts" was to add a "time remaining" to the Case completion "best- guess" day/time and give Case Managers the ability to trend "time remaining". If the Case is not moving forward, the CM gets an alert.

Karl interestingly with web most import of data can be handled in the UI by out extensive tag library also enhanced by in memory working. I think the sparing use reflects the fact there are better ways to handle large amounts of data from external sources. Totally agree escalations linked to events and time are important.
I hope by sharing it encourages others that the dream of the 80s to remove need to code is achievable and have a go..let's create the new mass produced Ford. .....few buy a Ferrari it's too expensive!
@David . . Terminology often trips up these questions/replies/comments.

My reference to 'trickle imports" is to multiple data feeds from multiple external systems/apps/devices [never users], almost always in the form of very small amounts of data (e.g. individual transactions OR 15-minute roll-arounds).

For this class of data, the UI is to be avoided - the technology is an interface, but it is totally automated (e.g. 100 clinics submitting their "tomorrow" list of patients in order to get visit authorizations from the managed care company they are a member of - easy to have 20 visits x 10 clinicians x 100 clinics =20,000 files per day at a managed care e-hub).

We don't find much interest in "bulk" data across our customer base
Karl you raise good point as I really struggle to understand "big data" having such high profile when as you indicate at operational level it is as you put it "trickle data". This also reflects the reality that even in big businesses people work and collaborate in relatively small groups which intuitively aids BPM thinking?
"Big data" impacts businesses in two ways i.e strategy development/re-development and operational efficiency/effectiveness.

Both play a role in sustaining and increasing corporate competitive advantage.

BPM, as a provider of orchestration at Cases, directly impacts operational efficiency and, to an extent, operational effectiveness


Big Data and Competitive Advantage

I think the article explains why "big data" has such a high profile except that without tools to provide predictive analytics at BPM process templates and without 3-D Kbases for display / search of corporate strategic assets "big date" is IMO unmanageable.

I find references to "new" agitating when the only change is a name change. Someone at LinkedIn, just this past week, described something as "new" that Russel Ackoff wrote about in 1970.
  1. more than a month ago
  2. BPM Discussions
  3. # 15
Accepted Answer Pending Moderation
Reading all of the above multiple times, I think what companies give up when they go to low-code/no-code BPM is membership in the 70 pct plus group of companies that fail with BPM.

The formula for success with BPM is really quite simple . . .

Recognizing that BPM is a subset of run-time "Case" Management for other than end-to-end processes - too bad we seem stuck with the term "case" - it works very well in healthcare and law enforcement but not so well for e.g. Maintenance, Repair, Overhaul on aircraft.

"Case is a methodology that helps you to manage short and medium term business activity based on orchestration received from background BPM and governance from rule sets at the run-time environment that is hosting Case."

Recognizing that there are 4 other core services that most Case Managers need in order to manage Cases.

"Case Managers/workers usually need supplementary services above and beyond BPM, examples of which are resource allocation, leveling and balancing (R.A.L.B.) across Cases; Decision Support services; Figure of Merit Matrices (FOMM) and Data Exchange".

Nothing much has changed from a 2016 (updated 2017) article "A framework for development of a Case Management Maturity Model" .


My model has 5 stages - I have tagged the stages where low -code/no code is needed

1. Ability to map a BPM process template and casually refer to it as part of achieving run-time operational efficiency and effectiveness at and across Cases. [code needed at steps for data calculations, code needed to build rule-sets at branching decision boxes]

2. Ability to automatically compile a template and generate instances that provide guidance to workers in respect of their performance of work at and across Cases.

3. Ability to host supplementary methodologies/capabilities such as R.A.L.B., FOMM, ECM, CPM. [FOMM requires a mastering of spreadsheets, so I suppose we have to say "code needed", otherwise no coding needed i.e. R.A.L.B., ECM, and CPM require no coding]

4. Ability to consolidate run-time data across instances at Cases and across Cases\instances and carry out analytics on the data. [lots of coding needed here, but we are at stage 4 - you don't need to get to stage 4 for success with BPM/Case]

5. Ability to improve the quality of decision-making using real-time predictive analytics.{lots of coding needed]

I don't see in any of this, a need to have programmers writing hundreds/thousands of lines of computer code.

If you are not a BPMs vendor and find yourself having to write a lot of code, you need to look at vendor platforms. They have evolved over time and will continue to evolve.
  1. https://kwkeirstead.wordpress.com
As the need for bi-directional communication between local, and remote systems and applications increases, now probably is the right time to add a 3.a. step called "Data Exchange"
I see no limitations in delivery of BPM thinking and as such can or should del I very any Case Management. The point about a "Case" is the focus to deliver the support to the end recipients. Sales; the customer, Supply the buyer; healthcare; the patient, HR; the employee, grants; the recipient, Claims; the claimant etc..... Agree with certain points you may have code for sophisticated manipulation of data such as analytics but the operational needs including rules are pre coded just need configuring and that should include the orchestration of any required data exchanges. Totally agree the platforms removing need to code is the future and that their capabilities will continue to evolve.
  1. more than a month ago
  2. BPM Discussions
  3. # 16
Accepted Answer Pending Moderation
I would ask "What does a company believe they will get using a low-code/no-code BPM?"

Understanding this, what drove the customer to seek a low-code/no-code platform, and how they reached this decision has everything to do with what they are giving up.

One believable scenario could be... the business has simply given up on their IT dept / partner to get what they need done. Utilizing the low-code/no-code capabilities in BPM platforms provides the business a way to avoid delays, IT backlog and to address the low hanging fruit in process to directly contribute to digitizing their business.

However, to answer the original question from a perspective of what they (likely the business) give up going with a low-code BPM is the following'
- Integration with source systems
- Rich architecture (soa, micro-services, etc)
- Transaction digitization - through no-code it is likely a simple process automation will be realized while a business transaction would certainly have broader concerns (i.e. integrations, services, corp ui standards, etc etc).

Our approach is to encourage the business to own process definition, workflow and automation... this creates the wave of demand to drive process automation directly by the business. IQ provides the guidance for the business to apply best practices and directly participate in the BPM story - lastly, IQ enables partnership with IT by creating the IBM BPM project in a way where further elaboration to address the broader business transaction by the IT partner (i.e. drop downs and meta data is created using best practices in IBM BPM so that a technical team can easily convert to pulling from a DB).

Capital BPM innovations addresses the gap of no-code with IQ specifically for IBM BPM, find out more @http://www.capbpm.com
  1. http://www.capbpm.com/demo
I like "Our approach is to encourage the business to own process definition, workflow and automation"

The following, however, raises a red flag " . . . so that a technical team can easily convert to pulling from a DB"

Our group long ago automated database access to where no technical assistance is needed to read/write data to a DB.

Most of the clients we work with require that a ticket be raised, that the SOW be discussed by a "change committee" (read time delays, high overhead) before something as minor as adding a new data element to a process step or process pathway can be carried out.

Users cannot "own" their processes if they have to go, cap in hand, to IT each time they want to augment data collection.

In Healthcare, there are "standard" formats that accommodate more than 10,000 data elements. Needless to say that for any transaction, easy to have 95% of the data elements with nothing in them.
John. Good question what do you get...in summary a future proof investment in the resultant application. And at fraction of price!
As for your concerns may be applicable to some but not truly comprehensive platforms
Integration with source systems. Remember it is the digitised front end with its in built back office which drives creation of all data with required orchestration of legacy systems and data. So think communication with legacy....no need to integrate which can very expensive!
A rich Architecture. If your Platform does not have this you are unlikely to deliver as you say. A true Digital Business Platform will need inbuilt "SOA in a box" that enables very efficient and productive job which can readily deliver micro-services.
Transaction Digitisation. All business needs should be enabled in a Platform that includes UIs as the most important task to deliver that vital Adaptive capability no limitations.....
Oh I see you use IBM....understand your concerns....! Remember disruptive technology never comes from big established players....too much to lose...
  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.