BPM.com
  1. Peter Schooff
  2. BPM Discussions
  3. Tuesday, 13 February 2018
  4.  Subscribe via email
How important would you say process modeling is to low-code/no-code BPM?
Karl Walter Keirstead Accepted Answer Pending Moderation
No, process modeling is not less important with low-code BPM, but modeling may take less time/effort.

The purpose of modeling is to discover how close your representation of reality is to reality.

Piano-playing your process from data scripts or via users logged into Case environments, in theory, is easier when the flowgraph logic / workload rules rely on less code as opposed to more code.

Functional department users can debug./ fix low code implementations.

If there is a lot of code, IT has to get involved.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Emiel Kelly Accepted Answer Pending Moderation
What? Process modeling is not the same as low coding?
Sharing my adventures in Process World via Procesje.nl
Comment
Just wondering, does "low coding" mean you have to write a lot of low-level, complicated computer code OR does it mean you have very little computer code (simple or complex) to write.

Either way, seems to me it has no connection to modeling other than as a prerequisite to modeling.

Not sure, either, what "no-code" means?

Presumably, you have a straight-thru process with no auto-branching based on data values i.e. at branching decision boxes there are no rules to fire any of the options at the decision box; you have no pre-conditions to process steps; no post-conditions; no wait-state steps; no external data flowing in, no data flowing out.
  1. Karl Walter Keirstead
  2. 3 months ago
@Karl No code capability needs to include all those attributes you mention and readily handled in the "model" which can the build environment. You just configure as required all well within business analyst skills or quickly picked up by the business.
  1. David Chassels
  2. 3 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 2
John Reynolds Accepted Answer Pending Moderation
I agree with Emiel -

Complete the phrase "Low code process _____"?
I can't think of a better term than "modeling"
Founder at John Reynolds' Venture LLC - Creator of ¿?Trules™ for drama free decisions
Comment
Process supporting application development by modeling it as a process?
  1. Emiel Kelly
  2. 3 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 3
John Morris Accepted Answer Pending Moderation
Interestingly, PCMag (PCMag!) has a top ten list of the "Best Low-Code Development Platforms of 2017" (from July, 2017):

https://www.pcmag.com/roundup/353252/the-best-low-code-development-platforms

Every single one checks off "process / workflow modeling".

As Walter, Emiel and John have so entertainingly pointed out, process modeling and low-code are not the same thing. And importantly, less time required for coding means more time for process modeling.

Let's go further. In the world of software development, the only thing project sponsors care about is acquiring or building tools that help us do more work with fewer resources. And that means starting first of all with understanding our work. And how we could in fact use technology to help us be more productive. In practise that highlights the centrality of process modeling. Process modeling, mainly by business analysts, is the key to business transformation, or just plain old business improvement. Process modeling (along with other irreducible domains of business semantics, such as rules modeling) is always part of any software project, whether implicit or explicit. Process modeling is the script from which any software is constructed according to the needs of our work. By definition.

From this perspective, coding, however much any of us like coding, or schools are promoting coding, coding is just a distraction. Coding is a means to an end and is a long way from value creation. Process modeling on the other hand is about directly focusing on the work of business; process modeling is much closer to value creation. So, insofar as we can reduce coding, we reclaim the opportunity cost lost to code. We can focus our scarce resources on process modeling. And we can drive our business forward. Code thinking crowds out business thinking. Code is a necessary -- and even thrilling -- evil. But if low-code or no-code makes it possible to spend more time on process modeling (and architecture etc. etc.), everyone is a winner.

