A Service-oriented Architecture for Mass Customization - CiteSeerX

Manuscript ID: TEM-04-0267.R3

1

A Service-oriented Architecture for Mass Customization – A Shoe Industry Case Study Andreas J. Dietrich, Stefan Kirn, Vijayan Sugumaran

Abstract—The ability of enterprises to react quickly to changes in the business environment is becoming imperative. Mass Customization (MC) is introduced as a competitive strategy for diversified markets by combining principles of mass production and individualization. Here, information systems are needed for supporting the entire value chain, especially for managing product and process complexity. Based on a dynamic view of enterprises working together, context-specific IT-services must be provided for successful MC. In software engineering, a similar concept called service-oriented architecture (SOA) is receiving lot of attention. By integrating all the elements of business networks (including organizations and information systems) in a loosely coupled manner, technical representation of value processes can be established. In this paper, we present a SOAbased approach for MC and illustrate it with a case study from the shoe industry, based on a public-funded research project called “EwoMacs.” Index Terms—Mass Customization, service-oriented architectures, flexible business networks, information systems.

I. INTRODUCTION

T

he competitive environment of companies has increasingly intensified over the past few years due to globalization, high rate of innovation and scarcity of resources. Growing customer requirements and changes in consumer behavior are forcing companies to adjust to market changes quickly by having to redesign and change products constantly. Mass Customization (MC) provides the conceptual framework for the combination of mass production and individual goods and services. With individual goods, which are adapted to customer requirements, the needs of diversified markets can also be supplied [1], [2]. The infusion of MC business models where final products are manufactured not by forecasts of demand but by incoming orders alone has altered the traditional definition of supply chain by adding the actual consumer into the order process.

This new paradigm requires a significantly greater degree of synchronization of the entire supply chain including the inventory systems. Such a synchronized production process will necessitate greater coordination among the participating members of the supply chain and willingness to significantly improve the inter-firm communications [3]. Traditionally, inter-firm communication and coordination has been accomplished through Inter Organizational Information Systems (IOIS). However, the architectures of these information systems are fairly rigid and inflexible. Hence, they are not equipped to handle the dynamic nature of the environment necessary for MC. Moreover, IOIS present a formidable barrier for entry into the supply chain for small companies that provide specialized components. Thus, OEMs may not have an opportunity to form any kind of partnership with these companies. Hence, there is a great need for an open architecture for information systems that support the MC supply web. The main objective of this paper is to develop a seamless and common platform that can be adopted by the channel partners to promote interoperability. We contend that by building information systems that utilize service-oriented Architectures (SOA), the effective integration of the members of the MC supply web can be greatly improved. This is feasible because the SOA-based approach uses open standards and technologies such as Web Services and XML for building interoperable distributed applications. This paper is organized into eight sections. First, we introduce MC as a management concept and discuss the role of information management for supporting it. This allows deriving the requirements for information technology (IT) and information systems (IS) for MC, which is discussed in section II. In section III we provide a review of the relevant literature. Section IV presents the typical set of actors found within a MC value chain. In section V our proposed solution approach is discussed and the idea of SOAs as a technical representation of business service networks is illustrated. An illustrative case study is presented and the SOA for MC in the footwear industry is demonstrated. Section VI discusses the infrastructure needed to implement MC environments and provides examples of service description and process model. As organizational and technological changes impact management level, we discuss the implications of interorganizational IT approaches in section VII. Finally, the results are summarized and further research work is outlined in section VIII.

Manuscript ID: TEM-04-0267.R3 II. OVERVIEW A. Mass Customization as a competitive strategy Davis [4] introduced the concept of MC and provided an initial definition. Since then, several researchers have refined that definition, notably, Pine [1] and Piller [5]. Piller defines MC in a pragmatic way: “Mass Customization is the production of goods and services for a (relatively) large market, which meets the different needs of every single customer of this product, but at expenses which are similar to the expenses of mass production of an underlined standard product” [5, p. 206, translated by the authors]. Subsequently, he relaxed the postulation of keeping almost the same selling prices (for both mass and mass customized products). Thus, MC products can be offered at slightly higher prices that customers are willing to pay compared to a mass product. This can be explained by the fact that providing customized goods leads to a higher value of the product. In contrast to a craft production, MC does not cause a change-over from the current market segment to exclusive niches [2]. MC is based on several distinctive principles. In contrast to a single element of a classification model, the following characteristics are intended to be common for all MC scenarios: a) modularization of product architectures and processes, b) limitation of customization possibilities, c) ondemand approach, d) stable fulfillment of processes, e) split of fulfillment system into standardized and customer specific parts, and f) use of dedicated information systems for configuration, manufacturing planning, order tracking, and relationship management [6]. An additional aspect of MC is the inter-organizational cooperation between partners in a business network [2], [7]. This fact does not result from the definition, but it results from the postulation that every partner in the value chain should concentrate on its core competences. Thus company networks can be built up that are comparable to virtual companies, which work together in the area of a single product and offer a common service in the form of a product on the market [8]. During the last few years, discussion on MC has continued in several scientific domains. A comprehensive literature survey can be found in [2] and [9]. B. Classifying Mass Customization Duray et al. [10] use two main characteristics for classifying mass customizers: “customer involvement” and “product modularity”. They identify the following four archetypes for mass customizers: - Fabricators – directly involve customers during design and the components are customized in fabrication. - Involvers – combine standard models to meet customer needs with limited involvement in design and fabrication. - Modularizers – use structured products in design and fabrication but customers are not involved until the assembly and use stage. - Assemblers – realize customer involvement and modularity in the assembly and use stage. It allows the customer to

