Keywords

1 Introduction

Service Identification (SI) is an important phase in Service-Oriented Architecture (SOA) lifecycle since it establishes the foundation for the later phases in the development of SOA [1]. Moreover, it is one of the main challenges in designing and implementing an SOA [2]. SI must support SOA promises of improving business agility, promoting business-IT alignment, and increasing the return of investment [3]. Service Identification Method (SIM) aims at identifying high-quality services based on desired SOA design principles [4]. Several SIMs have been proposed from both academia and industry [5].

Many SI challenges have been claimed in the research community that demand research efforts. A comprehensive overview of the existing SI challenges could help to establish a research agenda on SI. We could not find any literature reviews that explore the challenges related to SI in SOA; hence a comprehensive overview of the existing SI challenges in SOA is still lacking. This research study tries to answer the following main research question:

What are the claimed challenges of service identification published in the literature?

The main contribution of this research is to identify the main challenges of SI in SOA by conducting a literature review. The review can be very valuable when researchers and practitioners need to get a holistic view of the existing challenges in SI. To the best of our knowledge, there is no previous research that identifies the challenges in SI based on a literature review.

The rest of the paper is structured as follows. The conducted literature review is described in Sect. 2. Section 3 presents and analyzes the results of the review. The service identification challenges are described in Sect. 4. Finally, Sect. 5 concludes the paper and forecasts future research.

2 Literature Review

A literature review is defined in [6] as “a written appraisal of what is already known –existing knowledge on a topic– with no prescribed methodology”. The aim of this literature review is to identify the claimed SI challenges being recognized in the research community in order to present the state-of-the-art of SI challenges. Moreover, the review aims to provide the existing claimed causes, which are collected from the relevant literature, for each identified challenge.

We conducted a literature review exploring SI challenges that have been claimed in scientific studies published between 2005–2016. Table 1 provides a brief overview of the defined review protocol (i.e., plan). In this review, 46 primary studies are selected from 54 relevant studies to identify 8 SI challenges.

Table 1. An overview of the defined review protocol.

We apply the following rules to count the number of primary studies for each identified challenge:

  1. 1.

    A study is counted if it clearly proposed or faced a challenge during SI.

  2. 2.

    A study is not counted if it only cited a challenge that was proposed by another study.

  3. 3.

    Only one study is counted if a challenge was proposed by the same author(s) of different published studies.

Table 2 shows the distribution of the selected 46 primary studies based on publication year (i.e., 2005–2016) and source (i.e., journal, conference, book chapter, technical report, and thesis). The growing number of studies in each year indicates that SI challenges have been receiving significant interest in the research community. In regards to the source of the studies, the highest (i.e., 24) and lowest (i.e., 2) number of published studies belong to conferences and technical reports respectively. Moreover, the first two studies (i.e., [37, 39]) are from book chapters published in 2005, while the last two studies (i.e., [20, 45]) are from journals published in 2016. According to the publication year, the highest number of published studies (i.e., 8) belong to 2009. It is worth noting that most of the studies (i.e., 31 studies) were published in the years (2007–2009, 2013, and 2014).

Table 2. Distribution of primary studies based on publication year and source.

3 Results and Analysis

Table 3 presents the results of the literature review by providing a list of challenges in SI. The list is created by collecting the challenges from existing scientific research in the literature. Moreover, the list is ranked and sorted by the descending number of research studies that proposed each challenge. Based on the literature review, we identify 8 claimed SI challenges, namely from the top: service quality attributes, business-IT alignment, systematic SIM, comprehensive SIM, tool support, validation, input artifact, and configurability of SIM. The results further discover that service quality attributes challenge (specifically service granularity) is the top challenge.

Table 3. Challenges in service identification.

Figure 1 shows the distribution of SI challenges that were proposed for the first time based on publication year. It can be observed that the first challenge (i.e., business-IT alignment) was first proposed by [37, 39] in 2005. We also observe that the highest number of challenges (i.e., 3) were first proposed in 2006, one challenge (i.e., service quality attributes, specifically service granularity) was first proposed by [17, 27, 28], while the other two challenges (i.e., systematic SIM, comprehensive SIM) were first proposed by [27]. Moreover, validation challenge was first proposed by [21] in 2008, while configurability of SIM challenge was first proposed by [50] in 2010. In 2011, tool support challenge was first proposed by [46], while input artifact challenge was first proposed by [16, 49] in 2013. It is worth noting that the challenges were claimed between 2005–2013, also the researchers did not claim or identify new challenges after 2013.

Fig. 1.
figure 1

Distribution of SI challenges that were proposed for the first time based on publication year.

4 Service Identification Challenges

This section provides a description for each identified challenge in SI. Furthermore, this section presents the claimed causes for each challenge.

4.1 Service Quality Attributes (QAs)