How mature and capable is low-code or no-code is a separate question.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Stuart Chandler Accepted Answer Pending Moderation
Blog Writer
In one respect, I agree with others that low code exposes process like RPA activities and could minimize process modeling. However, I think it is a mistake that we ignore a reference 'process' architecture and that low code is not a modeling tool. Some low code approaches incorporate visual representation thus provide some ability to "see" what is what. The bigger the business and its complexities the more stakeholders involved and require a need to resolve vision to reality. For now, Modeling is the only way to grapple with challenging business problems. On top of that the 'What-if' can't be managed. Yes, some "What-if" is managed by assembling the low code pieces and doing a walk thru demo but time to build vs a process model to talk thru and bring visibility to the business challenges and complexities is quicker for now. Is a picture of a car and its components faster than building it and test driving it? I guess it all boils down to perspective and where one is with in the business platform build journey..........
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Max Young Accepted Answer Pending Moderation
Blog Writer
Of course: otherwise, you paint yourself into a corner. How does the use case expand?
References
  1. http://www.capbpm.com
  2. http://www.capbpm.com\iq
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 6
David Chassels Accepted Answer Pending Moderation
We built the no code capability based upon all business logic including workflow and once we discovered it actually worked we implanted a graphical builder on top to allow very quick understanding and build. So the "model" becomes the deployed application. We used a declarative technique from the model to the process engine which automatically set up the custom application. The model makes it easy and quick in hands of business not IT. Modelling on its own a bit of a theoretical exercise although was used by audit in the 70s to good effectively then IT took over....! However once business users realise they can now control their operational process via a readily understood model the game changes. But it is very "disruptive" where suppliers and even internal vested interests will not welcome or want to believe....! It takes business back the basics of how people in business actually work and how they need to be supported by "digitizing" their processes where the BPM discipline sits.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
E Scott Menter Accepted Answer Pending Moderation
Blog Writer
As David points out: the model is the application. What you don't need to do, however, is to create a bunch of paper models, like those billboard-sized flowcharts with which we're all familiar. Such renderings tell no story, and in any event are at best poorly connected to the executable model one will actually end up building using your BPM platform.

Use the tool. Dive right in: model, deploy, observe, enhance, repeat.
http://www.bplogix.com/images/icon-x-medium.png
-Scott
Comment
Well said Scott...only taken industry over 20 years to starting talking our language....and UK Government Digital Service still stick post it notes on walls..... But there is hope....
  1. David Chassels
  2. 3 months ago
The futility of paper mapping is easily explained by three observations:

1. The logical approach to to new process development is to start with two events and one arrow I.e. what inputs are we trying to transform to outputs. Then expand. As users map, they routinely discover they need to insert steps, disconnect/reconnect steps etc.- when they do this on paper and run out of real estate, they have to re-draw or work with ever-increasing graphic complexity.
2. The stakeholders can easily be in several cities, and mapping "work" for today is likely to depend on information on hand and the focus of the stakeholders - you want to be able to give the mouse and keyboard to different stakeholders and let them expand their portions of the overall process.
3. Every, say, 1/2 hour, it is a good idea to compile your map, roll-it out, see how it runs. i.e. get what you have done working properly before adding more detail/more complexity.
  1. Karl Walter Keirstead
  2. 3 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Rachel Accepted Answer Pending Moderation
I think we are putting the cart before the horse. There are a few larger questions to be answered first.

What exactly is Low-code BPM?
What business or technical problems are you trying to solve with Low-code BPM?
What are the goals and objectives of Low-code BPM?
What business outcomes are you expecting from Low-code BPM?
How do you measure the success of Low-code BPM?
Who is the audience of Low-code BPM?

Then we can make a comparison of how process modeling is used and its effectiveness. I have some theories and plan on working on those in 2018.
References
  1. https://www.outsystems.com/
Comment
Re: Some theories this year - sounds timely and useful! Can we "stay tuned"?
  1. John Morris
  2. 3 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Dr Alexander Samarin Accepted Answer Pending Moderation
Let us link this discussion with the previous one which said that work must be formalised before being able automated. As we know there may be two types of formalism – 1) Domain Specific Language (DSL) which is understandable for process owners (BPMN and DMN are examples of DSLs for BPM) and 2) code which is understandable for IT.

Thus, low-code/no-code BPM means either 1) less automation than “normal” BPM or 2) more process modelling in some DSLs than “normal” BPM.

Of course, only machine-executable processes are considered.

Thanks,
AS
Comment
@Alexander...well I can't pass view on DSL but the declarative from the model to the business logic as we have pioneered has no such limitations indeed opens door to greater automation ....
  1. David Chassels
  2. 3 months ago
@David, do you have a formal language for your declarative description? If yes then you have a DSL else, please, provide an example. Obviously, any DSL is more abstract than modern generic programming language thus the former offers more automation with less efforts than the latter.
  1. Dr Alexander Samarin
  2. 3 months ago
Re: "machine-executable" models versus expressive human-intelligible function models, this opposition is only an artefact of the round-trip problem. One can speak of more or less detail (zoom in or out) which supports a business discussion.
  1. John Morris
  2. 3 months ago
