bpmNEXT 2019 impressions

Back again this year in Santa Barbara for 3 days of discussions on bpmNEXT between (mostly) vendors on what we collectively believe the future might be looking like, or what challenges we face and how we can solve them.

And I will be blogging about my impressions of the presentations here.

This is part of a 5-part blog series on bpmNEXT 2019:

Day 1
Day 1 (part 2)
Day 2
Day 2 (part 2)
Day 3


BPM 2019-2023: Outlook for the next five years 
Nathaniel Palmer

Nathaniel is kicking it off with his traditional presentation of looking forward and predicting what we might see in the next few years in the context of “Intelligent Automation” (yes, the conference is still called bpmNEXT but the consensus seems to be that this term seems to cover better what we are discussing here).  He actuall started by looking back to the predictions from 5 years ago, where he predicted the 3 R’s (Rules, Relationships and Robots).  This all seemed fairly accurate, as “robots” are here now, and they definitely need rules. And the data is scattered across many systems (over 13 systems on average, many external) and all need to be related. Some of the 2019 prediction are that by 2022,

• 50% of the work will be done by robots
• 70% of the work will be done on third party cloud platforms: so that means that the “Intelligent Automation Platform” architecture that was presented a first time a few years ago, has been updated a little to reflect this (where the event bus is now much more inherently part of the cloud itself)
• 80% of the user interaction will be done through an interface other than the smart phone (think smart speakers), moving from a worklist metaphor to much more conversational interaction.

Since the concept of work is now much broader (including robots, autonomous intelligence, decision services, etc.), what’s the best way to represent and model this, as traditional flow charts have reached their limits in representing more adaptive requirements.
He also made a case for intelligent automation to shift to taking much more short term decisions based on the most recent live events as the business value is typically much higher if the response time is as small as possible and based on the most recent data rather than calculated the best approach long upfront (like how for example Waze can give me a much better route compared to just finding the shortest route long upfront).

Or as Nathaniel summarized it himself:

But we are responsible to make that happen, as “the best way to predict the future is to create it” !

Technology combinations that digitally deliverJim Sinur

Jim is making a case for open “Digital Business Platforms” where emerging digital technologies can be combined and are at the basis for digital transformation.  Quite a few of these exist and could be considered proven solutions but typically only in specific areas (e.g. AI, analytics, BPM, collaboration, cloud or IoT).

He then described how combining some of these create so-called productive pairs: for example CJM (customer journey mapping) + BPM, or BPM + AI / RPA / PM (process mining) or IoT and AI.  Or even triplets: BPM + PM + RPA, BPM + IoT + AI, Arch + Low Code + RPA, Workflow + Content + Collaboration and Unified Communication + AI + BPM.  Combining these technologies creates a platform with particularly advantages to achieve certain set of use cases.

Jim made a case for vendors to collaborate on this, because some of these technologies can be very complementary and improve customer experience and satisfaction.

Industry round table: how cloud architecture is redefining product suites and automation platform strategies

Next is a panel, with participants from IBM, BonitaSoft and our own Phil Simpson from Red Hat.  This is much difficult to summarize, so I'll just aggregate some of the ideas.

Why / how cloud?

• Unified platform that gives access to independent services in a containerized way
• Public / private / hydrid and multi-cloud
• Componentisation to guarantee elasticity of the solution
• Pick and choose the features you need rather than installing one big monolith
• Making the platform easily available where you are measuring

Vendor-neutral cloud strategy?

• Standards can be useful to achieve this to some extend
• There will always be differentiators built on top
• It's going to be hard to do this without more standardization (e.g. common data model)

Partner ecosystem?

• Use of an integration and api mgmt solution to be less dependent on specific integration
• Partner ecosystem is changing, from partners implementing solutions to partners offering value-add on top
• Cloud as a vehicle towards a unified target ecosystem, open-source as a way to generate collaboration
• System integrators are evolving to become more consultants delivering best practices than the technical challenges alone
• Partners build relationships and focus on specific verticals or areas

Do the standards invented decades ago need to evolve to adapt to this new reality?

• The advantage is that standards like BPMN and DMN are independent of the technology used to do the actual orchestration
• Connection to events is missing?
• Running into the limitations on how the standards can be interpreted vs how they were written, which leads to various challenges

Re-aligning BPM in the age of intelligent automation

Malcolm Ross, Appian

Appian believes that Intelligent Automation needs to be an effort to seamlessly offer RPA, AI, Integration and BPM altogether (rather than isolated silos for each of them).  BPM is the glue that brings all of this together, like for example it combines RPA with humans, AI optimized BPM or BPM integrates systems.

The demo is showing an invoice processing application that is being enhanced with RPA.  After attaching my invoice in the UI, I can send the robot automation desktop where data can be extracted and for example uploaded to an FTP site.  BPM can be used to handle for example exceptions during this part (creating new tasks for a human to manually solve).  Data from both BPM and RPA also needs to be combined into a holistic view on what is happening.

From the authoring point of view, you can set up integrations separately using various connectors (to for example RPA systems but for example also Google NLP) and then use these by calling them from the process.

Interesting analogy on why and when RPA: RPA is like ibuprofen where service integration would be like amoxicilline - ibuprofen solves the short term pain and is easily accessible, where amoxicilline is much more difficult to get but solves the issue at the root by killing the infection, there clearly is a market for both.