There are numerous academic methods that can be used for service modularization; however, these methods have not been classified according to their specific characteristics. Furthermore, a clear overview of the necessary steps to achieve an idealistic modularization process was still missing. A suitable classification would not only be of assistance to practitioners in selecting and adopting these methods but would also highlight which steps of the modularization process have been neglected so far, thus identifying future academic gaps. In general, classifications are used to provide a systematic order of elements of a population by dividing them into classes on the basis of common properties or characteristics (Bailey 1994). The elements (in this case, modularization methods) are grouped into classes, thus simplifying the representation of a population and enabling the systematic description of complex facts (Brennan 1987; Sodeur 2013). The classification framework is based on two dimensions (bold bullet pointed items), with six phases and three characteristics respectively (shown by cursive emphasis).
x Process phases24: The first dimension is based on the sequential flow of the modularization process and consists of six interconnected phases, with the output of a single phase being used as the input for the subsequent phase. The phase of Information Capturing marks the beginning of any (structured) modularization endeavor. The definition of the desired target state is hereby influenced by the meta-levels of service modularity presented earlier (i.e., objectives and scope). The outputs of this phase include structured documentation and service models recorded in texts or diagrams.
The gathered information then undergoes Decomposition into the smallest meaningful service elements that will later be used for the module composition. Depending on the specifics of the industry and the provider’s individual characteristics, the service portfolio can be decomposed on multiple conceptual levels (Dörbecker et al. 2014). For example, processes can be broken down into
24 It should be mentioned that the presented six phases portray an idealistic and complete modularization process (Figure 11), which may still differ depending on a company’s individual characteristics and level of readiness.
42
single activities (Lin and Pekkarinen 2011) or customer demands can be transformed into detailed functional requirements (Geum et al. 2012). The output of this phase is a collection of unstructured elements, which represent the company’s service portfolio on the lowest (desired) granular level.
The next phase is the Structuring of these elements based on their appropriate characteristics or descriptive dimensions. The interdependencies between the elements can be either quantified (Browning 2001; Corsten and Salewski 2013) or structured, based on the predefined qualitative attributes (such as the type of support or level of customer involvement (Erixon 1996; Stone et al.
2000)). The output of this third phase is a detailed element structure that will be used in the next phase, which means that all three phases (decomposition, structuring, and module creation) should be planned together in advance. The phase of Module Creation marks the core of the modularization process and is intended to cluster the atomic elements of the service provider in a most efficient way (i.e., satisfying the set modularization objectives and scope). The techniques for module building range from quantitative methods, such as clustering algorithms (Hölttä et al. 2003; Song et al. 2015) or heuristics (Stone et al. 2000) up to qualitative evaluations based on expert knowledge (Yu et al.
2008) or card-sorting approaches with customer participation (Kohlborn and Pöppelbuß 2013). The output of this phase is a set of loose modules, each consisting of highly homogenous elements. Next, in order to provide the modules with a necessary functionality and exchangeability (thus reaching the required variety of services or service packages), the phase of Interface Definition is required.
Apart from the technical specifications for the information flow (e.g., extract, transport, load (ETL) processes, data validation mechanisms) ensuring the interaction between the modules and the compatibility of their respective inputs and outputs (Wang et al. 2011), the interfaces may also implement a set of logical rules, enabling or excluding certain module combinations (Böttcher and Klingner 2011; Erixon 1996). This phase results in a modular set of configurable modules with pre-defined interfaces and configuration rules. Finally, the modularization process is concluded by the Testing phase, which covers functional (i.e., testing of the modules and their respective interfaces), non-functional (i.e., testing of the overall operational efficacy and efficiency), and domain-specific (i.e., evaluation of the service portfolio in the designated application scenario) requirements (Boucher et al. 2016; Peters and Leimeister 2013). The result of this phase is a ready-to-use modular service portfolio that can be integrated in the provider’s operations (more information on that will be provided in P4 and P5).
x Types of structuring. The second dimension of the classification framework rests on different approaches as to how elements and modules are ordered and operated, which results in three different types of structuring. The Logical type of structure is inherited from the domain of products and is characterized by a hierarchical composition of elements that can be pre-produced in advance (Pine 1993). Similar to bills of material in manufacturing, elements are represented as static trees or graphs. In contrast, due to the process character of services and the inseparability of production and consumption (Zeithaml et al. 1985), Temporal structures can be used to represent chronological sequences of activities or value-creating events (Böttcher and Klingner 2011). These structures are usually characterized by the definition of the predecessor-successor relationships (Wang et al.
2011), along with constraints prohibiting the initiation of a certain process step should the previous one have not delivered the corresponding input. Here, modelling languages which focus on the process character of services, such as flow charts, Petri nets, or specific modelling languages (e.g., Business Process Model and Notation (BPMN)) are used for the visualization of these structures (Peters and Leimeister 2013). Finally, if a modularization method combines these two structuring techniques (e.g., by introducing additional dimensions for characterization), this results in a Complex type of structuring. Examples include a Multiple Domain Matrix (MDM) that combines an arbitrary amount of logical Design Structure Matrices (DSM) (e.g., in the context of health services (Dörbecker et al. 2014)) or the Service-Metamodel for knowledge-intensive business
43
services that enhances a logical tree structure with additional logical and temporal dependencies (Böttcher and Klingner 2011).
For similar reasons as those presented in P1, a hermeneutic literature review (Boell and Cecez-Kecmanovic 2014) was used to identify potential methods for service modularization (further details on the selection process can be found in P3). Overall 16 distinct modularization methods25 were selected and structured using the developed classification framework (Figure 11).
Figure 11: Classification of Existing Methods for Service Modularization
Examining in further detail the first dimension (process phases), it becomes clear that structuring (16)26 and module creation (13) are the two phases most frequently covered. On the one hand, this can be traced back to the fact that these phases can also be solved mathematically (e.g., DSM or Modified House of Quality) if appropriate input is provided (e.g., a decomposed service portfolio together with the corresponding customer requirements if applicable), thus attracting additional researchers situated outside of service science. On the other hand, together with the decomposition (9), these three phases build the core of service modularization, and are, therefore, by default at the center of academic attention. Methods covering solely these three phases either regard the remaining ones as optional
25 Details about each of the methods, along with their intended use, inputs and outputs of single modularization phases, as well as their application context, can be found in P3 or online under www.bakerstreet-projekt.de.
26 The numbers in the brackets in this text block indicate how many of the 16 methods fall under a certain
44
(Buchmann 2016) or unnecessary (Stone et al. 2000). Next, the phase of information capturing (5) has been covered (or at least mentioned), as an initial step of the modularization process, by only a handful of researchers. The status quo of the service provider is captured by any of the following three: the process flow of the service provision (Böttcher and Klingner 2011; Peters and Leimeister 2013); the estimation of customer demands (Lin and Pekkarinen 2011); mapping customer demands against relevant information on the market and competition (Wang et al. 2011; Yu et al. 2008). Similarly, little attention has been devoted to the phase of interface definition (5), with all publications exhibiting temporal or complex module structure, despite the topic of interfaces being essential for ensuring the functionality of service modules. For instance, the topic was explicitly addressed by Böttcher and Klingner (2011), where temporal and logical interdependencies between modules determines the subsequent configuration rules of the modular service portfolio. The remaining four methods mention interface definition only briefly, emphasizing only the necessity for a closer examination during the actual implementation. Finally, testing (3) appears to be the most under-researched phase, with only three methods indicating the necessity of testing the created modules, their respective interfaces, and the functionality of the modular architecture as a whole. However, neither of these methods provide specific test procedures, nor do they offer any information as to the use of the appropriate IS necessary to support the use of the modular service portfolio in the Run-Time (e.g., via the use of online configurators). In general, with only two methods covering the whole modularization process (albeit remaining on the abstract level and thus insufficient for real-life deployment), this classification framework proves that the research direction ‘methodical support’ (cf. section 2.2.3) requires further academic attention.
As for the second dimension (types of structuring), two trends are observable. First, there are barely any methods relying solely on the temporal structure (3). This may seem unexpected due to the process character of services, but it also underlines the complexity of service modularization which require additional logical rules or a combination of different dimensions (Lin and Pekkarinen 2011).
Interestingly, two of these three methods cover the whole modularization process (Peters and Leimeister 2013; Yu et al. 2008), albeit both of them remain on a rather abstract level, paying explicit attention to the interconnectivity of each of the phases. The distribution of the remaining methods among logical (6) and complex (7) is almost equal. However, another tendency is the chronological shift of the methods towards complex structures. Earlier methods, such as DSM (Steward 1981) or dendrograms (Hölttä et al. 2003), were initially developed for product domains and exhibited a wholly logical structure. Modern approaches, however, have a complex structure, either considering different service dimensions or combining products and services during the modularization process, via the introduction of new concepts (such as integrated-service-products (Li et al. 2012) or PSS (Boucher et al. 2016; Wang et al.
2011)). In addition, complex methods tend to cover more stages and primarily consider the practicability of the results (i.e., their preparation for the Run-Time), while logic methods generally approach the topic of modularization from the academic perspective, focusing only on certain phases and making simplified assumptions for the remaining ones (e.g., none of the logically-structured methods covers the topics of interface definition or testing).
In conclusion, it can be stated that the presented two-dimensional framework of process phases and types of structuring is a useful artefact for classifying existing and future modularization methods. The academic value can be found in the identification of under-researched phases of the modularization process (i.e., information capturing, interface definition, and testing), together with the summary of current research trends in developing new modularization methods, thus contributing to the research direction ‘methodical support’, as described in section 2.2.3. Similarly, practitioners may use this as an overview of the modularization process with the special attention devoted to the principal modularization objectives and scope. The results of this Build-Time phase produce a ready-to-use modular service portfolio. The question now arises on how this can be operationalized in the context of KIBS providers; this forms the focus of P4 and P5.
45