BPM.com
  1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Tuesday, 28 November 2017
  5.  Subscribe via email
Looking back at the year that has almost passed, what tech development from 2017 do you think will have the biggest impact on processes in the year ahead?
Accepted Answer Pending Moderation
It's 10:30 and no responses. Can it be that there were NO tech developments in 2017?
Comment
  1. Ian Gotts
  2. 1 year ago
  3. #4824
yep
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
Well, the DMN (Decision Model and Notation) specification for decisioning and business rules modeling and management might be a candidate, but it was released in mid-2016. Nevertheless, it really only got some vendor traction in 2017. Adding rules to process is enormously important for business analysts (or any process automation project sponsor). Clarifies business logic and affords massive simplification of process models. Big opportunity; slower adoption, for all the usual reasons. But inexorable.
Comment
@John.

Beyond "enormously important" in my view.

Pointless moving to micro-processors in the absence of pre-processors and post-processors - no one wants bad results coming back to them from IoT devices


All of this pre-processing/post-processing stuff goes back to around 1985 to Dr Bertrand Meyer and his "Design by Contract"

"History of "Design By Contract"
The term was coined by Bertrand Meyer in connection with his design of the Eiffel programming language and first described in various articles starting in 1986[1][2][3] and the two successive editions (1988, 1997) of his book Object-Oriented Software Construction. Eiffel Software applied for trademark registration for Design by Contract in December 2003, and it was granted in December 2004.[4][5] The current owner of this trademark is Eiffel Software.[6][7]
Design by contract has its roots in work on formal verification, formal specification and Hoare logic. The original contributions include:
A clear metaphor to guide the design process
The application to inheritance, in particular a formalism for redefinition and dynamic binding
The application to exception handling
The connection with automatic software documentation
"
  1. John Morris
  2. 1 year ago
  3. #4837
