What BPEL Teaches Us About Human In the Loop": Design for People"

Design for people.? Whenever you are designing software, who you are designing it for is perhaps the most important thing to be sure of.? It affects every decision you make.? It isn't that much different when you design a business: knowing who your customer is, is perhaps the most important thing to have firmly in mind.? At BP3, we know that the faster way to a great set of requirements is to design around the right audience, and it is also important for us to get to know that audience.

So it stands to reason that when buying software, adopting software, or evaluating software, you want to understand who it is designed and built for, and whether it was built with you, or your team, in mind.? If they weren't designing and building it for you (or the people you hope will use that software), you'll be disappointed in the results because it will miss the target for what you need.

I've heard a lot of discussion from analysts and certain RPA vendors recently about a pattern they like to call "human-in-the-loop".? It's a fancy name that sounds like a design pattern.? But if you stop and think about it, it exposes that the human is the afterthought in the design of this pattern.? The "unique" thing about the pattern is that there's a human in the control path, whereas normally, it is straight through automated processing.

Why is this a mistake? Because human-in-the-loop wasn't designed for people. It was designed for the convenience of the bots. And the name itself tells you that that's the case. It was an afterthought to the original design.

Fear not, this is something we can address by using more of the tools in our toolbox.? If you find yourself thinking about human-in-the-loop designs for your RPA bot implementations, please take time out and talk to us, or another firm like us, about how to take a step back from that design and re-frame the problem and solution around the real objectives and people in your business process.? No doubt, you'll still leverage the bots in your solution, but let's do the people in your solution justice as well.? This is what we do at BP3 - we find a faster way to the business outcome - but if it is going to be faster, it has to be designed right the first time. You're going to need to orchestrate process work with your team and your bots, and make your team members first class members of your process, not after-thoughts!

Can we learn from the history of BPEL, why the human-in-the-loop approach to integrating people and bots into a single process is a mistake?? Sure we can.? Let's go to the way-back archive to give some perspective on why this is a yellow flag in the approach to solving automation problems that need human input, we have only to dial back our focus a few years to the days when BPEL and BPMN were fighting it out for dominance in the process automation space. Keith Swenson wrote an excellent obituary for BPEL three years ago "Still Think you Need BPEL?"

BPEL was originally proposed as an interchange format.? That is, one should be able to take a process defined in one product, and move it to another product, and still be executable.? It was to be the universal language for Process Driven Server Integration. [..] 

So far so good. But, who was it designed for?

It was designed from the beginning to be a Turing-Complete Programming Language which is a great goal for a programming language, but what does that have to do with business? The problem with the hype is that it confused the subject of server integration with human business processes. ?While management was concerned with how to make their businesses run better, they were being sold a programming language for server integration.

Keith hit the nail on the head at the time:

My position at the time was clear: as a programming language it is fine, but it has nothing to do with business processes. It was Derek Miers who introduced me to the phrase "BPEL does not have any B in it." The language had a concept of a "participant", but a participant was defined to be a web service, something with a WSDL interface.

But the folks behind BPEL didn't give up when they realized that they had hit one mark really well (server-side automated integrations) but left out the people... So they went back to the drawing board.

The process wonks knew that BPEL was inappropriate for human processes, but still wanting to join the party, there was a proposal for the cleverly named "BPEL 4 People" together with "WS-HumanTask". This is the idea that since people are not web services, and since BPEL can only interact with web services, we can define a standardized web service that represents a real person, and push tasks to it. It is not a bad idea, and it incorporates some of the task delegation ideas from WF-XML, it fails to meet the need of a real human process system because it assumes that people are passive receptors of business tasks.

Why, they designed a Human in the Loop design pattern for people to participate in what was otherwise a fully automated process. Keith nicely summarizes just *some* of the issues:

• There's no concept of changing your mind about who to assign the work to
• There's no concept of sending reminders (servers don't need reminders!), and additionally
• There's no elegant design for how the server should behave while waiting minutes... hours... days... weeks... months for a human to finish that task... so BPEL designed servers didn't manage resources efficiently for human-oriented work.

As Keith chronicles, what killed BPEL in the end wasn't BPEL, but that the community designed a better mousetrap around BPMN, which assumed, from the beginning, that humans (and the business) were a critical part of the design criteria.

BPMN, as a notation designed for business processes and people, did a better job of both representing the business process *and* providing an executable model that can be executed natively by a BPMN engine.

Fast forward to today. RPA software and bots have a great future in our operations and enterprises - they're no BPEL! - but let's remember that when we intend for people to use the software we're building, we should design it for and around them, rather than have them as an afterthought as a "human-in-the-loop".