2

specify the product which resembles the underlying mass product [10]. A list of additional classification models can be found in [2, pp. 246-248]. Because of the broad understanding of MC in the literature and practice, we state more precisely how this term is used in this paper. With respect to the existing classification models for describing various instances of MC, we illustrate selective characteristics in Figure 1. Our usage of the MC concept in this paper is characterized by the values highlighted in grey for each of the listed characteristics. Characteristic Point of customer involvement Type of goods Object of individualization Executor of customization

Values of each characteristic Design

Fabrication

Material goods Primary good Customer

Retailer

Assembly

Use

Non-material goods Secondary goods Producer

Supplier

Figure 1: Selective characteristics of MC

The point of customer involvement can appear at different stages within the production cycle. As indicated in [10], customers can be integrated in the design stage, fabrication, assembly process and/or the use stage. In this paper, MC is realized through customer involvement in the fabrication or assembly stage. Thus, “customer-driven product development” [11] and “self individualization” [2] are not considered. Although MC is mostly related to customization of physical products, this concept is also applicable for non-material goods (e.g. business services [12] or digital goods [13]). This paper is limited to customized material goods (“products”) but transferability of this approach should be possible. A main product (primary good) may be supplemented by secondary goods such as accessories, after-sales service or maintenance. If the whole order of a customer contains several products (product bundle) customization can be applied to one, or a few, or all the goods. The approach shown in this paper focuses on the primary good. One aspect that characterizes MC efforts is the executor of customization. Depending on the product modularity the customization process can be done by the customer, retailer, producer or supplier. In this paper, we focus on the producer and/or supplier as the executors of customization. Having described the fundamentals of MC, we now discuss the need for information management as well as the technical requirements for developing our approach. C. The Role of Information Management for MC Customers interact with the enterprise offering masscustomizable products directly for every single order [14]. The role of information management (IM) for MC is bidirectional. On the one hand, an integrated information flow must ensure that a particular order can be fulfilled correctly. On the other hand, enterprises can improve their knowledge about products and customers by gathering information during

Manuscript ID: TEM-04-0267.R3 the product configuration process. Figure 2 shows the information cycle for MC, which will be used to illustrate the need for IM. Enterprises have to build product models, which include the individualization options. As products will not be unlimitedly configurable, individual parts of products and the amount of possible features must be harmonized with existing knowledge about customers’ needs (“product development”). The “re-orders” and “new orders” stages in Figure 2 address the selling process performed by a product configuration system. The profiles of present customers have to be managed as well as the creation of data sets for new customers. Also, a logical configuration procedure must be developed based on the product model. If details about producers and suppliers are integrated into the information flow to the customer, the point of sale is enriched because of better disclosure about delivery time, for example. Product Development

Distribution and CRM

Re-Orders Acceptance

New Orders Acceptance

Manufacturing Planning Production and Assembly Supply Chain Integration

Figure 2: Information Cycle of MC (based on [14])

Before production starts, manufacturing planning takes place. Here, the production network will be coordinated. Scheduling activities, workload planning and assigning of every manufacturing step to a specific enterprise will be executed. Depending upon the product model and its composition out of standard and individualized components, the producer has to purchase product components by handing over individualization data to the supplier. Customer relationship management establishes a long-term relationship between the vendor and a customer. Therefore, customer care activities need information about orders and customers. Re-orders can be simplified because of the existing customer profile. Finally, quality assurance needs detailed information about each product specification with traceability of the production processes and the components that are used. III. LITERATURE REVIEW In this section, we discuss prior work related to flexible information systems approaches for mass customization. This is done in two parts – the first part discusses MC-specific information systems and the second part provides existing SOAs for dynamic business networks. Then, we point out the contributions of our approach.

