The time between changes in business processes and their IT implementation has an impact on a company’s competitiveness. In addition, the costs of such changes should be minimized. The article presents a method for implementing changes to business processes based on a process platform. By means of simulation it is shown that this method offers several advantages compared to traditional component-oriented software development. Changes are implemented with low labor and transaction costs and operational flexibility is increased.

1 Introduction

Companies must be able to carry out organizational adjustments effectively and efficiently to secure sustainable competitive advantages (Cyert and March 1963). For these necessary adjustments flexibility of business processes constitutes a key influence factor (Moitra and Ganesh 2005; Regev et al. 2007). Information technology (IT) has proved to be a crucial driver of business process flexibility in dynamic business environments (Clemons 1986; King et al. 1989). So far, the potential of IT for the organizational adaptation could not be fully accessed, which regularly appears as a lack of alignment between IT and the organization and/or the business processes – the so-called business-IT gap – (see Masak 2006; Chan and Reich 2007; Aier and Winter 2009). Evidence for this is the difficult individualization of complex operational software systems with regard to the variable requirements of the business processes (Brehm et al. 2001; Hong and Kim 2002).

Business processes are increasingly supported by software- and platform-as-a-service offers (SaaS/PaaS) (Buxmann et al. 2008), for which market sizes of up to 16 billion U.S. dollars have been forecasted (Ried et al. 2009). Successful PaaS providers (such as salesforce.com, NetSuite) succeed in making cross-industry solutions accessible to a broad user group. Therefore, flexibility of the provided software covering the changing requirements plays a crucial role. However, the actual implementation of the changes is always associated with costs, which may vary depending on the underlying architecture.

The following contribution examines whether a deployment of business processes based on a service-oriented platform is able to cope with changes more flexibly and efficiently than a classic component-based approach. The article is structured as follows. To better understand software-based changes in business processes and their evaluation, in Sect. 2 we first present a typology. Subsequently, we discuss the criterion of business process flexibility. Based on these observations we develop a model to simulate and evaluate the expenses for these changes in Sect. 4. In Sect. 5, we present the platform-based method, including a differentiation from the component-oriented approach. Based on selected change scenarios we perform a simulation and evaluation of the platform approach and discuss their results. Finally, the limitations of the model will be outlined. The contribution closes with a conclusion and an outlook on future studies.

2 Software Changes: A Typology

The literature on information systems change (ISC) covers a wide area as organizations using information systems may change in regard to a variety of dimensions, ranging from psychosocial to technological aspects. According to the classification of Lyytinen (1987), ISC is a process of creating and/or configuring elements and connections, and which takes place at and between three areas of IS: (1) symbols; (2) organizational tasks, structures, and processes; and (3) technological core of the organization.

This contribution is limited to the symbolic area, in particular to possible modeling grammars for software modification, and the organizational processes and structures in terms of business processes and their data. Changes in the technological core of the organization are out of the focus of this contribution. An additional restriction is made on the level of the extent of changes. Since the focus here is on software changes that are required by daily business and with limited amount of adaptations, we address the incremental forms of ISC as distinguished from episodic, radical, and occasional changes (Gersick 1991). Our literature study of typologies for software modification yielded a very broad diversification. Therefore, the following considerations were used to structure the analysis:

  • Grammar type: Describes the visual representation format, including the rules according to which the user can make a modification.

  • Affected layer(s): A generic 3-layer model for application systems with communication layer, application layer, and database layer to which the modifications may relate (Ferstl and Sinz 1998; Brehm et al. 2001).

  • Granularity of the observation: Ranges from fine (specific guidelines for action for the user, such as the selection of a value in a drop-down menu) to coarse (an IT project as a change activity, such as the launch of an ERP suite).

  • End-user focus (in terms of Web 2.0): Describes how the modification activities are aligned to typical end-users (focus on professional competence; predominantly working with word processing, spreadsheet tools, and browser-based applications). Highly user-focused modification options include e.g. the setting and connection of weblogs and online directories (Schroth and Janner 2007).

