A Framework for Integrating Shopping Cart Software in Mobile Applications (Fiscsima)

EXAMENSARBETE INOM TEKNIK, GRUNDNIVÅ, 15 HP STOCKHOLM, SVERIGE 2018

A Framework for Integrating Shopping Cart Software in Mobile Applications (FISCSiMA)

VALTTERI LEHTINEN

JACOB KRISTERSSON

KTH SKOLAN FÖR ELEKTROTEKNIK OCH DATAVETENSKAP A Framework for Integrating Shopping Cart Software in Mobile Applications (FISCSiMA)

Valtteri Lehtinen Jacob Kristersson

September 15, 2018 Abstract

Today an increasing share of shopping is happening online. The purchases are often made on online stores that are in turn often managed by software called shopping cart software. Simultaneously a new shift is underway in the e-commerce market where more and more purchases are made from mobile phones. In order to take advantage of this shift companies are eager to integrate their shopping cart software into mobile applications that take full advantage of the mobile phone’s capabilities and give the mobile shopper a better experience. Depending on the shopping cart software used, the software vendor might not provide any best practices for doing the mobile integration. Without any help from the software vendor, the businesses are facing a difficult problem with many possible integration architectures to choose from. The problem is therefore, that selecting the optimal integration architecture for integrating shopping cart software into a mobile application can be challenging and complex. In this thesis we explore the domain of shopping cart software with the purpose of developing a framework for integrating shopping cart software into a mobile application. We suggest an integration architecture selection framework, which we call A Framework for Integrating Shopping Cart Software in Mobile Applications (FISCiMA). Our goal is twofold: (1) guide entities in choosing an integration architecture for shopping cart software and (2) to provide a basis for further research in the domain of integration architecture selection models. Conducted research is of qualitative type, research method is applied research and research approach is inductive reasoning. We work in five research phases: (1) Literature study, (2) Interview of our client, (3) Design of framework, (4) Evaluation and (5) Fine-tuning. Following these phases, we collect basic knowledge of shopping cart software and their mobile integration from the two first phases to design a framework in the third phase. The designed framework is then evaluated in the fourth phase and finally improved according to the feedback received from the evaluation in the fifth phase. The evaluation of FISCSiMA framework is done using a questionnaire, which is answered to by our involved body. The results of the evaluation suggest that the framework is intuitive, straightforward and flexible and simplifies the integration of shopping cart software into mobile applications. The authors suggest further work should be done to evaluate the merits of the FISCSiMA framework and research if the FISCSiMA framework could be applicable to other types of software. Keywords: e-commerce, Shopping cart software, mobile application, framework, integration Abstract

Idag handlar ett ökande antal konsumenter online. Konsumenter handlar ofta på onlinebutiker som i sin tur hanteras av programvara som kallas kundvagn mjukvara. Samtidigt pågår ett nytt skifte på e-handelsmarknaden där allt fler konsumenter handlar online från sina mobiltelefoner. För att dra nytta av detta skift och ge konsumenter som handlar online via mobilen en bättre upplevelse vill företag integrera sin kundvagns mjukvara in i mobila applikationer som kan bättre utnyttja mobiltelefonens unika förmågor. Beroende på vilken kundvagns mjukvara som används finns det en risk att mjukvaruleverantören inte tillhandahåller metoder för att integrera deras kundvagns mjukvara in i mobila applikationer. Utan någon hjälp från mjukvaruleverantören står företagen inför ett svårt problem med många möjliga integration arkitekturer att välja mellan. Således är problemet att det är utmanande och komplext att välja den optimala integrations arkitekturen för att integrera kundvagns mjukvara in i en mobilapplikation. I denna avhandling utforskar vi domänen för kundvagns mjukvara med syftet att utveckla ett ramverk för att integrera kundvagns mjukvara in i mobila applikationer. Vi föreslår ett integrations arkitektur urval ramverk, som vi kallar A Framework for Integrating Shopping Cart Software in Mobile Applications (FISCiMA). Vårt mål består av två delar: (1) vägleda enheter i att välja integrationsarkitektur för kundvagns mjukvara och (2) att ge en grund för ytterligare forskning inom området integration arkitektur urval modeller. Den genomförda forskningen är av kvalitativ typ, forskningsmetoden är tillämpad forskning och forsknings inriktningen är induktiv resonemang. Vi arbetar i fem forskningsfaser: (1) Lit- teraturstudie, (2)Intervju av vår klient, (3) Design av ramverk, (4) ärdering och (5) Finjustering. I de första två forsknings faserna samlar vi grundläggande kunskaper om kundvagns mjukvara och deras mobila integration för att sedan designa ett ramverk i den tredje fasen. Det designade ramverket utvärderas sedan i den fjärde fasen och förbättras slutligen enligt återkopplingen från utvärderingen i den femte fasen. Utvärderingen av FISCSiMA ramverket görs med hjälp av ett frågeformulär som besvarats av vår involverade part. Resultat av utvärderingen tyder på att ramverket är intuitivt, enkelt och flexibelt och förenklar integrationen av kundvagns mjukvara in i mobila applikationer. Förfat- tarna föreslår att ytterligare arbete görs för att utvärdera meriterna av FISCSiMA ramverket och forskning görs för att se om FISCSiMA ramverket kan appliceras på andra mjukvaru kategorier. Keywords: e-handel, kundvagns mjukvara,mobila applikationer, ramverk, integration Contents

1 Introduction 1 1.1 Problem...... 1 1.2 Purpose...... 1 1.3 Goal...... 2 1.4 Research methodology...... 2 1.5 Commissioned work...... 2 1.6 Delimitations...... 2 1.7 Target groups...... 3 1.8 Beneﬁts, Ethics and Sustainability...... 3 1.9 Outline...... 3

2 Background 5 2.1 e-commerce and mobile e-commerce...... 5 2.2 E-commerce technology...... 6 2.2.1 Shopping cart software...... 6 2.2.2 Mobile operating systems...... 7 2.2.3 How the technologies are related to this project...... 7 2.3 Presentation of Watt-s...... 7 2.3.1 Watt-s...... 8 2.3.2 Watts-s website and mobile application...... 8 2.3.3 How Watt-s is connected to this thesis project...... 9 2.4 Related work...... 9

3 Research methodology 11 3.1 Research strategy...... 11 3.2 Research Type and Methods...... 11 3.2.1 Qualitative Research...... 11 3.2.2 Inductive Reasoning...... 12 3.2.3 Alternative Research Methodology...... 12 3.3 Research Instruments...... 12 3.3.1 Literature study...... 13 3.3.2 Interview of our client...... 13 3.3.3 Questionnaire...... 13 3.4 Validity threats...... 13 3.5 Research phases...... 15 3.5.1 Phase 1: Literature study...... 15 3.5.2 Phase 2: Interview of involved bodies...... 15 3.5.3 Phase 3: Design of framework...... 15 3.5.4 Phase 4: Evaluation...... 16

4 FISCSiMA framework 17 4.1 Overview...... 17 4.2 Steps...... 17 4.2.1 Identify software to be studied...... 18 4.2.2 Identify relevant integration architectures...... 18 4.2.3 Select evaluation criteria...... 19 4.2.4 Evaluate architectures...... 19 4.2.5 Rank the architectures...... 20

5 Using the framework 21 5.1 Identify software to be studied...... 21 5.1.1 Overview of shopping cart software and chosen criteria...... 21 5.1.2 Magento Open Source...... 21 5.1.3 Woocommerce...... 21 5.1.4 Prestashop...... 22 5.1.5 Shopify...... 22 5.1.6 Magento Commerce...... 22 5.1.7 Summary...... 22 5.2 Identify relevant integration architectures...... 22 5.2.1 Identifying architectural solutions...... 22 5.2.2 Overview of found architectural solutions...... 23 5.3 Select evaluation criteria...... 24 5.3.1 Overview of selected evaluation criteria...... 24 5.3.2 Details of selection criteria...... 26 5.4 Evaluate architectures...... 26 5.4.1 Evaluation of architectures Multi Platform...... 26 5.4.2 API used as intended...... 27 5.4.3 Not Vulnerable to Cross-site Scripting (XSS)...... 27 5.4.4 Evaluation of our Architectures Usability...... 27 5.4.5 Evaluation of our cost of implementation...... 28 5.4.6 Summary...... 28 5.5 Rank the architectures...... 28 5.5.1 Analysis of results...... 28 5.5.2 Interpreting the results...... 29

6 Results of framework evaluation 31 6.1 Analysis of the interview...... 31 6.1.1 Appropriateness of the interviewee...... 31 6.1.2 Appropriateness of the steps of FISCSiMA...... 31 6.1.3 Identiﬁcation of software to be studied...... 31 6.1.4 Identiﬁcation of relevant integration architectures...... 31 6.1.5 Selection of evaluation criteria...... 32 6.1.6 Evaluation of architectures...... 32 6.1.7 Ranking the architectures...... 32 6.1.8 Usefulness of FISCSiMA...... 32 6.2 Summary...... 32 6.2.1 Good parts of the framework...... 32 6.2.2 Suggested improvements...... 33

7 Fine-tuning the framework 35 7.1 Analysis of improvement suggestions...... 35 7.1.1 First step - Adding new criteria...... 35 7.1.2 Second step - Online collection of identiﬁed architectures...... 35 7.1.3 Third step - A standard set of evaluation criteria...... 35 7.1.4 Fourth step - Weighted evaluation criteria...... 36 7.1.5 Fifth step - Handling tie situations...... 36 7.1.6 Other improvements...... 36 7.2 Improved FISCSiMA framework...... 36 7.2.1 Fourth Step - Weighting criteria with Weighted sum model...... 36 7.2.2 Fifth Step - Handling ties...... 36 7.3 Test of the improved framework...... 37 7.3.1 Evaluate architectures...... 37 7.3.2 Rank the architectures...... 37 8 Discussion 39 8.1 Information gathering...... 39 8.2 Interview of involved bodies...... 39 8.3 Design of framework...... 39 8.4 Evaluation...... 40 8.5 Fine-tuning...... 40 8.6 What would we do diﬀerently...... 40

9 Conclusion and future work 41 9.1 Conclusion...... 41 9.2 Future work...... 42

Appendices 47

A Interview 48 Chapter 1

Introduction

Today’s high-speed internet has enabled e-commerce - the practice of buying or selling online to go mainstream. e-commerce provides many advantages for the consumer [1] and these advantages have led to 10.2 % of all retail sales in 2017 happening online [2]. While the shift to more and more retail sales happening online have made business tougher for some, others have evolved and made shrewd use of this new sales channel to cut out middlemen, launch new business models and increase customer loyalty. To deal with their online stores, most businesses use a shopping cart software - software that interacts with customers by letting them browse items, add the items to their cart and finally, check out with their purchases. There are many diffrent shopping cart softwares aviable, ecommerce-platforms.com lists over 120 of them [3] and most of the shopping cart software are built to be accessed as a website using only the browser. Just as companies are starting to figure out how to deal with e-commerce a new shift is underway towards mobile e-commerce - using a mobile device to shop online. This shift towards mobile e- commerce is enabled by the proliferation and capabilities of today’s smartphones. This shift is well underway and it is estimated, that in 2021 72.9 % of retail e-commerce sales will come from mobile commerce [4]. Much money can thus be gained or lost if companies take advantage of or neglect this shift. Hence in order to stay competitive online stores have to make their services accessible to mobile users. A common way companies deal with this is to scale their current shopping cart software website according to the users’ device screen size thus making the website easier to use. A website that scales to fit different screen sizes is called responsive. A drawback with responsive websites is that they do not fully use the unique capabilities of the smartphone like a normal mobile application does. Many companies want to use their current shopping cart software and at the same time integrate it into a mobile application to provide customers a superior experience than responsive websites. Depending on the shopping cart software used, the software vendor might not provide any best practices for doing it. Without any help from the software vendor, the businesses are facing a difficult problem with many possible integration architectures to choose from. To help businesses that are facing the difficult question of which possible integration architecture to choose from, we propose a framework for integrating web-based shopping cart software into a mobile application.

1.1 Problem

Selecting the optimal integration architecture for integrating shopping cart software into a mobile application can be challenging and complex. Therefore, a framework that simpliﬁes the selection of integrating architecture should be used. The problem is that to the knowledge of the authors no such framework currently exists.

1.2 Purpose

The purpose of this thesis is to develop a framework for integrating shopping cart software into a mobile application. The framework we present in this thesis is called A Framework for Integrating Shopping Cart Software in Mobile Applications, henceforth abbreviated as FISCSiMA.

1 1.3 Goal

The short-term goal of this thesis is to guide entities in choosing an integration architecture for shopping cart software that is appropriate for their operation. The long-term goal is to provide a basis for further research in the domain of integration architecture selection models.

1.4 Research methodology

In order to structure the project and guide the research, it is important to adopt an overall research methodology. The primary methodologies are quantitative- and qualitative methodology [5]. In the quantitative research methodology, a phenomenon is proven by using large data sets [5]. The qualitative research methodology takes the polar opposite approach and relies on a small set of qualitative data to study a phenomenon or an artifact to create theories and products [5]. In this study, we use qualitative methodologies and methods. When constructing our framework a smaller set of qualitative data is used and therefore the qualitative methodologies and methods are appropriate. The qualitative research method applied research was chosen for the project. The researchers gathered information by doing a literature study and by conducting an interview. Applied research was then used to examine the data gathered from the literature study, and used to develop the FISCSiMA framework. As the research was of qualitative character, the research approach inductive reasoning with the philosophical assumption interpretivism was chosen. The researchers made eﬀort to understand the most popular shopping cart software in the market today in order to construct an appropriate framework for integrating shopping cart software into mobile applications. Summing up, data collection was conducted via literature study and an interview, and the data collected was analyzed using applied research. More information about the research methodology is provided in Chapter 3.

1.5 Commissioned work

This work was commissioned to us by the founder of the project Watt-s Joachim Lindborg. Watt-s is a project that seeks to make renewable energy production fun and engaging for consumers [6]. In addition to commissioning the work, the role of Mr. Lindborg was to provide authors with guidance and evaluate the developed framework from his perspective.

