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, [url="https://tmail21.com/blog/zero-code-bpm-is-not-a-myth/"]Zero-code BPM is not a Myth[/url], what do you think?
Not 'til Siri or Cortana hit singularity. I wonder how good they'll be at patterns.
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!
- Dr Alexander Samarin
- 1 year ago
- Peter Hilton
- 1 year ago
In theory, BPM is feasible as a management approach using just pencil and paper, so there are really two questions here.
[list="1"]does BPM need to be feasible
How much [quote][i]process automation[/i]
How much of that automation is only possible with custom code?
Both questions hinge on
[i]integration,[/i]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
[i]in principle [/i]when it becomes organisations can meet all of their IT needs using standard SaaS products, such as Salesforce, Google Docs and (of course) [url="http://www.effektif.com"]Effektif[/url] for BPM. That’s only the first step, though: zero-code only becomes feasible
[i]in practice [/i]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 [url="http://www.effektif.com"]Effektif[/url] 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. [url="http://www.igi-global.com/chapter/object-model-development-engineering/78620"]http://www.igi-global.com/chapter/object-model-development-engineering/78620[/url] Good news no patents so have a go……! Just to remind all this was Bill Gates vision in 2008 [url="http://www.infoworld.com/d/developer-world/gates-talks-declarative-modeling-language-effort-386"]http://www.infoworld.com/d/developer-world/gates-talks-declarative-modeling-language-effort-386[/url] where he announced plans to build a declarative modelling capability reducing the need to code calling it the “
[i]holy grail of development forever”, “the dream the quest…. but would be in a time frame of 5 to 8 years.” [/i]
[i]So 2008+8 = 2016! [/i]
Now to be clear to build enterprise level BPM driven applications requires the following contained in one build environment!
Process engine [quote][i]to ensure all works to plan[/i]
[i]reflecting real world[/i]
[i]of compliance [/i]
[i]automating system work [/i]
[i]Real time feed back from any point[/i]
[i]focus on people and their processes[/i]
[i]everything connected in right order[/i]
Audit trail, events, escalations
[i]= control with empowerment[/i]
[i]user involvement in build[/i]
[i]supports activity based costing[/i]
Real time reporting
Prebuilt configurable dashboard
Build mash ups
[i]one screen multiple data sources[/i]
Linked intelligent Ajax grids
[i]enter data only once[/i]
Roles and performers
[i]people and machines recognised[/i]
[i]see who does what and when reallocate work[/i]
Orchestrating business processes and legacy as required in single environment
[i]a 21st century approach = agility in software[/i]
Call Web Services
[i]wrapped up in a process[/i]
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!
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.
Before 1900 all BPM was zero code. .
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
[i][quote][b]will standard SaaS integrations be a substitute for custom integration?[/b][/i][/quote]I think the answer to this is 'no'!
Let's take an example of a
[b]Blog Post process[/b]that a user has evolved to faciliate blogging (in a zero-code tool, say [url="https://tmail21.com"]https://tmail21.com[/url] ). Now a
[b]standard SaaS integration[/b]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
[i][quote][b]generic process level with generic process primitives [/b][/i][/quote](i.e. notifications, tasks, milestones etc). None of these standard integrations could be done with TMail
[b][quote][i]at the Blog Post process level[/i][/b][/quote]. 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 process
- TMail to Twitter post scheduled Tweets (
[i][quote][b]in the context of the specific user's Blog Post process[/b][/i][/quote])
- TMail to Wordpress post article (
[b][quote][i]in the context of the specific user's Blog Post process[/i][/b][/quote])
- TMail to email.. send email to influencers (
[i][quote][b]in the context of the specific user's Blog Post process[/b][/i][/quote])
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 '
[b]Code-later[/b]' 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.
[i][quote][b]Later[/b][/i][/quote], 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.[url="https://tmail21.com/why-tmail/lean-processes/"]https://tmail21.com/why-tmail/lean-processes/[/url]
Have a great 2016 everyone!
Co-founder and CTO, One Network Enterprises
A great 2016 Ranjit! Great question for the community!
- John Morris
- 1 year ago
Yeah, so, apparently we're all providing links to our products today? Great, [url="http://www.bplogix.com"]here you go[/url].
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, [url="http://slack.com"]Slack[/url] 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 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.
- Ranjit Notani
- 1 year ago
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?
[i][quote][b]GENERAL[/b][/i][/quote] TECHNICAL CAPABILITY -- Can we achieve all our process semantic and performance goals goals just with BPM software?
[i][quote][b]SPECIFIC[/b][/i][/quote] 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 "
[b]yes[/b]", 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.
[b][quote][i](The "uncommon management commitment" part hides a sales opportunity . . . )[/i][/b][/quote]
It's possible to say yes to the original question in part based on
[u]defining zero-code BPM according to what's essential about BPM technology[/u].
[i]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.[/i]
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
- Page :
However, you are not allowed to reply to this post.