Resolved
5 votes

I know we have circled this topic a few times, but I thought this was a good question to finish out an excellent year on the Forum with. Prompted by an excellent write up on this blog, Zero-code BPM is not a Myth, what do you think?

Tuesday, December 29 2015, 09:59 AM
Like
1
Share this post:
Responses (14)
  • Accepted Answer

    Tuesday, December 29 2015, 10:08 AM - #Permalink
    Resolved
    2 votes

    Not 'til Siri or Cortana hit singularity. I wonder how good they'll be at patterns.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, December 29 2015, 10:20 AM - #Permalink
    Resolved
    4 votes

    I think the author meant "zero-code-in-generic-programming-language" (i.e. Java, C#, python, etc.) not just "zero-code" because some DSLs are mandatory to express processes (i.e. logic coordinaiton). A breakthough will be a set of practical patterns which are ready to used (similar to cooking recipes). Thus any processes will be constructed from a few (maybe slightly modified) practical patterns.

    Happy BPMing in 2016!

    AS

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, December 29 2015, 10:25 AM - #Permalink
    Resolved
    6 votes

    In theory, BPM is feasible as a management approach using just pencil and paper, so there are really two questions here.

    1. How much process automation does BPM need to be feasible in practice?
    2. How much of that automation is only possible with custom code?

    Both questions hinge on integration, as do many IT projects. We’re used to the idea that IT projects always end up involving custom integration, but that’s because we’re used to IT landscapes that always include custom developed systems.

    Zero-code BPM becomes feasible in principle when it becomes organisations can meet all of their IT needs using standard SaaS products, such as Salesforce, Google Docs and (of course)  Effektif for BPM. That’s only the first step, though: zero-code only becomes feasible in practice when you’re using a combination of SaaS products that all integrate with each other.

    A likely objection to this scenario is that large organisations will always continue to do custom software development, creating the need for custom integration. However, that might only be true of the very big companies that can afford traditional (very expensive) BPM platforms. That’s why I believe that only small and medium-sized organisations will ever be flexible enough to run their businesses on standard SaaS products (that integrate with each other).

    Until then, small and medium-sized organisations (who can't afford custom software development), will continue to get by using zero-code tools that don’t (yet) integrate with everything else they happen to use. They’ll continue to rely on spreadsheets. And some of them will use  Effektif as well :)

    Meanwhile, we’ll continue to make steps in the right direction by reducing the cost of integration (e.g. with technical architecture approaches like REST and microservices) and improving the built-in integration between standard tools.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, December 29 2015, 10:28 AM - #Permalink
    Resolved
    4 votes

    This is not an "if" but rather a "when" question. The current low code initiatives can be seen as (very) early (stone age) stage prior to zero code; but they still require technical creators, let alone they are "manageable." The statement Smith and Fingar use about spreadsheet use is an excellent example of this. Why do business people bet their lives on Excel and Powerpoint? Precisely these apps are the major competition of most BPM initiatives (not in execution, but in managing) and there is a reason for it.

    Agreeing fully with Patrick and Alexander here: I believe it's a matter of much improved AI. So, yes, pattern recognition, creation, learning, self-repairing intelligent parts etc. Look at developments like (realtime) process mining: Combine this with the above and I believe we're getting close.

    I wish you all a healthy, great and inspiring 2016!

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, December 29 2015, 11:31 AM - #Permalink
    Resolved
    4 votes

    That's an easy one: YES! But then I would say that as founder of Omny Link wouldn't I?

    However, it's worth noting that just as not every business user today is prepared to be sufficiently detail-orientated to produce and maintain complex spreadsheets nor will everyone embrace the process and decision automation possible through low or zero code. Similarly (before the spreadsheet junkies rejoice) I suspect there will be less room in future workplaces for people without these 'technical' business skills just as there fewer secretaries today than before word processing and email enabled business users to perform those functions. Certainly there are still secretaries in professions such as legal or medical where the 'business' user can command high hourly fees but not in the broad swathe of general business management.

    On a side note, I think the proponents of low/zero-code seem a larger proportion of commenters this week than often: should I infer a correlation between low coders and those working when many organisations are shut down?! In any case to you all I wish a prosperous New Year - Tim

    References:

    1. http://omny.link
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, December 29 2015, 11:35 AM - #Permalink
    Resolved
    2 votes

    Zero code has been our mission with 20+years R&D and we cracked it. Sure if you want to do clever complex manipulation of data (algorithms etc) might be best in hands of “coder” but basically build and change is now in hands of business people. This research paper explains “how” this has been achieved. http://www.igi-global.com/chapter/object-model-development-engineering/78620 Good news no patents so have a go……! Just to remind all this was Bill Gates vision in 2008 http://www.infoworld.com/d/developer-world/gates-talks-declarative-modeling-language-effort-386 where he announced plans to build a declarative modelling capability reducing the need to code calling it the “holy grail of development forever”, “the dream the quest…. but would be in a time frame of 5 to 8 years.” So 2008+8 = 2016!

    Now to be clear to build enterprise level BPM driven applications requires the following contained in one build environment!

    • Process engine to ensure all works to plan
    • Rules engine reflecting real world of compliance
    • Calculation engine automating system work
    • State engine Real time feed back from any point
    • BPM focus on people and their processes
    • Workflow everything connected in right order
    • Audit trail, events, escalations = control with empowerment
    • Rapid prototyping user involvement in build
    • Time recording supports activity based costing
    • Real time reporting become predictive
    • Prebuilt configurable dashboard operational visibility
    • Build mash ups one screen multiple data sources
    • Linked intelligent Ajax grids enter data only once
    • Roles and performers people and machines recognised
    • Management hierarchy see who does what and when reallocate work
    • Orchestrating business processes and legacy as required in single environment a 21st century approach = agility in software
    • Call Web Services wrapped up in a process
    • User interface dynamically created linking people, roles, task type and data via forms for specific instances, web or client server
    • Content handler and in memory work capability to ensure high performance.
    • Pre-built templates for custom documents, letters, e-mails, messages etc dynamically populated with instance specific data and edit capability in browser
    • Process and task versioning control

    Whilst build takes place in easily an understood by business Graphical Process Designer our experience with early adopters suggest users or the knowledge workers doing the work are not really interested in building an application. Let’s remember all processes are based upon collaboration to achieve the desired business outcome.

    Users love the fact what they articulate is built in hours exactly as they describe. Where change is very likely in a process you can build in such flexibility and allow users to change. As ever the current mess of legacy needs to be addressed and we think of the wrap of a greenfield “BPM” driven Adaptive Applications around the brownfield of legacy; use it as required do not try to change such legacy; v expensive! Rule of thumb for time to build is one man-day per UI in the process. The complete data centric approach linked to all the above attributes allows intelligence within processes and more will come,

    It will be a new journey and highly disruptive as big vendors, their ecosystem of sellers and coders will not welcome! But it IS coming and will be driven by business people with resultant “assurance” that results of all activity is encapsulated in publication of financial accounts; something long over due!

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, December 29 2015, 12:50 PM - #Permalink
    Resolved
    3 votes
    Zero code has always been the goal for BPM and is already available for simple processes. Most or all BPM applications already do this. BPM evolution has always been about moving up the process value chain or along the process spectrum, increasing zero code capabilities to handle more complex processes.
    This discussion though can't ignore "no-code BPM" or on demand processes, where there's no need for a process designer or business analyst, which I think will become more relevant.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, December 29 2015, 01:23 PM - #Permalink
    Resolved
    6 votes

    Before 1900 all BPM was zero code. .

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, December 29 2015, 01:27 PM - #Permalink
    Resolved
    2 votes

    As the author of the cited article, naturally I'm in agreement with it :)

    I would like to clarify one point. Clearly the part of BPM that often requires coding is integration. The question is whether for small and medium businesses will standard SaaS integrations be a substitute for custom integration?I think the answer to this is 'no'!

    Let's take an example of a Blog Post process that a user has evolved to faciliate blogging (in a zero-code tool, say https://tmail21.com ). Now a standard SaaS integration can be done from (say)

    - TMail to Slack (post notifications, receive chat commands)

    - TMail to a Task Management tool like Asana or Basecamp (sync tasks)

    - TMail to Milestone tracking tool (integrate milestones)

    - TMail to email (send notifications)

    etc.

    Notice that these integrations are working at the generic process level with generic process primitives (i.e. notifications, tasks, milestones etc). None of these standard integrations could be done with TMail at the Blog Post process level. For example, the Blog Post process may involve coming up with a set of Tweets to promote the post. This would require custom integration because inherently, TMail21 has no concept of a Blog Post or Tweets regarding a Blog Post. The specific user evolved their own Blog Post process which require posting tweets to promote the article. So some custom integrations for a Blog Post processmay be

    - TMail to Twitter post scheduled Tweets (in the context of the specific user's Blog Post process)

    - TMail to Wordpress post article (in the context of the specific user's Blog Post process)

    - TMail to email.. send email to influencers (in the context of the specific user's Blog Post process)

    Notice that the TMail-to-email appears as both a generic integration (generic notifications) as well as a custom integration (The custom process has a list of influencers that need to be emailed).

    Without facilitating this user-level, process-specific integration a zero-code tool would be highly limited. And so this where the concept of 'Code-later' in the cited article comes in. The standard integrations would be done by TMail21 itself. However the user-specific custom integration (eg. post Tweets from Acme Corp's custom Blog Post process to Twitter) would need be done by the user (i.e Acme Corp in this example).

    The key to the code-later concept is that custom processes can be evolved without worrying about integration. Later, if needed, when the process has been hardened and is being scaled, custom integration can be done in a non-intrusive manner.

    You can see more of this Blog Post scenario if interested at the bottom of this page.https://tmail21.com/why-tmail/lean-processes/

    Have a great 2016 everyone!

    • John Morris
      more than a month ago
      Per 'the part of BPM that often requires coding", Volker Stiehl's work on separating business process from integration is a methodological way of achieving more with current BPM technology -- because the we separate headache-inducing integration questions from strictly business-oriented process questions.

      http://www.springer.com/gp/book/9783319072173

      A great 2016 Ranjit! Great question for the community!
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, December 29 2015, 01:34 PM - #Permalink
    Resolved
    3 votes

    Yeah, so, apparently we're all providing links to our products today? Great, here you go.

    With that done, I'll point out that anybody can (and, apparently, does) claim their product provides "code-free BPM' because they simply define "BPM" as that thing their product implements. So proclaiming "hey we do that today!" adds little to this particular conversation.

    The original post (which to be fair was also self-promotional, perhaps leading to the tone of this particular thread) simultaneously evaded answering the essential question while also highlighting a gap in the way we talk about BPM and process. Increasingly, BPM is actually about the rapid creation of custom business applications. At the same time, there are those—including, it seems to me, the authors of the referenced post—who think of BPM as a rather nebulous kind of collaboration platform, one whose purpose is to help knowledge workers be more efficient about, well, whatever it is they're trying to accomplish.

    The latter isn't a terrible goal—it's just not BPM. Frankly, Slack can accomplish many of the same goals, as can Exchange.

    BPM is for creating and operating business applications—not just "knowledge worker" apps, but true business applications, with all that implies (including customer-facing interfaces, supply chain links, data virtualization, federated authentication, and on and on and on). In order to make that task easier, BPM platforms will always make certain simplifying assumptions and abstractions. Traditional coding, then, will ideally be limited to those instances in which those assumptions need to be temporarily suspended, or those abstractions peeled away.

    Thus, BPM will never mean ZERO code, because the trade-off for simplicity is a certain loss of ability to do unusual or complex things. However, as with so much in this world, the 80/20 (or perhaps 98/2) rule applies: you don't have to have zero code to make a substantial and lasting improvement in expense reduction, risk mitigation, and market responsiveness.

    Happy new year to all!

    • Ranjit Notani
      more than a month ago
      Scott,
      I think your comment gets to the heart of the matter. I'd like to address two points in particular

      1) Is BPM fundamentally a (different kind of) app development tool/approach?
      It certainly could be if defined that way. The question is how it would fare compared to traditional apps.

      You cite Supply Chain as an example. As a co-founder of a company (One Network Enterprises) which has over 100k customers (including many Fortune 100 companies) and by virtue of having been in the Supply Chain space for over 20 years I can speak with some authority on this.

      Very few of our customers use traditional BPM as the CORE of their supply chain app strategy. Supply Chain has become just too sophisticated for traditional BPM. Core supply chain 'processes' (apps) include Stochastic Demand Planning, Multi-tier constraint based replenishment, Optimized sourcing, dynamic order promising and repromising based on ATP and Allocated ATP, Finite shop-floor scheduling, mark-down optimization, dynamic load consolidation, Highly coordinated flow-through distribution centers, near-real time planning/execution coordination etc. etc. These are not peripheral to Supply Chain, but are the absolute center of it. If one tried to build Supply Chain 'apps' in traditional BPM, one would get nowhere near 80/20 or 98/2. Maybe other application areas are different, but I suspect the sophistication bar in all areas will be pretty high.

      2) Is BPM geared towards knowledge work doomed to be a 'nebulous collaboration platform'?
      I agree that BPM geared towards knowledge work is not as standardized as BPMN etc. Hence there is a natural diversity in opinions and approaches on the matter. But I believe standardization and convergence will occur as we all learn what works and what doesn't. The question is there something in between Slack/EMail/Spreadsheets on the one hand and Specialized Apps on the other.

      Naturally, I believe the answer to this is 'yes'. In my example above, you could try to run a Blogging process in Slack/EMail, but I think you would quickly run into the following problems
      a) Where would you store the state of the Blog process (article, title ideation, promotional tweets, process state machine, promotion state) etc. etc.
      b) How would you evolve the state in a coordinated human-meaningful or machine-meaningful manner?
      c) Where would you track tasks coordinated with the process state?
      d) How would you templatize the process you've evolved? How would you instantiate these templates.
      e) How would you search the process state in a meaningful manner

      I think if one actually tried to run a relatively simple process like Creating a Blog Article on a chat tool like Slack one would quickly get frustrated.

      Having said that, I do think it is incumbent on proponents of 'Zero-code BPM' and 'BPM geared towards knowledge workers' to drive towards greater standardization.

      Regards,
      Ranjit
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, December 30 2015, 12:07 AM - #Permalink
    Resolved
    4 votes

    I can't say NO for the "ever" part of the question, although I believe the current status of such a solution is vaporware.

    However, I have this feeling that any platform that enables zero-code on the front-end will have a bucketload of code in the back-end and an army of developers. So - who are we kidding here?

    Happy New Year everyone!

    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, December 30 2015, 01:19 PM - #Permalink
    Resolved
    2 votes

    Just when you think BPM.com is taking a well-deserved holiday breather -- it sucks you back in! What a pace!

    And what a question! The question of zero-code BPM is one way of looking at the most important questions related to BPM technology.

    Here are four ways of rephrasing the original question concerning the feasibility of zero-code BPM

    1. BPM BUSINESS UTILITY -- Can BPM software technology support the direct creation and evolution of software technology-based business processes, by business people, likely in real time?

    2. BPM GENERAL TECHNICAL CAPABILITY -- Can we achieve all our process semantic and performance goals goals just with BPM software?

    3. BPM SPECIFIC TECHNICAL CAPABILITY -- Does BPM deliver business process artefacts as first-class citizens of business technology

    4. BPM TECHNICAL LIMITATIONS -- Or because of the limitations of BPM software, are we condemned to always stepping out to code for anything beyond the trivial -- i.e. the anything beyond the commodity process?

    In answer to the original question, I say "yes", it is possible to use some BPM products today to build any part of one's business processes, including the non-standard parts.

    It should be noted however, that currently such use requires uncommon management commitment and discipline. (The "uncommon management commitment" part hides a sales opportunity . . . )

    It's possible to say yes to the original question in part based on defining zero-code BPM according to what's essential about BPM technology.

    BPM software only concerns automation of the work of business. AI is irrelevant where the specific question is concerned. BPM-as-control versus BPM-as-guidance is irrelevant to the question. The fact that there is code behind the scenes is irrelevant. The fact that one might need to use code to support integration is irrelevant. The fact that one might code "something" "once-in-a-while" is irrelevant.

    BPM is THE technology of work. And along with other irreduceable technologies (e.g. business rules), explicit BPM will, by definition, increasingly be selected as providing THE technology platform for businesses and government process operations.

    The persistence of code is only an artefact of the maturity of BPM technology. There is no technical reason why BPM technology will not make code irrelevant for most business process construction. Business management will find the "advent" of better BPM both exciting and daunting at the same time.

    That's a happy thought for 2016!

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, December 31 2015, 06:13 AM - #Permalink
    Resolved
    2 votes

    A New Year wish of a BPM-suite: I want to become an essential component of corporate unified business execution [see ref1] platforms.

    Recorded by AS

    The reply is currently minimized Show
  • Accepted Answer

    Ian Gotts
    Ian Gotts
    Offline
    Thursday, December 31 2015, 06:18 AM - #Permalink
    Resolved
    7 votes
    BPM code is proportional to process complexity. And zero is a very small number.
    Like
    1
    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
277 Replies
28/09/2016
David Chassels
270 Replies
28/09/2016
Emiel Kelly
222 Replies
28/09/2016
Bogdan Nafornita
209 Replies
28/09/2016
E Scott Menter
182 Replies
28/09/2016