A quality attribute is a feature that influences the quality of software systems [52]. Service quality is considered as an important factor since it is used by a service consumer to select from competitive services that deliver similar functionalities [9]. QAs can be categorized into two categories: external and internal attributes [53]. The external QAs (e.g., reusability, flexibility, and maintainability) represent the goals and promises of SOA. On the other hand, the internal QAs (e.g., coupling, cohesion, and granularity) represent the design principles that should be supported and fulfilled in the design of SOA to achieve its goals and promised benefits. The assessment of service QAs is essential to check if the identified services align with SOA goals, and also to enhance the quality of the identified services besides the SIM itself [43]. In the following, we provide the claimed causes, which are collected from the relevant literature, for service QAs challenge:

  1. 1.

    The difficulty of finding the right SOA-based metric model that can be applied early in the development of SOA systems to quantify their overall quality [19, 54].

  2. 2.

    The role of QAs when architecting Service-Oriented Systems (SOSs) has not been vastly studied yet [12].

  3. 3.

    Lack of a comprehensive quality measurement for service-oriented design [18].

  4. 4.

    Lack of mature processes to determine the business values and also translating them to QAs. Furthermore, there are many research efforts in how to deal with QAs in the overall lifecycle management of SOSs [13].

  5. 5.

    SI is a multiple objectives optimization problem [21]; hence service designers need to balance the trade-offs between various QAs, which are somehow mutually exclusive, to identify appropriate services [4, 10, 20, 21].

  6. 6.

    More than 50 challenges (i.e., quality-related issues) have been identified in engineering SOSs [9].

  7. 7.

    Almost all SIMs usually do not evaluate their quality, also only a small number of SIMs address service QAs [11, 14, 43].

  8. 8.

    Current SIMs focus on a few QAs [7, 8].

  9. 9.

    Lack of mechanisms in the existing SIMs to evaluate service QAs [43].

  10. 10.

    Lack of comprehensive and systematic SIMs that consider service QAs [11].

  11. 11.

    Lack of empirical studies that examine the QAs in practice [8, 12].

  12. 12.

    QAs lack precise definitions [19].

  13. 13.

    The designers need a consolidated understanding of the definitions and measures of the identified services’ QAs [14].

  14. 14.

    Only very few software metrics have been proposed for SOSs. Furthermore, some of the existing metrics lack empirical evaluation to validate them [15].

  15. 15.

    Lack of formal transformation from qualitative QAs (e.g., flexibility, reusability, and composability) to measurable indicators over a solution design [19].

  16. 16.

    Measurement of service QAs still has not been fully developed [20].

  17. 17.

    Architects face difficulties on how to establish criteria for measuring QAs, such as granularity and reusability [17].

  18. 18.

    Previous SIMs are often prescriptive (i.e., propose principles or guidelines); hence the quality of the identified services is mainly dependent on the architect’s experience that result in non-optimal designs since they do not use technical metrics for measuring service QAs [4, 14, 16, 55].

  19. 19.

    Current SIMs ignore the required managerial (i.e., reusability, maintainability) and technical (i.e., coupling, cohesion) performance metrics that represent the goals of SI [21].

Service Granularity.

Service granularity refers to the service size and the scope of functionality implemented and exposed by a service [28, 56]. Service granularity is considered a crucial design issue in designing a qualified SOA [4, 14, 24,25,26, 28]. Moreover, it has many direct and indirect effects on promises of SOA [26]. Service granularity is also pointed out as a quality attribute [11]. The level of service granularity (e.g., fine-grained, coarse-grained) impacts the service QAs, such as coupling, cohesion, complexity, reusability, and performance [10, 11]. In the following, we provide the claimed causes for service granularity challenge:

  1. 1.

    There is no theory-founded method for determining the right level of service granularity [27, 56].

  2. 2.

    Service-oriented analysis and design methods lack on providing a quantitative and comprehensive model to evaluate whether services are identified with the right level of granularity [14, 26].

  3. 3.

    Managing service granularity is considered a primary concern that affects design decisions. Moreover, identifying the right level of service granularity is a difficult task since granularity is highly dependent on an application context [28].

  4. 4.

    The developers of service-oriented applications face difficulties on how to determine the right level of service granularity to identify appropriate services [10, 11, 22,23,24,25,26,27, 56].

  5. 5.

    Lack of concrete guidelines to define the appropriate level of service granularity [57].

  6. 6.

    Architects face difficulties on how to establish criteria for measuring service granularity [17].

4.2 Business-IT Alignment

A close business-IT alignment is considered as one of the main valuable benefits of service-orientation [35]. Business-IT alignment requires the cooperation of the business community and the IT community [9]. Service-oriented software engineering methods should systematically move from business requirements to IT solution in order to align business with IT [58]. IT is used by leading CIOs as an amplifier of business and innovation [59]. In the following, we provide the claimed causes for business-IT alignment challenge:

  1. 1.

    Business-IT alignment is considered a key challenge even before SOA solutions [38].

  2. 2.

    Defining a suitable scope for business-IT alignment is considered as one of the challenges to migrate legacy applications to SOA [44].

  3. 3.

    Lack of alignment between the business and IT standards [40].

  4. 4.

    The need of integrating business architecture with IT architecture has been widely agreed [37, 39].

  5. 5.

    Information systems community requires the development of methods to vest service-orientation with business concepts for business-driven deployment of SOA [41].

  6. 6.

    The implementation of e-businesses requires the integration of business and technical aspects that imposes an enterprise applications integration problem at the technical level [42].

  7. 7.

    Only recently, business-related challenges (i.e., issues that have to deal with by enterprises due to SOA adoption) are getting more attention in the research community due to the growing need for business-IT alignment [9].

  8. 8.

    The existing SIMs lack on analyzing both business and IT perspectives to identify business and software services [43].

  9. 9.

    Lack of comprehensive and systematic SIMs that combine or address both business and IT domains [11, 35, 36, 43].