Table  1 presents the identified modification activities according to authors and the above mentioned structural features. The literature study shows that specific modification activities for various grammar types, layers of granularity, and end-users have been classified. The focus of previous works is set on the areas of software maintenance, ERP customization, and configuration of process models, while in more recent works modifications at the level of comprehensive artifacts, such as sub-processes (Weber et al. 2007) and complete IT projects (Dreyfus and Iyer 2008), are increasingly addressed. Despite the differences in the structural features, comprehensive types of modification activities can be observed, as the intersections of the concepts (in italics and underlined) in the right column of Table  1 clearly indicate. These activities are: (a) add, (b) delete, (c) move, (d) adjust and (e) create. For the configuration, the activities (f) lock/unlock should be highlighted. Thus, we can identify a core set of modification activities independently of grammar, addressed system layers, and granularity, which can be consulted for a model-based approach of software flexibility.

Table 1 Process or software modification types identified in literature
Full size table

3 Business Process Flexibility and Efficiency

For a detailed analysis of various software change approaches, quality criteria are required on the basis of which management decisions can be taken. Business process flexibility is seen as an important quality measure for increased performance of companies in volatile markets (Davenport and Short 1990; Allweyer 1998; Berry and Cooper 1999; Kumar 2004; Gebauer and Lee 2008). This contribution relies on the work of Sethi and Sethi (1990), who characterized various facets of flexibility in a classification of 11 types of flexibility. Following this classification, our underlying consideration of the flexibility concept essentially addresses operational flexibility. In classical literature, operational flexibility refers to an object to be manufactured, which can be produced through traversing alternative process paths. In the context of software modification, operational flexibility can be transferred to a specific modification which must be “produced”. Alternative options for the realization arise from the fact that further employees – in addition to the person initially involved – now have the capacity to conduct further modifications. For example, specialized domain experts now have the ability to integrate an additional activity in a process model – an operation which has been a programmer’s task prior to the capacity shift. Multiple paths for making a specific modification result in higher operational flexibility.

While the above remarks follow a classical notion of flexibility, the implementation of process and software changes does not only involve operational flexibility, i.e. specifically increasing the number of qualified staff members, but also – as mentioned above – the efficiency of the implementation. Efficiency requires an amount of effort, typically time and costs, which is attributed to a well-defined activity, in our case to specific process and software changes. Approaches for software modification must adequately fulfill both criteria – flexibility and efficiency – in order to successfully face the system environment.

4 Simulation and Evaluation Model

Based on the works on flexibility characteristics of work systems we consider an information system to be a work system consisting of resources and requirement types (Iravani et al. 2005; Alter 2008). This view can also be reconciled with fundamental concepts of queuing and coordination theory (Malone and Crowston 1994). Since we focus on the specific context of changing software systems supporting business processes, we consider resources to be actors (the employees involved in the software change process of the organization) and the requirement types to be the respective modification operations (see Sect. 2). The actors execute the various modification operations. Dependent on the skills they possess, they can or cannot perform certain operations. Similar to the modification operations, skills can be regarded as capacity or means by which these operations can be implemented. Fig.  1 illustrates all potential modification operations as a combination of the basic types of modification across the language levels.

Fig. 1
figure 1

Modification operations

Full size image

The coverage of a set of modification requirements by a set of actors with different capacities/skills can be mapped into a connected graph. Fig.  2 illustrates two exemplary distributions of skills for N actors (A N ) and K modification operations (M K ). For brevity reasons, the model has the values N=3 and K=9. A solid edge between an actor and a modification requirement represents that the actor has the necessary skills to implement the operational requirement type. A dashed edge denotes an involvement of an actor by means of communication, e.g. through the formulation of requirements.

Fig. 2
figure 2

Exemplary distribution of skills

Full size image

According to our above given definition, higher operational flexibility exists if a modification can be carried out by several actors; i.e. the number of incoming edges of a modification operation can be taken as an index for operational flexibility. The operational flexibility of the overall system is represented by the vector consisting of the individual levels of flexibility. Therefore, the operational flexibility on the left-hand side in Fig.  2 is (2; 2; 2; 2; 2; 2; 1; 1; 1) and (2; 2; 2; 2; 2; 2; 2; 2; 1) on the right-hand side. Following Iravani et al. (2005), a higher operational flexibility can be assumed for larger values in the vectors. To develop an indicator it is necessary to represent the larger values in the vector. Average determination would be an example for the formation of a possible indicator. Hence, we have an operational flexibility of 15/9 for the system on the left and of 17/9 for the right-hand side system. Thus, the operational flexibility is slightly higher for the right-hand side system.

