Software systems are often designed without considering their social intentionality and the software process changes required to accommodate them. With the rise of artificial intelligence and cognitive services-based systems, software can no longer be considered a passive participant in a domain. Structured and methodological approaches are required to study the intentions and motives of such software systems and their corresponding effect on the design of business and software processes that interact with these software systems. This paper considers chatbots as domain example for illustrating the complexities of designing such intentional and intelligent systems, and the resultant changes and reconfigurations in processes. A mechanism of associating process architecture models and actor models is presented. The modeling and analysis of two types of chatbots - retrieval-based and generative - are shown using both process architecture and actor models.
Rapid advancement in software and emerging technologies is influencing the
design of enterprises while promoting continuous and ongoing cycles of innovation and
transformation [
Chatbots are an appropriate selection for introducing and illustrating some of the
concepts in this paper due to their apparent intentional nature. A chatbot is a software
system that converses with human users using natural language, either in verbal or
textual form [
Chatbots can be classified in one of two ways depending on their sophistication and the complexity involved in producing the response (to the inquiry): • Retrieval-based chatbots are simple in design and are generally used for situations where a simple response or action is required to a user inquiry or command. • Generative chatbots are more complex and are generally used in situations which require the construction of a unique and contextually appropriate response to user inquiries. 2
Analyzing Social Implications of Process Architecture
Reconfigurations
The visual depiction of the social aspect is done using the i* framework while the
process related elements and activities are modeled using a process architecture model
that was previously introduced in [
The two perspectives -- actor and process -- can be associated by considering common constructs that appear in both models, represented as a process segment in the process-based model and a task (or operationalized goal) in the actor-based model. The models can be associated together at one of two levels, • PS Level: PS are single-purpose process structures and are meant to accomplish certain enterprise functional requirements (goals) while adhering to non-functional requirements (softgoals). PS are executed by participants (or actors). • PE Level: In an actor model, a goal is eventually achieved through some task(s), which map to a PE in the process model (assuming both models are decomposed to the same granularity), thus allowing for model linking at a more granular level.
Thus, process goals and process activities would be mapped to actor goals and actor tasks respectively, with mechanisms and data flows being represented as dependent resources in the actor models. Existing actor modeling techniques (such as i*) can be used (with extensions and annotations) to signify the association between models from both modeling perspectives while allowing for traceability and movement of changes in one modeling perspective to the other. A PS may have multiple associated actors to ensure the attainment of the process stage goal. Although in simple cases, fulfilling the goal of a process stage maybe entirely self-contained within a single actor boundary. In general, this approach is not limited to a one-to-one mapping between the elements of the different modeling approaches, nor are they expected to be at the same level of granularity and abstraction.
Variation points (VP) in the process architecture model can signify alternative process configurations (also called variants). An actor model can be associated at this VP by having alternatives shown as one of several means-to-end for an actor goal. Actor goal satisfaction techniques will be employed to determine the optimum alternate (based on softgoal tradeoff analysis) which maps to a process architecture configurations. Care must be taken when proposing an alternate process configuration at a VP as the proposed alternate should not result in goal non-satisfaction for other process stages in other parts of the process architecture. 2.1
Retrieval-Based Chatbots
Retrieval-based chatbots are configured to select a response from a predefined set of responses based on the response’s suitability to the inquiry. As the responses are pre-constructed, there is no chance of grammatical mistakes and the primary intelligence required on the chatbot’s side is to retrieve an appropriate response to match the inquiry. This ensures that the chatbots are simple in nature, and as a result they are unable to handle advanced queries from the user. There are several third-party frameworks and solutions available that are able to provide message parsing and response selection capabilities, thus retrieval-based chatbots are quick to construct but have limited flexibility and use in cases where domain specific responses are required.
Fig. 1 shows the dependency relationships that exist between the retrieval-based chatbot on other actors (including the internal chatbot rationales). The i* model allows the determination of the type of chatbot that needs to be developed, and the nec
essary process structure that should be formed, to allow the satisfaction of various goals. In this case, the simplicity of the intentions and motives of the retrieval-based chatbot are reflected in a less complex process architecture (Fig. 2). The two tasks, Understand Request and Construct Response, are attained by corresponding process stages Understand User Request and Construct User Response.
Intent
Classifier Message
Parser Understand User Request
Deconstruct Message
Classify Message Intent IntenUt Classifier
Recognize Message Entities
U Message Parser
Understand Context Context
Generate Response
Plan
Response
Plan X
Generative chatbots attempt to construct a response by tracking the ongoing conversation, utilizing the history of exchanges with the users, and by matching appropriate responses based on a semantic understanding of the inquiry. As the responses are constructed by the chatbot in real-time, there is a chance of the chatbot making mistakes in sentence construction. Additionally, the responses as constructed by a generative chatbot may be domain specific (for example, queries about medical conditions) which require access to a domain-specific knowledge base. Due to their specialized and complicated nature, often such chatbots have to be developed within an organization itself without having the benefit of using pre-built third-party frameworks.
Intent
Classifier Message Parser
Natural
Conversation Sensible Response bot on other actors with the process architecture model depicting the processes involved in processing a user request shown Fig. 4. The generative chatbot requires an additional level of intelligence in order to be able to carry out a natural conversation with a human user. While the tasks (Understand Request and Construct Response) remain the same, the softgoals Intelligent Process and Natural Conversation indicate a different approach needs to be adopted to ensure their satisfaction. This requires the addition/modification of new tasks decompositions and dependencies on Internal Dev Team. The corresponding process architecture model (Fig. 4) reflects this by including a new process stage, Classify Intent, whose output is used by the Chatbot associated processes. While these diagrams are simplistic in nature and illustration, they do indicate the nature of propagation and traceability analysis that can be performed by associating actor models with process architecture models. 3
Conclusions and Future Work
The above is part of our ongoing research [