3

A. Information System Concepts for Mass Customization As mentioned above, MC requires adequate concepts for information management. Some of the information system concepts for MC addresses collecting individualization data, adapting product architectures, coordinating order fulfillment, unique identification of products, and supporting manufacturing processes etc. Piller [2] postulates that information technology is an enabler for MC. Since concepts for reducing complexity because of product variety are becoming more prevalent, many MC business models have come into existence and the concepts get more practical. Here, IT must support the entire information cycle. The application of web services for MC is discussed by Agrawal and Nandkeolyar [19]. By developing an interplant scenario they clarify how enterprises can interact over standardized interfaces. However, in contrast to our work, they do not provide explicit transference from business services to IT services. In [20] useful IT instruments for MC are outlined. However, there is no practical use or architecture development but simply lists several concepts like electronic catalogues. Rautenstrauch and Turowski [21] describe an interorganizational multi-agent system for MC. In [22] and [23] the benefits of cooperative agents for information logistics within MC are discussed. The agent-based approach considers autonomy and partial knowledge of participants of the supply chain. A general discussion about the implications of MC on information systems is provided by Dietrich et al. [24]. In particular, they discuss the requirements for future business systems that are suitable for MC. The main aspects here are customer integration, information flow throughout the value chain, and lose of autonomy. They provide an agent-based framework that combines process management and logistics simulation for coordinating MC supply chains. With the focus on production planning and control, Blecker and Graf provide an architecture for coordinating actors of a MC supply chain [25], [26]. Customers are integrated into this concept with interactions for product configuration. Product configuration is regarded as a major part of MC. It is important for meeting customer’s requirements that relate to the purchase of a customized product as well as promoting collaboration and satisfaction. A configuration model is used which includes the set of predefined product components and rules for combining them as well as rules for meeting customer requirements. In this subsection we provide a brief overview of MC-related work in this context because we have integrated product configuration processes into our solution approach. Wüpping [27] established that product configuration is a major part in realizing MC. He also discusses different configuration methods (e.g. rule-based approach), as well as organizational and technical aspects of implementation. Hahn proposes a common model for product information (e.g. product catalogue) and configuration rules using decision trees [28]. Hvam et al. [29] present a procedure for building product models. For product analysis and objectoriented analysis, two phases of the procedure trees and UML class diagrams are used [29]. A General model of product

Manuscript ID: TEM-04-0267.R3 families is illustrated in [30]. Model-based configuration is described as a combination of product modeling and solving the configuration problem. B. Service-oriented Architectures for Dynamic Business Networks Pour and Guo [31] provide an architecture based on web services to support supply chain management. By means of three actors (“customer”, “salesman” and “manufacturer”), they encapsulate the application logic between existing services in the value chain. In [32], a multilateral model for cooperation between business partners is introduced. Web services support ad-hoc interactions between four actors (“customer”, “salesman”, “forwarding agent”, and “bank”) by identifying potential business partners. Tiako [33] also advocates the use of web services for electronic markets. He has developed an actors model consisting of “customer”, “supplier”, “bank” and “logistic service providers” and specifies their services and mutual relationships. However, the above mentioned papers do not provide a systematic way to derive web services from business processes and don’t take into account aspects of product configuration in mass customization. The support of dynamic processes between organizations is illustrated by Schmidt [34] using an architecture based on web services. However, he does not provide an actors model; hence services cannot be assigned to specific actors. Koshida et al. [35] introduce a service-oriented approach to illustrate sourcing processes. Their model contains the following actors: “producer” (permanent and temporary), “wholesaler”, “retailer” and “association”. Besides describing the services for data- and function-oriented purposes, they also focus on locating business partners. Along similar lines, the combination of agent-oriented approaches and approaches based on web services are discussed in [36] and [37]. However, in these projects, the set of actors do not represent the multi-stage value chain and integrate the customer as a partner in the business network. C. Contribution of this paper While related to our current research, the articles discussed above do not consider the dynamic nature of the MC supply web and the realignment of partnerships needed to remain competitive. This requires effective information management as well as being able to find right partners at the right time. In our paper we focus on the well-known problem of supporting MC with information management and information technology [14], [20]. By taking an overall process-oriented view, we focus on seamless communication between all participants of a MC scenario. The decentralized perspective allows us to represent the autonomy of each actor. Our approach allows to identify win-win-situations for enterprises by enabling them to take part in MC business networks, manage economic effects and reduce the trade-off between their operational control and the global supply chain. The enabling factors for the promising benefit of our approach are:

4

