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).
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
humancentric 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 [
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), Informal Process Essentials (Sect. 3.1) and Informal Process Recommendations (Sect. 3.2) – A discussion on the related work (Sect. 4) 2
According to Leymann and Roller [
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 refers to the activities that need to be done to execute the corresponding process. In case of informal processes, business logic is quite diferent 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 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
Performers depend on IT resources for various reasons, e.g., finding some information, 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 diferent 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 diferent relationships of IT resources and the performers. In our motivating scenario, the access rights to the data of a temporarily recruited expert would be diferent than the other team members.
Means of Representing Informal Process Specific IT Resources (R6): Each informal process might have diferent 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
Organizational aspects of an informal process is important because they have a direct efect on the outcome of the informal process. Next, we present some requirements 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 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.
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.
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 Informal Process
Recommendations Resource Providers
Data Informal Process
Tools 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 [
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
BPEL4People [
Liptchinsky et al. [
In the work of Papageorgiou et al. [
Activity-centric computing [
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
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). 1 http://www.gsame.uni-stuttgart.de/