1. Peter Schooff
  2. BPM Discussions
  3. Thursday, April 06 2017, 09:53 AM
  4.  Subscribe via email
To finish out the week focused on bpmNEXT and the future of BPM, what do you think are the most overhyped and overblown technologies that will have little to no impact on BPM?
Patrick Lujan Accepted Answer
Blog Writer
Collectively I think the vendors themselves have way more impact and influence than do the analysts or the user community. Where they, with their install base, take the industry is where most everyone goes. That being said, listening to which message(s) which vendor(s) are saying I think low code and "citizen developers" will amount to bupkis.
there is clearly a "personal power hacks" market out there, but I think it's nowhere near the future of BPM that it's claimed to be. Building enterprise apps requires at least some level of systems thinking. That's very far away from the "look, ma, no brains" message that low-code vendors tend to pass to their customers.
  1. Bogdan Nafornita
  2. 3 weeks ago
@bnafornita yyyep.
  1. Patrick Lujan
  2. 3 weeks ago
With regard to "low code", vendors have been doing "low code" for decades (RAD/ O-O) for their "BPMs" and that is a big deal because the alternative is to take 3-5 times longer to develop a workflow/workload management environment.

End users of such systems are themselves already at no code but they need their IT departments to code rule sets and to interface to/from microservices.

If the users have a need for ancillary apps not on the market, they have to commission their IT or outsource to develop these.

"Citizen developers (for sure)" will amount to nothing
  1. Karl Walter Keirstead
  2. 3 weeks ago
Watch out, though, because here are two examples of degeneration of standards

1) Pro camera manufacturers (and their customers) are having a hard time because end users no longer seem to want/ need quality - it seems perfectly OK today to tape a wedding using a smartphone as opposed to hiring a professional videographer. I asked one couple how they felt about jittery videos where most of the scenes are over/underexposed , color balance is off and the sound is dreadful. Not a problem, they responded, it's no worse that the selfies we send/receive each day.

2) critical path diagrams that used to be de rigeur but are being skipped today by some organizations who feel it is OK to plan/monitor/control using to-do lists only.

Since building process maps seems to be "difficult", one possible customer scenario is "why bother to map?", particularly when many workers really don't care about organizational efficiency/effectiveness.
  1. Karl Walter Keirstead
  2. 3 weeks ago
+1 @Patrick, @Bogdan, @Karl re: comments concerning "citizen developers" and "low-code". Along with the reference to the requirement for "systems thinking", one can apply the term "magical thinking". Systems thinking includes not only strictly technology, but also business analysis. Alarm fatigue is a persistent multi-factoral problem centered around the failure to envision, fund and do business analysis.
  1. John Morris
  2. 3 weeks ago
Low-code/no-code and citizen developers are overhyped, but there is some truth at the core of them. It _is_ easier and faster to develop even substantially complex applications by starting with a BPM platform rather than a C compiler (or, as we used to say, a pointy magnet and a steady hand). And that ease of development (and maintenance) does represent tremendous value. But of course it's never going to be the type of thing where Bob who spends summers working on the loading dock between sessions at high school is going to sit down and start generating applications instead. (...which is a shame, because before long Bob and everybody like him are going to need to find jobs, and there's been shockingly little progress in figuring out what we're going to do about that...).
  1. E Scott Menter
  2. 3 weeks ago
I think Scott Mentor hit it right - there are always new or correct or closer-fit abstractions that improve productivity because they're a better tool for the specific problem you're solving. (e.g. the way Java handles memory management vs. C++ in the old days). But getting to no-code without leaving behind complex thought has been a windmill for tilting. Most of the no-code solutions I've seen look as complex as code :) (not that there's anything wrong with that, as Seinfeld would say)
  1. Scott Francis
  2. 3 weeks ago
The economics of low-code and RAD is this: you get 80% of where you want to go quickly. The last 20% is out-of-scope for the tool.
Now consider that the 80% is the commodity part of your business, i.e. the less complex part where there are probably apps pre-built with implicit data structures, processes and rules and UX. But you get most of your margin (in a competitive marketplace) from the last 20%, where you can't buy off-the-shelf.
That last 20% is by definition the more complex part -- where you achieve competitive differentiation. But being more complex, it's also where simple tools fall down. So, why bother? The cost/benefit often doesn't add up when you look at it this way.
  1. John Morris
  2. 3 weeks ago