customer integration, process data standardization, dynamic adjustment of supply webs, and partner sensitive access to the process models and the product model. IV. BASIC MODEL OF A MASS CUSTOMIZATION SUPPLY WEB A. Actors Model By building up intra-organizational interactions, business networks with multi-phase and spatially distributed value chain processes can be established. A typical set of actors for a MC scenario is illustrated in Figure 3. Actors are represented as nodes (circles), and interactions as edges (lines). As we take a highly aggregated view of the supply web, this model does not differentiate between systems, persons, and organizations. Production Network Logsistics Service Provider

Retailer

Supplier 2nd Tier

Supplier 3rd Tier

Supplier Customer

Configurator

Vendor

Producer

Figure 3: Actors model (based on [15])

Customer: Consumer of the final product, customers are involved more actively in comparison to conventional mass production. The customer is a partner in the value chain by acting as a “prosumer”1 [38], [39]. Vendor: The organization offering customized goods on the market is a vendor (“market maker”). It can also be a selling and marketing focused enterprise with no production plant. Configurator: A configuration system is the interface between the vendor and the customers. It identifies customer’s product requirements and the values of all product option parameters, and ensures that only valid and complete product specifications are approved for ordering. Retailer: Retailers act between customer and configuration system, customer and vendor, or logistics service provider and customer. This actor is not involved in the configuration process but only operates as an intermediary. Producer: The producer is responsible for planning, coordination and execution of manufacturing processes. Depending on the degree of vertical integration, production steps can be made in-house or substituted with external parts. Supplier: As part of the production network, these actors provide the producer with standardized or customized product components. Logistics Service Provider (LSP): This actor assumes the task of product distribution by interacting with other actors. While the LSP’s interactions are shown, the internal and 1

Made-up word, composed by combining producer and consumer

Manuscript ID: TEM-04-0267.R3 interplant logistics processes are not shown in our model. The main task of the LSP is to transport the customized good from the producer to the customer. The above list presents the usual set of actors within a MC scenario. Although it contains the relevant roles, in particular cases, supplementary domain specific actors may have to be modeled. The performance of such a value network greatly depends on adequate connections between the actors. Future information and manufacturing systems for MC have to support inter-organizational activities within the supply webs. Thus, before developing the overall architecture we have to delineate the IT support requirements for such systems, which are discussed in the following section. B. System Requirements Based on the results of the “EwoMacs” research project (www.ewomacs.de), we have listed the conceptual and technical demands, which have to be met during the implementation process. The project’s objectives are to analyze and optimize generic logistics structures for MC scenarios within the shoe industry. Empirical data was collected from two industry partners: adidas-Salomon AG and selve AG. As a result of interviews and analyses, we have determined the following conceptual requirements for MCspecific information systems [15]: - Support of interplant coordination: Customized mass products are made by several independent and autonomous enterprises (in consideration of their core competencies); - Assignment of value chain processes to actors based on their core competences: Each enterprise acts independently within different sections of the value chain (not fully vertically integrated); - Consideration of partial knowledge and autonomy of the actors: Creation of value takes place in a time and spatially distributed environment; - Representation of various process types: The entire production cycle consists of material or informational processes (e.g. cutting leather and collecting individualization data respectively) and can also be hybrid (obtaining individual preliminary products); - Providing mechanisms for managing product complexity as a result of individualization options: Goods consist of customized and standardized components which must interface well; - Integration of the customer as a partner of the business network; - Enabling seamless and permeable information transfer between actors: Reverse information flow allows the integration of the customer into the value chain. The development of information systems for supporting MC scenarios must be based on adequate technological concepts. From this point of view, the following technical requirements have to be met: - Flexibility of the technically represented business network in case of environmental and product-related changes (dynamic constellation of the participating actors due to the

5

entrance and exit of value chain partners) [16]; - Comprehensive and systemic technical support for the value chain (logistics & information management); - Semantic specification of product architecture, configuration, and production processes considering customized & non-order-related components [17], [18]. As we study the unsuccessful case studies reported in the literature, one of the major lessons learned is to standardize the communication and cooperation process among the participants of the MC supply chain. Efficiency must be improved by using information systems for harmonizing the principles of mass production with the challenges of product individualization. Shortcomings in this area often cause the break down of promising business models. V. MASS CUSTOMIZATION SERVICE ARCHITECTURE A. Solution approach: Concept of Service-oriented Architectures Adaptive information systems respond proactively to changes within organizations and their environment [40]. The understanding of value chains as a network of service units has a technological representation in software engineering, namely, service-oriented architectures [41]. In this section, the main characteristics of this concept are illustrated in addition to clarifying how they match the previously mentioned system requirements for MC (cp. section II.C). Service-oriented models are based on process management. Organizations communicate and interact with intra- and interplant business units. The type of the interactions (e.g. administrative or value-added) and their functions are defined within the specifications of business processes. By classifying the existing activities between enterprises (or actors in general) business processes can be understood as a combination of offers of and demand for generic services. Finally, a service-oriented architecture is built by combining and forming several IT services that represent the business services. The term “service-oriented architectures” (SOA) originates from standardization efforts of the W3C-Consortium and from developments in the software industry [42], [43]. As a technological approach for machine-to-machine communication, the SOAs are based on the idea of making resources available in distributed systems. The objective of this concept is to couple information systems loosely by using standardized interfaces and services [44]. These IT services can be requested over networks (e.g. internet) and they can be utilized and combined on demand. Therefore, at least one service provider and one service demander must exist in each case. A service provider is responsible for developing and executing services. In contrast, a service demander requests specific functions, which are not available in its systems but can be integrated by using external services. In order to find service providers and the services themselves, service directories exist that list the availability of services and related information.

