A Service-Oriented E-Commerce Reference Architecture

Electronic commerce (e-commerce) is getting more and more important in people’s every day shopping routines. Vendors who want to establish an online channel besides their traditional retail practice have to integrate the two supply chains. The underlying information technology systems should be able to support the integration of the new and old processes. While reference models are a popular means in designing this type of systems, the existing reference models in the field of e-commerce only give insight into the business processes and ignore the entire enterprise architecture. In this paper we address the lack of such a comprehensive reference architecture. Based on a systematic literature review, on current trends, and best practices in e-commerce landscapes we derive a reference model for service-oriented e-commerce architectures. The proposed architecture integrates new business partners and customers into the internal processes


Research Design
Our research is twofold and it combines a literature study, which aims at identifying the current state of the art in ecommerce architectures with the development of a reference architecture. For this purpose, a multi-method approach is applied consisting of a systematic literature review nested into a design science research cycle. Figure 1 visualizes the process we followed in this study: The design science research methodology described by [57] includes the following phases: 1) problem identification, 2) definition of objectives, 3) the development of an artifact, and 4) its validation. The artifact that is proposed in this study is an architectural model that outlines all the building blocks for an e-commerce solution and is based on the architectures proposed in current academic contributions in the field of e-commerce. The list of relevant literature and its categorization is presented as an intermediary artifact prior to the development of the actual architecture.
To systematically analyze the existing literature we follow the approach of [45]. This means that the process incorporates three steps: study selection, study qualification, and data extraction. The study selection is further divided into the definition of search criteria, the collection of the papers, and the application of the selection criteria. The presented architecture can be equally used by scholars and practitioners to further investigate the topic or to build solutions based on the aggregated knowledge on e-commerce architectures. As the architecture is derived from the current e-commerce research, it also gives insights into which aspects are over-or underrepresented in the current papers in the field of e-commerce.
Fettke et al. propose a framework to approach reference modeling by looking at the context, existing reference models and the modeling language [27]. In the remainder of this section we use this framework to outline the objectives for the e-commerce reference architecture model.

Context
The context of the reference model describes the technical, organizational and economic scenario in which the modeling process is embedded. According to the motivation for our research we focus on an e-commerce scenario in a retail context, where the business model of the retailer is to buy and store a large quantity of goods, and resell them in smaller quantities. This e-commerce process does generally not include production of goods but can include certain activities of finishing or customization. It usually includes additional services before, during and after the selling of goods. The process includes business-to-customer (B2C) as well as business-to-business (B2B) ecommerce transactions, between the e-commerce company, its suppliers, partners and customers.
In this study we are focusing on an enterprise architecture that reflects business processes and the required IT resources. The latter should be identified in a service-oriented manner in order to allow the users of the model to escape from the application centered thinking when designing their landscape. Neither the implementation of the services, nor how they might be bundled in various application systems are important. The system owner should be able to choose and exchange the IT services according to the business needs and overcome the limitations of monolithic business applications. We are going to cover internal business services, and more importantly, services that allow communication with business partners such as suppliers and logistic service providers.