For a comparative study of the efficiency of alternative approaches, we must also take an effort factor as a basis. In the process of collecting and passing on change requests, the effort mainly consists of communication, correction, and preparation activities of different duration that occur between the actors. We refer to these expenses collectively as transaction costs (Picot 1982; Hildenbrand et al. 2007). The dashed edges represent the transaction costs that arise between a requirement and an actor who is not primarily competent to carry out the respective modification. Eventually, the capable actors’ labor expenses Footnote 1 are incurred. The modification costs, consisting of labor and transaction costs, are shown in Fig.  3 with a general cost matrix for the operations M1–M9 as an example.

Fig. 3
figure 3

Left: General cost matrix for the implementation of changes M i by the actors A j . Right: Example values for the system in Fig. 2 right. Shaded cells correspond to the dashed edges and the values represent transaction costs measured in cost units CU. Non-shaded cells represent direct modification costs or no relation (costs=0 CU)

Full size image

5 Method for the Flexible Modification of Business Processes

We consider a method to be a systematic approach for the achievement of predefined goals. A method supports the user with behavioral rules and instructions, which are based on certain principles. This understanding is based on the analysis of the works by Jayaratna (1994), Greiffenberg (1997, 2003), and Braun et al. (2004) and is not to be compared with a methodology (Hildenbrand et al. 2005; Ovaska 2005; Greiffenberg 1997; Becker et al. 2001) or a framework (Jayaratna 1994). For an in-depth definition and differentiation we refer to Greiffenberg (2003).

From a scientific perspective, the development of the method belongs to the method construction discipline (Greiffenberg 2003; Hevner et al. 2004). Following Gutzwiller (1994), the present work defines the approach (time schedule of activities and their dependencies) and actors (roles) as well as requirements for tool support. The existing meta-model of the method and a detailed explanation of artifacts and techniques only bear secondary relevance to the understanding of the conducted simulation. Therefore, we abstained from going into this further in view of the limitation of this contribution’s size.

The presented method follows the principles of Web 2.0, enabling the simple modification of software systems (Schroth and Janner 2007). It draws upon the concepts of Model Driven Development (MDD). Frequently, the program code does not have to be changed manually. Simple changes can be made by persons without skills in software development. As a result of the implementation of changes being closely related to a specific department, the communication effort to mediate and the control functionality requirements can be reduced. More complex changes and the development of software services within a process still require advanced programming knowledge. Technological implementations of this philosophy can be found in Hoyer et al. (2009) and Kuropka et al. (2008), which however lack the formal evaluation in terms of flexibility and efficiency of the approaches.

5.1 Differentiation from the Component-Based Approach

The platform stands face to face with traditional component-based software development (component approach). The latter can be implemented for example with the Java Platform Enterprise Edition (Java EE) or .NET and C++ e.g. by using singletons. The differences between the component approach and the platform approach are (Roman 1999; Matena et al. 2001):

  • Specifications for components are not directly derived from business process models, but usually from UML use cases. On the process platform, the implementation is done based directly on the business process activities.

  • The business process is not directly represented in the software. The business logic is located in the components or by using a model view controller approach (MVC) in the controller. The business process is modeled and executed on the platform. The components are accessed by the user interface or, in case of the MVC approach, by the controller. On the platform, service operations are accessed by the business process.

  • The processes are only implicitly implemented in the software so that a simple modification requirement may cause a complex modification of the software. Process changes can be implemented in the platform very easily.

  • Change requests must be communicated via a number of persons in order to be ultimately implemented by skilled software developers in nearly every case. On the platform, a number of changes can be implemented by predefined roles.

5.2 Actor Model and Distribution of Skills

