Resolved
3 votes
There was a lot of talk at bpmNEXT about low-code BPM, but towards the end of the conference there was some pushback as well. So in your experience, when is low-code BPM not the best option?
Tuesday, May 17 2016, 09:50 AM
Like
1
Share this post:
Responses (17)
  • Accepted Answer

    Tuesday, May 17 2016, 09:57 AM - #Permalink
    Resolved
    5 votes
    Low-code isn't appropriate when a highly tailored user interface is necessary to achieve the required participant efficiency in performing their tasks.
    Like
    2
    • Tim Stephenson
      more than a month ago
      True enough John: highly specialised or deep domain knowledge will always need dedicated UIs to make the most efficient use of that knowledge.

      But... I'd maintain that people tend to assume that their problem is one of those requiring dedicated UIs more often than they should. Usability and efficiency are often functions of familiarity more than we're often ready to accept.
    • John Reynolds
      more than a month ago
      Agreeing with Tim's comment... and the same can be said for custom process definitions... "Our process is unlike anybody else's process" seems to be a given.
    • Ian Gotts
      more than a month ago
      Clear stable process
      Highly tailored UI
      Ultra high performance
      Complex integrations
    • David Chassels
      more than a month ago
      The UI build capability should be integral part of the software platform as such build should be well within low code capability including intelligent linking Ajax etc
    • John Reynolds
      more than a month ago
      Responding to David's comment...

      In my experience, the UI builders in most BPMS are Task oriented, which works well when Tasks are largely independent of each other. When Tasks are interrelated, such as when a dispatcher needs to make multiple assignments to optimize a field worker's day, then the OOTB builders tend to be of little help or require a lot of custom coding...

      I think we're ready for a new generation of tools for building UIs for business processes which aligns better with what's best for the process participants.
    • David Chassels
      more than a month ago
      John
      Let's remember a key attribute is "adaptive" where the UI presented is for that user with all data required to both undertaking their specific tasks and allowing easy submission of new data. As such this requires an architecture to orchestrate all this to the in built UIs which can be configured to present data in logical format with no limitations.
    • karl walter keirstead
      more than a month ago
      John... Do we ever get to " . . . when Tasks are largely independent of each other"?

      I suppose it happens when there is a Task that only one person is able to perform and that person has no other work to do.

      Otherwise, tasks almost always compete with each other for scarce resources and unless a performer starts and finishes a task without any interruption, we end up with a longer than normal performance times as a user starts/stops/re-starts etc.
    • karl walter keirstead
      more than a month ago
      Revisiting this discussion, I say low-code/high code in the area of plan-side process mapping has little to do with any UI design targeting participants at template instances\steps of compiled process maps.

      For the most part, participants will be working on multiple instances of multiple templates, so the focus for any run-time UI needs to be on auto-resource allocation, leveling and balancing. (R.A.L.B)m of workflow and workload.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 17 2016, 10:03 AM - #Permalink
    Resolved
    6 votes

    It's not appropriate when it's sold as an 'any business user can create apps' type solution. Regardless of how easy it is to use and create forms etc you still need to have an analytical mind and an understanding of how information flows to create an effective solution. If sold in this way it can just create confusion, mistakes and cost more than any benefits.

    • David Chassels
      more than a month ago
      Craig
      I agree our experience confirms business users are not really interested in "building" themselves; it's not their job! However they love fact it is their direct input that builds any requirement in their language. Leadership will be with business skills not old IT!
    The reply is currently minimized Show
  • Accepted Answer

    Ian Gotts
    Ian Gotts
    Offline
    Tuesday, May 17 2016, 10:09 AM - #Permalink
    Resolved
    5 votes

    "Low-code is appropriate in every situation. Sorry, what was the question?" - CEO low-code app vendor.

    Like
    2
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 17 2016, 10:10 AM - #Permalink
    Resolved
    5 votes

    When you have a business model that relies on large numbers of billable hours!

    Just couldn't resist ;-)

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 17 2016, 10:11 AM - #Permalink
    Resolved
    6 votes

    You have better options than low-code BPM when the following are true.

    • You have the 6+ figure budget (and the stomach) for custom software development.
    • You cannot accept any compromises on user interface, automation or systems integration.
    • You know exactly what kind of process management and automation to build.

    If you don’t have hundreds of thousands available (to start with), then a low code solution may be the only affordable option. Or spreadsheets.

    If you can use a generic user interface, or you don’t have to automate everything, or you can get started without complete systems integration, then you may well be able to achieve some business value without (someone) writing a lot of code.

    If you know exactly what kind of process management and automation you need, and your change management initiative is already complete, then you might as well build a process management system, instead of using something simpler to figure out what you need. Otherwise, start with the sticky notes, then move on to a low code system, before later going for a classic full BPMS.

    Of course, even if you really are in this situation, your other options might not actually bebetter.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 17 2016, 10:12 AM - #Permalink
    Resolved
    4 votes

    Taking the question at face value, how about "never"?

    The cost of coding is wildly underestimated. For business process automation, low-code, or better still, zero-code, is the target. And we're almost there.

    In the meantime, it's worthwhile looking at what's outside the Venn diagram bubble of "business process automation".  We don't want to muddy the argument.

    1. SOA CODE -- We should exclude from our question so-called "execution" code. Per Volker Stiehl's argument, with a proper systems architecture ESB and SOA "coding" is segregated from process business logic, which can be deployed from executable BPMN.

    2. ALGORITHMS & RULES -- Let's also exclude from "coding" legitimate uses of code which are external to what we are after, which is business process automation. Specifying an algorithm or a business rule is not "coding" per se, they are a formalization of business logic.

    3. USER INTERFACE -- And UI coding is also not coding strictly related to business process. (And even UI platforms are getting more and more powerful in terms of reduced need for coding.)

    Notice the initial "never" is qualified by "almost". To be able to execute any sensible arbitrary business process is what management needs. Most BPM products still have problems with some complex process graphs, which in those circumstances require a little coding for messaging. This is unfortunate. Better math in the BPM engine would help. But in most cases, avoid code.

    • John Morris
      more than a month ago
      Reading a few other comments, notably that of Mr. Nafornita, it's worth highlighting that performance, technical stability, (and as well security etc.), are all issues where the current state of low-code BPM platforms may not be up to the job. Per the Innovators Dilemma however, these use cases are likely only an artefact of time and today's technology and will not persist. (One could make an argument that most of these challenges are covered off by the "SOA CODE" exclusion above.)
    • Bogdan Nafornita
      more than a month ago
      I am all for code re-usability. That's one of the main kickers for using BPM for business apps, after all - you can organize functionalities as business microservices and re-configure them quickly in another implementation.

      Bu as pointed on many occasions (and on this topic as well), BPM solutions are part of a continuum from fully-customized business apps - to standard SaaS.

      But even when we're talking about SaaS (the usual solution for low-code implementations), one cannot ignore the enterprise-specific need for integration into existing system architectures and business logic (btw, innovation dilemma or not, this need will never disappear, no matter how advanced is the low-code platform).

      And that requires coding - beside a few other skills not usually residing with citizen developers.

      I find it disingenuous for low-code platforms to completely omit this from their YouTube cartoons.
    • David Chassels
      more than a month ago
      Bogdan
      You raise a good point re integration. However reality should be that where information is created is the dominant arena.....so legacy becomes the slave to these operational needs? Avoid integration trying to change old code. Yes you need links into legacy to use but driven/orchestrated by the new low code adaptive software.
    • Bogdan Nafornita
      more than a month ago
      David, I don't think reality is there... systems of record are still far more entrenched in enterprise than systems of engagement, and the logic there is hard to be dominated by low-code efforts (think complex master data). And of course integration means you do not touch old code. But you still have to architect this integration around that old code and logic (loose coupling, optimistic locking, idempotency, service layers, canonical data models, communication bus), and that's not something you find in low-code gigs and definitely not in citizen developers' concerns.
    • John Morris
      more than a month ago
      Bogdan, I agree that "citizen developers" definitely don't have the skills to do software development. Even software developers sometimes don't -- witness the decline in appreciation for proper **relational database design** by aficionados of the noSQL movement. The whole social idea that everyone should know coding is probably wrong, however interesting coding may be. And your emphasis on the importance of legacy systems of record is also important. Legacy systems aren't going anywhere fast, and indeed are a magnificent achievement even.

      And yet we are left with the situation where the "tail wags the dog" and business executives are told that "no we can't bring this new initiative to market for less than a million dollars and 18 months of development", or perhaps on a smaller scale "for less than a hundred thousand dollars and three months". And in both cases perhaps 80% or 90% or more of cost and time is in unproductive infrastructure wrangling.

      The question of governance of business processes is therefore a WICKED PROBLEM. In other words, almost intractable. Throw in MDM ("master data management") chaos in larger organizations and it's DOUBLE WICKED.

      A solution is also governance-related, I suggest, in two parts: (1) business leaders have to take more responsibility for owning the automation of business semantics (i.e. opening up the "black box of IT") and (2) IT needs to step up on surfacing business semantics for business purview (e.g. splitting off business process semantics from underlying integration technology).

      Result? BPM is now a DIFFICULT CHALLENGE, but no longer a WICKED PROBLEM.

      https://en.wikipedia.org/wiki/Wicked_problem
    • David Chassels
      more than a month ago
      It was an Accenture manager who once he "got it" leapt to his feet and drew a picture of legacy and then drew what he described as the Greenfield of agile adaptive software wrapped around the Brownfield of legacy......a good visualization of how it will end up....

      As for systems of record yes use them but reality is the one version of the truth will lie with the BPM driven "Greenfield". I would suggest over longer term the opportunity will emerge to retire much of the legacy silo mess. I believe that it will also make double entry bookkeeping redundant further reducing systems overhead in the business....?
    The reply is currently minimized Show
  • Accepted Answer

    Ian Gotts
    Ian Gotts
    Offline
    Tuesday, May 17 2016, 10:15 AM - #Permalink
    Resolved
    4 votes

    Low code is not an option UNTIL you have a clear understanding of the business processes and you have Simplified and Optimized them. Only then should you Automate. Otherwise you are simply spending money to "do the same shit, only faster"

    Jim Sinur just published a blog post about "Simplify & Automate"

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 17 2016, 10:24 AM - #Permalink
    Resolved
    3 votes

    As always, I look at BPM (yeah, not BPMS) from the business side. So you will not be surprised tha my answer is "as less as possible" .

    But when you think you need a BPMS (I think the 's' is missing in the question) to support the executing and managing of your processes, I would prefer it is as easy as possible.

    15 years ago, at Pallas Athena, we had a process modeling tool and a very complex Case management tool.

    Then we decided to make an in between product, where your process model could be "brought alive"

    This was already a little step towards lower code. I used it with nurses and they loved it. Not because it looked well, but because the picture became reality. Live in the room. It created so much more process understanding than looking at 'blocks and arrows' .

    So at that time it was absolutely cool for prototyping.

    But, when brought live you still needed some coding/scripting to connect, for example, with data sources.

    But as we know, there are some CEO's of low code app vendors that will solve it for us ;-)

    Also another thing not to forget; there are many types of processes (straight through, goal driven ,etc). So first start with a proper understanding what kind of support your processes need and then find the lowest code as possible.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 17 2016, 10:36 AM - #Permalink
    Resolved
    4 votes

    Innovations are usually not low-code solutions.

    Thanks,
    AS

    • John Morris
      more than a month ago
      Yes, but at what level? A business innovation for example could be constructed entirely of low-code business process solutions, n'est-ce pas?
    • Ian Gotts
      more than a month ago
      John - +1 Low-code means you could prototype a whole new business model and prove it before you commit to investment in scaleable apps
    • Dr Alexander Samarin
      more than a month ago
      Maybe that was not an innovation but just a quick fix of a serious performance error?

      Another case is the "iceberg" pattern - a properly architectured and implemented platform makes easy (i.e. low-code) implementation of typical business problems.

      As you said, level, scope, context and, maybe, some magic must be taken into account.
    • Dr Alexander Samarin
      more than a month ago
      Prototyping is low-code by definition. For example, for BPM-suite selection I recommend my clients to run a blind-test of BPM-suite vendors. Prepare a small app, ask vendors to implement it during 5 hours and then show you prototype. (Do not forget to record the presentation).
    • Bogdan Nafornita
      more than a month ago
      I'd argue that prototyping is not innovation, it's just a preliminary iteration (very much needed!) towards the actual innovation.

      Innovation implies execution and the prototype is not highly executable.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 17 2016, 11:07 AM - #Permalink
    Resolved
    5 votes

    It is when I flip the question on its head ("when is the low code BPM the best solution?") that I struggle to find an answer...

    I want to love low-code solutions - in my unusual quest as a tech-loving CFO, I tried a huge number of them, not only in the pure BPM space, but also in CRM, on-line database management, note-taking, collaboration, filesharing, project management - including purely mobile solutions as well.

    Few stuck to my workflow. Most of them, despite being highly proficient on their own terms, didn't.

    So, some of these tools are useful as long as they address a particular unmet workflow need in a very specific, peculiar way. They are usually oblivious to the overall customer-mandated goal of a business process - they just fix a small task or an immediate set of tasks (if we're talking teams).

    Low-code BPM solutions struggle heavily to meet the demands placed on them by serious, long-term running, business processes. It's fun to draw some user forms, and color the buttons and send some automated emails, but frankly that's not an business application:

    - it does not have a proper underlying architecture - data, integration layer with other systems, validation by business rules, coordinated with other business players etc.

    - since it's most likely not mandated / deployed by IT, it's probably not widely shared in the organization - it's just a collection of personal hacks, not documented, only sparsely managed and maintained.

    So, I'd conclude that low-code solutions are only suited for personal / team efficiency purposes. But that's just such a small subsidiary goal of BPM, that you simply do not need BPM-focused tools to achieve those.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 17 2016, 11:37 AM - #Permalink
    Resolved
    4 votes
    I mostly agree with John Reynolds, but I’d like to add the knowledge perspective.
     
    In one scenario, when you work with a great number of process instances, and you don’t have much time for each one, you need a customized app, much more than a fast-to-deliver, low-code BPM Suite. In this scenario you are engaging quick decisions, based on the information the system shows to the user.
     
    In other scenario, where the user has to make complex decisions, maybe he can spend a few more seconds opening an attachment or making some avoidable click. But it doesn’t matter, it is more important for the business to have a very agile low-code BPM Suite and being able to adapt their processes quicker.
     
    These two scenarios are different in one important dimension: the first is less knowledge intensive, while the second implies that the worker use all of its knowledge to complete each process instance. Obviously, the first scenario has a major propensity to be fully automated, I mean, replacing human beings with software. And it reinforces the notion that it will need a lot of coding, so a low-code-BPMS should be the best option.
     
    NR: These two scenarios are not the general rule; there could be knowledge intensive process in the first and several other combinations. But they work as clear examples.
     
    • karl walter keirstead
      more than a month ago
      Interesting comment, Juan

      "when you work with a great number of process instances, and you don’t have much time for each one, you need a customized app, much more than a fast-to-deliver, low-code BPM Suite"

      See the write up on "Beyond Case by Case Management" that describes the importance of automated resource allocation, leveling and balancing (RALB) when workers need to attend to simultaneously attend to multiple instances of multiple process templates.

      t's not uncommon under data analysis to find that interruption time between interventions (handoffs, changing priorities, having to attend meetings, etc.) rivals and often exceeds performance times at process steps.

      http://wp.me/pzzpB-KO

      I don't subscribe to the need for a customized app - we should today be at the commodity stage of maturity in respect of the management of operations management (mix of BPM taaks and ad hoc inserted tasks, hopefully within a post-relational dbms). Our group has ample evidence that all users need for task performance (aside from dashboards) is one split screen with a calendar on one side and a to-do list on the other.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 17 2016, 11:50 AM - #Permalink
    Resolved
    3 votes

    All business logic is prebuilt for quick build with easy configuration. Basic understanding of data base set up helpful but not coding. However there maybe need for complex manipulation of data support as an algorithm and here clever custom coding might be best bet. Howevesr this specific reguirement works directly under direction of the business driver.

    • karl walter keirstead
      more than a month ago
      David.... do you mean re prebuilt "business logic" having on hand an inventory of best practice fragments at a user menu of services that end users can, at run time, thread together, with the augmented facility of being able to insert ad hoc steps not in the menu, skip steps along process fragments, re-visit already-committed steps, terminating a process at any stage of processing?

      If so, are you happy with a menu that includes a mix of enterprise-specific best practices plus 3rd party launchable apps/algorithms?

      No worries about users picking/trying to execute the wrong menu items when you have pre and post conditions at the initial step and final step of each process fragment.

      Nothing in the notion of a menu of services to prevent incoming data from independently engaging processing, nothing to process fragments from daisy chaining themselves .
    • David Chassels
      more than a month ago
      Karl
      Our research established some 13 generic task types address all business logic. In the 70s audit involved talking to people and mapping the process so not rocket science! Business is actually quite simply once you understand how information is created and the associated actions. Once we cracked that rather simply reality and the linking for collaboration and rules then a new door opened as we began to understand the completeness of the capability .....Nothing is off the agenda including possibilities to skip steps, terminating as you mention to build it in but remember compliance and audit trail are important and require to be recognised when such flexibility is allowed.
    • karl walter keirstead
      more than a month ago
      We seem to have six pre-defined tasks in our mapping environment.

      However, our customers hold the view that a "task"is anything they invent that is able to post to a user InTray asking for work to be performed and proof of completion..

      They define "tasks" by giving them distinctive icons, names and by attaching forms needed to display and collect context/situation appopriate data.

      Each time they commit a task the Case that has the focus acquires a date/timestamp, user signature, plus the data that was on the form(s) they visited/recorded data on.

      I agree with you re "compliance and audit trail are important"

      When you let users basically do what they like you need to rely on pre-processing at best practice steps i.e. it is OK to engage this step?.

      Skipping steps quickly trips up best practice template instances and users - if a "ship" task posts to the InTray of the Shipping Department and the usual upstream QA has been skipped, the task reports "unable to proceed - no QA has been performed".

      The environment automatically builds a full audit trail at the time tasks are committed (date/timestamp, user, forms accessed, data that was on these forms). Once committed, no changes are allowed. If all is not right, the user has to insert an ad hoc task and re-perform/re-record as needed.

      The run time app also marks up the process map template instance to show which pathways/sub-paths were engaged so you can clearly see any arbitrary exits. Few users have the ability to exit from a template/instance but they can skip, insert ad hoc steps, forward record data.

      Bottom line, it's all about a proper balance between orchestration and governance. More of one means you need less of the other.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 17 2016, 03:32 PM - #Permalink
    Resolved
    5 votes

    Low-code, rapid application development is generally going to be preferable when the alternative is traditional, code-intensive, long-term application development. That's a pretty obvious statement, but not entirely helpful. It's rather like asking, “Which is preferable—the express train, or the local?” The worldwide economy rests upon this assumption: All else being equal, faster is better, cheaper is better.

    I don't agree with John's point about UIs. Build any UI you like, but you can still drive its behavior with BPM. Still, there are certainly applications for traditional coding, including:

    • Throw-aways: small but useful purpose-built tools that can be discarded once the immediate need has passed.
    • High precision applications: in particular, critical apps operating in real time. For example, I don't really see the guidance system for an F-35 running on BPM any time soon (BPM would nonetheless be perfect for the vast majority of ancillary apps, such as the pre-flight checklist, maintenance plan, weapons requisition, post-action reports, and so forth).

    Interesting, actually: those two cases are at the opposite ends of the criticality axis, leaving me wondering if the applicability of BPM to the universe of automation needs comprises a normal distribution. Are about 68% of applications whose criticality is within one standard deviation of the norm excellent fits for BPM, with the fitness decreasing as criticality increases or decreases from that point?

    Meh. Ignore me. My kid is taking stats. Last quarter he took astronomy and I kept wondering if the demand for BPM could be explained by multi-body gravitational dynamics*.

    *) Spoiler: No, it cannot.

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 17 2016, 06:25 PM - #Permalink
    Resolved
    2 votes
    Marvellous analogy by E. Scott Menter comparing types of trains and types of BPM! And the application of statistics seems like a good idea too.
     
    So now his thought process event has triggered a thought process of my own on the topic of statistics. And there is a sales angle! (Mr. Menter is certainly not responsible for whatever thoughtcrimes are about to be committed.)
     
    /triggerWarning("metaBPMspeculation")=on;
     
    STATISTICS OF BUSINESS PROCESS CONSTRUCTION
     
    Let's look at statistics that might apply to BPM-based automation. Getting meaning out of stats is very dependent on the definition of the thing that we are measuring. What is our "universe" (or domain) and the "subject of measurement" in that universe (or domain)? Let's see if we can tease apart "code" and "process" in the "universe of work automation" and see if the resulting distinction is useful.
     
    First, consider the possibility that BPM as "work automation artefact" should be the subject of our investigation. And consider that BPM concerns "conceptual models of processes" and their practical, instantiation as "executable technical artefacts". Given these assumptions, these are the topics then about which we can derive helpful statistics.
     
    WHERE DOES LOW CODE FIT IN THE MODEL?
     
    Where does low code fit in our model of work automation artefacts?
     
    It doesn't really! Instead the question of low-code becomes merely one of how we are supporting process modeling and execution, but process modeling and execution themselves exist on a higher level of abstraction. (Although from the business perspective, this "higher plane" is just practical business!)
     
    To make the point, let's go all the way into the black hole of coding and program in Assembler. The result might be very fast, but the cognitive load on programmers makes Assembler-based executable processes non-viable. Code is outside (as an input to) our process automation universe, and Assember itself is non-viable because the process use and business cases for Assembler are terrible.
     
    Here's a metaphor. We want to build a cathedral. We can build it out of bricks or out of toothpicks (comparable to building a process from a BPMS or from code). But in either case, the process has independent existence; process model and process executable "emerge", if you will, from the BPMS or the code.
     
    Conclusion (more stated than proved) Concerning Statistics And Process Automation: "Methods of construction" of business process automation artefacts are external to our subject of interest which is emergent reified and "directly usable" business process automation artefacts.
     
    AND THE SALES ANGLE
     
    The relationship between the two domains ("ways of building automation artefacts" and "the universe of business processes") is probably many to many, and the use cases and business cases for each are distinct. In times gone by, the immaturity of BPM technology made making this distinction difficult. But now with dramatic technology improvements the difference between the two are much more clear. (From a statistical perspective, there will be two distributions, not one.)
     
    What about the sales angle? From a sales perspective, we win insofar as we are living in the universe of business process technology, and not in the world of software and code. We win when we sell BPM where process is a first class reified capability of the tool -- and coding and programming is irrelevant to business-side deciders. (The implications for product or service positioning are rather dramatic; we have already seen this phenomenon in cloud-based offerings.)
     
    In case anyone is concerned, of course "one doesn't mention universes or reification on a sales call"! But then again, one should never have to mention code either . . . : )
     
    /triggerWarning("metaBPMspeculation")=off;
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, May 18 2016, 10:17 AM - #Permalink
    Resolved
    3 votes

    Minor update to deleted posting . . .

     

    Difficult question as BPM continues to be different things to different people.

    I read over “What is BPM?” and one key definition that needs to be kept in the forefront when commenting on low-code (of what?) seems to be:

    “Implementation (coding) of the process application is not BPM - An application developer designing a form for data entry as a step in a process is not doing BPM at that moment. Once the “to-be” process has been adequately spelled out, the actual implementation of the application that supports it is no longer actively engaged in improving the process. A small caution here: applications are often developed incrementally — show to the customer, get feedback, improve, and iterate — and the process may be improved incrementally as well. Those incremental improvements should be included as the activity of BPM, but the activity of implementation of the application is not BPM. The criteria is clear: if you are actively and primarily engaged in improvement of the process, then it is BPM, otherwise it is engineering”.

    - Not data collection forms at BPM steps

    - Not actual implementation of the app that supports BPM

    - Not run-time execution of BPM template instances in, perhaps, an Adaptive Case Management app.

    Looks like low-code BPM refers to coding in the process mapping environment, exclusive of the design of data collection forms (as above) that process mappers park at steps and exclusive of the design of rule sets that may be embedded in forms (given that forms design is not BPM).

    Likewise, application development (e.g. the run-time environment hosting BPM templates\instances and the UI for the run-time environment) is not BPM.

    This leaves low coding needed within the mapping UI and rule set “code” needed at branching decision boxes in process maps.

    I can’t think of any other need for “coding” when mapping processes so the entire focus of low code seems to go to rule sets at branching decision boxes and rule sets at loopback constructs.

    An expanded list of perceived coding needs from readers would be helpful.

    Within the mapping environment we can add that in respect of complex algorithms, someone has to do coding somewhere.

    The options are to use some computer language that allows you to invent a new process step that performs the required calculations but why do this when you can from any process step, link to and launch an external app that carries out the calculations?

    For complex algorithms I don’t see low code working for either of these options, so it’s not so much a question of whether low-code BPM is the best option, but whether it is an option. I say no.

    The problem with launching external apps to avoid coding within the mapping environment is that many external apps do not follow the rules of interoperability – i.e. some external apps cannot import and cannot export. If they are able to import/export, you typically have to write a formatter on export from the mapping environment so that the app can read the exported data and you need to write a parser in order to import data from the app. Let’s not forget the data transport and whether the paring of your BPM app with each external app accommodates push or requires pull. Few today are willing to allow direct writes at databases because of security issues so you end up with a database in the middle where publishers push and subscribers pull, each at their own frequency (real-time, fast-batch, batch).

    Formatters/parsers are complicated unless you have a generic data exchanger where publishers can use their own data element naming conventions and subscribers can use their own data element naming conventions.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, June 21 2016, 10:52 AM - #Permalink
    Resolved
    1 votes

    Sorry I missed this debate last month! Lots of very long answers. Could this be a reflection of the newness or threat of the approach in this context?

    I was one of those 'kids' in the business unit's shadow IT building useful systems that 'IS' couldn't get to. I say Low-Code solutions are an alternative that should be considered if feasible. (What would motivate someone to omit a viable alternative in their selection?) And, it should be selected if it meets the business project objectives within the constraints better than the others. That, obviously, includes the use case of a requirement for a simple system to help quickly.

    Now, does anyone know of a real good low-code solution?

    • John Morris
      more than a month ago
      Hi George, I'll add "situation application" software here as a term -- might help anyone searching for "situational" to find this discussion. I sold RAD for quite a while when the big four RAD tools were Powerbuilder, Delphi, Progress and Magic -- plus about 100 other competitors. There are even more solutions now, with the additional categories of cloud and open source and powerful frameworks. Everyone seems to think the world needs another software platform.

      The challenge is, as you have no doubt experienced, you can get 80% of the way quite easily with low code. It's the last 20% that is hard -- and also this part of the application is likely quite important from a business perspective. Another choice issue is career management -- developers don't want to be slotted into a niche environment of course.

      And lastly there's the question of development platform foundation -- is it in fact BPM, as per this discussion? Or a general development platform in which however BPM is not a first class construct?
    • David Chassels
      more than a month ago
      Hi George
      Yes we built such capabity with 20 years RandD working with early adopters and direct input from users; IT not involved. One early adopter a UK Government agency handling grants and claims. Over 15 years constant change class leading efficiency as users think of better ways and handling ever changing needs. Total cost £2m other agencies well over £250m doing same. Just converting to web from client server over half of over 500 UIs being converted cost less than £50K. UK Government got too many vested interests; classic disruptive challenges...But now at last market moves in our direction and we prepare to distribute globally with huge global contract and effective unlimited funding.....near there...it's going to be fun...!
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, July 17 2016, 02:23 PM - #Permalink
    Resolved
    0 votes

    I have absolutely no idea why "low-code" is even being talked about in an age when we've moved beyond zero code and into zero UI. Think about bots and interacting with them over an instant messaging channel. Billions of people across the world already do messaging, so if we are still talking about "low-code" which needs IT - there's something "very wrong" with the industry.

    I believe the status quo of the future is truly about zero code and even further - zero UI. We are thinking hard about both, and then the industry will finally embrace new markets like SMB (for whom BPM is not accessible) and new use cases - which do not need an IT or consulting army.

    Perhaps the real question should be - why aren't we already talking about BPM with zero UI?

    • karl walter keirstead
      more than a month ago
      I get it about bots and instant messaging channels but the reality of operations management in many industry areas is that some tasks must be performed by humans.

      Humans need guidance from background BPM, they need decision support from data in Case Histories and from decision support tools

      They need governance from the environment to prevent extreme, unwanted excursions away from corporate"best practices"

      Clearly, they need next-in-line tasks to post, they need access to HXs, access to support tools and the "task planning, monitoring and control" UI for this can be close-to-zero code but a zero-UI, assuming I understand what you mean by this, is not an option.

      The core component of any ACM/BPM operations management environment is R.A.L.B (resource allocation, leveling and balancing).

      Tasks from background BPM post, users add ad hoc tasks, Users performing tasks need to be able to micro-scheule their tasks and supervisors need to be able to level and balance tasks across users. One phone call from a customer can change the day schedules for one or a number of users.

      It's not unusual to find each user with 20 tasks to perform each day - healthcare is a good example i.e. 20 patients, each traveling along their own private care pathway (a combination of sequenced steps and ad hoc steps) each at a different step.

      From an overall operations productivity standpoint, time gaps between patients\steps can rival task performance times (particularly on the patient side).

      I have no problem with a no-code UI (with one exception) - all you need is a split screen with a calendar on one side and a task list on the other.

      See various articles on the design of UIs for operational efficiency and effectiveness.

      https://kwkeirstead.wordpress.com/2013/12/09/ecase-iii-the-ui-makes-or-breaks-it/

      What's the one exception? Seamless interconnectivity with local and remote apps.

      See
      https://wordpress.com/post/kwkeirstead.wordpress.com/1827
    • Amit Kothari
      more than a month ago
      Thanks for the comment, Karl. I agree with some of this - in particular that the zero UI part is possible for the "doer" of the task. Managerial functions can still be done with a zero UI bot, but may be better serviced with some level of UI - in particular for load-balancing resources.

      What's more interesting from my point of view is not the features/capabilities - it's the use cases that zero UI opens up that were previously impossible or inaccessible. Adoption is a critical concern which goes away with zero UI. That's where the huge opportunities lie. You can actually put something out there very quickly for a use case in which nobody doing that process would have the the patience to learn a UI or care (like a customer).
    The reply is currently minimized Show
Your Reply

Join the Discussion

Want to join the discussion?

Login, or create an account to participate in the forum.

Top Participants

Dr Alexander Samarin
276 Replies
26/09/2016
David Chassels
269 Replies
23/09/2016
Emiel Kelly
221 Replies
26/09/2016
Bogdan Nafornita
209 Replies
27/09/2016
E Scott Menter
182 Replies
27/09/2016