Manuscript ID: TEM-04-0267.R3

1) Deriving Services In Figure 4, the service-oriented concept is applied to customized shoe production. The known actors are both the provider and demander of specific value-added services. The outcome of these generic services is indicated on the lines connecting two actors. Customers specify the characteristics of the desired shoes using a configuration system that is operated by the vendor. The vendor cooperates with a producer and places it in charge of the shoe fabrication. There is a choice between two alternative factories, which operate jointly with the suppliers of components (e.g. leather supplier). The products are distributed indirectly to customers by the logistics service provider (via the retailer). From a global view we will derive relevant services. The customer uses a “configuration” service for specifying the possible individualization parameters. This is an interaction between the actors customer and configurator. Since the configuration system can be an autonomous actor, the vendor uses the configurator for “order acquisition”. By doing so, the vendor can obtain new purchase orders for the products offered. The producer is responsible for the overall fabrication and interacts with the vendor for “coordination of production” service. The producer is also a simultaneous demander of the “supply of components” service. If it does not operate all fabrication processes in-house, it will also be a requestor of the “production step” service of the sub-producers. Finally, the “distribution” service is used by actors needing logistical support, for example between producer and retailer.

ut io n Di st rib

Logistics Service Provider E.g. Sole Supplier

Customer

Configurator

Vendor

S Co upp m ly o po f ne nt

Co o Pr rdin od a t uc ion tio o n f

Ac Or qu de isi r tio n

nf ig ur at io n

Factory 1

Producer Pr od uc st tion ep s

B. Architecture and its elements In this section, the SOA for MC is described. It is divided into four sub-sections: First, generic services conducted between the actors (organizations, persons, etc.) are derived (based on the actors’ model). Second, an example MC product is defined that can be customized by product configuration processes (product model). Third, the overall service architecture of a MC business network for shoe industry is presented. This scenario demonstrates how a value chain can be represented using a network of services. Fourth, an example shows the sequence of interactions during service execution.

Production Network Retailer

Co

Enterprises and business networks can be seen as a coupling of a multitude of services. For building up a SOA, it is necessary to identify and specify all relevant interactions between the actors participating in the value chain. From a business point of view, the SOA consists of a technical representation of the business services. Therefore, all fields of technical integration must be determined.

6

E.g. Leather Supplier

Factory 2

Figure 4: “EwoMacs” scenario enriched with value-added services

2) Product Modeling All product parameters and individualization options have to be previously identified and defined before offering MC products. Historical data, customer information, and market research can be used for product development. In order to ensure that a product is configurable, a product model is needed which contains all product components, individualization options, and limitations in setting the product parameters (e.g. possibility, dependency, etc.). An example product model is shown in Figure 5. For modeling the customizable shoe, we use the notation based on part-whole-relations presented in [45]. This modeling method has been shown to be useful for representing highly configurable goods [46]. The underlying concepts are parts list, which are visualized using gozinto-graphs [47]. As this method was extended by classification trees using hierarchical generalization, it allows for clear visualization of product alternatives and possibilities [48]. Dependencies between parts of a product are modeled using implications ( ). In order to represent that a part (A) needs another specific part (B), such implications are denoted with antecedents and consequents (A B) [49]. A shoe (C1) consists of an upper part (C2), insole (ts0), sole (A1), and heel (A2). The upper part itself consists of two components: vamp and lining leather (A3, A4). For these components, multiple types and colors are selectable (ts1, ts2,… ts6) but at least one type must be chosen for both A3 and A4. For the sole, a rubber or leather variant exists (ts7, ts8). The heel is available as a small or wide version (ts9, ts10). As implied, there is a component-based limitation in selecting the sole and heel. If ts7 is chosen (rubber sole), the ts10 option (wide heel) is obligatory.

Manuscript ID: TEM-04-0267.R3

