Another perfect week in Santa Barbara.  Here are some notes I took from the keynote speeches from Nathaniel Palmer, Jim Sinur, and Sandy Kemsley.

Nathaniel Palmer

Five years ago Nathaniel predicts the term “Intelligent Automation” which came true. And the three Rs: Rules, Relationships, and Robots. Robots require rules, and rules are unambiguous.   My question was: “Robots won’t be manually programmed, and so those rules might not be anything we can understand.”

RPA was described as “deterministic AI”.  New prediction, “By 2022 robots and a digital workforce will perform 50% of commercial transactions and production work.”

Relationship: there is no centralized representation of a customer, but the real information is “out there” outside of our span of control. 13 system on the average are needed to find representation of customer, 8 of them are external.

Presented architecture with 4 key technologies: RPA, AI and Machine Learning, Decision Management, Process Management. Connected by an event gateway which is not an ESB. What is missing? No user interface. It is part of the loop of events going out and coming back in.

By 2022 80% of all user interactions will be on devices and interfaces other than the smart phones. Instead Alexa, Cortana, Google Assistant, and Siri will be the interface using natural language. By 2021 conversational interaction will be demanded.

Intelligent automation requires rethinking what a “task” is. “Decision as a Service” should be coming by 2020.

Workflow automation is constrained if it is a sequential, workflow diagram, and ultimately this is decision points, and those decision points define the work to be done. “Intelligent Automation” is about finding the path at runtime. (ESP)

Next systems will be like Waze, which estimates time of arrival, and immediately your goal is to try to beat the ETA. He told a story about following Waze which took him on a surprising, but successful, route.

Nice graph showing that any business event loses value over time, and so Intelligent Automation allows you to respond more quickly to business events.

Machine learning requires excellent data, and BPM can be a good source for this.

My take:

• All the points make sense.  He really did predict the current world well in the past, and probably has done as well today.
• We seems to be painting ourselves into a corner by seeing everything as discrete, durable, composed applications.  No mention of how Google and Facebook are transforming the world, and what this means for us regular people.
  

Jim Sinur

Technology Combinations that Digitally Deliver

Goal directed BOTs are right, but I believe that BOTs will bid on providing services. Agents will bid on work. Silos are int he way of getting all the systems to work together, and creates a zero-sum game. Constituents need to drive the goals, not the company/organization. Calls it outcome driven work management.

“Open Digital Business Platform Suite” better than BPM. Chart of existing open suites does not include Fujitsu.

Productive pairs: combining two or three gives you significant capability. Customer Journey Mapping and BPM. Listed a number of doubles and triples that combine well.

Sandy Kemsley

Kicked off day 2 witha  talk about building your own digital automation platform. Larger organizations are doing this. Experience is generally financial industry. It is not surprising that they build their own processes in house. It is also not surprising that BPM will be at the core of an intelligent automation system.

• Certain trends we have seen over the years:
  the swing between monolithic systems and best-of-breed combination of pieces. Monolithic is not the best for agility. Monolithic systems have no single process owner and no development team with an overall code view. Redeployment is too large and too risky to effectively do more than patch. This is why people work around monolithic systems.
• Tried to fix with multi-tier, SOA systems. Just produced monolithic layers that had their own dependencies. Same problem.
• Then it was “SOA is dead, long live micro-services.” The idea is you would be able to swap out business capability. More of a choreography than an orchestration.
• BPM systems then competed to become the new monolithic system: Franken-BPMS. Too many capabilities integrated in. Model driven development was just not there yet, but things are better now.

Business agility requires technical agility. The monolithic architecture makes this harder. Want to change the customer experience to remain competitive. (But it is not clear how a non-monolithic system makes this easier.)

Digital Automation Platform — doesn’t like the term Digital Transformation Platform because apparently we are over that — is composed from a collection of microservices which can be swapped out. Optionally low-code tooling. “Best of breed microservices from anywhere.” Process management itself is not a microservice.

Low-code is good for citizen developers and for quite prototypes, but technologist find it to be “death by properties panels”. There as some things you just can’t do. This is why BPMS should not be the core system. A BPMS forces you to start with a process model as the basic piece of the application, and this forces assumptions about the application that don’t fit the more complex application requirements. Especially core processes. Also, BPMN does not allow you to create microservices. Invoking a process as a service is not a microservice because you can’t scale up because they all run on a common layer. (However did not explain why you can’t scale up the BPMS in the same way as a microservice.) Some customers are missing testing capabilities for BPMS based systems.

Marketplace divisions: small to mid sized companies might still want to use BPMS as their DAP because it is not their core processes. Bigger companies want microservice DAP. A big organization will have many BPMSs and you can choose the right one for the specific process. But not core applications.

Cool thing of elastic scalability is that you can scale up part of the application, and not scale up other parts. Apparently scaling up a BPMS is “expensive” scalability and not like microservice style architecture.

Vendor recommendations: Even if a vendor offers pricing of separate components as you use it, this is not about pricing, but scaling. Need to be able to separate out components and scale separately. Want the ability to “create” microservices. Open source is doing this better.

Consumers: if it working for you, then don’t change it, but this is probably because you don’t have scalability needs. But if you need scalability, go to microservices.

My take is this:

• The whole talk was centered on how monolithic systems are hard to scale, and microservices are more flexible.  What if your monolithic platform is delivered as a set of microservices?  Don’t you then have the best of all worlds?  
• She never really justified “scalability of applications” as the key issue that soaks up most of the development budget. 
• At the same time completely ignored many other factors that cause development problems. 
  • In my experience a more important issue is ability of developers to make a hardened, reliable application.   Doing so often requires carrying certain design paradigms across the whole application. 
  • The problem with composing your own franken-stack is that when each component works along different development paradigms, the problem can be deep and hard to find.  
  • A consistent holistic application platform can offer a consistency that makes it easier for developers to create reliable applications. 
• The presentation did not address these, and seemed oriented to the point of view that the only thing that matters is to be able to scale individual parts of the system independently.