Keywords

1 Introduction

The context of this work is reuse in the course of creating and adapting software (SW) supporting business processes, where reusability depends on the explicit availability (and use) of a business process model (BPM). Reuse of software and of related BPMs together has the potential to increase efficiency and thus to reduce costs and time-to-market. However, the trade-offs with related investments into reusability need to be better understood.

More specifically, we focus on reuse based on repositories, as illustrated in Fig. 1. This approach integrates reuse of (similar) business processes and their adaptation for the case at hand (possibly also involving their composition) with reuse of related software parts (such as components or Web-services) and their adaptation. It requires repositories filled with reusable artefacts of both kinds, which can be efficiently looked-up for retrieval of (similar) artefacts as needed. This, in turn, requires some effort for making artefacts reusable. So, we discuss trade-offs between investments into reusability and related benefits for efficient software and process reuse.

Fig. 1.
figure 1

Business software development with reuse from repositories

Full size image

The remainder of this paper is organized in the following manner. First, we provide an overview of related work both on software and business process reuse and reusability. Then we explain an integration of software and business process reuse. For such a reuse approach, we compare trade-offs between making reusable and reusing in the context of developing software supporting business processes.

2 Related Work

Software reuse and reusability have a long tradition in general, see, e.g., [4], where Frakes and Terry reviewed, among other things, metrics and cost-benefit models. Rotaru and Dobre [14] studied the adaptability and composability of software components, both qualitatively and quantitatively (through metrics). Recently, Mohr [10] presented metrics for functional reusability of services based on their relevance. So, for software parts even quantitative measures related to their reusability are available. These could be used in the context of our approach for software reuse.

Reuse of business process models is the act of designing business processes by using existing process models. To this end, typically BPM repositories are employed. Requirements for such repositories from a stakeholders’ perspective were defined in [16]. Elias and Johannesson [3] provided a survey on repositories for process models. A similar survey was carried out by Yan et al. [17]. Such repositories may serves as building blocks in the context of our approach for BPM reuse.

For retrieving relevant BPMs from such a repository, Dijkman et al. [2] described graph matching on business processes to search and find similar processes. Business process fragments may be reused during business process modeling by integration [9]. According to [1], business processes are compositions of sub-processes or process fragments. Both composability and variability are necessary for deploying a business process in an adapted way. This work may be used in the context of our approach for BPM retrieval and adaptation.

When both a BPM and related software parts are available, software supporting the modeled process may be directly driven by the BPM [11]. Based on this idea, we recently proposed a software architecture including a BPMN 2.0 engine and a model of business artefacts for aligning the architectures of the business and its supporting software [5]. BPMs can be enriched at their enactment with additional artefact information for addressing certain usability problems of such software. We build on this previous work in our overall approach for integrating a BPM directly in the software.

3 Integrated Software and Business Process Reuse

Based on this previous work, integrated software and business process reuse is possible as illustrated in Fig. 2. Business Software Reuse as sketched at the bottom of the figure may happen with virtually any software reuse approach. The figure shows a simple case-based approach, where software cases are stored in a repository, selected using some similarity measure, and adapted for the case at hand. Even a single scenario was sufficient for finding useful software cases in [7]. Such an approach is also part of a feature-similarity model for product line engineering recently co-proposed by one of these authors [8].

Business Software Reuse is integrated in our approach with Business Process Reuse as sketched at the top of the figure. Also for such a reuse, different approaches are possible. Analogously to software reuse, the figure sketches the selection of a business process (more precisely a BPM) from a repository and its adaptation. According to [13], such a process adaptation can be an adjustment or a refinement. Both may be performed even automatically through model transformations specifying business rules (see also [12]). Model transformations have also been used for automated tailoring of a software process [6], but we consider this outside the scope of our approach as presented here.

Ideally, every BPM in the repository could be executed using the software artefacts in the repository. After a process adaptation, however, some part of the adapted BPM, e.g., a Task (as illustrated in green in Fig. 2), may not be executable by any piece of software in the repository. Then a related software adaptation will be necessary. It may have to be done manually, but model transformations could be employed as well.

Fig. 2.
figure 2

Integrated business process and software reuse

Full size image

4 Comparison of R&R Trade-offs