Figure 5: Product model of the MC shoe

C1

Photo © www.selve.net

A3

ts1

ts2

A1

ts0

C2

ts7

A4

ts3

ts4

7

ts5

A2

ts8

ts9

ts10

ts6

ts1

Piece of Text (Smallest part of the product at a specific level of abstraction)

C1

Conjunction (Components of an agregated part of the product)

A1

Disjunction (Choice among alternative components) Implication (Limitation in choosing components)

´ < < s e r v ic e > >

< < s e r v ic e > >

m e a s u r in g

d e s ig n in g

< < s e r v ic e > >

< < s e r v ic e > >

c o n f ig

a c q u is it io n

< < c o m p o n e n t> >

< < c o m p o n e n t> >

< < s e r v ic e > >

m yS hoes

vendor

p ro d c o o rd

< < c o m p o n e n t> >

< < s e r v ic e > >

< < s e r v ic e > >

< < c o m p o n e n t> >

LSP

d is t r ib u t io n

f a b r i c a t io n

p ro d u c e r

< < s e r v ic e > >

< < s e r v ic e > >

< < s e r v ic e > >

< < s e r v ic e > >

c u t t in g le a th e r

s e w in g le a th e r

s h o e a s s e m b lin g

d o q u a lity c h e c k

< < s e r v ic e > >

< < s e r v ic e > >

< < s e r v ic e > >

< < s e r v ic e > >

le a th e r s u p p ly

h e e ls u p p ly

s m a llp a r t s s u p p ly

s o le s u p p l y

Figure 6: Basic SOA for the MC shoe industry

The product model is used by all actors dealing with supply of components, fabrication of individual parts and assembly of the shoes. As actors normally need only part of the product model it should be exchanged between the actors partially. For example, preparing the upper part needs knowledge about C2 with its subordinated elements (A3, A4), but assembling the shoes requires the first level elements only (C2, ts0, A1, A2). After modeling the key processes within the MC supply

web and defining the offered good by building a product model and specifying the individualization options, a basic SOA is developed in the following section. 3) Service Architecture Based on the actor model (section IV), the product model (section V.B.2.) and the specification of generic services, a SOA can be developed. In Figure 6, the services of the SOA

Manuscript ID: TEM-04-0267.R3 for MC in the shoe industry are presented as a UML diagram. In general, the SOA UML diagram consists of various components and services that are specific to MC in a particular domain. Successful fulfillment of an accepted order requires effective and efficient collaboration among the various services provided by the actors. Customers specify their desires and requirements for the product. Each order is treated separately and will be stored in the myShoes component. By using the configuration service, config, the informal product idea is transformed into a formal product specification. The myShoes component represents the customer and is accessible through various user interfaces. As it can be seen from the product model, the configuration process must define several product parameters (e.g. color of leather, size of shoe, etc.). Therefore, the configuration service in turn uses two specialized services for finishing the product specification: the measuring service for determining the shoe size and the designing service for setting the design options. If the configuration process is finished and the order is accepted, one of the main phases of customer integration into the value chain is completed. The next step of overall production focuses on the vendor. As already mentioned, the configuration service is an order acquisition instrument for a vendor of MC products. If the configuration system is not operated by the vendor, the acquisition service acts as a broker. The prodcoord service contains the selection and assignment of suppliers and producers. It is conducted by the vendor. By using the fabrication service, manufacturing of the product is managed. Specializations of the existing services are related to the product model. Here, all respective parts of the product can be derived: leathersupply, cuttingleather, and sewingleather are related to specific components of the upper part of the shoe; heelsupply, solesupply, and smallpartssupply belong to the entire product. The doqualitycheck service is related to product-based quality assurance. Physical transportation of the finalized products is supported by the distribution service. For each order, the tasks of the described service network are repeated. In the architecture discussed above, all interactions are shown as information flows. As real business scenarios obviously consist of both material and informational flows, the different impacts must be considered during the implementation process of a SOA. First of all, technical representations of value-added services by IT services (e.g. Web services) can be seen as a virtual simulation of the underlying business processes. However, for practical use, the effects of digital services onto material processes have to be discussed. Besides services that deal with only information exchange (e.g. data mining, configurations processes etc.), there are two other implications with possibly two kinds of

8