@Scott Francis: "Most of the no-code solutions I've seen look as complex as code" - it's actually worse if you think about what's easier to debug :-)
  1. Bogdan Nafornita
  2. 2 weeks ago
Peter Whibley Accepted Answer
I vote for Virtual and Augmented Reality. Good for gaming and some other niche use cases but will go the same way as 3D TV in terms of widespread adoption.
Bogdan Nafornita Accepted Answer
Besides low-code, I'd venture and say that AI/ML still needs to prove outside its current pattern-recognition problem space (where it performs excellently). Business process data has no natural ideal state that any other state can be optimized towards. Also, except for massive consumer businesses, it may not have enough volume / velocity to warrant a juicy enough use case for enterprise process deployment. It may happen in the mid term but now it's just not there.
I'd say something about blockchain as well - but I may be biased here by my customer size - I cannot yet see the compelling case for immutable public ledgers in the enterprise. Enterprises have a gazillion reasons to lie and hide, most of the times even more so than humans - they will likely sit on the fences on this one for a while.
Managing Founder, profluo.com
John Reynolds Accepted Answer
Overhyped Technologies?
Isn't that a synonym for Competitors' Technologies? ;-)

TGIF :-)
Join @John - Overhyped Technologies? It is a synonym for "I-do-not-know-how-to-use-them-together". See [1].

A few examples (sorry @Bogdan):

AI - business process is already a model and you got a lot of data (including results) thus one can validate the model, validate its use and make adjustments.

Blockchain – a perfect multi-owners records management which allows BPM to be placed between various business partners.

Low-code – good DSLs and architecture can reduce amount of code-to-be-written (and duplicated)

AR/VR – is it a way to access your processes faster, better and cheaper? Think about GPS.

  1. https://en.wikipedia.org/wiki/The_Fox_and_the_Grapes
Per AR/VR and AI/ML -- at least in field service both these technologies are already making an impact.
  1. John Morris
  2. 3 weeks ago
I knew I was going to get challenged by you, Alex :-) So here's my take:
AI on process model data - yes, but it may not be that much data, plus there's algorithms that do this pretty well already in the process mining space. Of course could be improved by AI, but it's not going to get that magical. AI excels on nonlinear, nonexplicit relationships - not exactly the case with explicit process models.
Blockchain - great - do you have any examples where this has been done and could not be implemented by other means in the enterprise space, where anyway access control and encryption are a given?
Low-code - yes, for dev purposes it's clear, we invest in this everyday. But for regular non-programmers to develop fully-fledged process enterprise apps?
  1. Bogdan Nafornita
  2. 2 weeks ago
Kay Winkler Accepted Answer
Sadly, we have seen that technologies focused on process data analysis, statistical pattern recognition, projections and simulations have had little impact in real life implementations.
That's not say that these features of an (I)BPMS are useless - all to the contrary - they absolutely have the potential to enrich any BPM initiative. However, most end users don't dedicate the sufficient resources to take advantage of these technologies. Ironically, at the same time, these same users put said technologies as obligatory requirements on any RFP (which in turn motivates vendors to engage in hype cycles...).
Same observations we made with features around social BPM, process rules portals on others.
NSI Soluciones - ABPMP PTY
Auto-building of Case Histories where each intervention at a Case results in a date/timestamped & user "signature" entry with a load on click of the forms that received data with the data that was recorded goes a long way toward "process data analysis" in some application/industry areas.

Healthcare is an example where a simple at-a-glance inspection of the patient "e-chart" gives the physician a lot of information of assistance to "what should the next intervention be"

I suppose a similar consult at the history for trouble tickets tells the support rep what kind of customer they have on the line (frequent support desk caller, many "problems" that turn out not to be problems, requests for custom features that never get authorized, etc.)

Auto-histories require NO resources to build.
  1. Karl Walter Keirstead
  2. 3 weeks ago
John Morris Accepted Answer
IFTTT and other simplistic integration technologies (which have been mentioned, often negatively, in these forums) either directly as "BPM- or workflow-lite" or indirectly as SOA/ESB-proxies-lite for BPM integration. More magical thinking than systems thinking. Useful for very simple use cases certainly. But entirely wrong for any enterprise mission. And is inherently incapable of dealing with semantic richness. It is to build a cathedral with toothpicks. Toothpicks made of glass. The result is brittle, complex, inflexible, ultimately expensive, missing the point and often irresponsible. It's the GOTO statement of today.
IFTTT and other simplistic integration technologies are fine for simplistic integrations.