Re: "human-intelligible function models" - can you share an example, please?
  1. Dr Alexander Samarin
  2. 3 months ago
I should have said "process models", but I simple referring to business analyst models with boxes and arrows, in software, that are used to facilitate business discussion. Function as in "business function".
  1. John Morris
  2. 3 months ago
It is recommended that such "process models" from business analysts must follow some (corporate) formal modelling guidelines - so it is a first step for formalisation of work.
  1. Dr Alexander Samarin
  2. 3 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Juan J Moreno Accepted Answer Pending Moderation
In my experience is just the opposite: low code (or no-code) BPM Suites make Modelling even more important. Given you don't have to deal with coding and you have a pre built set of useful KPI's, you have more time to analyze them, detect improvement opportunities, and go over your model to improve it.

I'd say that Low-code BPM Suites enhance the importance of modeling, allowing it to refine the process model iteratively and agilely, shortening the deployment time of new improved process' versions.
CEO at Flokzu Cloud BPM Suite
Comment
Key Process Indicators (processes) or Key Performance Indicators (corporate level)?
  1. Karl Walter Keirstead
  2. 3 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Kay Winkler Accepted Answer Pending Moderation
I agree with Juan. In my personal and practical experience with platforms that prescribe to the no/low code maxim, such as Flokzu or Aura Portal, process modeling is an indispensable prerequisite for the later steps of the BPM lifecycle.
NSI Soluciones - ABPMP PTY
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Dr Alexander Samarin Accepted Answer Pending Moderation
So far I see a new law of BPM (with thanks to @Karl, @Juan and @Kay) - "Level of automation" = c1 * "Level of modelling"**2 + c2 * "Level of coding" + c3

Thanks,
AS
Comment
Polynomial!
  1. John Morris
  2. 3 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 13
Emiel Kelly Accepted Answer Pending Moderation
Although my avatar is an (ironically meant) post it, I agree with lot of the above.

The only thing that surprises me is that I get the feeling that 'an implemented application' is seen as 'an implemented process'.
Sharing my adventures in Process World via Procesje.nl
Comment
For me,
"implemented application" is an encapsulation of functionality with a UI that encourages sustained use.

"implemented process" is the result of compiling a process map, carving it up into steps/roles, rolling it out to a workflow/workload management platform such that a resource allocation/leveling/balancing engine can post steps to the attention of workers as steps become current along the process timeline.
  1. Karl Walter Keirstead
  2. 3 months ago
@Emiel, some people are trying to implement a process but always producing an application.
  1. Dr Alexander Samarin
  2. 3 months ago
@Emiel @ Alexander - seems to me when an organization finds that each process it implements becomes "a new application", this is a sign of bad architecture.

See my 9/2012 article "The Last UI You'll Ever Need to Manage Workflow/(Workload)"
https://wp.me/pzzpB-lz

Microsoft doesn't put out a new version of Microsoft Word each time one of their customers decides they want to write a new letter.
  1. Karl Walter Keirstead
  2. 3 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 14
Bogdan Nafornita Accepted Answer Pending Moderation
Process modelling is a very generous notion - it ranges from back-of-the-napkin drawings (meant to provide end-to-end overviews for business owners) up to full executable process architecture.

From that standpoint alone, process modelling does more than low-code development, in that low-code (especially the UI- or database-driven varieties) usually does not expose the application logic in a way that's palatable to business owners.

Low-code also does not secure an architectural approach towards process-driven app development, which may be less palatable to Enterprise IT.

So low-code is the middle-ground, good-enough, power/team hacks that enable quick and small wins in the workplace. It's cheaper and faster than process modelling, but has limited impact on digital transformation (whatever that means).
CEO, Co-founder, profluo.com
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 15
David Chassels Accepted Answer Pending Moderation
Alexander raises a number of key issues and my views based upon what we have created and proven with early adopters.

First the "language" question on the basis we do not need a "DSL". The link below as part of a research paper where I contributed gives a summary of the thinking in what and how we addressed. With our architecture the "language" used to build the custom application is "business language" which is used to directly configure what is required. Before you start best to configure the relational database identifying users their roles and a focus for the data structure all well within business analyst skills. If complex manipulation of data required such as an algorithm get a programmer but otherwise spreadsheet skills adequate. Really is that simple a days training and you can start to build you custom application and as ever learn on the job and maybe even discover new capabilities as our early adopters experienced!