For our approach, four basic actors are distinguished: user, configurator, process administrator, and developer. The distribution of the actors’ skills is illustrated in Fig.  4 . To simplify matters, the allocation of the change operation is carried out via categories; some categories may also be adopted by several actors. Analogously, the graph-based representation of the distribution of skills is illustrated in Fig.  5 .

  • User: The user has simple changing competencies with regard to the business process – Category A. He is given greater decision-making authority than in traditional software development, the latter being characterized by little direct opportunities for the user to intervene in the process. At the same time, increased knowledge of a process-oriented language is required.

  • Configurator: The configurator does not exist in classical approaches, currently his tasks are in the area of an administrator or developer. The configurator is trained for the adaptation and verification of (executable) business processes. He has all user skills for conducting changes and has further rights to modify a process – Category A and B. He can release changes requested by users. He has the final say regarding the bundling and communication of change requirements.

  • Process administrator: The process administrator is responsible for the receipt of bundled changes and the implementation of changes in the process models. He is responsible for most of the changes and can theoretically inherit changes of categories A, B, and C. He is the controlling authority regarding the work of the configurators and, for further changes, of the developers.

  • Developer: The developer creates software services and their orchestration, supporting the business process – Category D. The tasks are similar to those of a traditional software developer. The focus, however, is mainly set on the adaptation and development of services.

Fig. 4
figure 4

Distribution of skills for the adaptation of business processes, categorization for the process platform. Not all language constructs from Fig. 1 are relevant to our configuration

Full size image
Fig. 5
figure 5

Graph-based distribution of skills for the platform approach (left) and the component approach (right)

Full size image

5.3 Approach

The process model of the method allows for a structured treatment of the change requests based on the presented distribution of skills. The decision which actors have to carry out certain modifications in which manner is based on the required type of change. The process model is illustrated in Fig.  6 .

Fig. 6
figure 6

Process model of the method for flexible modification of business processes. Labor and transaction costs are associated with the activities

Full size image

5.4 Tool Support

Only the support of the method by a suitable tool allows for compliance with the presented approach and the division of tasks based on the defined roles. The presented approach is based on a platform implementation with various components to support the modeling and technical implementation of business processes (Elhadad et al. 2008; Schönherr et al. 2008). These include:

  • Portal: Access to the process modeling through a web-based portal which offers different functions depending on the change options of the roles.

  • Modeling tool: Based on an extended version of the Business Process Modeling Notation (BPMN 1.0), the users are able to take on the modeling and manipulation of processes. As part of the modeling tool existing models and services can be browsed.

  • Semantic repository: In the repository, additional reference models are provided in addition to the customers’ models (processes, data, organization), which can be adapted during modeling. Furthermore, a number of web services exist to support the processes.

For a better understanding, we present a short list of possible tool functionalities in the following:

  1. 1.

    Syntactic modeling support: Creating syntactically correct models can be difficult, especially for less trained users (e.g. the role user). In support of the users, the presented approach therefore offers situational advice and modeling proposals (e.g. potential successors to an activity, review of the number of edges for decision nodes, etc.; Born et al. 2007; Koschmider 2007; Soffer et al. 2008)

  2. 2.

    Semantic service search: For locating existing services, two methods are used. Existing data of the process are used to perform a match on the basis of semantically annotated service descriptions and to identify candidates for the support of the activity/activities. In addition, the current process can be analyzed with methods from NLP (Natural Language Processing) and the concepts can be compared with a terminology of the customer (if available). In order to overcome the heterogeneity of different terminologies, methods from the so-called ontology alignment are used. (Elhadad et al. 2008; Kuropka et al. 2008; Rake et al. 2009)

  3. 3.

    Process model adaptation: The definition, to what extent the modeler is allowed to make adjustments to the workflow model, is included in the process model adaptation. Approaches for the specification of these operational steps of process model adaptation can be found in adaption patterns for workflows (Weber et al. 2007), in specialization rules for the derivation of process models (Soffer et al. 2007), and in approaches on the extension of process models with ontology-based annotations to express constraints and rules for the change process (Soffer et al. 2008).

6 Case-Study-Based Simulation and Results

In order to illustrate the simulation, in the following section we will explain the design, the case study, and the change scenarios as well as outline and discuss the results.

6.1 Simulation Design

To evaluate the platform-based method, we conduct a simulation (Kellner et al. 1999; Andres and Zmud 2001; Kleijnen et al. 2005). As the basis of the simulation we consider change scenarios, which have been taken from real change requirements of business processes. These scenarios are explained below. The options available for adaptation are defined by the modification operations.