effects: (1) Information flows of a SOA service can trigger an event that causes the beginning of a material process (e.g. end of production triggers distribution process), and (2) Information flows of a SOA service may be used as a substantial input for the material process (e.g. the product specification dataset generated at the end of configuration process is used as the input for the manufacturing processes). There has been a push towards digitizing services and informational representations of physical goods for years. So, an approximation of the combination of informational and material services to form largely digitized supply webs with technological support using the SOA approach has a broad appeal. Therefore, enterprises have to define their business capabilities in the form of services. While this makes the supply web more agile and flexible, there are several managerial implications, which are discussed in section VII. 4) Example After describing the conceptual parts of the SOA for MC we provide an exemplary order process for customized shoes. A UML sequence diagram is used for modeling the interactions between the actors and their assigned services. Figure 7 indicates how the services are executed one after another. In order to reduce the complexity of the diagram the fabrication related services have been omitted (indicated by the two parallel lines on the right side of the figure). Starting with an expression of interest, the customer initiates the flow of services. The customer chooses one of the offered products (e.g. on a website). This causes a request to be sent to the configuration service because the product must be specified by collecting individualization data. The configuration process consists of two sub-processes, which are executed successively. First, the measuring service collects anatomic information of the customer in order to match it against the size of the product and its components. After that, the designing service integrates styling information. Once a product is specified completely, the order is sent to the acquisition service. This service represents an interface between configuration systems and vendors of MC products. We emphasize this separation because configuration systems can be provided as a vendor independent service within public networks. Here, vendors can cooperate with many configurations systems. A configuration system can be invoked by several vendors and vice versa. After the order is received, the production coordination service selects and assigns a particular producer to it. Additionally, the order information is sent to the producer. The fabrication service entails several sub-services (e.g. supply services and manufacturing services). Once the production is completed, the distribution service will be requested. This service responds to the production coordination service. Once the acquisition service is triggered by the production coordination a message is sent to the customer (e.g. by email).

Manuscript ID: TEM-04-0267.R3 myShoes

send (interest)

config

measuring

designing

acquisition

9 prodcoord

fabrication

distribution

request (config ) request (measuring) response (measuring)

Customer request (designing) response (designing) send (order) assign (producer) instruct (producer) send (order)

request (distribution )

response (distribution) response (prodcoord) response (order)

Figure 7: Sequence diagram of the example

The approach shown in this paper considers several issues of MC manufacturing systems. First, product configuration and order fulfillment are integrated into one model. Second, we provide an actor model for representing all relevant roles in the MC supply web. Additionally, product models are distributed partially with correspondence to the actual information demand of each actor. Finally, the over-all information flow is represented in order to enable vendors to give information back to the customers if needed (e.g. extension of the estimated delivery time). VI. IMPLEMENTATION In this section, we discuss technologies for implementing our proposed approach and provide an initial infrastructure architecture for implementing an MC environment. This includes a report on the current progress of implementation. A. Enabling Technologies Recently various approaches for implementing SOAs have been developed. Basic technology paradigms as well as proprietary software products are available (for an overview, see [50]). In the following sub-sections, two basic technologies, namely, Web services and software agents are discussed as approaches for building SOAs.

1) Web Services A web service is defined as “a software system designed to support interoperable machine-to-machine interaction over a network [and it] […] has an interface described in a machineprocessable format” [51, p. 6]. For this purpose, three XMLbased technologies have been established: WSDL (Web Service Description Language), UDDI (Universal Description, Discovery and Integration), and SOAP (Figure 8).

Find

Service Service Directory Directory

WSDL

UDDI Service Service Requestor Requestor

Publish

Interact

SOAP

Service Service Provider Provider

Figure 8: Web service technologies

WSDL is used to describe and formalize web services and the current version makes it possible to separate service descriptions (Meta data on availability and location) from the functions of the service [52]. UDDI allows for registering and searching for services within directories. Classification into categories is possible by constructing taxonomies [53], [54]. Potential users search for suitable services on UDDIservers. After successful retrieval, the user communicates with the service provider directly in order to initiate the service execution. Finally, the instructions for processing the service are defined by the SOAP protocol, which uses XML-based communication. A SOAP message contains system information and the actual message, i.e. the semantic

Manuscript ID: TEM-04-0267.R3 information for the targeted system of the service demander. 2) Software Agents Agents are software units, which are able to perceive and modify their surrounding [55]. As elements of a system, they are embedded into an environment and can act autonomously and adjust their behavior based on the changes that take place in that environment [56]. Furthermore, since they can recognize neighboring systems and communicate with them, agents have quasi-social characteristics [57]. Unions of at least two agents are called multi agent systems (MAS). MAS are established to solve complex problems jointly. Using a form of speech acts and services, agents are able to communicate. The interaction can consist of simple information transmission to the realization of extensive tasks. In this context, methods for adaptive coordination, such as planning [58], negotiating [59], or cooperative problem solving [56] are very applicable. B. Infrastructure architecture Our MC infrastructure uses Web Services and Agents. The architecture for a system implementation is shown in Figure 9. The architecture consists of: a) service providers, b) web service registry, c) service consumers, and d) customer application. Service providers are various actors within the MC supply chain that offer different services such as fabrication, shoe assembling etc. Typical services that are offered in the shoe industry are shown in Figure 6 and each actor in the supply chain may provide one or more of these services. The web service registry is a repository that maintains the list of available services. This UDDI-registry uses WSDL-documents for describing the functionalites of the services and how to invoke them. Overall processes are defined by using BPEL4WS-documents (Business Process Execution Language for Web Service) [60]. Service consumers are components that make use of the