Existing Models
A number of related reference models can be found in the scientific literature. Those models mostly focus on the business process of an e-commerce scenario and do not present a comprehensive architecture for e-commerce. In the following we present those models, discuss their limitations with regards to the context of this study as well as their potential reuse in the architectural model.
Becker's H-Model for retail [8] provides a domain-specific reference architecture for retail enterprises. The model describes eleven tasks within the three major groups of procurement, storage and distribution (Table 1). Different views allow the extension or simplification of the model according to business requirements. The model is based on the Architecture of Integrated Information Systems (ARIS) framework and contains three viewpoints which are business functions, processes and static data. The model originates from a traditional retail business model and ignores some functional tasks that are specific to e-commerce.
Frank's E-MEMO -Reference Business Processes and Strategies for E-Commerce [29], [30] contains a library of 85 business process models divided into nine business functions. Table 1 shows a mapping of these business functions to the functional tasks of the H-Model.
In [11] Burt and Sparks investigate the impact of e-commerce on the retail process. Their procedural model is used as a framework to compare activities, ownership, costs and efficiency in an e-commerce setting against traditional retail. According to this model the retail process comprises five business functions, which we mapped as well onto the previous models in Table 1. This procedural view on the retail process is more or less in line with the 8 business functions identified by [33] for a similar purpose. This paper is available online at www.jtaer.com DOI: 10.4067/S0718-18762016000100003 Some other reference models such as [20] exist and provide a specific focus on parts of the overall business process, such as order fulfillment and supply chain matters. These reference processes might be relevant on a more detailed level of the ERA.  [8] Frank [29], [30] Burt [11] Gunasekaran [ None of the above mentioned models considers return handling activities as a primary business function. Compared to traditional retail, return handling is a critical activity, as the volume of returned goods is much higher in online shopping. A proper return handling strategy is essential for online retailers in order to limit the expenses caused by these high volumes. In three of the models we are also missing an explicitly defined customer service business function. Other than in offline retailing, online customers need to be provided with a hotline and e-mail help center in case of any individual inquiries or exceptions from the regular transaction process, which does not involve any personal contact as opposed to a brick and mortar shop.
Apart from these minor functional gaps, existing retail models do not cover IT aspects such as application layer and technology components that make up a complete enterprise architecture. Building information systems based on the available models will eventually lead to information systems that support either one specific business function or the end to end process. These are in most cases either a bunch of horizontally oriented systems that support one business function only or monolithic systems that are not able to support the integration of specific application services. In order to overcome this development a reference architecture model that includes all required IT services which can be reused across business functions will lead to an agile and open architecture.

The ArchiMate Modeling Language for Enterprise Architectures
The modeling language of a reference model is important because it sets the formal framework and viewpoints taken in the specification of the systems. The H-Model and the E-MEMO model for example are using the ARIS framework and the process modeling language MEMO-OrgML respectively. To facilitate the shift from this process centric modelling frameworks to a more comprehensive view of the enterprise architecture, the ERA presented in this paper is specified using the ArchiMate language [37] which was developed to model all the aspects of complex organizations. Figure 2 shows a simplified version of the ArchiMate core meta-model. The language distinguishes between three layers: the business layer, the application layer, and the technology layer. Within each layer, ArchiMate considers structural, behavioral, and informational aspects. It also identifies relationships between and within the layers. Each layer is a means to provide services to the next higher level where the highest level provides business services to the customer. For a full description of the language, we refer to [37].   [49]. According to Lee et al. existing literature reviews fall into either of the following two categories: generic reviews identifying themes and methods in ecommerce across disciplines [19], [48], [56], [69], [74] or studies focused on one specific aspect of e-commerce namely economic theories [43], marketing [63], customer relation and satisfaction [15], [60], adoption [16], payment [21] and marketplaces [71].
According to this categorization our contribution falls into the category of studies aggregating existing knowledge from literature with regards to one specific theme. Other than the existing literature reviews our focus lies on the identification of building blocks for e-commerce architectures discussed in recent e-commerce studies. These will allow us to develop a state of the art e-commerce reference architecture based on the knowledge of the last decade.
In this section we are going to describe how this research was carried out.

Data Sources and Search Strategy
In order to capture a maximum number of relevant sources we carried out two selection cycles. The search query for the first selection cycle was developed collectively by the authors. The search query of the second selection phase reflects synonyms and related terms that where found during the first selection phase. The following search query was defined for the first selection phase: (E-commerce OR electronic commerce) AND (architecture OR SOA OR EA OR reference model OR platform) To increase the ratio of relevant contributions and due to the generic nature of some of the used search terms we limited the search to the title and abstract of the publications. We also limited the search to publications that where published within the last 10 years as we want to investigate on the state of the art. Some of the above mentioned literature search services allow the direct entry of the search query, some require multiple searches to achieve the same. After omitting the duplicates and scanning the titles 880 documents were taken into the selection phase described in Section 4.2.
After selecting the papers the search terms have been extended to cover synonyms and related terms that turned out to occur often in the abstract of relevant publications. In the second selection phase the following query was applied: (E-commerce or ecommerce or electronic commerce) and (component or model or process or framework or platform or service o cloud) After pre-selection and removal of duplicates 3292 additional papers entered the selection phase.

Study Selection and Study Quality Assessment
To select relevant publications from the large list of found documents we filtered them based on their title, abstract and available meta-information by using the following inclusive criteria: The document is published in a journal, conference, workshop, as a technical report, thesis or book (chapter) to ensure that search results meet certain academic quality standards and have been peer reviewed.
The document proposes an architecture for e-commerce scenarios or discusses design principles or best practices.
All papers have been scanned independently by the first two authors to increase objectivity of the results. After applying the above filtering criteria a list of 864 papers has been generated. To further limit the amount of papers considered for this study the papers have been rated with scores from 1-5 by scanning the full content of the paper: 1 Pts Has no relationship to e-commerce architecture at all 2 Pts Discusses one aspect of e-commerce architecture 3 Pts Discusses several aspects of e-commerce architecture 4 Pts Proposes a partial architecture
Based on the papers of the final selection of literature we have carried out the literature review. This has been done by using a coding technique that extracts categories from the paper [62]. By using in-vivo codes the authors extracted the relevant architectural concepts from the papers and later grouped them into semantically identical categories. This way we maximize objectivity while identifying the architectural building blocks and minimize the effect of projecting the authors' assumptions on e-commerce architectures when applying predefined criteria to the sample. In the next section we are going to present the results of the coding.

Results
The purpose of this section is to give an extensive overview of the academic research on e-commerce architectures since 2003. In order to do so, both a qualitative and a quantitative analysis are carried out. We deem both analyses as necessary because the quantitative analysis helps us to get a general overview of the trends and topics in academic research on e-commerce architectures, while the qualitative analysis gives insights into the content of the papers and forms the base for the identification of artefacts belonging to the reference model. Four different perspectives are taken that are used to classify and analyze the selected literature.
In the first place, the papers are analyzed from a technological point of view. This first dimension describes the underlying software technology or the framework used to design the solution. Both are included, since not all papers design a technology oriented architecture, but may take other perspectives such as knowledge, stakeholders, or process perspectives. By doing this, we provide an overview of the used technology and extract relevant information for the reference model. Secondly, the different types of artifacts have been proposed by the various authors (e.g., an architecture description, model, or a framework). Thus, the second dimension aims at classifying the selected papers according to the type and nature of the proposed artifact. The third dimension is concerned with application functionality, i.e. the functional building blocks (e.g., the application services) of the proposed solutions. According to the ArchiMate meta-model these could be components, services, application functions, objects etc. of the proposed solutions. Extracting them from the selected literature provides us with an overview of the most relevant and most discussed functional building blocks which will be further used as the basis for the application layer of the reference model. Similarly, the fourth dimension is concerned with technological building blocks of the proposed solution such as devices, nodes, system software and infrastructure functions. These form the basis for ERA's technology layer.

Reference Architecture
Reference models are a means to facilitate the process of information system design by providing enterprises with a reusable and adaptable blueprint for a class of domains. It helps to validate current solutions and supports the development and selection of new applications [27]. Especially organizations with limited resources can profit from such models [29]. Their benefits are lower costs, less expertise needed, and less time to design the architecture. A In this section, based on the four reference models discussed in Section 3.2 and the conclusions of the literature review, we propose a new extended ERA. The main distinctions between our model on one hand, and the existing models on the other hand reside in the scope and in comprehensiveness: all existing reference models are in essence process models while ours is a reference architecture model that goes beyond business process specifications. More precisely, in this section we cover the concepts belonging to the business, application and technology layers, i.e., the application services proposed enabling business processes, and the technology services that are used internally and enable the provisioning of the application services.
The approach we followed in designing the new reference architecture is based on the methodological foundation described in Section 3.3. The business layer of the ERA is based on the context and the existing process models presented in Sections 3.1 and 3.2. The application and technology layers are then derived from the findings of the literature review in Section 4.3. Figure 6 shows the three layers of the ERA as well as the relationships within and across the layers. In the following we are going to elaborate on each layer individually.

External Business Services
On the business layer, from an external viewpoint and according to the context of our model the online retailer provides three main services. Similarly to [51], we make a distinction between pre-trade, trade and post-trade in ecommerce. A more in depth investigation of activities and tools for external e-services in e-commerce is provided by [64]. In an online retail scenario pre-trade are product information services and encompass all activities in which the end customer gathers information and consultancy about available products leading to a possible buying decision.
Product Information Services are services offered by the e-commerce company prior to the sales transaction, such as: Searching for products to get specifications of the product and the offered price Getting subjective information on the products, such as reviews from other customers or the retailer Generating product recommendation based on customer profile information, especially on past purchases Product Purchase Services, are the services which allow the customer to purchase the product. Those are: Order entry allowing the customer to close a buying contract Payment allowing the customer to settle purchases Fulfillment of the contract concerning the home delivery service of products to the customer Post Trade Services are all the services which take place after the purchase, including: Warranty processing services such as repair or exchange of defect products Support services, e.g. troubleshooting problems or software updates Return services for damaged products or reverse transaction of purchased goods

Application Services and Components
The application layer describes the software artefacts used by the internal business users, customers and partners to achieve their business goals. Active structure elements of this layer are application components which are selfcontained units of functionality. They include, among others, behavioral elements such as application functions, and services. Passive structure elements are data objects.
As a result of the literature survey in Section 4.3 we have identified 19 different concepts that are mapped onto the different element types of the ArchiMate language. More precisely, six main application components have been identified, namely Procurement, Sales, Customer Service, Logistic, Finance and Production. The latter has only limited applicability to e-commerce (see Section 3.1), which is confirmed by the limited contained functions and services discussed in the literature. Components such as Sales and Procurement provide a couple of application services. However, the application functions implementing those services have not been discussed in the literature. Although in general e-commerce literature provides an overview of the main application components, we get little insight into the specific details of these components.
Besides the main application components, other generic components have been mentioned in the literature, such as Authentication, and Search. These components are characterized by their universal applicability across the business specific applications. We argue that the list of such generic components could be extended with Communication, and Collaboration (including documentation), Policy Automation, and Business Rules, or Data Analysis and Reporting to name just a few.
Another building block contains the Product Information service based on the actual product data. We put these components separately as we think they do not belong to one specific application component but are shared resources across specific application services and functions. Furthermore, Product Information can be considered as just one out of a number of other shared resources in the e-commerce landscape. Trading Community data (customers, suppliers and partners) and Sites are other examples of master data that are used across application components.
A mapping of Business Functions to the Application Components has been carried out in order to identify gaps between the two layer models, and to find out if there are any business functions that are not supported by the application layer of the model or vice versa. Table 4 shows the result of this exercise. As mentioned in Section 3.1 production is not a critical business activity in the context of this study as we mainly deal with the retailing of finished goods. Only finishing or customization steps are considered as production activities in this context. Nevertheless production components have been mentioned in a number of e-commerce studies and, therefore, we consider them relevant during sales and order fulfillment. The procurement component is used in particular on the supply side, i.e. when purchasing, receiving, and paying goods. The sales component is critical throughout all other business functions that deal with the actual marketing, selling, and distribution activities. We also consider it for warehousing and receivables as stock levels and reverse sales transactions should be reported to the actual sales data. Customer service is relevant in pre-sales or marketing activities, during sales, and to provide after sales service, or returns. The logistic component is used for inbound, outbound, stockholding, and returns handling. Finally, the finance component handles accounting such as receivables and payables. It should also be able to enable monetary aspects of sales and reverse transactions.

Technology Services and Components
To complete the architectural model, a mapping of the concepts in Table 3 to the technology layer of the ArchiMate meta-model has been carried out. Despite of this classification, these concepts are connected to each other.  Hardware and Network infrastructures act as fundamental basis for other concepts. Supported by these infrastructures, technological advances emerge; these advances started by Legacy Systems, which are a special type of systems that is characterized by its use of outdated technologies and its potential replacement; and continued by Cloud Systems, which can be considered as an alternative to on-site systems, and as a special type of virtualized hardware infrastructure. Both have been discussed only in one study, [13], [65], respectively.

Validation
To validate the ERA we carried out a single case study as proposed by [77]. The goal of the case study is to map the ERA to a real world case in order to identify potential gaps in the model. The chosen case originates from the orderto-delivery practice of a major Dutch online retailer for media and books. The architecture of the various key processes was gathered during a series of workshops in cooperation with the head of the organization and the IT architect. In the following we are going to present the high level architecture including four key processes, as well as the executing and contributing IT components.

Case Study
The case study consists of four core processes, and the required IT systems. The four processes are chosen with the goal of obtaining a comprehensive view of all IT systems, i.e., adding another core process to the architecture will not lead to any changes in the application layer. Figure 7 shows an overview of processes and systems. It includes pre-sales activities in the form of sales campaigns, the actual sales transaction and the customer credit check, as well as the picking and packing of the orders. In the following we are referring to the different layers of the ERA for validation.

Retail Processes
The ERA contains ten different business functions, which are responsible for the various processes. These are: three front office business functions responsible for pre-sales, sales, and post sales activities, three back office business functions, which can be further divided into strategic and operational functions, as well as four different supply chain functions. The four core processes of the case study can be unambiguously mapped onto these business functions. The goal of the run campaign process is to increase sales through marketing initiatives which can be special offers, or other programs offered to a specific group of existing customers. The process encompasses the identification of the target customer group, selection of the customers, and the communication to the customer through various online channels. These pre-sales, front office activities are part of the marketing and branding business function of the ERA. The sell product process allows the customer to place an order providing delivery and payment information, and ends with the order confirmation. In terms of the ERA it is a front office sales activity and belongs to the pricing and selling business function. The purpose of the credit check is to approve the payment method for the transaction. Based on the past payment behavior of the customer and the information provided by an external credit agency certain payment methods such as purchase on account will be granted or not. The process can be considered as a backoffice activity and is part of the collection and receivables business function. Finally, the pick and pack process is part of the order fulfillment business function which is one of the four supply chain activities of the ERA. This process encompasses the split and combine logic for orders with more than product, box size determination, picking of product and printing of invoices.

Application Services
Each of the described business processes is supported by a collaboration of application components. Within the collaboration one main component manages the overall process execution while the other components deliver additional logic or data. For example the sales transaction is handled by the web shop while the external payment service and the product catalog are providing additional payment functionality and product information. The provisioning of higher level services by composition of various services is reflected on the application service layer of the ERA. However most of the literature proposes distinct, generic business process management services responsible for orchestrating the various business services. This approach can be beneficial to support the centralized management of the business process life cycle including design, development, execution monitoring and improvement, but has not been globally adopted in practice.
The application services covered by the ERA include front office, back office, and supply chain services. However, on a more detailed level only particular services have been covered in the underlying literature. While for example the back office services for negotiation, contracting, sourcing and purchase are covered, sales and accounting related back office services from the case study have not been found. The same applies for the supply chain services where the warehousing service related topics are not being discussed in the reviewed e-commerce literature. One can argue that those topics are not specific to e-commerce as warehouse management is a generic

Application Components
When it comes to the actual application components providing the various application services the ERA contains eight main components. In the case study on the other hand nine different components are used. In Table 5 we map the application components of the case study to those included in the ERA.
The most dominant application component in the case study is the enterprise resource planning (ERP) system which covers financial, procurement and sales functionality. It also is the de facto master data management system. While the e-commerce literature differentiates between these components, in practice much functionality is bundled into one system and provided as modules. However, other components mentioned in the literature are more complex and are handled by a number of different systems. For example the logistic component consists of a warehouse management component, on the one hand, and the warehouse control system, on the other hand. In the same way the sales component consists of a web shop, a separate product catalog, and the sales module of the ERP system.

Technology Services and Components
The ERA provides four different technology layer services. The application services and data services are consumed by the various business applications of the case study. As mentioned earlier the organization has not implemented a dedicated master data management system. Thus, there is no application layer counterpart to the technical data services. The same applies for the business process services were the company uses the build in functionality of the applications to support the process lifecycle. Accordingly the underlying technology components are less differentiated compared to the ERA. The various applications rely on various application server, and database nodes. One exception is the customer service application, which is entirely cloud-based, and has no footprint on the technical layer, a scenario which is also reflected in the ERA. However, the company operates advanced printing facilities, which are required for printing invoices and the production of flyers and leaflets that are included into the shipments. This component has not been found in the e-commerce literature and is not part of the ERA.

Conclusions
In this paper we have shown how traditional, process oriented e-commerce models can be extended to get insight into the application and technology layer services and components. We have studied relevant literature since 2003 and came up with an enterprise reference architecture, which is specified in the ArchiMate language. The reference architecture can be used for several purposes: It can be implemented in various ways. In particular the implementation of a service-oriented e-commerce platform is an upcoming research endeavor of the authors.
It can be used to validate existing solutions with regards to their comprehensiveness.
The architecture also gives an overview of the state of the art in e-commerce research and points out gaps as mentioned in Section 6.
The proposed architecture is drawing exclusively on components exposed in the academic e-commerce literature, and uses a well establish framework to structure them. The architecture can, thus, be considered as objective, as it excludes authors' or any biased parties' assumptions on e-commerce architectures such as platform or software vendors. On the other hand the architectures proposed in the literature might focus (due to topical trends or expected research value) on certain aspects and leave out some components that should belong to a comprehensive architecture. In the following we are discussing each architectural layer in this respect.
The business layer of the architecture is based on a number of existing reference models. The most dominant model in this collection is the Retail-H from [8]. The other models are matching all, a subset, or a specialization of the business functions identified by the Retail-H. The only exception to this is the customer service function which is only mentioned explicitly by the model by Frank [30]. We think this is due to the origin of the Retail-H model in a brick and mortar setting where individual customer communication is an inherent part of the sales process, which happens face to face. Frank's model in contrast focuses specifically on e-commerce and considers the fact that the sales process itself is automated, and individual communication requires a distinct practice, such as a call center.
The application layer of the ERA is based on the literature review, and proposes six main business specific application components. Furthermore, master data and generic constructs can be found in the model. As mentioned before the containing services can only be considered as a placeholder for further master data and generic services. Some of the main application components contain in turn further services, especially sales and procurement applications are discussed in more detail in the e-commerce literature. Other applications such as customer service or logistic are not very elaborated. This might be due to their extensive applicability in broader contexts than just ecommerce settings. Further investigation of those topics in specific literature for customer service and logistics could be helpful to analyze in detail these application components, but is beyond the scope of this study. Nevertheless, from an enterprise architecture perspective, a good overview of the application layer is provided in the existing ecommerce literature.
The technical layer of the proposed reference architecture contains the most common middleware nodes, the underlying infrastructure, and the services used by the different application layer components. The implementation of all the services is not described in detail. For example, security and user management is described in various studies, but we learn very little about how these are implemented in an e-commerce context (for example what encryption techniques are applied or how users are managed across applications). The e-commerce literature is not going much into detail here, probably assuming that the implementation of those technical services does not differ from those used in other domains. Similarly to the application layer, going into the details about printing or user management systems would be beyond the scope of this study.
The comprehensive view of the overall process and data has led to large end-to-end monolithic software solutions in the past. Nowadays companies are struggling to maintain and to replace those legacy applications with new systems or cloud-based offerings. The shift from modeling application functionality as self-contained services may help companies to build their systems in a way that pluggable components can be exchanged more easily with new offerings based on the business needs and without architectural constraints.
The surveyed literature helped us identify the most important functional and technical building blocks facilitating ecommerce operations. These findings helped us transform existing reference models and identify required services. The evaluation has shown that there is no gap between the systems covered in the case study and the reference model layers. Further evaluation of the architecture is possible through validation by experts or an analysis of existing solutions on the market. While the latter is subject to another future research by the authors, we think it has a higher risk of subjectivity then the presented approach.
When shifting from monolithic systems to integrated self-contained services new challenges will arise. To assure variety and flexibility in a system, a platform is required as a stable unit among the evolving services [5]. Building a service platform for e-commerce that allows to integrate the functional building blocks identified in this study will help retailers and partners to achieve more flexibility and sustained innovation. While platforms are slowly evolving in the industry no research has been carried out on what components such service platforms require. The quality, complexity, and pluggability of the resulting system, and its downsides are subject for future research.