The question is how easily the original process can be adapted with regard to the above mentioned change scenarios: once following a current software development model (component approach) and once following our method. The effort required for implementing a change consists of the specific expenses of the executing actors and the transaction costs which arise from the communication between actors during the transmission of change requests (see Sect. 4).

We assume different labor costs for the platform approach depending on the category of the change. In the component approach, every change will be implemented by a developer; therefore, no differences exist between the various change categories.

Transaction costs depend on the category since different actors are involved in the changes of a category (see also Fig.  5 ). The corresponding cost matrices are illustrated in Fig.  7 (transaction costs of the actors involved are shaded).

Fig. 7
figure 7

Cost matrices for the alternative approaches to software modification (cost in CU)

Full size image

The weightings have been developed based on expert estimates since we are not aware of any empirical work showing this granularity of observation. We assume conservative values for the platform approach as it is still technologically maturing.

6.2 Case Study

In the context of current customer projects in the public sector, we could draw upon a basis of management processes. We identified the registration process for childcare facilities (which takes place in all municipalities nationwide) as a potential domain for the application of our approach. This process and its context are suitable for the analysis of our approach since on an abstract level the individual processes in local communities are the same: parents register their children for various care facilities, an administrative unit determines the legitimacy and possibly special needs of the children and assigns day care places, and care facilities finally accept and take on the children. At the implementation level, however, the process can be realized differently. The provision of this registration process as a service by a single IT service provider may be an attractive model due to the above-mentioned advantages – for the individual municipalities as well as for the IT service provider. In order to enable the successful consumption of the process by many municipalities it is important for the offering company to be able to quickly and easily adjust the basic process to the individual differences between the municipalities. To verify the presented approach, we selected typical change scenarios of varying complexity from the domain. These are carried out in a simulation in order to quantitatively assess flexibility properties. In a comparison with an existing software development model (component approach) we ultimately highlight the benefits and risks of our approach.

6.3 Change Scenarios

We consider three change scenarios that may occur in practice according to our analysis of various municipalities.

  • Change Scenario 1: Early end of registration deadlineFootnote 2 – The expiry date of a central registration will be moved to an earlier date. This requires a change of the corresponding temporal event in the workflow. The process flow is then resumed earlier accordingly.

  • Change Scenario 2: Central place assignment instead of individual prioritizationFootnote 3 – The parents of the children should not be allowed to prioritize child care services in the online reservation on their own anymore. Instead, the administrative unit carries out the prioritization and assignment of childcare offers (central planning of the childcare). Parents only register their children online; preferential facilities can no longer be specified.

  • Change Scenario 3: Additional data transmission for statistical analysisFootnote 4 – Presently, the transmission of personal data (of the children) by the childcare facility to the administrative unit can also be performed manually (e.g. by mail) – in future, the transmission will be done electronically. This makes it necessary to provide corresponding services and to incorporate them into the process. In addition to the transmission of personal data to the administrative unit or the Department of Children and Families respectively, the data should be transmitted to the local government in order to create reports on this basis for enabling statistical analysis. This requires not only new activities and control flows, but also adding a new role (local government) in the process.

6.4 Implementation of the Simulation and Summary of Results

The simulation was carried out for the two alternative approaches based on the change scenarios described in Sect. 6.3; i.e. we carried out a total of six simulation runs (three runs for each approach).

The results of the simulation are summarized in Table  2 . Due to the limitation of this contribution’s size we only briefly discuss each scenario.

Table 2 Results of the simulation: Modification costs of the alternative approaches in three change scenarios (costs in CU) and their individual operational flexibility
Full size table

In change scenario 1, only change operation AdE had to be performed to set the timer in the time event correspondingly (see Fig.  8 ). In the component approach the developer is involved for a relatively small change, causing additional expenses in the LC compared to the platform approach. However, the more complex actor structure leads to slightly higher coordination costs in the platform approach.

Fig. 8
figure 8

Detail of change scenario 1

Full size image