The R&R trade-offs in the context of software supporting business processes are between an initial investment to create reusable software or BPM artefacts, and the benefits from having either or both of them available for later reuse. We compare such trade-offs in three different scenarios that primarily differ in what is given for a development or change effort:

  • Software development from scratch

    This is the extreme case where nothing would exist yet for being reused, not even software built for prior (similar) projects.

  • Software available, but neither BPMs nor repositories for reuse

    This is a case where software exists, which has to be changed or may be informally used somehow for creating similar software. However, no investment into (systematically) making artefacts reusable has been done yet, neither for software nor BPM artefacts.

  • Repositories filled with reusable artefacts

    This is the other extreme case where investments have been made for creating both software and BPM repositories with reusable artefacts.

These scenarios are obviously on different levels of R&R maturity for software (see, e.g., [4]). However, they do not involve software artefacts and processes only but also related business process artefacts or processes dealing with them.

Table 1. A comparison of approaches to software development and change based on reuse and reusability
Full size table

In Table 1, these scenarios are given in its rows. The columns contrast software development without any systematic reuse or reusability with the R&R approaches illustrated above in Fig. 2. In the third column, a software repository filled with reusable software artefacts is assumed to be available and used. In the fourth column, in addition, a related BPM repository filled with reusable BPMs is assumed to be available and used. “MR” indicates an investment through making reusable, while “R” stands for reusing.

Such a trade-off can obviously be in terms of some cost measure. As discussed below, however, investing some cost for MR may have a positive return by R in terms of time, e.g., time-to-market, i.e., in a different ‘currency’. We also discuss positive and negative results in terms of quality. So, we discuss trade-offs with a triple (cost, time, quality), which was also inspired by [15].

Let us start with the scenario of software development from scratch. If it focuses on development only, then there is no investment into explicit reuse later. If there is no BPM available, developers directly encode the business process in the source code. However, if an executable PBM is explicitly given or created for the software supposed to support this process, this BPM may be directly included into a specific software architecture and drive the software at runtime (see, e.g., [5]). While this approach can be efficient, it reduces the flexibility of the software and may even entail usability problems. In terms of making such software reusable, investments should be made here to enter pieces of software such as components or Web services into a software repository. This requires that a repository is technically available or has to be created, and the artefact to be stored has to be enriched with meta-data and organized into the repository. In addition, the BPM should be made reusable as well by entering it into a repository, analogously to entering pieces of software. These investments are usually in terms of cost. While they will also take extra time, it can be spent in parallel to development projects.

When software is already available from previous projects, but neither BPMs nor repositories for reuse, then source code has to be added or changed directly. The difficulty of doing this will depend, e.g., on the software architecture. If an executable BPM drives the software, primarily adaptations of such a model will have to be made. Investments for making such software or BPMs reusable in repositories are basically the same as indicated above. When this is done only after several projects have already created software and models without making them reusable, then even some reverse engineering may have to be done additionally now.

For the scenario with repositories already filled with reusable artefacts, development will try to reuse as many as possible to make best use of them. Let us first have a brief look at the well-known case where software artefacts (only) are available for reuse in a repository. In general, it will be more efficient than software development from scratch, i.e., there will be a return of invest from MR for R in terms of cost. Actually, there should also be an improvement in time-to-market, where the investment by MR in terms of cost is paid back in terms of time. When software artefacts are often reused, it is well-known that they may become more mature, i.e., there may be a return of invest in terms of quality.

If an executable BPM drives the software, primarily adaptations of such a model will have to be made and, if they can be implemented completely by software parts from the repository, ideally no software developer will have to make any change to the source code. This requires a given framework for automatic execution of BPMs, however, with the possible downside of reduced flexibility and quality, e.g., of the user interface.

If, in addition, a repository full of BPMs is available, then they can be reused as well. In particular, BPMs may be found in the repository as needed, and two or more of these BPMs may be merged. If these BPMs are supported well by stored software parts, then ideally not much new software will have to be created anew, in stark contrast to pure software development in such a case without reuse. The return of invest from MR on this level may also be in terms of cost, time and quality through R of BPMs, much as through indirect R of related software artefacts.

5 Conclusion

In this paper, we discuss trade-offs between reuse and reusability of software supporting business processes, depending on different development approaches with and without explicit business process models and corresponding repositories. This discussion is based on the literature and on previous work of these authors.

This work aims to contribute an improved understanding of these trade-offs for different development approaches for software supporting business processes. In particular, such trade-offs may arise with different currencies, e.g., cost vs. time-to-market, with effects on quality as well. We found an argument why efforts into making artefacts should be invested early, since otherwise even additional effort in some reverse engineering may arise. Overall, a reuse approach integrating both business processes and software artefacts appears to have a high potential.

Still, our comparison is based on qualitative assessments only. Based on already existing work on metrics especially in the context of software reuse and reusability, future work should investigate such trade-offs quantitatively as well.