Otherwise you need some orchestration.

BPM handles this for work that can be mapped plan-side.

If deviations away from plan-side are needed we move to Case (i.e. ACM/BPM) where two major needs are satisfied

1) decision support by way of consultation of the Case history
2) easy access to cross-case data history/predictive algorithms - so that users can have suggestions re options at branching points (go this way/ go that way)

If time/cost considerations overshadow, we call a CPM engine or you embed ES-EF-LS-LF calculations onto your BPM flowgraphs.

Calling an engine works much of the time (providing you can get to it and get back results). Embedding functionality that will be used only occasionally can be a major source of bloatware.

As I explained in my infrastructure protection comment a day or so ago, BPM is also good at avoiding work (alarms -> avoidance -> no need to do any work).
  1. Karl Walter Keirstead
  2. 3 weeks ago
Regarding my reference above to the construction of cathedrals with glass toothpicks and "fragility" -- I realize that tempered glass toothpicks could in fact be very strong -- fiberglass is very strong and not far from toothpicks -- thus not all metaphors will "stand up" to real-life scrutiny. : )
  1. John Morris
  2. 2 weeks ago
Scott Francis Accepted Answer
Blog Writer
BPEL.... ;)

I can think of more humorous than serious responses to this :) I think there are lots of hyped tech that can interact with BPM at the edges. Or in specific spots. That's all to the good and time to get the popcorn out.
Isn't all of life a tree structure? Cyclic graphs will never catch on . . .
  1. John Morris
  2. 3 weeks ago
Brian French Accepted Answer
I believe most of the things we might call overhyped, may end up being part of the BPM ecosystem at some point, as Scott Francis mentioned above, and some already are.

My first example would be the explosion of workflow for the masses, which some have said will create an RIP BPM tombstone. As was pointed out in the Forum discussion about this (or at least specific to Apple's acquisition of Workflow), and in Neil Ward-Dutton's blog on the subject, rather than being a disruptor for BPM, this may end up lifting the whole BPM market due to the increased visibility of workflow to the masses. It could also drive larger BPM vendors to include more user friendly features.

Another example of a highly hyped technology which some have said will kill BPM is RPA. While I definitely believe RPA has its place, and can think of many use cases where it should be used instead of some other type of solution, it is still just a subset of an overall BPM discipline, and one could argue BPM vendors should be offering an RPA solution with their overall BPM offering. I think a fairly good explanation of this can found via Nividous's open source implementation of RPA for IBM BPM. However, I just don't see RPA displacing BPM since it's usage is limited and I have not seen yet how implementations can overcome the inherit "brittle" nature of the implementation.

Of course, coming from BPM background I am going to have a BPM centric view of the world. More than likely, some of these things I believe are hype will end up actually disrupting at least some portion of BPM. I just can't predict which those are :).
David Chassels Accepted Answer
The business software industry has been one of the most over hyped sectors ever.....driven by huge vested interest to sell their offerings to a generally uninformed market. ERP has been high up the list of culprits. The time has come to refocus back to the basics of how business really works and this puts people at centerfield stage. BPM was created in late 90s to recognise this need but was also over hyped as the early supporting software remained in hands of techies and the interpretation gap remained and generally failed to deliver. This included the earlier BPEL and now BPMN.
I smile at the comments on the no/low code movement as being over hyped. Yes as ever it is hyped but reality is that significant reduction in need to code in the business arena is coming and a few have proven. Even Bill Gates 10 years ago saw removal of coding as the holy grail of software yet his organisation fails to deliver as promised.....was that vision or hype? I think the former as a genuine belief but fact is such delivery will be very disruptive and large vendors do not promote their own demise....
So where are we in the evolution of capability to support the outside in BPM thinking? Our 20+ years research and working with early adopters using the no code approach has proven that it works yet we have been ridiculed and ignored as the industry hype and self interest has ruled. Whilst I have been encouraged by the no/low code movement much is hyped and so I do understand why this is mentioned by some as over hyped....but reality is it will be the future and lead by user needs in being supported at work.
We need to see much greater research by industry analysts to articulate just how the BPM supporting software actually works. This move will put buying power into hands of informed buyers. This is a vital change in disbursement of knowledge not driven by the over hype from big vendors which has held back progress to sort out the decades of complexity and over sold promises/hype to business.
  • Page :
  • 1

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