@Walter, can we tie your reference to pre- and post-processing to the growing problem of alarm fatigue? (I've written about this a few times too.)

Cheap data production inevitably results in human cognitive overload. "Data is cheap and business analysis is expensive". In other words especially, the post-processing. All sorts of documented anti-patterns. Or better yet, "experienced anti-patterns", as in what happens in hospitals in the ICU with nurses and alarm fatigue.

And why does the problem even arise? Because stepping up and funding the business analysis necessary to do the filters between machines that can throw millions of bits at people is hard. It's a technology meets economics meets governance problem. And it's getting worse, and probably will continue to do so before it gets better. You think?
@John,

You can get some relief from alarms by smarter rules that tighten up as you move through a process.

Example: At some step where we might, for example, be picking up a cluster of 6 data elements "name, address, city, street, zip and phone", the process designer can declare this cluster to be "mandatory" plan side, which means if one of the 6 data elements is missing, the app alarms with a notice "One or more data elements are missing"

Except that we can make that "One or more data elements are missing, do you want to record more data or skip?"

Now, the user has to option of looking up/providing the missing info OR skipping - the thing is we really don't need the phone number unless/until we want, downstream, to make a phone call and unless/until we need to send out a letter via USPS, you don't need the zip.

So, here, we issue an "alarm" once only, but it's a local prompt that appears whilst the user is in the form (much less intrusive compared to an alarm that rolls around every 1 minute)

If the user responds "skip", that will be the last complaint re the data cluster unless/until we hit a hard stop downstream at "phone customer" or "mail letter to customer".

Point is it could be a day, a week, or months before the next complaint/alarm relating to that data cluster

Users can, I suppose, turn off all of their alarms ("I have had it with alarms for today!), avoiding all "missing data" notifications.

Incommunicado users will not see the hard stops either - work will simply grind to a halt.

Not a problem in Case Management. The effect of a stalled pathway (assuming the presence of a countdown milestone) is that "criticality" will escalate, capturing the attention of the Case Manager who will reach out and smack the negligent user.

Not saying I have a "solution" to alarm fatigue but seems to me the number of alarms can be reduced significantly using various strategies.

The beauty of pre-post rules IF you can park them at process steps is that you don't have to expressly insert pre-post steps immediately upstream or downstream from a normal process step.

Unfortunately, my software (unlike Eiffel classes) cannot accommodate pre and post "edges" to steps resulting in a need for inserted "process control (i.e.gatekeeper) steps" that just sit and wait for the data they need, then fire when the data becomes available. Something for the 2018 wish list!

Now, can we get all customers to go to "smart alarms" - nope !

Good fit with "in theory, theory and practice are the same, in practice they are not"
  1. John Morris
  2. 1 year ago
  3. #4848
@Walter, good point re: "relief from alarms by smarter rules". As shown in a field with which you are familiar though, writing those rules is a non-trivial task. Because "data is cheap and writing rules is a big job for business analysts". The fact that alarm fatigue continues to be an issue in hospitals (and other environments) is testimony to the difficulty of getting edge data filtering acknowledged as a significant part of any project. More devices, more data, not enough analysis, bad filtering, cognitive overload --> "articles about alarm fatigue in hospitals" and more importantly, "scary system failures".
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
AI-enabled RPA creating BPMN and DNM which automatically builds mobile-enabled Low-Code Apps. Did I get all the acroynms in there?
Comment
  1. Emiel Kelly
  2. 1 year ago
  3. #4826
Rba?
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
Tech progress in certain areas (DevOps, container architectures, process engine multitenancy, CI/CD) is reaching a tipping point and this will benefit the way executable processes are being deployed, used, and reused in the organizations.
CEO, Co-founder, Profluo
Comment
  1. John Morris
  2. 1 year ago
  3. #4827
If all these "below the line" technical tools contribute to faster roundtrips -- then there could be an impact on process automation. Faster roundtrips means executives are forced to pay attention, over shorter cycles. Organization learning and adaptation is improved. IFF executives (and their business analysts) are willing and able to step up. Big IFF.
  1. Ian Gotts
  2. 1 year ago
  3. #4828
The faster we run, the further we run in the wrong direction.
My point was not about being faster (how did this even get across, I don't know), but about reusability of common complex process patterns. That's why I only bolded the word "reused".
  1. John Morris
  2. 1 year ago
  3. #4833

You didn't (suggest "faster"). However, "reading between the lines", I thought your tech and associated use cases created an opening for faster roundtrips, which can have a huge impact on learning. So I guess that means business case. (Sorry previous note done from a phone included an "?" which kind of changed the meaning. . . .)
Hey John, faster roundtrip is indeed a consequence of reuseability.
But reuseability in itself is a business model capability for a cloud platform, which may be a different than simply faster deployments. It's about clarity of business process vision and inclusiveness of the underlying architecture.
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
I think the "marriage" between BPM and modern digital archives (i.e. blockchain-based storage) will allow BPM expanding beyond organisational boundaries. Thus BPM can coordinate people, organisations, services, etc. in the end-to-end (from the customer's point-of-view) manner.

Thanks,
AS
Comment
+1, Alexander
Seems to me that if all trading partners adopt platforms that (for each) build\s a History with system applied date/timestamps and user "signatures" of their side of transactions, all they need on top of this is parallel automatic export to a public read-only data store and they would have the basics for blockchain.

Am I missing anythihg\?

Karl, also we need "ordinary" people as trading partners but those people can't afford to run platforms. Thus it is necessary to have an independent trusted platform. Example - http://improving-bpm-systems.blogspot.ch/2016/07/digital-contract-as-process-enables.html
Hmm, we still struggle with "ordinary" people and you are right, they cannot afford platforms - the workaround for us has been "no-log-in" users, who cannot get to the platform, they also have no software other than a portal log- in where they get to see a "menu of services" and where we decide what they can request and what they get back.

All of their "communication" is with an engine on an isolated server. It is the engine that talks to the dbms and if anything looks suspicious, the engine tilts and the in-message or out-message goes to a human.

I suppose all we need to do to let them participate in blockchain is to route a copy of what they upload and what they download with facilities for them to locally store what they uploaded and downloaded and let them ping the blockchain storage for a 2nd opinion.

I need to get to understand blockchain. I have the book I recall you recommended. All fascinating!
Karl, and some small businesses can't afford BPM platforms.
  1. John Morris
  2. 1 year ago
  3. #4850
Alexander - I think there are some newer BPM platforms (can we call them "platforms"?) which ARE affordable for SMB and are INTENDED to be affordable to SMB -- at least in terms of technology access. Then it's up to sales to get the customer (notice "customer", not "client") to budget the time for business analysis (whether or not one actually uses a professional business analyst or not).
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
@Karl Thanks for that piece of history on "Design by Contract" and Eiffel Software. Interesting that the 80s seem to hold so much hope to remove need to code as articulated by thought leader Naomi Bloom “Writing less code to achieve great business applications was my focus in that 1984 article, and it remains so today. Being able to do this is critical if we’re going to realize the full potential of information technology” “….how those models can become applications without any code being written or even generated”. “If I’m right, you’ll want to be on the agile, models-driven, definitional development side of the moat thus created…..” ”If your Enterprise vendor isn't pretty far down this path, their future isn't very bright”. Naomi goes on to say “It really matters how your vendors build their software, not just what they build” Bill Gates saw it in 2008 when 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.”

Our research started in the 80s and whilst we found the answer to this no code "object oriented software". It was a complete fresh approach driven by business people with a few clever and "uncontaminated" coders! It really does it all and as indicated by John Rules are vital and encouraging to see DMN make progress.....but our way there is no need for any "Notation" language! Build direct from user needs and natural business logic and very fast .....count number of UIs as number of man-days to build using declarative from the Model.....Now interesting that Bill Gates thought the same 20 years later! We were decades ahead of the game and we did not know what to call it....and we were often ridiculed but as I learned that is a consequence of "disruptive" innovation! As BPM emerged in late 90s it became apparent we totally supported this thinking which was easy for me having had experience of mapping out processes talking to people who did the work. Interestingly we delivered on the "Adaptive" capability in both easy change and UIs which were adaptable for use by specific users....something Microsoft tried to patent but a decade too late! Take note no one can patent not even us as prior art solid!

So what has happened in past year some 30 years from those ambitious visions? Yes DMN relevant but credit to this forum has started to ask some really good questions which brings out very relevant thoughts. We see the tag "Digital Enterprise" added to BPM.com not sure when you did this but another sign recognising the need to focus on the operational front end of business. AI over past year has grown in profile and as VW discovered "processes" in build and use are vital.... Maybe driverless vehicles need process approach to deliver safely...? What ever the scene is set for Enterprise Software to get back to business basics where BPM sits. I am sure we are not alone indeed certainly hope not and with likes of DMN maybe all are drivers to rethink "how".
Comment

Good points, David. -

Tthe reason for digging up Eiffel is that we were part of that history - our parent holding company Jay-Kell Technologies used to host O-O seminars based on Eiffel, plus seminars on military stuff we don't talk about, out of Singapore, from 1980 -1990. When we moved our ops to Canada, we were, for a time, distributors of Interactive Sofware Engineering (Dr. Meyer's original Santa Barbara company) and we were also distributors for mdbs inc out of Lafayette, IN, the authors of Object1.

We still do a lot of our platform programming in pure O-O.

Instead of having eight teams for eight products, we have one team for eight products.. . . Encapsulation, Abstraction, Inheritance, Polymorphism almost allow you to make a new product any day you like. The big chore is the terminology which has to change when you go from one industry/app to another - nothing to do with programming.
  1. John Morris
  2. 1 year ago
  3. #4838
@David, you have shared bits and pieces of your story with the BPM.com community over time,, and it's fascinating. And now your note today especially resonated with me because I spent 6 years in the Magic Software ecosystem (late 90's early 00's).

Magic at that time was one of the big four RAD tools (along with PowerBuilder, Delphi and Progress -- and hundreds of other lesser knowns). Magic's claim to fame was that it was entirely rules-driven (with strongly defined pre- and post-processing too). I note the rules were lower level than what you would define as a full-on business rule today, but entire applications could be constructed declaratively. Magic (still traded on NASDAQ) had some amazing successes world-wide, especially, like Progress, through channels (one notable success being almost 20 large life and annuity insurance providers in North America). An experienced Magic programmer was typically an order of magnitude more productive than any competitor code-based technology.

Why mention all this? Because I've wondered and analyzed over the years why "the better mousetrap" was not more successful. Sure, part of the reason was that most organizations realized they should not be in the custom software business, and in the early 90's big and small ERP systems rolled down from Mount Olympus and were adopted by smaller and smaller enterprises. The RAD tools market collapsed.

Now ERP is great - you get powerful software to run you whole business for a fraction of what it would cost to build it yourself. But then you realize -- you're on a level playing field with the competition. And who wants to be on a level playing field in business? And thus BPM (and RAD?) are still attractive when you want to differentiate. ERP serves the functions that are by definition commodity functions. But you'll earn probably the largest portion of your profit though in those parts of the business supported by custom apps.

This still doesn't answer the question concerning the difficulty of pitching declarative RAD tools. Because there is a difficulty pitching RAD and declarative regardless of market trends. (And despite it's intellectual attractiveness, I don't think Bill Gates ever achieved his goal either. I guess code "just sucks you back in".) Certainly part of this difficulty stems from career-minded technical staff. High-productivity RAD tools by definition take few programmers. And they have often been proprietary. For this reason, there is economic risk to any technical staff choosing high-productivity tools.

I think there may be an additional reason too, and that is the question of management "wait states". With code, management has the luxury of waiting for the latest round of coding to be delivered before it has to get involved again. And certainly management has lots on its plate already. RAD tools (and agile methodologies too) put enormous pressure on management to "step up" on automation strategies on very short cycles. It's both a time pressure AND a cognitive load. Consider at any random point in time, management staff are 100% committed. Adding to this load a new demand for business analysis and strategy and it's a challenge! And RAD, declarative and agile just make it that much worse. These sorts of phenomenon are probably why real disruptive change rarely comes from operations, but only from separate business units. Does this make sense to you maybe?
@John.. Delphi as in turbo-pascal?.

If yes, that used to be a Borland product but is now owned by Embarcadero.
@John It is an interesting issues as to why such innovation seems to fail to get attention and traction. Trouble is the way the software industry has evolved has put too much "power" in hands of those who have too much to lose! Add to that business people and that includes accountants were too easily fooled by ERP as the answer to computerised business operation....and we know that it created a huge gap between people and those systems! I put responsibility on the industry analysts who should be educating business on latest ideas and developments...I could write a book about our experiences....maybe some day I will!
@ Karl Interesting you mention Borland...our original prototype was based on their relational database we later did rewrite using Oracle for scaling. The real trick was discovering how to store task types inside a relational database and of course understanding what they were. Again Microsoft tried to patent and we know others failed to achieve but it is possible and strong prior art ensures no patents valid.
@David...

I guess stupid customers are at fault for allowing vendors to be in the driver's seat.

Surely, with phishing, fake invoices, customers are becoming more knowledgeable/wary, so why can't they just verify for themselves during a WebEx or GoToMeting what a platform looks like and how it runs, particularly in the area of visual mapping, compile and run-time testing of a small yet representative workflow?

If it takes more than 1 hour, they should probably move on.
  1. John Morris
  2. 1 year ago
  3. #4845
@Walter - yes re: TurboPascal.
@David - is this maybe evidence of major software technology governance / market sub-optimization? Whoever can figure this out . . .
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
Not an easy question to be answered, since I don't recall a specific breakthrough research in 2017 that in fact can cause a tangible change to the 2018's BPM market. Landing at https://www.technologyreview.com/lists/technologies/2017/, I would say bots, IoT (payments) and self-driving vehicles stand out as likely candidates of having an impact on business processes to come. However, I think their effect on BPM and BPMS in particular, will be a more gradual thing.
NSI Soluciones - ABPMP PTY
Comment
  1. John Morris
  2. 1 year ago
  3. #4865
Good point about payments. As you know payments require a lot of orchestration. And payments technology and business models are exploding. The combination of business opportunity and technological requirement could push BPM adoption for the space. The orchestrations are very scripted, but it's amazing how complex they can be. And there's a requirement for customization. Just for fun, I'll share an animation I did at Oracle (in public domain) using BPEL to drive an EDI 850 transaction inbound to ERP. Much easier now! Here's the video: https://vimeo.com/39723654

Payments are of course a superset of invoicing. (The point of the animation was to show business people that what they were buying actually made sense.) BPM will win if it can be shown that the technology is easier than coding with frameworks (and that performance will be good too). Given the risks at stake BPM is a much better solution -- because you're working directly with payment processes "as first-class citizens" of the system.
  1. Kay Winkler
  2. 1 year ago
  3. #4872
Thanks for sharing. I recognize the general layout from several countries' now adopted e-invoicing standards. For some strange reason, in most cases, most governments have completely ignored the BPM component as part of the greater payment life cycle,sadly leaving the standardized XML files to be orchestrated manually.
What became of your POC?
  1. John Morris
  2. 1 year ago
  3. #4882
Glad you took the time to see the animation Kay! Now I will share some results (see URL below).

The background was that I was in the middleware overlay group (the only way to sell specialized technology when the deal sizes are smaller compared to big infrastructure) where one of our foci was B2B (as in "B2B gateways"). And we developed a successful programme built around BPEL (at the time) plus the suite of specialized adapters we had (as well as having the ability to incorporate 3rd party adapters). As you know EDI has been around for a half century. It's very complicated -- and the only reason any vendor ever adopted it was because GM (or Walmart etc.) forced them to do so. From the big picture, automated ordering makes sense. But from the perspective of smaller players, it's a tough sell (channel partners help). Now with IoT and micro-payments and proliferation of automated payments world-wide we are seeing a whole new generation of interest -- and the potential for frustration and risk. That's why business development tools can help.

As for the POC, here are the public results of another B2B POC I did, with Helena Chemical, this time in the agricultural chemicals space. This article was done after implementation and shakeout; the reference was a huge win because it enabled us to say "see -- it works" for new technology!

http://www.sys-con.com/?q=node/318418
Microservices Expo: Article
BPEL & B2B Synergies Reduce Supplier Enablement Costs
Helena Chemical Company Deploys New Technology & Techniques
BY DAVID WEBBER, NISHIT RAO
  1. more than a month ago
  2. BPM Discussions
  3. # 7
  • Page :
  • 1


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