1.6 Delimitations

This study results in the FISCSiMA framework, which guides entities in their selection of integration architecture for their shopping cart software. The integration architecture selection process is the initial part of integrating shopping cart software into a mobile application. This initial part proceeds with development of the mobile application and the deployment of the selected integration architecture. This thesis focuses only on the initial process of selecting the integration architecture and does not cover the development and deployment steps. Although this work was commissioned, we could not evaluate the developed framework at the commissioned entities. Those entities could not offer us access to their integration architecture selection process. Instead, we had to design the FISCSiMA framework on our own using information gathered via literature study and an interview. The developed framework was tested during the research, but none of the integration architectures handled were implemented. Instead, we trusted the results gained from the evaluation part of the framework. The evaluation was done using a questionnaire to interview the involved body. Questionnaire was the only evaluation method and involved body was only person to be interviewed due to time limits. The choices of shopping cart software chosen for inspection, which integration architectures are considered valid and the specific evaluation criteria will highly affect the results that are obtained as a result of the framework. During the testing only a subset of these was used, thus the testing of the framework does not cover every situation.

2 1.7 Target groups

The main target group of this project is industry, especially entities that make use of shopping cart software and are interested in creating a mobile application with similar functionality. Another target group is academia, which consists of researchers, teachers, and students who are interested in possible implementations of embedding shopping cart software into a mobile application, their security, performance, scalability, or some other aspect.

1.8 Beneﬁts, Ethics and Sustainability

The results of this project are beneficial to entities planning to provide mobile access to their online stores by embedding the store functionalities into a mobile application. The resulting framework serves as a guide for the entities easing the selection of suitable integration architecture and speeding up the development and thus decreasing its costs. The framework helps entities avoid inessential solutions that for example are not secure, use too many resources or are not future proof. The framework is also beneficial to the customers of online stores as the applications become more accessible and customer data is not put at risk. Increased accessibility of online stores is likely to speed up the shift from shopping to online shopping. The effects of online shopping on greenhouse gases is hard to quantify and researchers are split on if online shopping will reduce greenhouse gases. A study conducted in 2015 showed that online shopping could reduce carbon dioxide (CO2) emissions [7]. Another study from 2016 found that home shopping (online shopping is included in home shopping) increased the stress on a city’s transportation network by negatively affecting travel time, delay, average speed and greenhouse gas (GHG) emissions [8]. Online shopping have potential rebound effects, a study from 2014 cautions that home deliveries may in practice only replace a limited number consumer shopping trips thus the greenhouse gas savings may be limited [9]. The same study cautions that a rebound effect of online shopping is that complementary shopping trips may negate the carbon benefits of online shopping [9]. Examples of ethical issues related to online retailing are privacy of personal information, system security, online retailer fraud and online marketing to children [10]. Our hope is to help companies mitigate the ethical issues of system security and privacy of personal information by creating a framework that will guide companies to suitable integration architectures that are secure and do not put user data at risk.

1.9 Outline

The remainder of this thesis consists of: Chapter 2: Background: This Chapter presents a more detailed background of e-commerce and shopping cart software. It also introduces the client that commissioned this work to us and presents previous studies that are related to ours. Chapter 3: Research methodology: This Chapter presents an overview of the research methodology and strategy that we used when working on this research. Chapter 4: FISCSiMA framework: This Chapter presents the framework developed and every step and component it consists of. Chapter 5: Using the framework: This Chapter presents the work of using the framework. Chapter 6: Results of framework evaluation: This Chapter presents the results of the evaluation of the FISCSiMA framework. Chapter 7: Fine-tuning the framework: This Chapter analyzes the results of the evaluation and discusses suggested improvements to the framework. This Chapter also introduces improvements to the framework and ﬁnally presents the work of using the improved framework. Chapter 8: Discussion: This Chapter presents critical discussion about the conducted research and the developed framework. Chapter 9: Conclusion and future work: This Chapter presents conclusions drawn from the research conducted, as well as suggestions for future work.

Chapter 2

Background

In this Chapter we introduce the reader to e-commerce and relevant background information con- cerning our study. In Subchapter 2.1 we discuss e-commerce and mobile e-commerce in general. Subchapter 2.2 explains the technology behind e-commerce. Subchapter 2.3 describes our client project Watt-s, its business model and how it is connected to this study. Finally, in Subchapter 2.4 we present previous work and research that is close to our study.

2.1 e-commerce and mobile e-commerce e-commerce is a transaction of buying and selling online, which is a large domain [11]. We focus on a form of e-commerce, online shopping, where consumers use web browsers to purchase goods or services over the internet [1]. Online shopping provides multiple advantages for customers compared to conventional shopping, like no more standing queues, stores are always open, as well as ability to quickly seek out deals [1]. Disadvantages include risk of credit card fraud, security concerns and a delay in receiving bought products [1]. Online shopping is becoming increasingly popular, which erodes the sales of conventional retailers [12]. In 2014, Best Buy, which is the largest electronics retailer in the U.S., reported the tenth consecutive dip in quarterly sales and named the increasing shift by consumers to online shopping as the reason [13]. This popularity makes it vital for companies to have an e-commerce presence. To quickly establish their e-commerce presence, many companies use shopping cart software. Shopping cart software works behind the curtain to enable the e-commerce store to fulfill and manage orders [14]. We discuss shopping cart software in greater detail later in this Chapter. After the invention of the iPhone and Android operating system, smartphone ownership has become ubiquitous. In 2011 just 35 % of Americans owned a smartphone and in 2018 that same figure had grown to 77 % [15]. The increase in smartphone ownership has resulted in the trend that services previously accessible from computers, such as online shopping, are becoming accessible from mobile phones. This shift is well underway and it is estimated, that in 2021 72.9 % of the retail e-commerce sales will come from mobile commerce [4], thus it is increasingly important for businesses to have their e-commerce stores be accessible from mobile devices. This accessibility can be provided with mobile device optimized websites or mobile applications [16]. Optimized websites scale according to the browser screen size of the client. Mobile applications provide user interface scaled to fit the screen size of the client device. Both come with their pros and cons [17] and depending on the situation, other might be better than the other. Depending on the shopping cart software used, the software vendor might not address how to create a mobile application for the store. In case it has not been addressed, the retailer must come up with a solution themselves. These solutions may be hard to come up with and furthermore they may have shortcomings. The hardest part of the work is to select an integration architecture which to use. Integration architecture is a software architecture that is used to facilitate integration of multiple software components [18]. Software architecture refers to the structure of a computer system comprising of multiple software elements, the externally visible properties of these elements, as well as their relationships [19]. In our case the integration architecture facilitates the integration

5 Table 2.1: Technical Terms REpresentational State Transfer (REST) An IT-architectural concept describing how services for machine to machine communication can be acquired via web technology Simple Object Access Protocol (SOAP) A protocol specification that specifies how structured information is exchanged between web services in computer networks [20]. JavaScript object notation (JSON) A standard text-based file format, that is used for exchanging data [21]. Extensible markup language (XML) A markup language that defines how data should be encoded so that it is both human and machine-readable [22]. Software Development Kit (SDK) Library that provides developers with all the tools needed for creating software on a specific platform [23].

Table 2.2: API Terms Application Programming Interface (API) A specification of how different application components can use and communicate with a specific software[24] Web API An API for either web server or web browser. Web server web API exposes endpoints to the public. Endpoints respond to defined set of request-response messages that are usually ex- pressed in JSON or XML [24]. API proxy A proxy server is a host that acts as an inter- mediary between requests from a source to a destination [25]. An API proxy is a proxy that acts as the facade for an API [26]. of shopping cart software and mobile application. Hereafter we refer to integration architecture simply as architecture.

2.2 E-commerce technology

This Subchapter provides introduction to the technologies that are dealt with in this project. The terminology is introduced brieﬂy to the reader in Table 2.1 on page6 and Table 2.2 on page6 and the terminology that need further explanation are discussed more in Section 2.2.1, Section 2.2.2 and Section 2.2.3 below.

2.2.1 Shopping cart software Shopping cart software works behind the scenes of an online store doing everything required to manage the store and fulﬁll orders [14]. It is used for example to manage inventory, to calculate taxes and to add or remove products [14]. Shopping cart software is also used by customers when they communicate with the online store to collect items into cart and ﬁnally checkout with their purchases [27]. Through this document, we refer to shopping cart software also using names e-commerce software and e-commerce platform. Shopping cart software can be divided into three categories by type; Open source software, Licensed software and Hosted service [28]. Open source software and Licensed software are installed on a web server by the merchant, whereas Hosted service is provided by the application service provider [28]. Shopping cart software consists of two components [27]; storefront and administration. Store- front is the area of the website used by visitors to browse items for sale and make purchases [27]. Administration is an area that is used by the merchant to manage the store [27]. A Merchant can