The issue raised of "process models" we followed well established designs used by analysts and auditors in the 70s each object handling a specific business function just click drag open and configure. This includes links which also facilitate rules etc.

Referring to Alexander's law of BPM "Level of automation" = c1 * "Level of modelling"**2 + c2 * "Level of coding" + c3 Sounds complex? First BPM is the discipline in thinking what is required. Whilst extraction from users can be aided by simple high level "modelling" as Scott articulated using a platform "Use the tool. Dive right in: model, deploy, observe, enhance, repeat". Users then really do buy into this approach after decades of being side lined and dictated to by IT! Much automation already built into the "Platform" but as users understand more opportunities to automate many routine activities will emerge and readily implemented via the model as no coding or compiling to hinder future change in the process.

All this sits comfortable outside IT but as ever their input important for secure delivery and of course accessing legacy systems and data for use as dictated by the process.
References
  1. https://www.igi-global.com/chapter/object-model-development-engineering/78620
Comment
@David, DSLs are used to make some artefacts
1 domain-friendly,
2.executable (of course, ideally),
3 formal (thus testable),
4 explicit (thus existing outside tools).
There are a few DSLs in BPM – BPMN, DMN, CMN. Because of DSLs one can define some artefacts in one tool and use them in another tool. Also some value-added tools can be developed.
Of course, the items 3 & 4 are not mandatory in an BPM-suite tool. A lot of BPM-suites do not make all their artefacts formal and explicit. In many case, such artefacts are hidden somewhere in databases.
But, for the better “health” of the whole industry the items 3 & 4 are very important. They dissolve monoliths.
Also, these two items promote formalism which is important for efficient automation.
  1. Dr Alexander Samarin
  2. 3 months ago
@Alexander Thanks for explanation just confirms how disruptive what we "discovered" really is and DSL may have limited life.......if we can hand back to business their processes....that requires IT to give up that aspect to their business...but many conflicts to new ways ......bit like the Pharma industry......just a thought!
  1. David Chassels
  2. 3 months ago
@David, DSL is one of ways to empower business people to manage their business by them with enough of formalism and by knowing good business practices (i.e. patterns expressed in DSLs). If you know other ways to achieve the same (as minimum) then, please, share them. I will be happy to discuss this topic.
  1. Dr Alexander Samarin
  2. 3 months ago
Systems thinking and empowering people in my DNA and hence my frustration with how IT with inside out systems imposed command and control and yet very little true understanding and thus support of operational activity supporting people. I see DSLs as a step in the right direction but as I have articulated that final solution puts build and change in hands of business. However empowerment needs that real time monitoring and feedback so all know what is happening and any problems quickly addressed. Where they are systematic then users can initiate and contribute to how to change. The removal of techie coding achieves this with no compiling certainly aids easy change and implementation of a change management system into the real time system. Business is actually quite simple when analysed down to the low operational needs...IT has made very complex and so time for change long overdue as I am sure we all agree!
  1. David Chassels
  2. 3 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 16
Boris Zinchenko Accepted Answer Pending Moderation
Integrated development environments (in short, IDE) dominate nearly every area of modern IT. Developers cannot work productively without a graphical shell, which accelerates routine code writing and wraps common constructs. Despite common belief of business, IT is the area occupied by low-code platforms.

Why these low code platforms of IT are not recognized as such in business? Because all of them encapsulate and expose technical details not suitable on business level. This creates false impression of them as high-code platforms. Ironically, exactly business level remains a virgin land of high-code debris little touched by overall code reduction. It happens exactly due to insufficient modeling. Low-code platforms do not appear out of nowhere. Instead, they arise as a generalization of established models and vocabulary in their subject area.

Dynamics and versatility of business scenarios complicates creation of such universal models and vocabulary commonly accepted by entire business community. Exactly this circumstance is a key factor impeding successful adoption of low-code solutions in business. Thorough business modeling and accumulation of universally recognized dictionary of standard primitives is the ultimate foundation of any successful implementation of low-code platform in business.

Low-code platform without carefully tailored library of components encapsulating low level logic and drill down sequence of nested models is not a blessing but a hollow nightmare only suitable to destroy a business. Successful low-code platform can only appear as a natural result of low-level scrupulous business modeling, not as its starting point.

