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?
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!
In theory, BPM is feasible as a management approach using just pencil and paper, so there are really two questions here.
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.
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!
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
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!
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!
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)
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!
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!
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!
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!
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