10

available services. Examplary components are configurator, vendor, producer, and logistics provider. Each of these components utilizes the demanded services from the registry to accomplish the goals they have for an actor in the supply web. The configurator component is responsible for selecting most appropriate product specification based on user measurements and additional requirements (such as color or accessories). The vendor component makes use of the Actor Model and the Product Model in materializing customized goods to be supplied to the market. The service consumer components may employ one or more agents to accomplish their task. For example, components may use service locator agents for searching for appropriate web services from the service registry. Similarly, there may be other agents that handle service composition, optimization, quality of service, etc. This agent federation also facilitates communication between various components in order to achieve the overall objective. Both technologies are combined in our approach because Web services offer a flexible integration concept that can be used to assimilate disparate systems coupled with coordination principles from agent technology [61]. Web services support the business cooperation processes and agent technology provides algorithms for planning, scheduling, and coordinating them. Once appropriate services and the actors that provide them are identified, the components can directly interact with those actors and invoke the services. The consumer application provides the interface for the customer to provide their personal information as well as their specifications for customization. Typically, it is a web based application with a browser interface.

Manuscript ID: TEM-04-0267.R3

11

Service Consumers Vendor

Configurator

“Actors Model” “Product Model” “Over-all process”

Service Locator

Consumer Application

Supplier

UDDI Service Registry

Producer

LSP

… “solesupply”

“distribution”

“prodcoord” “fabrication”

Service Providers Figure 9: Mass Customization Infrastructure Architecture

C. Implementation of MC Web Services As a service represents business processes, a detailed specification of its functions must be defined. For each service shown in Figure 6, interfaces for accessing the service, invocation requirements of its operations, and message input/output data must be committed. The configuration service, for example, must offer a list of methods, which are needed to carry out the product specification process config (Figure 10). In the following, we show some of the included output methods of this service. Before the configuration process starts, a list of available products can be received by using the getArticleList method (e.g. shoe model “basic”). After choosing a particular product, all configurable parameters are named by getArticleOptions (e.g. color, size, type of sole). The setArticelOptionValue method allows to specify the values of a particular article option. As shown in Figure 10, this method invokes supporting services (such as measuring or designing) in order to choose values or match them against the customers’ requirements (step 1 requests the measuring service, step 2 sends the results back to the config service; step 3 requests the designing service and step 4 responds with the result). The list of possible values is accessible through the method getArticleOptionValues (e.g. range of shoe sizes or results of the measuring service). The dataset of the actual product individualization can be received using the method getCurrentSpecification. Finally, the method getValidationResult checks the chosen product options and confirms that the specification is valid and ready for order acceptance and production release.

config - getArticleList - getArticleOptions - setArticleOptionValues - getArticleOptionValues - getCurrentSpecification - getValidationResult

1

2

measuring

3

4

designing

Figure 10: Methods of the config service

The abstract specification of a particular service (e.g. measuring) is provided by WSDL document. The orchestration of the dynamic processes within the service architecture is described by BPEL4WS documents. Figure 11 shows how services can be described using WSDL. The root element contains all relevant elements of the service specification [52]. The namespaces used are defined in the upper part of the document. The tag defines the message that will be transmitted by using this service, the tag contains the dedicated operations that the service will execute, and the defines roles which are related to the actors of the underlying business process. The config service contains an operation called “doConfig” (sub element of ) which returns the result of the configuration process for a specific article option. Thus, this method has two input parameters: article number and the identification number of the article option (defined as elements within the tag). The service

Manuscript ID: TEM-04-0267.R3 sends back the results of the configuration process. Figure 11: WSDL description of the config service

The overall process is modeled using BPEL4WS as shown in Figure 12. As this example concentrates on the operations of the process, we hide some additional elements of BPEL documents (e.g. additional sub-elements of ). The process is named as “configProcess” in the root element . Services that are interacting with the process are defined as partners in the element. All sequentially running activities are specified within the element. The set of possible activities can be found in [61]. This example contains (waiting for a message of a process partner and assign the content of the message to a variable), (manually assign values to variables), and (call an operation of a particular service). Additionally, corresponds to the elements and answers the received message. ...