Supporting Informal Processes C. Timurhan Sungur, Oliver Kopp, and Frank Leymann Institute of Architecture of Application Systems, University of Stuttgart, Germany lastname@iaas.uni-stuttgart.de Abstract People play an indispensable role in many tasks in various domains and they collaborate to accomplish those tasks. During these collaborations software tools are used, data is created/consumed and best practices might be applied. These a priori unknown informal processes are conducted with the help of experience of their actual performers. In this work, a new concept of supporting these informal processes will be introduced, i.e., Informal Process Support Model, consisting of Informal Process Essentials and Informal Process Recommendations, which support informal processes based on the previous executions without limiting their flexibility. Furthermore, we will introduce how these concepts can be realized with the use of Topology Orchestration Specification for Cloud Applications (TOSCA). Keywords: ad-hoc processes, informal processes, informal processes support model, informal process essentials, informal process recommendations 1 Introduction In various domains, e.g., manufacturing, scientific, IT, etc., business process (aka. workflow) models are used for documenting the implicit knowledge, re-use and for automation purposes. In these models, domain experts predefine the actual execution steps for the enactment of the corresponding process. Beside these formal processes, there are informal processes which are typically human- centric and carried out based on the experience of their human performers. These processes are called informal processes on account of the lack of formal definitions. Although there are no formal definitions, their existence are known by human performers [9]; however, they are for some reason, e.g., due to previously unknown set of activities, being considered not valuable enough, etc., not formalized. As the main driver of the informal processes are human-decisions, they are quite volatile in their nature. Performers use IT resources to carry out these informal processes. During enactment of the informal processes, data can be created or consumed. An execution of a traditional business process might cause an informal process execution or in an informal process, formal process might be executed. Despite the fact that the informal processes are not formally documented, there might exist recurring activities and best-practices in these processes, which might be re-used. This work introduces a new concept of supporting these informal processes by using the available knowledge in these processes. N. Herzberg, M. Kunze (eds.): Proceedings of the 6th Central European Workshop on Services and their Composition (ZEUS 2014), Potsdam, Germany, 27-03-2014, published at http://ceur-ws.org 50 C. Timurhan Sungur et al. The main contributions of this paper can be listed as: – An overview of requirements for supporting enactment of informal processes (Sect. 2) – Introduction of the concepts of Informal Process Support Model (Sect. 3), In- formal Process Essentials (Sect. 3.1) and Informal Process Recommendations (Sect. 3.2) – A discussion on the related work (Sect. 4) 2 Requirements for Supporting Enactment of Informal Processes According to Leymann and Roller [6], business processes have three dimensions, i.e., business logic, IT infrastructure, organization and we will analyze our requirements under these categories. Next, we will explain a simple motivating informal process scenario to describe requirements easier. In an enterprise, a product team receives a new product feature request and makes an assessments of their available resources, i.e., human and IT resources, to satisfy corresponding requests. After assessment, a new expert is recruited, and he uses the software tools as the other members of the product team do to participate in this collaborative work. To satisfy the new feature request, the product team installs a new software tool, which will be used by all team members. In the following section, we present the first set of requirements based on the dimensions of business processes, which came up in discussions with the scientific community. A proper justification is out of scope of this paper and follows in future work. 2.1 Business Logic Business logic refers to the activities that need to be done to execute the corre- sponding process. In case of informal processes, business logic is quite different from standard business processes because there are no predefined steps and new steps can emerge in each execution. In the following paragraphs, we have the requirements for supporting enactment of informal process regarding business logic dimension. Means of Providing Core Elements of an Informal Process (R1): Providing core elements of an informal process involves describing core elements, i.e., performers, IT tools, data and the means of making these resources ready, e.g., textual descriptions of how to make these ready. By satisfying this requirement, we define the main performers, tools and data to carry out corresponding informal process. In our motivating scenario, the core elements are the product team, their tools and the data used during product development. Means of Supporting Performers without Constraining the Flexibility (R2): Performers need to be guided without any constraints on the execution of informal Supporting Informal Processes 51 processes. By this way, we provide means of supporting the performers without dictating any activities. An example of this could be providing the related data to the new team member in our motivating scenario. Means of Exploiting Existing Implicit Knowledge (R3): Previous executions of an informal process would contain resourceful information and usage of this information in the further executions would be needed. During satisfaction of a new product feature request, users could be guided with possible further actions. 2.2 IT Resources Performers depend on IT resources for various reasons, e.g., finding some infor- mation, creating some artifacts, collaborating with each other, etc., to accomplish informal processes. In this section, we present the requirements for supporting enactment of informal processes regarding IT resources aspects. Means of Inclusion of IT Resources (R4): IT resources influence outcome of the informal process and we need a means of associating them with informal processes. By associating the IT resources, we provide a common collaboration infrastructure where interoperability increases. In our motivating scenario, all the tools that are used by the product team for the feature request. Means of Representing Relationships of Performers and the Tools of Inflexible Process (R5): Each role might have different kind of relationships with the software tools that they are using and we need a means of representing these, e.g., a regular user vs. an admin. By this way we can express different relationships of IT resources and the performers. In our motivating scenario, the access rights to the data of a temporarily recruited expert would be different than the other team members. Means of Representing Informal Process Specific IT Resources (R6): Each informal process might have different set of software tools and we need a means of isolating informal processes from each other. By this way, each informal process has an isolated execution context. In our example the informal process of adding a new feature has its own set of tools which are shared by the performers. Means of Changing the Set of Tools During Execution (R7): Performers might need additional tools and remove old ones as they desire. We need a means of changing the list of tools after initialization. In our motivating scenario, we have an additional tool for the new feature. This new tool is added to the informal process context and used by all the performers. 2.3 Organization Organizational aspects of an informal process is important because they have a direct effect on the outcome of the informal process. Next, we present some require- ments for supporting enactments of informal processes regarding organizational aspects. Means of Representation of Human Performers and Their Relationships (R8): The performers of an informal process have some roles, skills and certain 52 C. Timurhan Sungur et al. relationships among each other which would influence the outcome. We need a means of associating these performers and relationships. As a result, we abstract our actual set of performers and they can be replaced with an equivalent set of performers in the next enactment. In our motivating, we would have a team with certain relationships among each other, e.g., manages relationship vs. recruits relationship. Means of Addition and Removal of Performers During Execution (R9): In case of a lack of an expertise, new experts might be recruited and informal processes might be associated with new performers. We need a means of adding and removing performers from informal processes during the enactment of the business process. As a result, we do not limit the list of performers to problem. In our example, the product team recruits a new expert based on their needs. Means of Providing Context Switching for a Performer (R10): A performer might be a performer in an another informal process and means of context switching is needed. As result, performers can be more productive and use the related tools and data for an informal process. In our motivating scenario, the recruited expert participates in more than one informal process and each of them has their own set of tools and data. 3 Informal Process Support Model To satisfy these requirements, we introduce the concept of Informal Process Support Model (IPSM) (Fig. 1). The concept contains additional new concepts, i.e., Informal Process Essentials (IPE) and Informal Process Recommendations (IPR). The concept of IPE follows a declarative approach by stating what the problem is and bringing together the core solution elements for the problem. IPR not only supports IPE with some improvement recommendations but also it recommends some action steps based on the past enactments of the corresponding informal process. In the following sections, we will detail these two main concepts. 3.1 Informal Process Essentials IPEs describe not only the building blocks of informal processes, i.e., performers, data and software tools, but also they describe how to make the core elements ready for the enactment of the informal process, i.e., resource providers. The model provides the necessary concepts and relations for modeling core elements of an informal process. As a result, we can initialize for the enactment of an informal process and we meet the requirement R1. IPEs include description of software tools that are used in the enactment of corresponding informal process and each informal process model can have its isolated set of tools. As a result each IPE is associated with informal process specific tools and data, which satisfy the requirements R4 and R6. IPEs enable association of IT resources independent from the status of the corresponding IPE, e.g., running, suspended, etc., of the corresponding informal process, which Supporting Informal Processes 53 Informal Process Recommendations Data Resource Providers Informal Process Tools Figure 1. An abstract view on the Informal Process Support Model satisfies the requirement R7. In IPE, with the relationships provided by IPE, custom relationships are possible and one can associate IT resources, i.e., data and software tools with human performers. As a result R5 is satisfied. In IPE both performers and their relationships can be defined. Performers are abstract description which are made concrete during initialization or update of an IPE. They have interrelations among each other. By providing means of defining a group of performers and their relationships, we satisfy the requirement R8. Addition and removal of performers do not depend on the status of corresponding informal process, which results in satisfaction of R9. For each informal process that a performer participating in, there are performer specific views based on the described software data and permissions in an IPE. These performer specific views provide an isolated view for the performers and a means of easy context-switching. By providing an isolated view, we satisfy R10. Initially, IPEs are created by performers who have knowledge about the corresponding informal process and they are assumed to contain necessary set of elements to conclude a corresponding informal process. However, as the needs change the instances of the concepts can be updated at any time, e.g., adding new performers, tools, etc. For realization of IPE, we need to model our performers, software tools and the related data. Moreover, we need a means of making these resources ready. Considering essential characteristics of cloud computing [8], cloud computing would be a good choice for automated provisioning of IT resources. Topology and Orchestration Specification for Cloud Applications (TOSCA) [3] provides means of modeling cloud IT infrastructures and data associated with the corresponding applications. It has a corresponding run-time container (aka. TOSCA container) [2] and an open source editor Winery [5]. In TOSCA models, one can define the topology of an application and how the corresponding application components can be provisioned in the form of business processes, e.g., using BPEL [11] or BPMN [12] or scripts. In our use case, topology templates could be used to 54 C. Timurhan Sungur et al. represent human performers, IT infrastructure and data concepts of an IPE and to describe how these resources are provisioned we could use corresponding deployment plans. The suitability of TOSCA for modeling IPEs needs to be further investigated and left as a future work. 3.2 Informal Process Recommendations IPRs contain the tips which are gathered from previous executions. They guide the performers during modeling time of IPSMs and during run-time of an informal process. Considering that they are just “recommendations”, we do not constrain the flexible execution of an informal process. However, we still make some recommendations based on the information collected and by doing so we satisfy R2. These recommendations are collected during the enactment of an informal process so they are based on the implicit knowledge of the performers. As a result, we use the best practices that the performers bring to the enactment of the informal process; therefor, we satisfy the R3. During realization of the concept of IPR, we will exploit the information created in the IT infrastructure where the informal process takes place. 4 Related Work and Discussion BPEL4People [4] is an extension of BPEL to support people in business processes. However, it is not possible to change the model, after it is initialized, i.e., we have constant staff query and after assignment, it cannot be changed. The work of Shall et al. [14] introduces a framework for Human-provided Services, these services provide a unified interface for web-services and human services. By use of this framework people can publish services based on their skills. These can be used as a complementary to our approach during finding the corresponding resources; however, not an alternative. Liptchinsky et al. [7] define a modeling framework for collaborations. An extended version of UML state diagram is used to represent collaboration artifacts, their relationships with performers and relationships of performers. They include additional transition concepts to design the flow of a collaboration process. The models do not include software tools (R1, R4, R5, R6, R7, R9 are not satisfied). By adding some states and some conditions, we limit the flexibility of the process (R2, R3 are not satisfied). In the work of Papageorgiou et al. [13], based on some pattern definitions, users are guided through a collaboration process. Events are analyzed and they are mapped to some collaboration patterns and users are guided based on these patterns. Inclusion of software tools and some means of making the resources is not explained in the work (R1, R4, R5, R6, R7 are not satisfied). Moreover the authors do not mention addition and removal of performers during execution (R9 is not satisfied). Activity-centric computing [1, 10] provides a platform where users can create activities, associate people, resources and to-do lists with these activities. Users Supporting Informal Processes 55 collaborate using some applications integrated to activity-based components. From an instance of an activity, an activity-pattern can be extracted and can be used for another similar case. In the concept of activity-centric, no concept of resource providers have been proposed, the relationships between software tools and performers have not been mentioned and relationships of performers cannot be represented (R1, R5 and R8 are not satisfied). By our introduced concepts, we preserve the flexibility of informal process enactments. IPE provides the performers, tools and data for the enactment of an informal process and it is supported by the IPR. This model suits well because in case of informal processes the business logic not modeled beforehand and with this model, we do not enforce modeling it beforehand. After establishing an initial support model, we analyze the on-going collaborations in the context of corresponding informal process. Hereafter, we analyze the collaborations and we present the findings as recommendations to the performers. 5 Conclusions and Outlook In this work, requirements for supporting enactment of informal processes have been introduced and with some new concepts, these requirements have been fulfilled. The concept of IPSM has the purpose of providing necessary elements for the conclusion of an informal process and assisting performers and IPSM designers. IPE is the concept which contains the descriptions of core elements of an informal process and IPR refers to the tips and recommendations to provide an easy execution of an informal process. As the next step, requirements will be justified, the introduced concept of IPE will be detailed and a corresponding prototypical implementation will be provided. Thereafter, on top of the established concept of IPE, we will detail the concept of IPR. Acknowledgments This work is supported by Graduate School of Excelence in Advanced Manufacturing1 (GSaME). References 1. Bailey, J., Kandogan, E., Haber, E., Maglio, P.P.: Activity-based management of IT service delivery. In: CHIMIT 2007. CHIMIT ’07, ACM, New York, NY, USA (2007) 2. Binz, T., Breitenbücher, U., Haupt, F., Kopp, O., Leymann, F., Nowak, A., Wagner, S.: OpenTOSCA - A Runtime for TOSCA-based Cloud Applications. In: ICSOC’13. LNCS, vol. 8274, pp. 692–695. Springer Berlin Heidelberg (Dec 2013) 3. Binz, T., Breitenbücher, U., Kopp, O., Leymann, F.: chap. TOSCA: Portable Automated Deployment and Management of Cloud Applications, pp. 527–549. Springer, New York (Jan 2014) 1 http://www.gsame.uni-stuttgart.de/ 56 C. Timurhan Sungur et al. 4. Ings, D., Clément, L., König, D., Mehta, V., Mueller, R., Rangaswamy, R., Rowley, M., Trickovic, I.: WS-BPEL extension for people (BPEL4People) specification version 1.1. OASIS Committee Specification (Aug 2010) 5. Kopp, O., Binz, T., Breitenbücher, U., Leymann, F.: Winery – Modeling Tool for TOSCA-based Cloud Applications. In: ICSOC’13. LNCS, vol. 8274, pp. 700–704. Springer Berlin Heidelberg (Dec 2013) 6. Leymann, F., Roller, D.: Production Work Flow: Concepts and Techniques. Prentice Hall PTR (2000) 7. Liptchinsky, V., Khazankin, R., Truong, H.L., Dustdar, S.: A novel approach to modeling context-aware and social collaboration processes. In: Ralyté, J., Franch, X., Brinkkemper, S., Wrycza, S. (eds.) CAiSE, Lecture Notes in Computer Science, vol. 7328, pp. 565–580. Springer Berlin Heidelberg (2012) 8. Mell, P., Grance, T.: The NIST definition of cloud computing (draft). NIST special publication 800(145), 7 (2011) 9. Moody, P., Gruen, D., Muller, M., Tang, J., Moran, T.: Business activity patterns: A new model for collaborative business applications. IBM Systems Journal 45(4), 683–694 (2006) 10. Moran, T.P., Cozzi, A., Farrell, S.P.: Unified activity management: supporting people in e-business. Commun. ACM 48(12), 67–70 (Dec 2005) 11. OASIS: Web Services Business Process Execution Language Version 2.0 – OASIS Standard (2007) 12. Object Management Group: Business process model and notation version (BPMN) version 2.0 specification. Tech. rep., Object Management Group (OMG) (Mar 2011) 13. Papageorgiou, N., Verginadis, Y., Apostolou, D., Mentzas, G.: Event-driven adaptive collaboration using semantically-enriched patterns. Expert Systems with Applica- tions 38(12), 15409–15424 (2011) 14. Schall, D., Truong, H., Dustdar, S.: The human-provided services framework. In: E-Commerce Technology and the Fifth IEEE Conference on Enterprise Computing, E-Commerce and E-Services, 2008 10th IEEE Conference on. pp. 149–156 (Jul 2008)