Business Processes and Planning
Business process management has been one of the most actively researched areas when it comes to applications of planning technologies. A fantastic guide to existing work and challenges at the intersection of planning and business process management can be found in . Salient problems addressed in this area include specification and construction of business processes in the form of planning problems , robustification and adaptation to failures , validation, verification, and monitoring of processes , and prediction and mitigation of risk . We address a somewhat overlooked promise of this union – that of using planning to automate and optimize business processes. Specifically, we want to compose an existing process with “AI skills” or services so as to generate an optimized process that is automated to the extent possible. The motivation for this comes directly from an extensive body of work under the umbrella of “web service composition” .
Web Service Composition
The problem of composing web services finds a ready ally [10, 1] in automated planning techniques since the latter inherently deals with the task of composing together actions in the service of constructing a course of action or a plan. There exists a rich variety of planning techniques, each with their own assumptions and features, and it follows that composition techniques built on top of them also demonstrate properties that can be traded of depending on the needs of the deployment. We refer to  for a great summary of work done in this area, while [44, 42] provides a very useful summary of many of the challenges involved.
Competing Philosophies: Head to Head
We begin with a very brief survey (to the extent possible within the confines of a conference paper) of existing composition techniques and discuss their unique trade-offs. This will aid in uniquely placing our tool among existing techniques for web service composition – and by extension the optimization of business processes using web services – for clients trying to choose between competing technologies.
Classical & Multi-Agent Planning
Automated planning offer a concise way of describing and maintaining process – it is not surprising that the exploration of web service composition in planning literature begun with classical (deterministic, fully observable) planning or compilations into it . From the planning point of view, sophisticated interaction between services can be dealt with at the level of reasoning with capabilities of multi-agent systems . A typical feature of web services is the uncertain nature of their execution  which can be modeled in classical form and dealt with at execution time in certain circumstances .
Non-deterministic / Probabilistic Planning
A more natural way of dealing with uncertainty is to reason about it during planning itself. This can be done offline, by planning with a probability distribution or set  of possible outcomes. As an example, consider calling an API that returns employee information of a company. The call may return the information or hit a 404 error. A non-deterministic planner will thus plan for both contingencies instead of waiting till execution time to reason with the outcome. Of course, a critical assumption here is that nothing changes between planning to execution . Furthermore, since the planning is done offline, dealing with uncertainty in an open world becomes tricky.
Robust (Model-Lite) Planning
Theoretically, every domain is deterministic if you can model all the variables. However, a complete model is rarely available, and incompleteness can manifest itself in a different form of uncertainty at the time of planning. Let’s go back to the example of the API that returns employee information. Imagine that the API can only be pinged from inside the company firewall, but this constraint is not part of the planner’s model. This uncertainty will be resolved at the time of execution (since the domain is deterministic, you will get the same outcome every time you ping it) but the planner can account for this uncertainty at planning time. This flavor or planning, referred to as “model-lite planning”  was proposed especially keeping web service composition in mind. Planning in this paradigm tries to maximize success in the most number of possible models, i.e. the robustness  of a plan. In our running example, the planner would string together API calls that can potentially provide the same information in order to maximize chances of success (instead of contingent solutions like non-deterministic planners). We will see later, given the size of our compositions, stringing together so many services is probably not a viable solution.
Replanning offers a viable alternative to planning with uncertain outcomes upfront . The replanning strategy, of course, varies largely based on assumptions about the underlying domain as we discussed above  – e.g. in the context of robust planning, doing the same action multiple times will yield the same result since the underlying domain is deterministic. The replanning strategy also depends on the what properties of the new plan one wants to optimize – e.g. whether it is desired that the new process is as close to the older one as possible or it preserves key properties or commitments .
Replanning significantly increases the runtime complexity, but is necessary at the end of the day especially since most models are not complete and will eventually require replanning even with the most carefully constructed plan dealing with possible contingencies. In the context of business processes, for example, replanning has been used in the past for the adaptation task .
Hierarchical Task Networks or HTNs based planners such as SHOP2  provide a powerful and alternative framework for composition of services. This includes unique features such as baking in considerations of quality of service into the action theory and the ability to sort preconditions to effect this. The HTN framework has seen continued interest in the space of web service composition tasks  outside the scope of more traditional planning mechanisms.
D3ba Value Proposition
Our tool D3BA brings the notion of web service composition to the task of business process management . The idea here is to be able to change, evolve, and optimize a business process by injecting into it services that can perform specific computation, while at the same time providing the persona in charge of the process tools to manage it easily. The specific notion of optimization we focus on is that of maximizing automation in the composed process and thus reduce the load on individual case workers. Of course, if the automated components come with additional features we can add those considerations (such as health, probability of success, cost, etc.) into the optimization criterion.
Thus D3BA comes with two main features:
an interface to build, edit, visualize, and maintain complex processes concisely using a declarative specification that allows exponential scale-up from the representation to the realized process; and
an interface to optimize the process by composing it with services that can automated one or more parts of it while still maintaining the features from (1).
In order to achieve this, we build on a substrate of non-deterministic planning so as to be able to (a) compute the composed process offline and allow the process manager to analyse and edit it; while also (b) be able to plan for the inherent uncertain nature of execution with external services. The tool also comes with its own inbuilt executor for the generated process once it is deployed. This can be used to optimize a part of a given business process or orchestrate the entire life-cycle of the process.
With regard to past work at the intersection of non-deterministic planning and declarative specification of processes, we would like to emphasize that our focus here is not on the declarative aspect as a means to define a process but as a means to facilitate a particular kind of optimization (through composition with automation) and also not on non-determinism as a means to handle uncertainty (which comes for free) but as a means to facilitate the user interaction for this optimization process. There is indeed a lot of work [33, 45] on how the declarative paradigm readily translates to business process applications that require the definition and composition of processes. That particular aspect of the problem is admittedly quite well explored but only acts as a means to an end here.
The unique value proposition we are providing is the business process + skills = optimized business process interaction patterns with the human in the loop at design time . The proposed interaction is a very specific flavor of human-in-the-loop composition that allows the business process manager persona to take in a new process or write a process in a declarative form, take in a catalog of skills, and author optimized processes offline. This is where the proposed framework built on non-deterministic planning comes into form in being able to surface different optimized compositions to the manager persona to edit, debug, visualize, and personalize further. The declarative form is necessary for this to happen (as well as account for the fact that skill catalogs are independent of the process).
In AAAI 2019, mai demonstrated D3WA – a tool meant to bring down the effort and expertise required to design sophisticated goal-directedconversational agents e.g. for applications such as customer support. The state of the art  in the design of such agents requires the dialogue designer to either write down the entire dialogue tree by hand (e.g. Google Dialogue Flow or Watson Assistant) which becomes intractable pretty soon or train end-to-end systems which provide no control over their emerging behavior  and are thus unusable in the enterprise scene. Instead, in [25, 3], the authors proposed a paradigm shift in how such agents are built by conceiving a declarative way of specifying them. In this paper, we extend their framework for the purposes of the definition and composition of automated skills into business process specifications.
Anatomy of a Declarative Specification
At the core of the declarative specification (as shown in Figure 2 is a set of variables that model the state of the world and actions that depend and operate on those variables to define capabilities that an agent has to affect change to the world. In the context of a conversational agent, such actions can be either speech actions that interact directly with the end user, or internal actions such as logical inferences or API calls. The latter, of course, is more relevant to our case.
Each action is defined by a set of NEEDs or statuses of variables
which tells the agent when it can perform the action (these become preconditions of actions available to the planner in the backend),
and a set of OUTCOMES (recall the two outcomes in the example of an API call from before), one of which might occur at execution time.
Each outcome produces a set of updates to the variables
– these are compiled to the non-deterministic effects of the
actions available to the planner in the backend.
A non-deterministic planner111
We use PRP 
as the non-deterministic planner
and Hovor  as the execution engine.
The intent classifiers that make up the determiners
for the action outcomes are based on
as the execution engine. The intent classifiers that make up the determiners for the action outcomes are based on Watson AssistantBeta features. in the backend uses this specification to plan all possible outcomes offline and automatically generates the resulting dialogue tree (which would otherwise have had to be written manually). This results in an exponential savings from the size of the specification to the complexity of the composed agent, as shown in Figure 2. For more details on D3WA we refer the reader to . In the following section, we will describe how we adopt this platform for the management and optimization of business processes.
D3ba: Process + Skills = Optimized Process
This section outlines the basics of the proposed composition technique with illustrative examples. A video demonstration can be viewed at https://bit.ly/33RNMiR.
The starting point of the composition process is a business process written either inside D3BA itself, or an existing process imported from an outside source (e.g. as in Figure 1), usually in the form of a finite state machine, a graph, a mind map, or a similar data structure. Though the D3BA tool currently does not support the latter yet, refer to  how this translation is done (note that this translation will lose the exponential savings that can be gained from a declarative specification).
The interface to specifying a process remains almost identical to D3WA. This is not surprising since a key aspect of designing goal-oriented dialogue is the specification of the underlying process that must be maintained in conversation (e.g. in customer support). The only difference is that certain types of actions, namely the API calls and the logic actions, take more precedence over the speech actions. The latter may or may not occur in a process at all but we keep them around to facilitate a conversational interface to the processes (as we will see later). These form a sufficient set of capabilities to represent any business process.
As we mentioned before, our goal is to augment existing business processes with automated components, so as to optimize the overall task. We call these automated components: skills. This notion of skills is consistent with skills in Watson Assistant222Watson Assistant Skills: https://ibm.co/2LblJ70 or Amazon Alexa 333Amazon Alexa Skills: https://amzn.to/2ZH9Olp as a function that can perform microtasks. We assume a catalog of skills444 Once a new process has been composed, it can be packaged into a new service and folded into the skill catalog. Such “complex actions” have been explored before in . accessible to the persona designing and managing the process, which she can import and hit compose on the interface.
The skill specification interface follows a similar structure to that of a generic D3WA action but provides an even more simpler abstraction to the outcome enumeration. It accepts as NEEDs and GOTs the inputs and outputs of a service. The declarative specification of these skills, to be consumed alongside that of the rest of the business process, is compiled internally from this abstract specification by considering a power set of the GOTs as the possible OUTCOMEs of invoking the service. The semantics of this compilation is that by invoking the service the planner is expecting to get back (n)one or more of the promised outputs.
The inputs to the composition step is thus a process and a set of skills and the output is a optimized process wherein the original process has been composed with skills wherever possible to maximize automation, as shown in Figure 3. Once the skills have been compiled to the standard D3WA form the rest of the process remains same as in D3WA. This means we get all the rest of its features for free, including being able to visualize, debug, and iterate on the composed process once it has been computed. Specifically with regards to business process management, we illustrate some key capabilities next.
The reason declarative works well in this setting is two-fold: First, the sheer size of these composed processes, and the need to be able to be flexible with their management, makes it imperative that they are not written and maintained by hand. Furthermore, as we mentioned before, the source of skills and processes may be different. The declarative framework allows developers of either to develop without having to worry about how they relate to each other. The planner preforms an essential role in the background by providing a powerful tool to stitch them together.
It is important to note that this composition task is quite non-trivial. This is because, given a complex business process and a large set of skills, it is computationally intractable by a human being to figure out all the possible combinations and find the optimal ones among them. Further, the source of the process and the skills may be different. For example, a developer who is writing the skill may have no idea about the business processes that their skill is eventually going to be used in. Furthermore, the features of these skills, as well as the process itself, change over time, making it essential that the composition process is automated.
Features of Proposed Composition
Consider the travel application process again (see Figure 3
). On the left, we see a part of the travel approval business process dealing with acquiring information from the applicant. There are three back-and-forths with the employee, to figure out the name of the conference, title of the presentation, and estimated expenses, until this step of the process is complete.
On the right of Figure 2(a), we see the optimized business process composed out of skills. These skills, for example, may be able to come up with estimated expenses given a conference555Built on the Amadeus API: https://developers.amadeus.com/., or look up the paper title given the employee information666Built on top of the (IBM internal) Author Workbench service.. In the optimized process, the added flows due to the automated skills are shown in blue, while handovers from automation to the original process is highlighted in red. Notice that the four original back-and-forths are still there, but two of them have been bypassed by the skills and are only resorted to as fallbacks, if they fail. This is noticeable in the dialogue in the inset, where the number of interactions with the caseworker is reduced.
These fallbacks need not be restricted to the original process only. As shown in Figure 2(b), our approach figures out how to chain equivalent skills to maximize success of the automated components. The composition technique allows this optimized process to grow exponentially to increase the robustness of automation. This is an example of how quickly the composition task (let alone the orchestration – i.e. execution and monitoring – of the process once it is composed) can go out of hand for manual approaches even for the small process used here for illustrative purposes.
An additional feature to note in Figure 2(b) is that the catalog is quite larger than the set of skills finally finding a role in the optimized process. Our approach figures out which skills to use (and when and where) and which to ignore from the skill catalog. In addition to the complexity or chained composition demonstrated above, this too is often beyond the scope of manual composition.
Finally, our approach also makes it very easy to modify and personalize the composed process with your own rules. In Figure 2(c), for example, we have added a rule to bypass the manager approval if the presentation is going to happen at a particular conference. This is automatically reflected again, in the newly composed process. This ability to make small edits and effect large changes in the process is a unique feature of declarative modeling.
|number of skills||Base||5||10||15||20|
|size of composition (#edges)||23||134||209||370||1039|
|time to generate (secs)||-||0.02||0.24||3.10||19.48|
Before we end, we would like to give a sense of the complexity of the compositions. Table 1 illustrates the sizes (measured in edges to compare against the complexity of manual build) of the composed processes and runtime with respect to increasing size of the skill catalog. Clearly, while composition is intractable without automation even for small catalog sizes, the planner is quite fast (especially considering the compositions are offline) in coming up with the solutions.
We end with a discussion of two key research challenges that come out of the D3BA paradigm.
Meta-Reasoning on Business Processes
So far we have concentrated only on improving existing processes using skills. The improvements have been closed world, i.e. confined to the existing process, and underlying process or model never changes. The promise of D3BA need not be confined to this. In fact, the planning community has recently seen increased attention to the ability to search and reason in the space of models [17, 6]. Such techniques can allow us to evolve a process to maximize measurable performance metrics such as risk . Recent work has take the first steps  towards evolving business processes to that effect. Model space reasoning can be used to identify opportunities for improving a workflow by addressing hot-spots, bottlenecks, and dead-ends in a process (Figure 4). Works on process mining for planning specifications [8, 7] can also provide powerful tools to his end.
Taxonomy and Knowledge Base
One of the assumptions we made throughout this work was that the skill developers and the persona in charge of managing the business process, though working independently, still have access to a shared vocabulary or taxonomy to specify artifacts of their processes or skills. Ideally, we would like to relax this and instead be able to call to a knowledge base in the background that can make a suitable mapping between the two specifications. This knowledge can reside in an ontology in the backend or may, for example, come from meta information provided by the skill developer in the manifest file corresponding to their skill. Existing approaches such as Embedded Business AI Framework777Embedded Business AI Framework: https://www.eba.ai/ (EBA) has attempted to provide a tight integration with skills and ontologies in the past, and can potentially provide inspiration towards enabling more sophisticated composition strategies in D3BA as well. The now sunsetted project API Harmony888API Harmony: https://apiharmony-open.mybluemix.net can also provide valuable lessons on the representation and composition of diverse web services and skills. In the context of planning in particular, authors in  have previously attempted to leverage ontologies in the context of web service composition, while works in business process management  has also proposed similar solutions for this problem.
Looking Forward: Path to Deployment
In this paper, we demonstrated how non-deterministic planning can provide a powerful way of constructing, maintaining, and optimizing business processes using AI microservices. Going forward, we will be looking to integrate this tooling into IBM’s Digital Business Autamation999DBA: https://www.ibm.com/cloud/garage/architectures/dba (DBA) suite aimed to streamline business operations through automation. The larger effort towards this integration can be read in .
We thank IBM’s digital business automation team and the research team including Yara Rizk, Scott Boag, Vatche Isahagian, Falk Pollock, Vinod Muthusamy, Sampath Dechu, Merve Unuvar, and Rania Khalaf for their support and ideas throughout the project. A special word of thanks to Christian Muise and the rest of the D3WA team  on whose work we built our D3BA extension. Finally, many thanks to Shirin Sohrabi and Michael Katz, also from IBM Research, who helped us navigate the fascinating world of planning, business processes, and web service composition.
-  (2012) Customizing the composition of web services and beyond. Ph.D. Thesis, U Toronto. Cited by: Web Service Composition.
-  (2008) Planning for Interactions Among Autonomous Agents. In International Workshop on Programming Multi-Agent Systems, Cited by: Classical & Multi-Agent Planning.
-  (2019) Generating Dialogue Agents via Automated Planning. arXiv:1902.00771. Cited by: Background: D3WA.
-  (2011) Adaptation of Service-Based Business Processes by Context-Aware Replanning. In SOCA, Cited by: Replanning.
-  (2003) Web Service Composition as Planning. In ICAPS Workshop on Planning for Web Services, Cited by: Classical & Multi-Agent Planning.
-  (2017) Plan Explanations as Model Reconciliation: Moving Beyond Explanation as Soliloquy. In IJCAI, Cited by: Meta-Reasoning on Business Processes.
-  (2017) On the disruptive effectiveness of automated planning for ltl f-based trace alignment. In AAAI, Cited by: Meta-Reasoning on Business Processes.
-  (2016) Computing trace alignment against declarative process models through planning. In ICAPS, Cited by: Meta-Reasoning on Business Processes.
-  (2018) Aligning Partially-Ordered Process-Execution Traces and Models Using Automated Planning. In ICAPS, Cited by: Business Processes and Planning.
-  (2004) Similarity Search for Web Services. In VLDB, Cited by: Web Service Composition.
-  (2005) Semantic Business Process Management: A Vision Towards Using Semantic Web Services for Business Process Management. In ICEBE, Cited by: Taxonomy and Knowledge Base.
-  (2007) Web Service Composition as Planning, Revisited: In Between Background Theories and Initial State Uncertainty. In AAAI, Cited by: Classical & Multi-Agent Planning, Taxonomy and Knowledge Base.
Conformant Planning via Heuristic Forward Search: A New Approach. AIJ. Cited by: Non-deterministic / Probabilistic Planning.
-  (2016) Rethinking BPM in a Cognitive World: Transforming How We Learn and Perform Business Processes. In BPM, Cited by: D3BA: A Tool for Optimizing Business Processes Using Non-Deterministic Planning.
-  (1999) Exploiting AI Technologies to Realise Adaptive Workflow Systems. In AAAI Workshop on Agent-Based Systems in the Business Context, Cited by: Business Processes and Planning.
-  (2007) Model-Lite Planning for the Web Age Masses: The Challenges of Planning with Incomplete and Evolving Domain Models. In AAAI, Cited by: Robust (Model-Lite) Planning.
-  (2019) Efficient Heuristic Search for Optimal Environment Redesign. In ICAPS, Cited by: Meta-Reasoning on Business Processes.
-  (2007) Probabilistic Planning vs Replanning. In ICAPS Workshop on IPC: Past, Present and Future, Cited by: Replanning.
-  (2017) A Planning Approach to the Automated Synthesis of Template-Based Process Models. Service Oriented Computing and Applications. Cited by: D3BA Value Proposition.
-  (2017) Intelligent Process Adaptation in the SmartPM System. TIST. Cited by: Action Languages.
-  (2018) Supporting Adaptiveness of Cyber-Physical Processes through Action-based Formalisms. AI Communications. Cited by: Action Languages.
-  (2017) Automated Planning for Business Process Management. Journal on Data Semantics. Cited by: D3BA Value Proposition, Business Processes and Planning.
-  (2002) Planning with Complex Actions. In Workshop on Non-Monotonic Reasoning, Cited by: footnote 4.
-  (2018) Microsoft’s Neo-Nazi Sexbot was a Great Lesson for Makers of AI Assistants. Note: MIT Tech. Review Cited by: Background: D3WA.
-  (2020) Planning for Goal-Oriented Dialogue Systems. AAAI Workshop on Interactive and Conversational Recommendation Systems. Cited by: Figure 2, Anatomy of a Declarative Specification, Background: D3WA, Acknowledgements.
-  (2012) Improved Non-Deterministic Planning by Exploiting State Relevance. In ICAPS, Cited by: Non-deterministic / Probabilistic Planning, footnote 1.
-  (2019) Executing Contingent Plans: Challenges in Deploying Artificial Agents. In AAAI Fall Symposium, Cited by: footnote 1.
-  (2018) Towards enterprise-ready ai deployments minimizing the risk of consuming ai models in business applications. In AI4I, Cited by: Meta-Reasoning on Business Processes.
-  (2019) Counterfactual reasoning for process optimization using structural causal models. In BPM, Cited by: Meta-Reasoning on Business Processes.
-  (2003) SHOP2: An HTN Planning System. JAIR. Cited by: Hierarchical Planning.
-  (2017) Robust Planning with Incomplete Domain Models. AIJ. Cited by: Robust (Model-Lite) Planning.
-  (2003) Service-Oriented Computing. Communications of the ACM. Cited by: Business Processes and Planning.
-  (2006) A Declarative Approach for Flexible Business Processes Management. In BPM, Cited by: D3BA Value Proposition.
-  (2005) Automated Composition of Web Services by Planning in Asynchronous Domains. In ICAPS, Cited by: Classical & Multi-Agent Planning.
-  (2007) Integrating Planning and Scheduling in Workflow Domains. Expert Systems with Applications. Cited by: Business Processes and Planning.
-  (2004) A Survey of Automated Web Service Composition Methods. In Workshop on Semantic Web Services and Web Process Composition, Cited by: Web Service Composition.
-  (2017) A unified conversational assistant framework for business process automation. In AAAI Worskhop on Intelligent Process Automation (IPA), Cited by: Looking Forward: Path to Deployment.
-  (2004) HTN Planning for Web Service Composition Using SHOP2. Web Semantics: Science, Services and Agents on the World Wide Web. Cited by: Hierarchical Planning.
-  (2010) Preference-Based Web Service Composition: A Middle Ground Between Execution and Search. In ISWC, Cited by: Non-deterministic / Probabilistic Planning.
-  (2009) Web Service Composition via the Customization of Golog Programs with User Preferences. In Conceptual Modeling, Cited by: Action Languages.
-  (2018) An AI Planning Solution to Scenario Generation for Enterprise Risk Management. In AAAI, Cited by: Business Processes and Planning, Business Processes.
-  (2010) Customizing the Composition of Actions, Programs, and Web Services with User Preferences. In ISWC, Cited by: Web Service Composition.
-  (2018) What it Takes to Build Enterprise-Class Chatbots. Note: Chatbots Cited by: Background: D3WA.
-  (2003) Web Service Composition – Current Solutions and Open Problems. In ICAPS Workshop on Planning for Web Services, Cited by: Web Service Composition.
-  (2004) A Decision-Support Framework for Component Reuse and Maintenance in Software Project Management. In CSMR, Cited by: D3BA Value Proposition.
-  (2013) A Theory of Intra-Agent Replanning. In ICAPS Workshop on Distributed and Multi-Agent Planning, Cited by: Replanning.
-  (2007) FF-Replan: A Baseline for Probabilistic Planning. In ICAPS, Cited by: Replanning.