6 Figure 2.1: Components of shopping cart software ( Website.com. (n.d.). eCommerce - Shopping Cart and eCommerce. [online] Available at: https://www.website.com/beginnerguide/ecommerce/3/1/shopping-cart-and-ecommerce.ws [Accessed 15 June. 2018].) for example, add or edit products for sale using the administration area [27]. For a view of the components please see Figure 2.1 on page7.

2.2.2 Mobile operating systems Mobile operating systems are Operating system for mobile devices, such as phones, tablets and smartwatches [29]. Android and iOS are the biggest mobile operating systems with 85 % and 14.7% market share in 2017Q1 [30]. The tools used to develop applications for these platforms share a set of functions that are potentially of use in implementing the mobile application, for example application embedded browser, which enables browsing web from within the application.

2.2.3 How the technologies are related to this project Only some e-commerce software provide oﬃcial instructions how to build mobile application client for their software. When designing client without instructions, one has to know how the client can communicate with the e-commerce software. There are two main ways they can communicate; using browser and using API’s. Shopping cart software are designed to interact with a browser as a part of a website, but some of them also have web API’s that enable machine-to-machine communication. The browser is thus one-way the mobile application can use to communicate with the store. Web API’s allow REST or SOAP based communication using machine-readable data, such as JSON or XML [24]. This machine-to-machine communication can be used in a mobile application as another way to interact with the e-commerce store. Some shopping cart software, such as Magento EE provide special libraries, SDK’s, that make using their API simpler [31]. Even if there was an API available on a shopping cart software, it does not mean it can be used to integrate the software into customer mobile application. This is because the API might allow functionality in the administration part of the site, that is only designed to be used by merchants. Hereafter we call API that can and API that cannot be used by customers suitable respective unsuitable API.

2.3 Presentation of Watt-s

This Subchapter introduces the project Watt-s, presents its business idea and describes how it is connected to this thesis project. Section 2.3.1 introduces the project Watt-s, Section 2.3.2 describes its current online store and mobile application, and Section 2.3.3 describes how it is connected to this thesis project.

7 Figure 2.2: Business model of Watt-s (Source: Personal collection)

2.3.1 Watt-s Watt-s is a one-man solar engagement project that seeks to make renewable energy production fun and engaging for consumers, with the ultimate goal of creating a social movement of micro-solar producers [6]. Watt-s is also a research project that does research on whether it is possible to create commitment and sense of participation with commercial grounds by owning a part of a solar panel together with other people [32]. Figure 2.2 on page8 shows an overview of Watt-s business model.The steps of Watt-s business model are marked with numbers from one to seven. In the first step a customer buys shares of solar panels from Watt-s, where each share is a solar cell as a service for fifteen years [33]. In the second step Watt-s installs solar panels, in the third and fourth steps Watt-s sells the renewable energy from the solar panels. The customers get data from Watt-s about how much renewable energy their solar panel produces in the fifth step. This data plays an important role because is shows the customer that buying shares of solar panels helps the environment thus giving the customer a good conscience. In the sixth step Watt-s reinvests the profit into new solar panels. In the last step the excess profit from Watt-s is given to charity. [33]

2.3.2 Watts-s website and mobile application Watt-s has an e-commerce website with Woocommerce plugin to sell its shares [6]. Woocommerce is an open source e-commerce plugin for Wordpress [34] that makes it possible to run e-commerce store on a Wordpress site. Woocommerce is thus considered shopping cart software. The website serves also as a hub for users to view the data about energy produced by the shares the user owns. Watt-S has a mobile application that keeps track of the energy produced by the user’s shares and compares it to the energy consumed by the user’s phone. Currently, the e-commerce site and the mobile application are not connected. Thus, users of the mobile application have to input the number of shares bought and the date of purchase in order to get right data out of the application. The application has to be a native application, as then it can measure battery usage on the phone, which is not possible using responsive websites. A native mobile application is an application made speciﬁcally for one mobile operating system, often downloaded from an app store and able to use the mobile phone’s capabilities such as GPS and

8 gyroscope to their full extent [23]. Watt-s wants to improve the user experience of its application by embedding the login functionality present on its website as well as the Woocommerce e-commerce store into the mobile application. This would enable users to access their data stored on the Watt-s website and buy more shares using only the mobile application. Watt-s wishes the mobile application to be available to both Android and IOS, thus the solution should be compatible with both platforms. The solution should also be future proof, which means that no technology should be used that will get outdated in near future. Watt-s also set security as one of the requirements for the solution, given ﬁnancial transactions are involved.

2.3.3 How Watt-s is connected to this thesis project Because Woocommerce does not provide instructions for creating client applications as seen in Subchapter 2.3 Watt-s, commissioned us to research the subject. Joachim Lindborg of Watt-s inﬂuenced our selection of evaluation criteria and allowed us to examine the workings of Woocom- merce on the servers of Watt-s.

2.4 Related work

The background information presented in this chapter is used as a basis for our research. Informa- tion about e-commerce and mobile e-commerce, as well as the technology behind them is essential to understand in order to develop a framework for integration architecture selection. In our research, we could not find any frameworks for integrating shopping cart software into mobile applications. Therefore we built our research on related previous findings of e-commerce and mobile e-commerce, e-commerce technology and shopping cart software. We also looked at different frameworks for guidance on how to best evaluate our framework. A method of selecting appropriate software architecture styles : Quality Attributes and Analytic Hierarchy Process by Wang and Yang from 2012 [35] introduces a method for novices in software architecture to select appropriate software architecture for their projects. It comes close to our research, but it does not address integration architectures. System Requirements Prioritization Framework [36] (SRPF) by Högberg M. et al. from 2018 suggests a framework to aid companies in their prioritization of system requirements. The framework described in this paper served as an example for the FISCSiMA framework and its structure is therefore similar. We also examined closely how the authors of the SRPF framework conducted their evaluation of their framework and conducted the evaluation of our framework in similar fashion.

Chapter 3

Research methodology

In this Chapter we go through the research methodology used during the thesis project in detail. Subchapter 3.1 provides an overview of the research strategy. Subchapter 3.2 presents the type of research and motivates the selection of research methods. Subchapter 3.3 presents the research instruments used. Subchapter 3.4 presents the validity threats of our research. Subchapter 3.5 speciﬁes the phases during research.

3.1 Research strategy

To guide us through the whole thesis project we created a research strategy that is suitable for the kind of research we are conducting. The research strategy served us as a roadmap and user manual from the early stages of the project until completion. The created research strategy consists of four parts; Research methods, Research phases, Re- search instruments and Validity threats. Figure 3.1 on page 12 provides graphical presentation of the strategy. In this Chapter we will describe each of the four parts. Research methods and methodologies are processes, or particular courses of actions, that ensure the quality of results of the project [5]. Research conducted in this project is qualitative. Qualitative research methods chosen for this project are inductive reasoning and applied research. Research methods are presented in Subchapter 3.2. Research instruments are the tools that are used to collect data [37]. We use three different research instruments. These instruments are Literature study, Interview with our client and Questionnaire. Research instruments are presented in Subchapter 3.3. Validity threats are threats that negatively affect the quality of the results of the research. In order to ensure that results have high quality, we focused securing the Credibility, Transferability, Dependability and Confirmability of the results as a part of the research strategy. What these properties are and how the threats were managed is presented in Subchapter 3.4. Research phases are the steps taken by us during the research. There are a total of five phases. We named each phase with descriptive names that reflect to the actions taken on each phase. The research phases are; Literature study, interview with involved bodies, Design of framework, Evaluation and Fine-tuning. The research phases are presented in Subchapter 3.5.

3.2 Research Type and Methods

In this Subchapter we present the type of research and motivate the selection of research methods. In Section 3.2.1 the qualitative research method used is presented. In Section 3.2.2 the qualitative research method inductive reasoning is presented and ﬁnally in Section 3.2.3 the alternative research method quantitative research is explored brieﬂy.

3.2.1 Qualitative Research The research in this study was of qualitative character. Qualitative research is a broad research approach that tries to understand opinions, context and actions to reach a preliminary hypothesis or theory about a phenomenon [5]. Qualitative research uses modest data sets that are large enough to obtain reliable results [5].

11 Figure 3.1: Graphical presentation of our research strategy (Source: Personal collection)

The qualitative research method used was applied research. Applied research is used to answer a specific question or to solve problems [5]. Applied research builds on current research and actual data from particular situations [5]. Applied research was used to fulfill our specific research goal with data from the literature study and the involved body of Watt-s. We used inductive reasoning and the philosophical approach interpretivism to identify and interpret patterns in the data and finally answer our research question.

3.2.2 Inductive Reasoning Inductive reasoning is a research method that can be said to work using a “bottom-up” approach [38]. Inductive reasoning goes from precise observations to identifying patterns and then concluding by developing broader theories about a phenomenon [38]. In inductive reasoning data is generally collected using qualitative methods [5]. Data collection is done until there is enough data to be able to demonstrate why a phenomenon is occurring [5]. Inductive reasoning was used in this study because we work with a limited amount of qualitative data collected through literature study, interview of client and questionnaire. In this study we used the collected data in several ways to identify patterns. We concluded the study with a broad evaluation of how to best implement shopping cart software in a mobile phone application.

3.2.3 Alternative Research Methodology The other fundamental research method is quantitative research. Quantitative research is conducted with experiments that create a large amount of computable data [5]. The computable data is then used to verify or disprove the researcher’s original hypothesis [5]. Quantitative methods could not be used in our research because our gathered data is subjective and not quantiﬁable.

3.3 Research Instruments

Research instruments are the tools that are used to collect data [37]. The three chosen research instruments literature study, interview of our client and questionnaire are presented in this Sub- chapter. Literature study is presented in Section 3.3.1, interview of our client is presented in Section 3.3.2 and questionnaire is presented in Section 3.3.3.

12 3.3.1 Literature study Literature study was an essential instrument in this study. Because we didn’t have any systems to test, we had to rely our study completely on published work within the related domains. Literature study was also necessary for us to gain a deep understanding of shopping cart software in order to be able to design client applications for them. This instrument was used mostly in the ﬁrst phase of our work, but also continuously in other phases. The knowledge gained from literature study was used throughout the whole study.

3.3.2 Interview of our client Interview is a research instrument [39] that can have different structures and are often used to gain a participant’s perspective of a specific subject matter [5]. To benefit from the expertise of our client Joachim Lindborg, we conducted an unstructured interview of them during our research. The interview was not recorded, and we didn’t follow any templates or ask specific questions because the interview happened spontaneously. Our client provided us with information of what they deem important in a mobile application.

3.3.3 Questionnaire A questionnaire is a research instrument [37] that can collect quantifying data or qualitative data depending on the shape of the questionnaires questions [5]. The work presented in this thesis is of qualitative character and the questionnaire therefore consisted of general reviewing questions. The questionnaire was used to interview the involved body, Joachim Lindborg of Watt-s, with the goal of evaluating the FISCSiMA framework and getting feedback on its steps as well as the framework in general. The full questionnaire used for the evaluation is shown in Figure 3.2 on page 14. and the transcription of the interview using the questionnaire is in the Appendix A. The questionnaire contains questions in three different categories, Appropriateness of the interviewee, Appropriateness of the steps of FISCSiMA and Usefulness of FISCSiMA. These categories focus on evaluating different things. Figure 3.2 on page 14 shows the names of the three categories bolded. Under each category name is the questions that belong to that category. First category, Appropriateness of the interviewee, focuses on evaluating and establishing whether Mr. Lindborg is an appropriate person to evaluate the framework. Second category, Appropriateness of the steps of FISCSiMA, aims to evaluate whether the step of the framework are reasonable and justified. Which step each question correspond to is visible in Figure 3.2 on page 14. The last category, Usefulness of FISCSiMA aims to evaluate whether the framework is in fact of use to entities that need a framework for choosing integrating architecture in the first place.

3.4 Validity threats

Quality assurance is concerned with validation and verification of the research material [5]. This Subchapter presents the validity threats that this study was exposed to and how the threats were managed. Because of the qualitative nature of this study, it was exposed to validity threats such as credibility, transferability, dependability and confirmability [40]. In qualitative research, credibility or validity is concerned with the trustworthiness of the research material used [41]. It makes sure that the research has been conducted according to existing rules [41]. In order to assure the credibility of the material used, made a note of where the source was published, who is the author, for who was it written and whether the information is relevant for the study. Taking these notes into account we made judgment whether the source is credible or not and chose to use only sources we deemed credible. Transferability in qualitative research determines to what degree the results obtained are gener- alizable beyond this study [42]. This study evaluates and compares different software architectures in a specific scenario and does so using criteria that are common when evaluating software. The general nature of the criteria makes it possible that the results are repeatable and useful in other similar researches where the scope is different but includes some architectures compared in this study.

13 Figure 3.2: Questionnaire used for evaluation (Source: Personal collection)

14 Figure 3.3: Graphical presentation of the research phases (Source: Personal collection)

Dependability refers to judging the correctness of conclusions by the repeatability of the study [40]. Qualitative research is hard to repeat identically in practice and thus lacks in dependability. To prove the dependability of this study, it needs to be repeated in different contexts. Confirmability is concerned with objectivity within research without any personal assessments that might affect the results for the researcher’s part [40]. This was ensured by conducting data collection and interpretation together as a team as well as individually. Furthermore, all sources were kept in their contexts when interpreting them in order not to misunderstand them.

3.5 Research phases

The research consisted of ﬁve main phases, Literature study, Interview of involved bodies, Design of framework, Evaluation and Fine-Tuning. Figure 3.3 on page 15 shows the phases and the workﬂow graphically. The phases are presented in Sections 3.5.1-3.5.5.

3.5.1 Phase 1: Literature study The goal of literature study was to gain understanding of the field and see if there were any previous frameworks on integrating shopping cart software into mobile applications. Literature study was done of e-commerce, shopping cart software, and mobile applications as well as different frameworks. Literature ranged from research articles to official online documentation of the technologies to blog posts and communication between developers. No published material that handled the exact problem of integrating shopping cart software into mobile applications was found, so we needed to piece together information collected from multiple sources. Example sources we used are Aheadworks’ study about e-commerce platform popularity [43] and research article A View to kill: WebView Exploitation [44]. To find literature, we used Google search [45], Google scholar [46], Github [47] and Wikipedia [48]. While searching for material, for example following search keywords were used: shopping cart software, e-commerce platform, integrating shopping cart software into mobile application, scenario based evaluation software architecture and shopping cart software market share. This phase provided us with enough theoretical knowledge to begin writing the thesis report and prepared us for the next phases. Complementary literature study was conducted during the whole project when needed, as we faced something that was not familiar to us. For example when we were evaluating the solutions, we needed to read about how each solution evaluate according to each criterion.

3.5.2 Phase 2: Interview of involved bodies Before we started designing the framework, we did an unstructured interview of our client Joachim Lindborg. The interview was not recorded, and we didn’t follow any templates or ask speciﬁc questions because the interview happened spontaneously. Our client provided us with information of what they deem important in a mobile application and ideas how shopping cart software could be integrated into mobile application. We then took these ideas into consideration when creating our framework.

3.5.3 Phase 3: Design of framework In this phase, we used the data from the interview and the literature study to design a framework

15 for choosing architecture for integrating shopping cart software into a mobile application. The result of this phase was the ﬁve-step FISCSiMA framework.

3.5.4 Phase 4: Evaluation In this phase we evaluated the FISCSiMA framework. Evaluation was done by interviewing our client using a questionnaire presented in Subchapter 3.4. Two weeks before the interview, our client was given time to familiarize themselves with the FISCSiMA framework and the questionnaire. In the beginning of the interview, the memory of the interviewee was refreshed by giving a short presentation of the framework. Then ﬁnally the questions of the questionnaire were asked from the interviewee in order while recording.

3.5.5 Phase 5: Fine-Tuning phase In this phase we analyzed the results of the evaluation questionnaire obtained in Phase 4. Based on this analysis we ﬁned-tuned the framework with a few improvements. The improved framework was then tested.

16 Chapter 4

FISCSiMA framework

In this Chapter we present the framework developed and the steps and components it consists of. Subchapter 4.1 provides an overall description of the framework. Subchapter 4.2 goes through the steps of the framework in more detail.

4.1 Overview

The framework consists of five steps. Together the steps describe how the architecture for integrating shopping cart software into a mobile application is chosen. The steps are presented in the order they are taken in Figure Figure 4.1 on page 17. The five steps are (1) Identify software to be studied, (2) Identify relevant integration architectures, (3) Select evaluation criteria, (4) Evaluate architectures and (5) Rank the architectures. The five steps of the framework encapsulate different components that users of the framework use to guide the selection of the architecture. Figure 4.2 on page 18 presents the different components of the framework. It includes the method steps introduced earlier, as well as the components that are used in the steps. The components in Figure 4.2 on page 18 are related to the five method steps. Numbers in the components describe which step the components are used in. Identification criteria and identification method are used in the first step of the framework. Architecture selection method is used in the second step. The third step, Select evaluation criteria, use evaluation criteria component. Fourth step uses the component evaluation method. The last step of the framework does not use any of the components. Some components in the Figure 4.2 on page 18 have dots in them. This implies that the user of the framework is free to extend these components or choose component items that suit their needs. Extending of components and choosing component items is discussed in Subchapter 4.2 when each step is described more closely. Some components have items with “e.g.” in them. This implies that they are examples.

4.2 Steps

As stated in the previous Subchapter, the framework consists of ﬁve steps that are followed in the exact order. In Sections 4.2.1 through 4.2.5 the ﬁve steps of FISCSiMA framework are explained in more detail. When necessary, an example is provided of the step.

Figure 4.1: Graphical illustration of FISCSiMA framework steps. (Source: Personal collection)

17 Figure 4.2: Outline of the framework. Dots imply that framework users are free to extend the framework parts with their own suggestions. (Source: Personal collection)

4.2.1 Identify software to be studied In this step, the starting set of shopping cart software is identiﬁed. The intention is to narrow down a large number of shopping cart software into a set that is more interesting and easier to inspect. The narrowing is done as follows;

• An identiﬁcation criterion is chosen

• A number of the shopping cart software is chosen on the basis of the chosen identiﬁcation criteria

For example, the criterion chosen later in next Chapter is popularity, and the five most popular shopping cart software are chosen. These five software are now the set of software that are researched in later steps. The criterion used as well as the number of chosen software affect the outcome of the framework. This is because only the set identified is researched in later steps and it might be that the set identified misses shopping cart software or architectures that are relevant to the framework user. Both the identification criterion and the identification method are components of the framework, and their items can be chosen by the user. By choosing a criterion that is important to the user of the framework, the starting set is likely to include shopping cart software that is relevant to the framework user. By deciding how many shopping cart software are chosen, the framework user chooses how many different software are researched in next steps. More software researched increases probability that relevant shopping cart software are included in the starting set.

4.2.2 Identify relevant integration architectures In this step, possible architectures of integrating shopping cart software into a mobile application are identified. The identification is done through searching the official documentation of the shopping cart software that was identified in the first step for instructions for building mobile applications out of the software. Each different architecture proposed by the documentation is added to a collection of relevant integration architectures. In addition to the architectures identified by studying official documentation, architectures are added to the collection by conducting a literature study. Literature studied can be for example

18 documentation of the mobile operating system the application is to target. In the case of the study conducted in next Chapter, the literature included developer documentation of Android and IOS, as well as online articles of shopping cart software. The literature studied affects the outcome of the study, as official documentation of the shopping cart software alone and poor choice of literature may miss relevant integration architectures. Documentation of the selected shopping cart software and literature study are items of the Architecture selection method component, which is used in this step. Users of the framework can extend the component by defining other sources for information to identify other integration architectures.

4.2.3 Select evaluation criteria Evaluation criteria that are used later to evaluate the solutions are selected in this step. The purpose of the selection is to enable comparison of the architectures in later steps. The number of criteria selected is optional, but multiple criteria make the distinction between architectures in results more apparent. Selection of the criteria is done by each user of the framework individually. The criteria are items of Evaluation criteria component. Selected criteria should include properties that are important in an architecture for the framework user. By choosing criteria that are important for the user, the result of the framework reflects which architecture is best by properties that the user deem important in an architecture. There can be two types of evaluation criteria; Boolean and tiered. Boolean criteria can either be true or false, either an architecture fulfills the criterion or it does not. Boolean criteria are chosen so that it is more desirable that the architecture fulfills the criteria. Tiered criteria has three cumulative levels with corresponding requirement for each of them. In tiered criteria the architectures are put into one of the three levels depending on how they fulfill the requirement. Tiered criteria are chosen so that it is more desirable that an architecture is put into a higher level, thus the higher the level, the better the architecture did according to the tiered evaluation criteria. An example of Boolean criterion is multi-platform, where the definition for multi platform is that the architecture is applicable to both Android and IOS mobile operating systems. Either an architecture is multi platform or it is not. Multi platform is a desirable property of an architecture and therefore it is more desirable that the architecture fulfills the criteria. Multi platform criterion is one of the Boolean criteria used in next Chapter. An example of tiered criterion is price of implementation. The requirement for the first level is that implementation price is more than $1000, the second level that implementation is less than $1000 and the third level that price is less than $500. The third level corresponds to the cheapest implementation and is therefore the most desirable level. Price of implementation is one of the tiered criteria used in next chapter.

4.2.4 Evaluate architectures In this step, the identified integration architectures are evaluated using the evaluation criteria selected in the previous step. Each architecture is evaluated according to each evaluation criteria. On each tiered criterion, architecture is placed on one of the three levels, on each Boolean criterion architecture is either true or false. The evaluated architectures are then assigned points depending on how they did in the evaluation as follows: Boolean criteria True: 1 point False: 0 points Tiered criteria Level 1: 0 points Level 2: 1 point Level 3: 2 points In Boolean criteria if an architecture fulfills the criterion it gets assigned one point. If the architecture does not fulfill the criterion, it does not get assigned any points. In tiered criteria, the evaluated architecture gets assigned points according to the level of requirements fulfilled. The first level is not assigned any points, whereas the second level is assigned one and the third level is assigned two points.

19 The Evaluation method component used in this step deﬁnes the above method of assigning points to each architecture. A user of the framework can extend the component by additionally including other point assignment techniques, such as assigning bonus points if a certain combination of criteria is fulﬁlled by an architecture.

4.2.5 Rank the architectures In this step the results of the evaluation of the architectures are compared and ranked. The points assigned to an architecture by each criterion are summed up and the sums of each architecture are compared. Then, the architectures are ranked by their points from the architecture with most points to the architecture with the least points. The architecture that was ranked ﬁrst is overall the best as it gained most total points in the evaluation. Therefore, it is generally the optimal choice for an architecture.

20 Chapter 5

Using the framework

In this chapter we use the FISCSiMA framework to choose a suitable architecture for integrating shopping cart software into a mobile application. Subchapters 5.1 through 5.5 describe the ﬁve steps of FISCSiMA framework in the order they are taken.

5.1 Identify software to be studied

In the ﬁrst step of using the FISCSiMA framework we narrow down the set of shopping cart software to be studied into a more manageable set using a chosen criterion. In Section 5.1.1 we have an overview of shopping cart software and our chosen criteria. We take a closer look at each chosen shopping cart software in Sections 5.1.2–5.1.6 and in Section 5.1.7 we have a summary of all our identiﬁed shopping cart software.

5.1.1 Overview of shopping cart software and chosen criteria There is an enormous amount of shopping cart software available, e-commerce-platforms.com lists over 120 of them [3]. It is therefore important to narrow down the shopping cart software into a more manageable number through some criterion. We use the criterion popularity to limit our survey of shopping cart software. Popularity is chosen because we want a starting set of shopping cart software that includes software used by a majority of online retailers. We choose the five most popular e-commerce platforms in 2015 from the study e-commerce Platforms Popularity conducted by Aheadworks [43]. Only five are chosen because according to the Aheadworks study [43], the five most popular take up 70.3% of all shopping cart software used. The set of shopping cart software that we will research in the later steps are thus Magento Open Source, Woocommerce, Prestashop, Shopify, and Magento Commerce [43]. In addition to choosing the shopping cart software to be studied, we survey the chosen software and analyze their features briefly. On the survey, we focus on the features that allow communication between a mobile application and the e-commerce software identified in Chapter 2, namely presence of an API and whether the API is suitable. We also focus on whether the software provides official instructions on how to build a client application.

5.1.2 Magento Open Source Magento Open Source (previously named Magento Community Edition) is an open source shopping cart software developed by Magento Inc [49]. It was the most popular e-commerce platform in 2015 according to Aheadworks [43]. Magento Open Source has REST API and SOAP API that can be used to develop shopping applications according to the oﬃcial documentation [50]. The API is thus suitable for consumer use and has documentation for developers on how to integrate Magento Open Source in a mobile application.

5.1.3 Woocommerce Woocommerce is an open source e-commerce plugin for Wordpress developed by Automattic [34].

21 According to the study conducted by Aheadworks, it was the second most popular e-commerce platform in 2015. Woocommerce has an API for programs to use, but the API is designed only for administering the website [51]. This means that if the API is enabled for a user, the user has administrative priv- ileges to the website and can perform any action an administration can, including malicious ones. Examples of actions only meant to be performed by an administration include listing new products for sale and modifying descriptions of products. Woocommerce does not provide instructions for integrating it into customer mobile application.

5.1.4 Prestashop Prestashop is an open source e-commerce software developed by PrestaShop [52] that ranked the third most popular e-commerce platform in 2015 According to Aheadworks’ study [43]. PrestaShop has an API that enables merchants to give access to third-party tools to the merchant’s shop database [53]. Like in Woocommerce, PrestaShop’s API is not meant to be used by customers and it is not secure. PrestaShop also does not provide instructions for integrating it into customer mobile application.

5.1.5 Shopify Shopify is a hosted service e-commerce platform developed by Shopify [54]. It was ranked the fourth most popular e-commerce platform of 2015 in Aheadwork’s study [43]. Shopify provides API’s for administration and storefront functionality and has oﬃcial instructions for building integrating Shopify into mobile application [55]. Furthermore, Shopify provides a Software Development Kit (SDK) for iOS and Android to make using its API’s easier [56].

5.1.6 Magento Commerce Magento Commerce, previously named Magento Enterprise Edition, is a licensed shopping cart software from Magento Inc. It was ranked the ﬁfth most popular shopping cart software in 2015 by Aheadworks. The features in the Magento Commerce are a superset of those in Magento Open Source as they are based on the same codebase [57]. This means that the same API’s that are available on the open source version are also available in Magento Commerce. Magento Commerce thus has suitable API for consumer use and has documentation for developers on how to integrate Magento Commerce in a mobile application.

5.1.7 Summary Magento Open Source, Shopify and Magento Commerce have API’s that are suitable for customer mobile applications and they all provide instructions for building the applications. Woocommerce and PrestaShop only have API’s for administering the store and provide no information how they should be integrated into a mobile application.

5.2 Identify relevant integration architectures

In this second step of using the FISCSiMA framework we identify relevant integration architectures. In Section 5.2.1 we identify the relevant integration architectures and Section 5.2.2 goes through each identiﬁed integration architecture in more detail.

5.2.1 Identifying architectural solutions In this step possible architectures of integrating the shopping cart software into a mobile application are identified. The identification is done by searching the official documentation of the shopping cart software that was identified in the first step and through a literature study. Reading the official documentation, we identified the architecture Using API, in the literature study we identified the architectures Using API with Proxy and Integrated browser. The documentation of each shopping cart software in the starting set was already researched in Subchapter 5.1. Using an API to communicate with shopping cart software was proposed

22 integration architecture for mobile applications in the documentation of Magento CE, Magento EE and Shopify. We call this architecture Using API. In the case of Woocommerce and Prestashop, there were no mentions of creating mobile applications in their documentation. A literature study was conducted of developer documentation of Android [58] and IOS [59], as well as online resources of shopping cart software and related technology, such as an article by Nielsen Norman Group [60], a blog post by Larry Garﬁeld [61] and documentation of Apigee [62]. As noted in Chapter 2, shopping cart software can be interacted with by using a browser and by using an API. The ability to use an API to interact with shopping cart software is used by the architecture Using API, but as noted in Subchapter 5.1 Woocommerce and Prestashop have API’s that are not designed to be used by customers. Their API’s are not suitable which is why the architecture Using API cannot be used as it is in their case. In these cases as long as storefront functionality is available through the API, an API proxy can be placed between the mobile client and the shopping cart software. The mobile clients would then use the storefront functionality through the API proxy which makes it a possible integration architecture. We call this architecture Using API with Proxy. The ability to use a browser to interact with shopping cart software is useful as mobile operating systems have an integrated browser functionality, which allows the usage of a browser within a mobile application [58][59]. This integrated browser can be used to access the shopping cart software. Therefore, the integrated browser is a relevant architecture. We call this architecture Integrated Browser.

5.2.2 Overview of found architectural solutions In this Section we go into detail about the three previously identified architectures, Using API, Using API with Proxy and Integrated browser. We start with Using API, go over to Using API with proxy and finally present the Integrated browser architecture. Using API In order to allow separate software components communicate together, they can make use of an API. In our case, the separate software components are an e-commerce website that acts as a server and a mobile application that acts as a client. APIs of different shopping cart software can be used to perform different things, but the basic idea stays the same; it can be used to access storefront functionality, such as browse purchasable items and make purchases from the store. The client communicates with the server using the methods defined by the API specification and the messages passed back and forth are shopping cart software specific. Different API’s may require the use of different protocols. The data that is received from the API calls can be used in various ways in the mobile application in order to make the experience similar to the website version of the store. Using these defined communication messages it is therefore possible to implement the same functionality that is available on the website version of the e-commerce store in any application with internet access. Using API with Proxy Woocommerce has an API available but it is officially said that the API is only meant for administering the website and not for customer use [51]. Prestashop API gives all permissions to the application’s data store, which means that using the API it is possible to do actions that are only safe for administrator to use [53]. In both cases, the API available is thus too powerful for regular use. After reading the documentation of Apigee [62] we came up with an architecture that involves a kind of API proxy on the server side that makes use of the insecure API but allows only actions that are safe to be invoked. The proxy authenticates users and enables authenticated users to perform the same operations that they can perform on the website version of the Woocommerce store. The proxy uses the Woocommerce or Prestashop API with privileged credentials to perform the operations. In this solution the regular API grants excessive access to the client to be used in customer applications. In order to make use of this API, a new component, proxy, is introduced between the client and the server. This proxy defines its own API interface that clients can use similarly they use the API in for example Magento CE. Woocommerce REST API defines functions similar to Magento CE for listing products and creating orders [63]. However, there are also features available in the API such as creating refunds, deleting customers and creating new products [63] that are definitely not meant for customers to

23 Figure 5.1: Illustration of proxy architecture (Source: Personal collection) use. This is why only the proxy would be authorized to use the API in this solution. In its own API, the proxy would define only functions that are safe for customers to use, for example listing products and making orders. Only when these functions are called by a client, the proxy uses its authorization of the unsafe API to call the same function. The output proxy receives from the unsafe API is then sent back to the client, after possible filtering of sensitive information. The proxy would effectively act like an application firewall, stopping any tries to use API functions that are not meant for customers to use. Figure 5.1 on page 24 is an illustration of this architecture. Integrated browser Integrated browser in an application can be used to access the web interface of the shopping cart software. An application-integrated browser functions similarly with a traditional browser sending requests to web servers, rendering the web pages, storing cookies, and executing JavaScript [35, 66, 67]. Webkit is the package that provides tools for Android applications to browse the web. The most important class in this package is WebView [64]. The created instance of the WebView class in an application acts like an integrated browser and enables browsing the web and interacting with web applications. WebKit has also other classes that enable the application to have powerful web functionality such handling cookies from the webview [65]. With Integrated browser we can thus fetch and display the e-commerce store and interact with the JavaScript on the page. This way, it is possible to provide users similar experience as with a responsive website, using an application instead of a browser. An overview of the integrated browser architecture is seen in Figure 5.2 on page 25.

5.3 Select evaluation criteria

In the third step of the FISCSiMA framework, we select the evaluation criteria. Section 5.3.1 presents an overview of our selected evaluation criteria and in Section 5.3.2 the selected evaluation criteria are explained in more detail.

5.3.1 Overview of selected evaluation criteria In this section, we show an overview of the selected evaluation criteria. The selected evaluation criteria should be properties that are important to the framework user in an architecture. The criteria for evaluation of the architectural solution were produced through literature study and through the interview of Joachim Lindborg of Watt-s. All the evaluation criteria are listed in Table 5.1 on page 25.

24 Figure 5.2: Illustration of Integrated browser architecture.(Source: Personal collection)

Table 5.1: Solution evaluation criteria Criteria description Multi platform The resulting e-commerce store must be accessible from both Android and iOS. API used as intended The API is used in a way that is officially supported by the API vendor. Not Vulnerable to Cross-site Scripting (XSS) Is the solution not vulnerable or vulnerable to the computer security attack of Cross-site Scripting (XSS). Usability To which degree a software can be used by consumers to achieve quantified objectives with effectiveness, efficiency, and satisfaction in a quantified context of use [66]. Cost How much the implementation of the system will cost in money and effort.

25 Some criteria proposed by Joachim, such as security and future proofed, had to be left out of the study because they were too subjective. Subjective properties are hard to compare with each other and comparison is the basis for the framework. The criteria that were not included are not present in the Table 5.1 on page 25

5.3.2 Details of selection criteria Multi platform This criterion was provided by Mr. Lindborg when we interviewed him. What this criterion means is that the architecture works on both Android and iOS. Multi platform was chosen as a criterion because it is important for retailers to target multiple mobile platforms. It was also an important property for Watt-s. Multi platform is Boolean criteria, either an architecture can be used on both Android and iOS, or it cannot be used. API used as intended This criterion is about whether the API is used in a way that is officially supported by the API vendor. We included this criterion because if the API is used as it is intended from the official documentation it greatly simplifies the development process. This criterion is of type Boolean, either the API of shopping cart software is used as intended by the software vendor or it is not. Not Vulnerable to Cross-site Scripting (XSS) We included this criterion so consumers can be sure that their credit card info is safe from the common security vulnerability Cross-site Scripting (XSS). In such vulnerability, an attacker is able to add malicious JavaScript to a webpage, which is executed by a device of a user viewing the web page [44]. This evaluation criterion deals with if the proposed architecture solution is vulnerable or not to Cross-site Scripting exploits. This criterion is of type Boolean, either an architecture is vulnerable to XSS or it is not. Usability Usability can be described as to which degree a software can be used by consumers to achieve quantified objectives with effectiveness, efficiency, and satisfaction in a quantified context of use [66]. This criterion was included because there are reports that poor usability can negatively affect e-commerce [67]. Research has shown that a positive mobile phone usability experience results in brand loyalty [68]. Usability is a tiered criterion. For this criterion, there is a study [69] comparing the exact architectures we have identified. Therefore, the levels in this criterion are assigned to the architectures according to the results of the study. Cost of implementation This criterion is about how much the integration of the selected architecture into the mobile application will cost to implement. We include this as a criterion because the invested time and money are considered a big factor influencing the architectural solution choice in an application [70]. Cost of implementation is tiered criteria. For this criterion there are two studies, Mobile: Native Apps, Web Apps, and Hybrid Apps by Nielsen Norman Group [71] and Taxonomy of cross- platform mobile applications’ development approaches by El-Kassas et. al [72], comparing the exact architectures we have identified. Therefore the levels in this criterion are assigned to the architectures according to the results of the two studies.

5.4 Evaluate architectures

In the fourth step of the FISCSiMA framework, the identiﬁed architectures are evaluated using the previously identiﬁed evaluation criteria. We go through the evaluation criteria one by one and evaluate the architectures in Sections 5.4.1–5.4.5. In Section 5.4.6 we summarize the evaluation of the architectures.

5.4.1 Evaluation of architectures Multi Platform The APIs make it possible to access the functionality from any device with internet connection, effectively enabling usage of both Android and iOS. This means that architectures using API and using API with proxy fulfill the multi platform criteria. The integrated browser also fulfills the criteria for both Android and iOS have integrated browsers that can be used similarly inside a mobile application [66, 72]. You can see the ranking overview in Table 5.2 on page 27.

26 Table 5.2: Evaluation of our solutions multi platform Solution Evaluation of our solutions multi platform API 1 - True API with Proxy 1 - True Integrated browser 1 - True

Table 5.3: API used as intended Solution Evaluation of our solutions multi platform API 1 - True API with Proxy 0 - False Integrated browser 1 - True

5.4.2 API used as intended Using API is an architecture found in the official shopping cart software documentation. Therefore, we can be sure the API provided is used as intended in the Using API architecture, provided the API is suitable. In the architecture Using API with Proxy, the official API for store owners to manage the online shopping cart software is used with a proxy to enable it to instead be used by customers in the mobile application. The API is not intended to be used this way and thus the architecture Using API with Proxy does not fulfill the criteria. The architecture integrated browser makes use of the web interface of the shopping cart software and does not use a shopping cart software API. Therefore, it cannot misuse the shopping cart software API. An overview of the ranking for the evaluation criteria API used as intended can be seen in Table 5.3 on page 27.

5.4.3 Not Vulnerable to Cross-site Scripting (XSS) In all of our architectures, there is a mobile application that connects to a server. The diﬀerence between the architectures is what kind of data is exchanged between the client and the server and whether the client connects directly to the server or via a proxy. Integrated browser fetches whole web pages, whereas using API with or without proxy fetches only data. The usage of the fetched information is not equal; the fetched web pages are rendered in the integrated browser, whereas the fetched data is only displayed in architectures that use API. Rendering web pages in the browser may include running JavaScript code that is on the webpage. This causes risk to the user as an attacker might manage to perform a so-called Cross-site Scripting attack [44]. The execution happens whether normal browser or integrated one is used [44]. This kind of risk is not present when only data is fetched. Using API and Using API with Proxy do not render web pages and are therefore not vulnerable to Cross-site Scripting attacks. Because integrated browser renders web pages, it is vulnerable to Cross-site Scripting attacks and the evaluation criteria is therefore false. The ranking is presented in Table 5.4 on page 27.

5.4.4 Evaluation of our Architectures Usability The solutions Using API and Using API with proxy are both native applications.Native mobile applications have shown to give the users the best user experience whereas the integrated browser solution gives users only a moderately good experience [69].

Table 5.4: Not Vulnerable to Cross-site Scripting (XSS) Solution Evaluation of our solutions multi platform API 1 - True API with Proxy 1 - True Integrated browser 0 - False

27 Table 5.5: Evaluation of our solutions Usability Solution Evaluation of our solutions multi platform API 2 - Level 3 API with Proxy 2 - Level 3 Integrated browser 1 - Level 2

Table 5.6: Evaluation of our solutions Cost of implementation Solution Evaluation of our solutions multi platform API 1 - Level 3 API with Proxy 0 - Level 1 Integrated browser 2 - Level 3

Graphics and experience of an application with an integrated browser may diﬀer slightly from the established design patterns across the mobile operating systems [71]. The solutions Using API and Using API with proxy, on the other hand, are native applications that can give a more consistent user experience that is in line with the operating system [71]. Native applications will also give the user better usability by enabling the application to have faster navigation [73]. The solutions Using API and Using API with proxy are implemented as native applications and therefore they are positioned in level 3. The integrated browser gives the user an overall good user experience but may diﬀer slightly from the established design patterns of mobile platforms and therefore it is positioned in level 2. You can see the overview in Table 5.5 on page 28.

5.4.5 Evaluation of our cost of implementation It is argued that because development of applications with integrated browser builds on common proﬁciency with web programming, they are cheaper to develop than native applications [71]. When building a native application, higher development skill is required than when building an application with an integrated browser [72]. Likewise, when building a native application, separate applications need to be developed for each mobile platform raising the cost and eﬀort for the company [71]. This is why the integrated browser is positioned in level 3 considering cost of implementation. Between the solutions implemented as native mobile applications, Using API and Using API with Proxy, Using API with proxy is more expensive. This is because in order to implement it two components need to be built, proxy and mobile application, whereas in solution Using API only mobile application needs to be built. From a cost perspective it is thus suggested that the solution Integrated browser is scored in level 3, Using API is scored in level 2, and Using API with proxy is scored in level 1. Overview of the evaluation considering Cost of implementation can be seen in Table 5.6 on page 28.

5.4.6 Summary The rankings of the three architectures by all ﬁve evaluation criteria are summarized in Table 5.7 on page 29. The total points acquired by each architecture are also visible in the Table.

5.5 Rank the architectures

In the ﬁfth and ﬁnal step of the FISCSiMA framework, we rank and compare the architectures. In Section 5.5.1 we analyze the results obtained in the previous step and in Section 5.5.2 we interpret the results and explain what they mean.

5.5.1 Analysis of results From Table 5.7 on page 29 we see that of the architectures, Using API acquired 6 points in total, which is more than the points acquired by the other two architectures. Of Boolean criteria it scored true in Multi platform, API used as intended and Not Vulnerable to Cross-site Scripting (XSS) attacks. Of tiered criteria, it scored level 3 in Usability and level 2 in cost of implementation.

28 Table 5.7: Summary of evaluation Criterion Using API Using API with Integrated Browser Proxy Multi platform 1 1 1 API used as intended 1 0 1 Not Vulnerable to 1 1 0 Cross-site Scripting (XSS) Usability 2 2 1 Cost of implementa- 1 0 2 tion Total 6 4 5

Integrated browser acquired 5 points in total. It scored true in Multi platform and API used as intended and false in Not Vulnerable to Cross-site Scripting (XSS). Of the tiered criteria it scored level 2 in Usability and level 3 in the cost of implementation. Using API with proxy scored the least amount of points with a total of 4 points. Of Boolean criteria it scored true in Multi platform and Not vulnerable to Cross-site Scripting (XSS) and false in API used as intended. Of the tiered, criteria it scored level 3 in Usability and level 1 in the cost of implementation.

5.5.2 Interpreting the results Because Using API gained the most points according to our evaluation, it is the best of the architectures when all ﬁve evaluation criteria are taken into account. It is better or as good as the two other solutions in every criterion except Cost of implementation. In case it was equal to the integrated browser in the cost of implementation it would be perfect in all aspects considered by our criteria. This implies that Using API should be chosen in all cases where the cost of implementation is not highly prioritized. One drawback with this solution is that it requires that there is a suitable API available from the shopping cart software vendor. Only three of the ﬁve studied shopping cart software have a suitable API. The integrated browser comes close to Using API with only one point less. Integrated browser loses to Using API in Usability and Vulnerable to Cross-site scripting while winning in the cost of implementation. If the cost of implementation is considered the most important evaluation criteria by the user of the framework or there is no suitable API in the used shopping cart software, the integrated browser is the preferred architecture. Using API with Proxy comes last. It is inferior or equal to Using API in every criterion and inferior or equal to the integrated browser in every criterion except usability. Using API with Proxy is in the light of these results not advisable for companies to implement.

Chapter 6

Results of framework evaluation

In this chapter we present the evaluation of the FISCSiMA framework which was done by conducting an interview of our client using the questionnaire presented in Subchapter 3.4. The interview was recorded and transcribed, and the full interview transcript can be found in the Appendix A. The questionnaire aims to evaluate FISCSiMA framework through the three question categories presented in Chapter 3. Subchapter 6.1 goes through each question category in the questionnaire and analyzes the answers received from the interviewee. Subchapter 6.2 summarizes the analysis and speciﬁes which parts of the framework are deemed good by the interviewee and which parts need improvement according to them.

6.1 Analysis of the interview

In this Subchapter we go through each category of questions in the questionnaire and analyze the answers received from Mr. Lindborg. Section 6.1.1 presents analysis of the category Appropriate- ness of the interviewee, Section 6.1.2 presents analysis of the category Appropriateness of the steps of FISCSiMA and Section 6.1.3 presents analysis of the category Usefulness of FISCSiMA.

6.1.1 Appropriateness of the interviewee Questions in this category focus on evaluating whether the interviewee is an appropriate person to evaluate the framework. Mr. Lindborg is found to be an appropriate person to answer the questionnaire, as he has used two diﬀerent shopping cart software as a retailer, and he is interested in integrating the software into a mobile application.

6.1.2 Appropriateness of the steps of FISCSiMA Questions in this category aim to evaluate whether the step of the framework are reasonable and justiﬁed. The analysis of answers to questions in this category is divided between the ﬁve steps of the framework.

6.1.3 Identification of software to be studied In the first step of the framework, Mr. Lindborg thinks the way that FISCSiMA framework identifies software to be studied is good and suitable. In addition to the popularity criterion used in Chapter 5, he names a new criterion, “liveliness of development” that could be used instead. Liveliness of development means that the software that is used is not deprecated and receives support from its creators.

6.1.4 Identification of relevant integration architectures In the second step of the framework, Mr. Lindborg thinks the FISCSiMA framework uses appropriate way to find relevant integration architectures. He brings up that if multiple FISCSiMA processes are done, it might not be relevant to go through the specific documentation again.

31 Therefore, he suggests that there could be a sort of wiki that people can look at and see which architectures exist and work.

6.1.5 Selection of evaluation criteria In the step selection of evaluation criteria, Mr. Lindborg thinks a standard set of evaluation criteria, that is used every time when running the framework, would be suitable. The standard set of criteria could then be tweaked by adding specific criteria by the user of the framework. The standard criteria would enable comparison of results obtained by different framework users. When it comes to the types of criteria used in FISCSiMA framework, Mr. Lindborg thinks the two types, Boolean and tiered, are appropriate. As an improvement, he thinks that weighting of the criteria would be good to have, as it makes it easy to prioritize criteria and tailor a standard set of criteria to the specific project.

6.1.6 Evaluation of architectures Mr. Lindborg remarks that the tiered criteria can weight more than the Boolean criteria and this inﬂuences the evaluation in step four of the framework. He thinks that assigning Boolean criteria that exists in a solution only one point can be too few. As an improvement, he states the weighting of evaluation criteria, as on the suggestions to the previous step.

6.1.7 Ranking the architectures Mr. Lindborg thinks the method of selecting the best architecture in the last step of the framework is appropriate. The only situation he is worried about is if there was a tie between two diﬀerent architectures. He facetiously suggests that in the case of a tie, dice could be thrown in order to select one of the architectures with most points.

6.1.8 Usefulness of FISCSiMA Questions in this category aim to evaluate whether the framework is in fact of use to entities that need a framework for choosing integrating architecture in the ﬁrst place. Mr. Lindborg has never heard about any other methods or frameworks for choosing integration architecture for shopping cart software. Nevertheless, he thinks that FISCSiMA is a straightforward framework and that it would help him pick a suitable architecture for integrating shopping cart software into a mobile application. He cannot think of any other ways of doing what the framework does. About the presentation of the framework, Mr. Lindborg thinks there should have been more introductory information available about how many diﬀerent shopping cart software and how many architectures there are. From the framework itself, he thinks it is missing an optional testing part About the usefulness, functionality, and completeness of the FISCSiMA framework, Mr. Lind- borg thought he was not the appropriate person to evaluate it. He suggested asking the questions from a company that is in the process of integrating software into mobile applications more often.

6.2 Summary

In this Subchapter we summarize the analysis done in Subchapter 6.1 and specify which parts of the framework were deemed good by the interviewee and which parts need improvement according to them.

6.2.1 Good parts of the framework Mr. Lindborg thinks that FISCSiMA is a straightforward framework which helps in the selection of integration architecture. Following the steps of the framework, he thinks that the choice of software to be studied in the ﬁrst step, the identiﬁcation of integration architectures in the second step, and the selection of the best architecture in the last step of the framework are done in an appropriate manner. Mr. Lindborg also thinks that the two types of evaluation criteria used, Boolean and tiered, are suitable.

32 6.2.2 Suggested improvements The interviewee suggested improvements to the existing steps of the framework, as well as to the framework in overall. The following list contains suggestions for the existing steps of the framework.

• In the ﬁrst step of the framework, Mr. Lindborg brings up a new criterion “Liveness of development”, which could be used instead of popularity. • In the second step, Mr. Lindborg suggests that there is repetitive work of searching for integration architectures done each time the framework is used that could be replaced by having a collection of architectures which users of the framework could refer to. • The third step of the framework, according to Mr. Lindborg, could be improved by adding a standard set of evaluation criteria to it. A standard set of evaluation criteria would be used in evaluation every time the framework is used, but the user of the framework would be able to add in their own criteria that are not included in the standard set. • Mr. Lindborg thinks that in the fourth step, the evaluation criteria could be improved by adding weighting to them. Weighting should allow the user of the framework prioritize between the criteria. • The last step could be improved by solving or specifying what to do if a tie occurs between two architectures. For example by throwing a dice, according to Mr. Lindborg.

Overall, Mr. Lindborg suggests that the framework should include an optional testing step. Also, the presentation of the framework could be improved by adding more introductory information about how many shopping cart software and how many diﬀerent integration architectures exist.

Chapter 7

Fine-tuning the framework

In this Chapter, we discuss the improvements suggested by the interviewee and introduce improvements to the framework. We also discuss how the improved framework would have done diﬀerently in the test of the framework presented in Chapter 5. Subchapter 7.1 discusses the suggested improvements and arguments whether they are appropriate to be added to the framework or not. Subchapter 7.2 presents the improved steps of FISCSiMA framework. Subchapter 7.3 discusses how the test of the framework would have been diﬀerent with the improved steps.

7.1 Analysis of improvement suggestions

We start the analysis of improvement suggestions from the suggestions aimed at the existing steps of the framework in the Sections 7.1.1-7.1.5. In Section 7.1.6 we go over to the improvement suggestions aimed at the overall framework.

7.1.1 First step - Adding new criteria Having a new criterion “Liveness of development” in the ﬁrst step is in fact included in the framework. FISCSiMA makes it possible to use any criterion when identifying software to be studied. This is why we do not consider it as an improvement.

7.1.2 Second step - Online collection of identified architectures Identifying integration architectures is repetitive and the results obtained from the step can be reused when doing the same step again, regardless of different criteria used in the first step. A collection of integration architectures would make it possible for users to see architectures identified by other users and share their own findings avoiding redundant work. However, a collection available online is not considered part of a framework and thus this suggestion is not considered as an improvement.

7.1.3 Third step - A standard set of evaluation criteria A standard set of evaluation criteria would make it possible to compare results obtained from running the framework with others. It would also make it easier to select evaluation criteria because a number of them have already been chosen. However, a standard set of criteria would induce redundant work to the process of using the framework, as criteria that is not important for the user, or not applicable to the architectures identiﬁed, must be used in the evaluation. Also, the standard criteria would aﬀect the results obtained from running the framework, even though they may not be important to the framework user. As technologies develop, the standard set of criteria chosen today may become obsolete in the future, thus they would require maintaining. Because of these reasons, we decided that having a standard set of evaluation criteria as part of the framework is not appropriate.

35 7.1.4 Fourth step - Weighted evaluation criteria The weighting of evaluation criteria would make it more ﬂexible to prioritize between the evaluation criteria used. Without it, the user of the framework must choose carefully which criteria to include as the criteria are otherwise treated as equal. We decided to add this improvement to the fourth step of the framework. The improved step is described in the next Subchapter.

7.1.5 Fifth step - Handling tie situations What to do in a tie situation has not been addressed by the FISCSiMA framework and this may confuse users. Tie situation in the ranking eﬀectively means that the architectures are equal according to the chosen evaluation criteria. We decided to add mention of the tie situation and suggestion how to make a selection in that case to the ﬁfth step.

7.1.6 Other improvements Having introductory information in the presentation of the framework is not part of the framework and thus not considered an improvement. Nevertheless, introductory information about how many shopping cart software and how many integration architectures exist were added to this document. After the best architecture is selected, it is the best according to the evaluation criteria provided evaluation was done properly. Therefore, no testing should be necessary to be included as a part of the framework. In the case of tie situation testing could be justiﬁed, but not in other cases. How exactly the testing of architectures should be done in order to serve its purpose best is a matter of completely another research. For these reasons, we decided not to include testing as a part of the framework.

7.2 Improved FISCSiMA framework

In this Subchapter we introduce the two improvements, the weighting of evaluation criteria and handling tie situations to the steps four and ﬁve of the framework. Weighted criteria are introduced in Section 7.2.1 and Handling of tie situation is Section 7.2.2.

7.2.1 Fourth Step - Weighting criteria with Weighted sum model We decided to add weighting of criteria to the framework with a well-known weighting model, the Weighted Sum Model (WSM). WSM is a straightforward and uncomplicated method in decision theory for evaluating multiple alternatives in terms of multiple decision criteria [74]. In the WSM model, weights are added to each evaluation criteria in order to prioritize them. The more prioritized a criterion is, the higher weight it should have. The weights are decimal values and the sum of all the weights used must be 1. After evaluation of architectures has been done in the fourth step of FISCSiMA framework as described in Chapter 4, a WSM score is calculated for each architecture. The WSM score is calculated for an architecture by multiplying points received according to each evaluation criteria with the weight of the evaluation criteria and summing them up. The architecture with highest WSM score is best according to the weighting.

7.2.2 Fifth Step - Handling ties Handling of ties is solved partly with the weighting of the criteria. When multiple architectures have the same amount of points, the one with most points on the criteria with most weight is chosen as the best one. In case there are multiple criteria with most weight, the solution with most points in total on the criteria with most weight is chosen as the best one. If the architectures in a tie have the same amount of points in the most weighted criteria, the criteria with second most weight are used in an identical manner and so on. In case the algorithm described above does not succeed in picking the best solution, for example, if there is a tie where multiple architectures have scored identically on every criterion, the architectures can be diﬀerentiated by tossing a coin. A coin toss is appropriate as the architectures have scored identically in every criterion signiﬁcant to the user.

36 Table 7.1: Summary of evaluation using WSM method Weight criterion Using API Using API with Integrated Proxy Browser 0.3 Multi platform 1 1 1 0.3 API used as in- 1 0 1 tended 0.1 Not Vulnerable 1 1 0 to Cross-site Scripting (XSS) 0.1 Usability 2 2 1 0.2 Cost of imple- 1 0 2 mentation Total 6 4 5 0.3 + 0.3 + 0.1 Calculation of 0.3*1 + 0.3*1 + 0.3*1 + 0.3*0 + 0.3*1 + 0.3*1 + + 0.1 + 0.2 WSM score 0.1*1 + 0.1*2 + 0.1*1 + 0.1*2 + 0.1*0 + 0.1*1 + 0.2*1 0.2*0 0.2*2 1 WSM score 1.1 0.6 1.1

7.3 Test of the improved framework

In this Subchapter we consider how the usage of the framework in Chapter 5 would have been different if the improved version of the framework was used. Because only steps four and five of the framework were improved, we limit our consideration to those steps. Step four and five are considered in Sections 7.3.1 and 7.3.2 respectively.

7.3.1 Evaluate architectures Using weighted criteria in the fourth step, we decided to prioritize criteria Multi platform and API used as intended the most. These were both given weight of 0.3. The criterion Cost of implementation was prioritized as being less important than the two, but more important than Usability and Not vulnerable to Cross-site Scripting (XSS). Cost of implementation was thus assigned a weight of 0.2. The remaining two criteria were both assigned weight of 0.1. The sum of the weights is 1. Table 7.1 on page 37 contrasts the use of the weighting with our previous unweighted approach in chapter 5 Using the FISCSiMA framework. The bold rows show the results got without weighting on row as well as with weighting. The results show that with this weighting Integrated browser is as good architecture as Using API, whereas without using weights Using API was preferable. By using the weighting of criteria, we have made the FISCSiMA framework more powerful and flexible by enabling customization and personification of the evaluation criteria to fit the user’s specific needs.

7.3.2 Rank the architectures The ranking done in Chapter 5 did not end up in a tie situation, thus the tie-solving improvement would not have made any diﬀerence. However, in the last Section when evaluating the architectures using weighted criteria, it resulted in a tie between Using API and Integrated browser. This tie can now be solved by our improved FISCSiMA framework. The criteria Multi platform and API used as intended have the highest weights. On those criteria, both architectures have a total of two points. The second highest weight is on criteria Cost of implementation and Using API has only one point on it, whereas Integrated browser has two. Thus Integrated browser is the best solution and the tie situation is solved.

Chapter 8

Discussion

In this Chapter we discuss our work critically and consider what we would have done differently if we were to conduct the same work again. The critical evaluation of our work is divided into parts by the research phases we had. Literature study and complementary literature study phases were merged into one part called information gathering. The rest of the parts have identical names to their corresponding phases. The five parts are thus Information gathering, Interview of involved bodies, Design of framework, Evaluation and Fine-Tuning. These parts are presented in Subchapters 8.1 through 8.5 respectively. In Subchapter 8.6 we consider what we would do differently if we were to conduct the same research again.

8.1 Information gathering

When conducting literature study to gain understanding of the field, it was revealed that the previous state of shopping cart software and their integration into mobile applications is poorly researched and the information is scattered around. Great deal of our work therefore consisted of piecing together shopping cart software-, mobile application- and mobile application creation specific information and forming an image of the whole of the field. Literature study focused on e-commerce, shopping cart software, and mobile applications as well as different frameworks. It is possible that when searching for literature, suboptimal keywords or search engines were used. It’s also possible that the material found is not trustworthy. We attempted to mitigate the problem of untrustworthy material by making a note of where a source was published, who is the author, for who was it written and whether the information is relevant for the study as stated in Chapter 3.

8.2 Interview of involved bodies

In the second phase we conducted a spontaneous unstructured interview of our client to gain information of what they deem important in a mobile application and ideas how shopping cart software could be integrated into mobile application. Our client is not a shopping cart software- or mobile application professional, thus the information gotten from the interview may be false or not as valuable as it would have been if we had interviewed a professional. Also only one interviewee was used. More information could have been gained with multiple interviewees.

8.3 Design of framework

In this phase we used the data from the literature study and interview of our customer to design the FISCSiMA framework. We made use of the information pieced together in the literature study and complementary literature study phases. Because the information were pieced together by us, there are risks of overlooking limitations or making false generalizations. For example the group of shopping cart software may be too heterogeneous to be compared to each other or to be put into same category. There is also possibility that we have misinterpreted the literature used or the results of the unstructured interview of our client.

39 8.4 Evaluation

Evaluation of the framework was conducted in fourth phase of the research by interviewing our client using a questionnaire. The client was allowed to familiarize themselves with the framework description in Chapter 4, the example usage of the framework in Chapter 5, as well as the questionnaire questions before the interview. The results of the usage of the framework in Chapter 5 cannot be compared to results from some other framework, because there are no existing frameworks for selecting integration architectures. Also as the results have not been implemented and tested, the correctness of the results obtained from the framework are only backed up by architecture ranking step of the framework. The ranking step of the framework grounds its results on evaluation that is done by the framework user. This effectively puts the responsibility to the framework user to evaluate the architectures correctly and incorrect results are not caused by the framework. The results of the evaluation of the FISCSiMA framework conducted using the questionnaire indicate that FISCSiMA is a straightforward framework that helps in the selection of shopping cart software integration architecture. According to the interviewee, the activities of FISCSiMA are appropriate and the flow of the framework is intuitive. However, the framework was evaluated only by one person, who is not a shopping cart software- or mobile application professional. Our client therefore felt that he was unable to evaluate the usefulness, functionality and completeness of the framework. This means that it is crucial that further investigation is done to validate FISCSiMA’s merits. Furthermore, the evaluation was only done before the improvements were applied to the framework. This leaves the final version of the framework unevaluated. We chose not to evaluate the improved framework as the changes were minor. Instead we attempted to re-do the steps of the framework that were changed by the improvements.

8.5 Fine-tuning

In the last phase of our work we incorporated part of the improvements suggested by our client in the evaluation of the framework to the FISCSiMA framework. After incorporating the improvements, the framework was tested. Only part of the suggested improvements were incorporated to the framework and the decision whether to incorporate an improvement was done by us. We attempted to justify every decision, but there is a chance that we have overlooked something and therefore a suboptimal improvement was incorporated or an optimal improvement was left out. Nevertheless the testing of the improved framework showed promising results that suggest the framework functions as intended.

8.6 What would we do diﬀerently

If we were to conduct the same work again, we would approach the subject similarly and have identical set of research phases. During interview of involved bodies we would conduct unstructured interview of, instead of an individual, multiple professionals that work with shopping cart software integration on a regular basis. When evaluating the framework, we would also use the same set of professionals to interview using the questionnaire. After incorporating suggested improvements to the framework, we would try using the framework in real life, implementing the architectures and evaluating them. This way we could quantitatively test whether the results of the framework are correct.

40 Chapter 9

Conclusion and future work

To simplify e-commerce, many retailers use shopping cart software. However a large number of shopping cart software do not address serving mobile clients, otherwise than using a responsive website. In these cases, if a retailer wants to serve mobile clients using a standalone mobile application instead, they need to solve how to convert the store into mobile accessible form. When converting shopping cart software into mobile accessible form, the hardest part is to choose an integration architecture. The problem is, that selecting the optimal integration architecture for integrating shopping cart software into a mobile application can be challenging and complex. To solve this prolem we conducted a research with the purpose of developing a framework for integrating shopping cart software into a mobile application. The conducted research had two goals: (1) guiding entities in choosing an integration architecture for shopping cart software and (2) providing a basis for further research in the domain of integration architecture selection models. The research conducted was of qualitative type, research method was applied research and research approach was inductive reasoning. During the research we worked in five research phases: (1) Literature study, (2) Interview of our client, (3) Design of framework, (4) Evaluation and (5) Fine-tuning. Following these phases, we collected basic knowledge of shopping cart software and their mobile integration from the two first phases to design a framework in the third phase. The designed framework was then evaluated in the fourth phase and finally improved according to the feedback from the evaluation in the fifth phase. The research resulted in FISCSiMA framework, which assists users in choosing a suitable software architecture for integrating their shopping cart software into a mobile application. In this chapter we make final conclusion and then go over to suggestions for future work. Subchapter 9.1 presents the conclusion, and Subchapter 9.2 presents the suggestions for future work.

9.1 Conclusion

There are various standards that aim to aid organizations select software components. Right now, there are methods for selecting software architecture styles. However, there are no models or frameworks that aid in choosing an architecture for integrating shopping cart software into a mobile application. This is surprising considering the popularity of shopping cart software in online stores and the increasing popularity of mobile e-commerce. Our client Mr. Lindborg was facing this exact problem and it made us formulate a research question inquiring how different integration architectures can be identified and how selection can be done among them. To address the research question, the heterogeneous domain of shopping cart software, software architectures, and mobile applications was researched. The research materialized in Framework for Integrating Shopping Cart in Mobile Applications (FISCSiMA) framework. FISCSiMA framework defines how shopping cart software is chosen for research, how integration architectures are identified, how the identified architectures are evaluated and how the best architecture is chosen. The framework aims at guiding online retailers using shopping cart software in selecting an appropriate integration architecture for their mobile application. The research was qualitative and it used inductive reasoning approach. Interpretivism was the philosophical assumption used. Data collection was conducted mainly via a literature study and an interview questionnaire. Due to the lack of available information regarding shopping cart

41 software and their integration into mobile applications, we could not base our work on anyone else’s research. The theory behind the FISCSiMA framework had thus to be created from scratch instead. The test of the framework, both before and after improvements, as well as the results of the questionnaire have shown that FISCSiMA is a straightforward framework that helps in the selection of shopping cart software integration architecture. According to the interviewee, the activities of FISCSiMA are appropriate and the flow of the framework is intuitive. FISCSiMA is extremely flexible and it can be used choose the best integration architecture according to almost any criteria. As the suggested improvements indicate, there are also shortcomings in the framework, such as redundant work in the absence of living collections of integration architectures and a standard set of evaluation criteria. However, the omission of these from the framework was justified in Chapter 7.

9.2 Future work

To investigate the merits of the FISCSiMA framework it needs to be further evaluated by industry and academia. One specific group we would like to see the FISCSiMA framework evaluated by is industry actors that integrate shopping cart software into mobile applications regularly, as suggested by our client in the interview. He suggested that this would give new and important insights on the effectiveness of the framework. Further work also includes researching the possibility of extending the FISCSiMA framework with some suggestions mentioned in the evaluation but not included in the final framework. For example an online collection of identified architectures or a standard set of evaluation criteria. Finally, as FISCSiMA framework is aimed at shopping cart software, it could be researched whether it is applicable to other types of software.

42 Bibliography

[1] M Niranjanamurthy, N Kavyashree, S Jagannath, and Dharmendra Chahar. Analysis of e- commerce and m-commerce: advantages, limitations and security issues, 2013.

[2] Statista. Global e-commerce share of retail sales 2021. https://www.statista.com/ statistics/534123/e-commerce-share-of-retail-sales-worldwide/, 2018. Accessed: 2018-03-02.

[3] C. Zorzini. All the ecommerce platforms & shopping cart softwares: 120+ list. https:// ecommerce-platforms.com/articles/shopping-carts-software-ecommerce-platforms, 2017. Accessed: 2018-03-02.

[4] Global ecommerce topped $2.3 trillion in 2017. https://retail.emarketer.com/ article/global-ecommerce-topped-23-trillion-2017-emarketer-estimates/ 5a6f89f5ebd40008bc791221, 2018. Accessed: 2018-03-02. [5] A. Håkansson. Portal of research methods and methodologies for research projects and degree projects. Proceedings of the International Conference on Frontiers in Education: Computer Science and Computer Engineering FECS’13, 13, 2013.

[6] watt s.se. Om watt-s - watt-s. http://watt-s.com/om-watt-s. Accessed: 2018-03-02. [7] L. S. Rosqvist and L. W. Hiselius. Online shopping habits and the potential for reductions in carbon dioxide emissions from passenger transport, 2016. [8] J. Laghaei, A. Faghri, and M. Li. Impacts of home shopping on vehicle operations and greenhouse gas emissions: multi-year regional study, 2015. [9] P. Van Loon, A.c. Mckinnon, L. Deketele, and J. Dewaele. The growth of online retailing: a review of its carbon impacts, Apr 2014. [10] O. X. Huei and R. Yazdanifard. On-line retailing; ethical issue, legal issue and challenges of on-line retailers., 11 2013. [11] T. L. Mesenbourg. Measuring electronic business, 2001.

[12] Stores are being hit by online retailing. https://www.economist.com/special-report/ 2017/10/26/stores-are-being-hit-by-online-retailing, Oct 2017. [13] Best buy looks to new products to push sales. http://www.minneapolisnews.net/news/ 225119543/best-buy-looks-to-new-products-to-push-sales, 2014. Accessed: 2018-03- 02.

[14] Bigcommerce. What is ecommerce software? https://www.bigcommerce.com.au/ ecommerce-answers/what-ecommerce-software/. Accessed: 2018-03-02. [15] Mobile fact sheet. http://www.pewinternet.org/fact-sheet/mobile/, 2018. Accessed: 2018-03-02.

[16] Wikipedia contributors. Online shopping. https://en.wikipedia.org/wiki/Online_ shopping. Accessed: 2018-03-02. [17] T. Horda. Pros and cons of mobile websites and mobile apps. https://rubygarage.org/ blog/mobile-app-vs-mobile-website. Accessed: 2018-03-02.

43 [18] Techopedia. Integration architecture. https://www.techopedia.com/definition/30625/ integration-architecture. Accessed: 2018-03-02. [19] Bass L., P. Paul Clements, and R. Kazman. Software architecture in practice, 2003. [20] H.F. Nielsen, A. Karmarkar, J.-J. Moreau, M. Hadley, M. Gudgin, Y. Lafon, and N. Mendel- sohn. Soap version 1.2 part 1: Messaging framework (second edition). http://www.w3.org/ TR/2007/REC-soap12-part1-20070427/, apr 2007. Accessed: 2018-06-13. [21] Json introduction. https://www.w3schools.com/js/js_json_intro.asp. Accessed: 2018- 03-02. [22] Xml tutorial. https://www.w3schools.com/xml/default.asp. Accessed: 2018-03-02. [23] P. Christensson. Sdk (software development kit deﬁnition. https://techterms.com/ definition/sdk, 2010. Accessed: 2018-03-02. [24] Bruno Pedro. What are web apis. https://hackernoon.com/ what-are-web-apis-c74053fa4072. Accessed: 2018-06-15. [25] A. Luotonen and K. Eltis. World-wide web proxies. http://courses.cs.vt.edu/%7Ecs4244/ spring.09/documents/Proxies.pdf, 1994. [26] Apigee. Api proxy. https://apigee.com/about/cp/api-proxy. Accessed: 2018-03-02. [27] website.com. ecommerce - shopping cart and ecommerce. https://www.website.com/ beginnerguide/ecommerce/3/1/shopping-cart-and-ecommerce.ws. Accessed: 2018-06-15. [28] C. Zorzini. Best ecommerce platforms & shopping cart software comparison chart. https: //ecommerce-platforms.com/comparison-chart. Accessed: 2018-03-02. [29] P. Viswanathan. What is a mobile operating system? https://www.lifewire.com/ what-is-a-mobile-operating-system-2373340, 2018. Accessed: 2018-03-02. [30] International Data Corporation (IDC). Idc: Smartphone os market share. https://www.idc. com/promo/smartphone-market-share/os. Accessed: 2018-03-02. [31] Magento Inc. Introducing enterprise edition 1.14.2 - magento. https://magento.com/blog/ magento-news/introducing-enterprise-edition-1142, 2015. Accessed: 2018-03-02. [32] J. Lindborg. Solceller engagerar, men hur får vi alla att ta ett litet steg, tillsammans? - gästkrönikor. http://blogg.solelmassan.se/ solceller-engagerar-men-hur-far-vi-alla-att-ta-ett-litet-steg-tillsammans/, 2016. Accessed: 2018-03-02. [33] T. Harnesk. Nu kan alla köpa in sig i solcellsanläggning. Ny Teknik, 2016. Accessed: 2018-03-2. [34] Automattic. Woocommerce features - woocommerce. https://woocommerce.com/features/. Accessed: 2018-03-02. [35] Q. Wang and Z. Yang. A method of selecting appropriate software architecture styles : Quality attributes and analytic hierarchy process, 2012. [36] M. Högberg, M. Kajko-Mattsson, P. Persson, and A. Håkansson. System requirements prioritization framework, 2018. Accessed: 2018-03-02. [37] Research Rundowns. Instrument, validity, reliability. https://researchrundowns.com/ quantitative-methods/instrument-validity-reliability/. Accessed: 2018-03-02. [38] W. Trochim. Social research methods - knowledge base - deduction & induction. http: //www.socialresearchmethods.net/kb/dedind.php, 2006. Accessed: 2018-03-02. [39] A. B. Kajornboon. Using interviews as research instruments, 2005. [40] M. Myers, D. Qualitative research in business and management, 2009. [41] I. Bryman and E. Bell. Business research methods, 2007.

44 [42] Statistics Solutions. What is transferability in qualitative research and how do we establish it? - statistics solutions. http://www.statisticssolutions.com/ what-is-transferability-in-qualitative-research-and-how-do-we-establish-it, 2018. Accessed: 2018-03-02. [43] Aheadworks. Ecommerce platforms popularity, may 2015: Two platforms take half. https://blog.aheadworks.com/ ecommerce-platforms-popularity-may-2015-two-platforms-take-half/, 2015. Ac- cessed: 2018-03-02. [44] Neugschwandtner M., Lindorfer M., and Platzer C. A view to a kill: Webview exploitation. http://publik.tuwien.ac.at/files/PubDat_223415.pdf, 2013. Accessed: 2018-03-02. [45] Google. https://www.google.se/. Accessed: 2018-03-02.

[46] Google scholar. https://scholar.google.se/. Accessed: 2018-03-02. [47] Build software better, together. https://github.com/. Accessed: 2018-03-02. [48] Wikipedia contributors. Wikipedia. https://www.wikipedia.org/. Accessed: 2018-03-02. [49] Magento Inc. ecommerce open source - free ecommerce website - magento. https://magento. com/products/open-source. Accessed: 2018-03-02. [50] Magento Inc. Getting started with magento web apis magento 2 developer documentation. http://devdocs.magento.com/guides/v2.2/get-started/bk-get-started-api. html. Accessed: 2018-03-02. [51] Rest api - authenticated user has ability to read/write others users data · issue #9494 · woocommerce/woocommerce. https://github.com/woocommerce/woocommerce/issues/ 9494, 2015. Accessed: 2018-03-02. [52] PrestaShop. About prestashop. https://www.prestashop.com/en/about-us. Accessed: 2018-06-13.

[53] X. Borderie. Using the prestashop web service - prestashop 1.6 - prestashop documentation. http://doc.prestashop.com/display/PS16/Using+the+PrestaShop+Web+Service, 2014. Accessed: 2018-03-02.

[54] Shopify. The ﬁrst shopify store was our own. https://www.shopify.com/about. Accessed: 2018-06-12.

[55] Shopify. Shopify app developer program. https://developers.shopify.com/. Accessed: 2018-03-02.

[56] Shopify. Mobile buy sdk. https://help.shopify.com/api/sdks/custom-storefront/ mobile-buy-sdk. Accessed: 2018-03-02.

[57] T. Cain. Magento opensource vs magento commerce... who wins? https://www.salmon.com/ en/what-we-think/blogs/magento-opensource-vs-magento-commerce/, 2017. Accessed: 2018-03-02.

[58] Webview - android developers. https://developer.android.com/reference/android/ webkit/WebView.html. Accessed: 2018-03-02.

[59] Uiwebview - uikit - apple developer documentation. https://developer.apple.com/ documentation/uikit/uiwebview. Accessed: 2018-03-02. [60] S. Amatya. Degree project cross-platform mobile development:, alternative, an development, native mobile. http://lnu.diva-portal.org/smash/record.jsf?pid=diva2: 664680&dswid=OATDFullTextWindow, 2013. Accessed: 2018-03-02.

[61] L. Garﬁeld. Backward compatible apis - garﬁeldtech. https://www.garfieldtech.com/ blog/backward-compatibility, 2012. Accessed: 2018-03-02.

45 [62] Apigee. Understanding apis and api proxies. https://docs.apigee.com/api-platform/ fundamentals/understanding-apis-and-api-proxies. Accessed: 2018-03-02.

[63] Woocommerce rest api documentation - wp rest api v2. http://woocommerce.github.io/ woocommerce-rest-api-docs/. Accessed: 2018-03-02. [64] Google. Webview. https://developer.android.com/reference/android/webkit/ WebView.html. Accessed: 2018-03-02.

[65] Google. Cookiemanager. https://developer.android.com/reference/android/webkit/ CookieManager.html. Accessed: 2018-03-02. [66] Ergonomic requirements for oﬃce work with visual display terminals. Technical report, Inter- national Organization for Standardization, Geneva, 1998. Accessed: 2018-03-02.

[67] J. Nielsen. Is poor usability killing e-commerce? https://www.nngroup.com/articles/ did-poor-usability-kill-e-commerce/, 2001. Accessed: 2018-03-02. [68] D. Lee, J. Moon, Y.J. Kim, and Y.Y. Mun. Antecedents and consequences of mobile phone usability: Linking simplicity and interactivity to satisfaction, trust, and brand loyalty, 2015. Accessed: 2018-03-02.

[69] Hazarika P., Rahul R. C. P., and Tolety S. Recommendations for webview based mobile applications on android, 2015. Accessed: 2018-03-02.

[70] Choosing between a web and native experience. https://msdn.microsoft.com/en-us/ library/jj149679.aspx, 2012. Accessed: 2018-03-02.

[71] R. Budiu. Mobile: Native apps, web apps, and hybrid apps. https://www.nngroup.com/ articles/mobile-native-apps/, 2013. Accessed: 2018-03-02. [72] W. S. El-Kassas. Taxonomy of cross-platform mobile applications development approaches, 2017. Accessed: 2018-03-02. [73] M. Andersson and J. Andreasson. Smartphoneutveckling för ﬂera plattformar, 2013. Accessed: 2018-03-02. [74] Triantaphyllou, E. Multi-criteria decision making methods: A comparative study, 2000.

46 Appendices

47 Appendix A

Interview

The software from www.trint.com has been used with corrections made by Jacob Kristersson to dictate the interview.

VL: [00:00:00] All right. We have like.These categories like we start with appropriateness of the interview interviewing and then we go to identification of software to be studied which is step of our framework then Identification of relevant integration architectures selection of evaluation criteria evaluation of architectures ranking of architectures and then lastly we’ve got other questions in total we have like 1 2 4 6 7 8 9 10 11 12 13 14 questions but it just the page right. Yeah. All right. First question Joachim. Did you use any kind of shopping cart software as a retailer. JL: [00:00:56] Yes I have used woocommerce and I’ve tried another one for my little sisters cake shop which was sort of a it was a package inside loopia where you just sort of point and click and you get the shop I don’t really remember the name but it’s a loopia thing right. VL: [00:01:26] Are you interested in integrating the shopping cart software into mobile application. JL: [00:01:33] Yes very. Because otherwise or my my my take is that it will be much easier for users to buy the products I have since they are very small and its very small amounts and you probably don’t do that in sort of a bigger environment you need to be on a mobile app. It’s easy you just just buy things. VL: [00:02:02] Yes yes. All right. That was the appropriateness of the interviewee. Then go to the first step off the framework which was identification of software to be studied. It’s the way that FISCSiMA framework identifies shopping cart software to be studied suitable. JL: [00:02:28] I would say yes. The problem is of course to find the architectures from the beginning. If there is a sort of a start where you can find all of this because if you start just from scratch and start searching it you could miss a lot. VL: [00:02:48] Yes. JL: [00:02:48] But there’s a good sort of list where you can stop and look. VL: [00:02:57] Yes. Yes. I think you like mean the architectures now. JL: [00:03:03] Yes. VL: [00:03:04] We were talking about shopping cart software. JL: [00:03:07] Yep. VL: [00:03:07] Yes like there are 120 of those and you need some help like you know shrink the amount of like. JL: [00:03:17] Yes. VL: [00:03:18] The ones you gonna study more closely. The way we do it was that we take some criteria for example popularity and then we take like five most popular shopping cart software and then we study those in the framework. Is that suitable way. JL: [00:03:41] I would say yes. VL: [00:03:44] Yes. JL: [00:03:45] I would also perhaps think about it is that’s probably other category is popularity and what can you call it liveliness in development. So is it’s sort of a dead product that a lot of people use or is it an live product that’s not really finished. VL: [00:04:09] Yes. True. VL: [00:04:12] All right then. Is there something that should be done differently in the selection.

48 JL: [00:04:24] No I think it’s good. Perhaps what I said though with the liveness. So you do know that this is not a dead product that you sort of choose and then really it really you realize that two months later that would be good. VL: [00:04:45] All right very well. And then we go to identification of relevant integration architectures. I think you thought about this one. Is the way the FISCSiMA framework identifies integration architectures appropriate if not what should be done differently. JL: [00:05:07] Oh yeah. Would agree you need to find the criterias and you need to. Of course the most important ones from what I need to be done in the app. So that’s that’s a good way to go. VL: [00:05:30] Like going to the documentation of a software. JL: [00:05:34] Yeah. And of course if you were to redo it a lot of times having done the reading and getting continuous knowledge expansion in the FISCSiMA network. So if you have done one and then you do several according to your process you’ll of course learn more. You don’t need to start again with the documentation. Yes that would be very good for others. So if it could be a sort of live tool where people do these tooling works. Look at that. So you get the criteria is quite closely together. Then it would be a very good start for the next one. VL: [00:06:26] Yes. Okay then step 3 The framework would you prefer a standard set of evaluation criteria standard set of evaluation criteria main criteria that is always used as a criteria. When you when you go to through things. JL: [00:06:54] Yes I think so definitely be very good. If it’s a repeated thing for me as a onetimer doing it for my app I perhaps feel that oh I would like to have my tweaked special criteria sort of is ing good in handling SVG because I’d really like to have a lot of life things that can perhaps be very narrow criteria. So if there is a set of standard and criterias that is used in this schema so no great tools JK: [00:07:29] for different users maybe. JL: [00:07:31] Yeah yeah. So so I would say yes to the question What is it good to have a set of the same evaluation criterias VL: [00:07:39] and should be used always to reduce always. JL: [00:07:42] And then you perhaps add one or two that is specific to a certain application VL: [00:07:50] but don’t you don’t you think that it would like to make it hard to use the framework if there is always some criteria that you may be or not interested in. But like needs to be like used. JL: [00:08:04] I would say that in that case I could perhaps have a lower weight on that criteria, that would bring me to a level that well okay this is a good criteria to compare but it’s not so important for me. Then I put a low wait on it. But it’s very good to have. If you look at the toolchain and to see that while others have already evaluated on these criterias VL: [00:08:37] Oh yeah that’s true. JK: [00:08:38] Can compare them JL: [00:08:40] there’s a good comparison way. And they don’t need to be many a few. VL: [00:08:48] All right. Then second question Are the two types of evaluation criteria in FISCSiMA framework Boolean and tiered relevant. Is it good to have these two kinds of criteria. JL: [00:09:08] Yes. I can’t believe there is anything else. I mean then you go for a sort of mathematical Twist’s It’s a logarithmic or linear or. So yes it’s good because you keep it simple. VL: [00:09:24] Yeah. JL: [00:09:26] And it has two differences and it gets another level of weighting since you can in the triple tiered have more weights on different things. So yeah I can’t imagine another way to do it unless for a total mathematical method or something where you sort of calculate what to choose from that VL: [00:09:51] very well. Third question would you prefer weighting off evaluation criteria. JL: [00:09:58] I would say yes yes. That would be very good for me to sort of oh I don’t have a problem with cost but it needs to be very nice or cost is more important for me. You can skip spinning icons. It would be. Yeah I think weighting is very good to have VL: [00:10:28] and show we move to the next step then evaluation of architectures steps 4 do you agree with the way how do architectures are assigned points if not what should be done differently. JL: [00:10:52] Well that’s one 1 zero as well get down to the weighting then again. I think then again should the tiered criteria go when they come up to the two points are they there. They are weighing more than a Boolean criteria with one point. So perhaps when you do this have done a

49 few perhaps you see that the Boolean things are weighing too less than the tiered ones that could be a fact that that sort of influences the evaluation. But I don’t see that we should to remove or change it until you have tried it. VL: [00:11:42] You see we’re seeing. All right. Well next step then the last one to framework ranking of architectures. Do you agree with the way FISCSiMA framework selects the best architecture they can the best the one with the most points if not what should be done the differently. JL: [00:12:10] I mean if you have done the weighting and you’ve done the measuring then you shouldn’t really be on the right track. So no I wouldn’t say that it’s wrong VL: [00:12:22] How about the tie situation JL: [00:12:24] The tie situation could be problematic. Well then you have special stack where you have dice and do ten or eleven dice throws. And then you have the solution. Well it’s no I don’t say it’s a straightforward method. It’s nothing you can sort of say no to. VL: [00:12:54] All right. And then other questions have you used any other methods or frameworks for choosing integration architecture for shopping cart software. If Yes which ones and how do they work. VL: [00:13:10] I have never heard such a tool. I think you First off there. you’re almost on to a product here. So yeah. This is sort of a go for a Web site started up and have the knowledge and people will probably help you to get the data in. And then you can sell it to anybody because people have a lot of troubles finding the right one for them. So you’re probably onto a product. VL: [00:13:43] All right next quick question. What are your overall thoughts of FISCSiMA framework. JL: [00:13:53] What if you look on the steps. It’s very straightforward. Is there any other way you can do it. Is it any new knowledge or is it just the fact you need to gather information gather what you want to do make a decision. Which is quite true but when you line it up and you do these evaluation materials and you make it more solid it is a real framework VL: [00:14:25] all right very good. Is there anything missing from the FISCSiMA framework in your opinion. If Yes please explain your thoughts. JL: [00:14:38] Well looking at all the papers I agree that I haven’t read everything having a line up of the architectures and the softwares would have been good to have in the beginning of the document somewhere to get a feeling of there is 150 plus architectures there is 25 of these or products and there’s 25 architectures and we now need to choose around it. So that could be a sort of a lay out the setting. JK: [00:15:14] So you have more introductory introduction setting JL: [00:15:18] A bit more introductory setting or you know there’s these hundred fifty software. Oh yeah. And among them there is 25 architectures that is sort of VL: [00:15:28] Need to be chose from JL: [00:15:30] And then we have these standard categories that you need to look at. So that could be a bit more of a formalized questionnaire through the process. VL: [00:15:42] Do you think there is any steps missing or JL: [00:15:49] perhaps if you think agile should there be a test. an iterative thing that you sort of. Okay. You’re almost there now do a test. VL: [00:16:03] Yes. JL: [00:16:05] But that depends on the project of course if there is time or if the money to do the test perhaps you need to choose one and then go for it. VL: [00:16:13] Yeah. JL: [00:16:15] So that could be perhaps an extra thing on finding three do an evaluation quickly get a feeling then narrowing it through the last so that perhaps you can sort of connect that around the evaluate of the architectures to have tests of that’s optional. VL: [00:16:45] Is FISCSiMA framework useful functional and complete when comparing to your normal way of working to choose integration architecture. JL: [00:16:59] Well define normal integration. Since I’ve been working with more or less 1 or two integrations. Yeah. Perhaps you could go to some development company to just put that question on on them. Yeah that can be. Who’s doing it constantly. Yeah because you know I’m sort of doing it once. VL: [00:17:26] Yeah except we see. JL: [00:17:27] Yes but I see it’s a very useful thing to do and it would help me to go do their choices for Watts.

50 VL: [00:17:40] Alright at the last question then. In what way does this framework solve the problem of choosing and integration architecture JL: [00:17:53] and you mean the special architecture or the actual software type used. VL: [00:17:59] Well yeah. It’s like you can include it both JL: [00:18:03] going all the way to the software so it’s the software chosen to do the actual VL: [00:18:10] Yeah. JL: [00:18:14] Well it’s probably giving me in the end the right choice. So that would probably be the answer to that in what way does it solved my problem. It will give me the right software to be used. VL: [00:18:34] Anything to add JK: [00:18:36] No I think that’s enough. VL: [00:18:39] Yes. It’s pretty straightforward. Self I can guess that you’re getting ties pretty often VL: [00:18:52] Ohh with the architectures yes. JL: [00:18:54] Both in selecting when you select the name drew the attention cafeteria’s will be slightly overlapping because you is. Yes. And then you have the architecture. Probably a few overlapping architectural things. VL: [00:19:10] Yeah. JL: [00:19:11] They sort of are almost equal on the criteria that you were thinking of. And then you have five or six softwares that solves the two architectures and in the end you perhaps have five software that will solve everything. VL: [00:19:28] Yes JL: [00:19:29] and then you’re stuck on what to choose. VL: [00:19:31] Yes yeah that’s true. So then you need to choose one of those JL: [00:19:36] and then have the dice. But perhaps it’s when you do all the criteria then you go to pricing that would be bring you to the one that cheapest or JK: [00:19:49] Evaluation criterias is the hardest part. VL: [00:19:57] to my mind it’s the second step of finding the architecture. JL: [00:20:03] And if you want if you move the evaluation criterias to be first one that change any JK: [00:20:13] then you can like the choose more appropriate software. So for those criterias maybe movers and VL: [00:20:21] you need to have a complete view of what’s out there. JK: [00:20:27] Yeah. JL: [00:20:30] I mean if you have the complete or at least a broad view of both architecture and software and then you take the criteria that it’s a good way to go for it. VL: [00:20:43] Yeah. JL: [00:20:45] So that’s I mean that’s the way you do now. And if I say well I need the cheapest thing ever then I could sort of go out and go to the softwares directly starting with the criteria VL: [00:21:01] yes JL: [00:21:02] so if I were to start with relation to criterias, cut off quite a lot of bits and then VL: [00:21:08] but in the first step when when you choose which software you want to study you can select the practice as one of the five cheapest ones and then you go through but then you weighting how you like it how you get most bang for the buck. It can be problematic. JL: [00:21:36] there can be a nice discussion in the end. VL: [00:21:38] Yes it’s true to work.

51 TRITA TRITA-EECS-EX-2018:671