Change scenario 2 (see Fig.  9 ) includes the movement of the process elements which describe the prioritization of childcare offers since these activities are no longer carried out by the role of the parents, but by the administration. The LC for the platform approach amount to 135, which is well below the component approach (= 200). This is due to the fact that many change operations, such as moving, adding, adapting, etc. are performed by the configurator without generating work for process administrators or developers. The platform approach can thus avoid “small” changes for the developers. Again, the higher TC are a result of the more complex actor model.

Fig. 9
figure 9

Detail of change scenario 2

Full size image

For change scenario 3 (see Fig.  10 ) we can see that the platform approach leads to the fact that the LC for the overall change reduced by about 20% compared to the component approach (49<60). Although in this scenario changes necessarily require the participation of developers for both approaches, the expenses are not higher in the platform approach in terms of the LC compared to the component approach. However, the development effort for the adaptation of a service is higher in the platform approach (category D). As to the other change operations, the platform approach provides the advantage that many change requests do not even reach the developer because they could already be implemented by the user or the configurator. This will also result in slightly lower TC in the platform approach.

Fig. 10
figure 10

Detail of change scenario 3

Full size image

Operational flexibility can be determined for each approach according to the definition given in Sect. 3. In the component approach only the developer can implement a change. Thus, for this approach we obtain an operational flexibility of 30/30=1. Due to subsumption of the categories A to B and B to C, we receive a different picture for the platform approach. Here, the operational flexibility is 46/30=1.53 and with 53% is much higher than for the component approach.

All in all, the platform approach was able to reach a better result in the LC for all three simulated change scenarios. However, the platform approach causes higher TC in two of three change scenarios. The increased operational flexibility in the platform approach can be explained by the increased distribution of modification operations to various actors. Employees without further programming knowledge can now make (simple) modifications on their own This quality becomes especially apparent in case of capacity shortages for specific actors, such as developers. Regarding the labor costs a cost reduction can be shown for the scenarios in the platform approach – this, however, is usually traded off for an increase in transaction costs as a result of the increased interactions between multiple actors.

6.5 Limitations of the Model and Results

The graph-based model for transactions may not sufficiently reflect the complexity of software modifications. The TC are based only on simple relations in the graph. This assumption is legitimate only if the described change operations remain limited to certain areas in the organization (e.g. that changes are only communicated between user and configurator) and do not cause interdependencies beyond these regions. The relaxation of this restriction would increase the TC again and possibly neutralize any advantage gained.

The incurred costs were assumed on the basis of expert evaluations since an empirical basis is not available in the required granularity. Further analyses based on the presented model can be carried out by means of future empirical surveys.

The platform approach will possibly not be able to realize radical changes efficiently, while the component approach may be better suited. Under the assumption that radical changes occur with limited frequency, the proposed approach can be sustainably efficient. The frequency assumption may be inaccurate. Due to the specific flexibility of our approach, which assumes a basic process and allows for certain change operations, deviant extents of change requirements have to be assessed accurately. If changes exceed a certain quality, especially those requiring the costly adjustment of the code, then a change request by the configurator may be restricted or can even be rejected by the process administrator.

The realization of the platform’s service-orientation also carries additional costs in the use of process engines and service management as well as a non-negligible communication overhead in the form of XML data transmission. Alternative solution architectures need to be evaluated.

7 Conclusion and Outlook

Process platforms (in terms of PaaS solutions) founded on diagram-based and user-centered interfaces and composable services can be seen as an opportunity to further improve the changeability of business processes. In this article, we evaluated a platform based method which follows these principles. For the evaluation a model consisting of actors and types of modification was developed, which also allows for the formulation of labor and transaction costs. By means of this model we carried out an analysis of software change approaches with regard to flexibility and efficiency.

The simulation of three real-world change scenarios showed that the platform approach has advantages in terms of flexibility and efficiency compared to a traditional component-oriented approach for software change. The option that changes can be conducted by actors who are more closely involved in the business side, can help reduce the above described business-IT gap.

To demonstrate the general robustness of the approach it is necessary to conduct further empirical research. Potential change scenarios should be modeled as stochastic processes which allow for the analysis of the performance of alternative software modification approaches. In supplementing research the approaches which enable high operational flexibility and efficient implementation for certain assumed distributions of change requirements can be identified.