https://caseagile.com/wp-content/uploads/Low_code_business_IDE.png
Comment
@Boris, the shape should be not a pyramid, but an iceberg.
  1. Dr Alexander Samarin
  2. 3 months ago
+1 Dr's Samarin and Zinchenko, for "land of high-code debris" and a battle of the metaphors ("pyramids versus icebergs"). Entertainment aside, humans are successful with technology insofar as we turn 1's and 0's into comprehensible language.
  1. John Morris
  2. 3 months ago
@Dr Alexander Samarin, Thank you for mentioning "iceberg". I noticed your wonderful iceberg diagram on another thread recently and was partially inspired by it drawing this illustration. I thought on using iceberg first. But then decided for pyramid. In fact, lower level business environment is very wide. Next level dictionary generalization is narrowing it. Then model relies on selected dictionary subset. IDE appears on top of these. Normally, management should not see deeper than level 2 from top: business IDE and model. In this sense, deeper level can be depicted under water to represent an iceberg. I ve missed adding this separation level perhaps.

  1. Boris Zinchenko
  2. 3 months ago
@Boris, Thanks for providing additional explanations. In preparation of illustrations for my thoughts, I found an important factor, i.e. the first impression of readers. Usually, such an impression is based on some strong associations. The pyramid is associated with the distribution of power or importance. Thus some reader will think that IDE and "low-code" are the most important things.

Perhaps the "inverted pyramid" will be better in this case.
  1. Dr Alexander Samarin
  2. 3 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 17
Karl Walter Keirstead Accepted Answer Pending Moderation
This has been a very interesting Question/Response/Comment set.

@Bogdan
I liked "Process modelling is a very generous notion - it ranges from back-of-the-napkin drawings (meant to provide end-to-end overviews for business owners) up to full executable process architecture"

On deliverables . . . based on the responses, I think the BPM community doesn't get high marks overall. I suppose some of the vendors have universal platforms for workflow and workload management but I get the impression many corporations seem to get caught up in a slippery slope of UI development, back end application development, all in the aid of being able to manage BPM workflows and management of workload.

My opinion

Not necessary ! - if you have the right architecture.

Take the time to look at the following

https://youtu.be/nVL18aaMVR8

  • New industry (what you see was built for healthcare, initially).

  • No new application

    No new UI

    No "coding", other than rules at steps.

BPM is fully integrated, documents, images, video, sound can be attached to steps, History is built automatically.

There are 200 forms and some navigating menus that we did have to build - I don't count dragging and dropping form controls on a canvas as "coding" (Am I wrong?). In any case, the forms are licensed material, they get delivered with the "application system", the customers don't have to worry about other than adding their logo to the forms.

Comments please . . .
References
  1. https://youtu.be/nVL18aaMVR8
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 18
kritika pandey Accepted Answer Pending Moderation
No, process modeling is not at all less important. Let's in the case of Low Code BPM, there's as of now a past history of visual apparatuses, yet things have achieved a considerably larger amount now, precisely because months of training are no longer necessary, decreasing to just a couple of days what was beforehand performed in months in Traditional BPM stages or advancement situations concentrated on programming and codes.
When we use the expression Low Code Platform, or Low Code business process management, during a specific case, we have a tendency to aren’t simply talking regarding reducing the amount of codes, however reducing time and prices to hurry up the delivery of an answer, sometimes with the assistance of the cloud and without really depending on the inner infrastructure of a corporation.
Kritika Pandey (Software Analyst)
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 19
David Chassels Accepted Answer Pending Moderation
@Boris Given your last para much thought...so are you saying getting to the low level logic i.e. details step by step what is required is the answer but best starting point is......a need for business and IT to talk same language? If so Yes been our experience and once IT saw us make inroads to business the initiative was stopped...takes brave business people to take on IT. But operational processes were business responsibility then IT vendors with false promises took over in the 70s and even accountants fell for their hype...and some joined in. But now we must get back to the basics yes the low level business logic where people create information. Look at the mess of legacy and despite those promises 15% of global economy is corrupt....Time for change to track all activity....the banking sector with blockchain making start as corruption will no longer be tolerated..just look at the global arrest actions and changes over past year.......and now businesses need to regain control and that takes back to basics...people and their processes need to be monitored and that is where digitisation with business as driver will play important role in their language?
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 20
  • Page :
  • 1


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