4.3 Systematic SIM

Systematic SIM refers to the method that provides detailed guidance for SI [20]. It is difficult to apply any SIM that does not provide detailed guidelines to identify appropriate services [34, 51]. In the following, we provide the claimed causes for systematic SIM challenge:

  1. 1.

    Lack of systematic SIMs that propose detailed guidelines [31, 33, 34, 45, 51].

  2. 2.

    Due to the short time since the development of systematic SIMs is in the focus of research, no one of the existing systematic SIMs was so far able to become widely accepted and dominate the others [32].

  3. 3.

    Lack of comprehensive and systematic SIMs [20, 27, 29, 30].

  4. 4.

    Lack of comprehensive and systematic SIMs that integrate business-driven and technical-driven SI [11, 35, 36, 43].

4.4 Comprehensive SIM

Comprehensive SIM refers to the method that includes all the activities of SI process. In the following, we provide the claimed causes for comprehensive SIM challenge:

  1. 1.

    Lack of comprehensive SIMs that include all the activities of SI process [1, 4].

  2. 2.

    Lack of comprehensive and systematic SIMs [20, 27, 29, 30].

  3. 3.

    Lack of comprehensive and systematic SIMs that integrate business-driven and technical-driven SI [11, 35, 36, 43].

4.5 Tool Support

Most of the existing SIMs do not provide any tool support for implementing or evaluating their processes [8]. The lack of automation refers to a large amount of manual work that is required by many SIMs to identify a set of services [34]. SIMs can be classified based on tool support into three categories: prescriptive, semi-automated, and fully automated [4, 16, 46]. In the following, we provide the claimed causes for tool support challenge:

  1. 1.

    Prescriptive SIMs are difficult to apply in practice, also they are hard to comprehend by the architects who may cope with a limited degree of complexity [4].

  2. 2.

    Limited support of automation in the existing SIMs [8, 16, 20, 45, 46, 55].

  3. 3.

    Lack of a comprehensive automated SIM that fully automates all the activities of SI process [16, 20, 34, 55].

  4. 4.

    Lack of human supervision in the fully automated SIMs [46].

4.6 Validation

Validation describes the way (e.g., case study) that can be used to evaluate the applicability of a SIM in practice. In the following, we provide the claimed causes for validation challenge:

  1. 1.

    Lack of practical research and evidence for the applicability of SIMs [8].

  2. 2.

    The current research is lacking empirical evaluation of SIMs at enterprise levels [21, 47].

  3. 3.

    Most of the existing SIMs have not been validated using case studies [20].

4.7 Input Artifact

Input artifact describes the type of input that a SIM starts from to identify services. SIMs have different types of inputs (e.g., business process, database, source code, etc.) that can be used to identify a set of services. Selecting the suitable types of inputs is considered a critical decision since the business or technical orientation of any SIM is determined based on its input types, also the process of preparing the input is considered timely and costly [49]. In the following, we provide the claimed causes for input artifact challenge:

  1. 1.

    Selecting suitable types of inputs in a clear and step-by-step form is still in its infancy [49].

  2. 2.

    The task of identifying services from various inputs has not been sufficiently solved yet [48, 60].

  3. 3.

    Lack of SIMs that use business process models (e.g., BPMN, activity diagrams) given by standard modeling languages [16, 55].

4.8 Configurability of SIM

Configurability of SIM is considered a critical attribute in situational method engineering that offers a flexible adaptation of methods [50, 61, 62]. New SIMs have to be configurable to accommodate different situations of the projects at hands in order to improve their applicability [1, 11, 20, 43, 50, 61,62,63]. In the following, we provide the claimed causes for configurability of SIM challenge:

  1. 1.

    Most of the existing SIMs do not address method configurability [43, 50, 61].

  2. 2.

    Lack of mechanisms in the existing SIMs to configure a new SIM according to the development situation [43].

5 Conclusion and Future Work

According to the results of the review, 8 claimed SI challenges were identified from the selected 46 primary studies, namely from the top: service quality attributes, business-IT alignment, systematic SIM, comprehensive SIM, tool support, validation, input artifact, and configurability of SIM. The findings of this review discovered that service quality attributes challenge (service granularity in particular) needs further attention in the research community since it is considered the top challenge. The identified challenges would help to find the gaps in current research and also suggest future research directions. Future work would include:

  • Analyzing the claimed causes of each identified challenge in service identification to provide possible solutions that address the identified challenges.

  • Conducting a survey for confirmation of the identified challenges from researchers and practitioners in SOA.

  • Developing a new SIM that considers the identified challenges for resolving the shortcomings of the existing SIMs.