Impact of stealth SaaS-ing for public organisation

Impact of stealth SaaS-ing for public organisation

a_{Student at the Univeristy of Amsterdam}

Abstract. Adoptions of SaaS (Software as a Service) are becoming increasingly more used in organisations. This increase in SaaS adoptions leads to an increasing need for understanding the implications of SaaS adoptions to the organisation. SaaS adoptions are, in some cases, adopted by business units without consulting or informing IT units. This is also called stealth adoption of SaaS or stealth SaaS-ing (Zainuddin, 2012). This latter part will be the focus of the research thesis. The research question is handled in the thesis research is: How does SaaS-ing impact the public sector?

The research consists of a literature analysis and a case study within three public organisations. This study is exploratory, and multiple real life cases are researched. The cases give insight to the impacts of stealth SaaS-ing. The outcome of this research in more knowledge about stealth SaaS-ing and a (new) understanding about the impacts of SaaS-ing. Impacts found during the research are that stealth SaaS-ing will increase risks for the organisations in the field of data security, availability, compliance of laws and more. It could also widens the gap between ICT and the business. In the long run it can change the role of the ICT department. However it could also give organisations a more flexible and creative ICT landscape. In the end it is up to the organisations themselves to see what kind of stealth SaaS-ing is beneficial for the organisation and should be allowed.

Keywords. SaaS, SaaS-ing, stealth SaaS-ing, stealth adoption, public service, public organisations.

Version: 2.0 – Public version

Data: 27-08-2015

Supervisor: Arjan Vreeken

Introduction

Software as a Service (SaaS) adoptions are increasingly in use within the organisational landscape. In the past years more attention has been given to SaaS by both practitioners and researchers. And SaaS suppliers themselves have grown and shifted from small pioneers to giant software companies (Goth, 2008). It is safe to say that almost all companies make use of SaaS, for example through a small service or multiple bigger ones.

This increase in SaaS adoptions lead to an increasing need for understanding of the implications of SaaS adoptions to the organisation. Within the literature SaaS can be adopted through two ways. Firstly the regular way, in which the innovation is managed through a top down structure. And secondly when the innovation is managed as a bottom up structure. The problem with the latter way is that the business units often adopt SaaS without consulting or informing the responsible IT unit. If that is the case, than it is also called stealth adoption of SaaS or stealth SaaS-ing (Zainuddin, 2012). And this stealth SaaS-ing is the focus of this research thesis.

This document is structured as follows. In chapter 1, the research field is explained. This chapter also include some relevant literature out of the fields of SaaS and SaaS-ing. In chapter 2, the research question and sub-questions of the thesis research is discussed. The research question is directed towards the impact of SaaS-ing within a public organisation. Chapter 3 discusses the research methods that are used during the thesis research. This chapter includes information about; the case studies, literature analysis and contains a global planning of the thesis project. Chapter 4 answers the first sub-question. In this chapter the types of SaaS are researched and the characteristics of stealth SaaS-ing are explained. Chapter 5 answers the last two sub-questions. In this chapter the selection and setup of the cases of the case studies are selected. The second half of chapter 5 discusses the found results of the case studies, and literature is analysed to account for the results. Chapter 6 contains the answer to the research questions. These are a generalization

of the found results of chapter 5.2. Finally in chapter 7 a discussion is placed regarding the results found, the research that is conducted and research that could potentially be conducted in the future.

1.

Research field

1.1.

Software as a Service (SaaS)

Before diving deeper in the concept of SaaS, let us first look at the concept of cloud computer or cloud services. Within cloud computing there are typically three types of services, see figure 1. Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS). In short, IaaS provides the hardware of servers in cloud form. PaaS provides an operating system installed on servers in cloud form. And SaaS provides already installed applications in cloud form. (“Cloud Computer”, 2010)

Figure 1: Layers of the cloud computing. Source: (“Cloud Computer”, 2010)

The term “Service Cloud” and “Sales Cloud” are used by Salesforce as synonyms of SaaS. Only the differences with the term SaaS is that people connect the term “cloud” to an application hosted somewhere on the net. (“Cloud synonym SaaS”, 2011)

“Software as a Service (SaaS) refers to an increasingly deployed delivery model, where standard enterprise applications are provided as a service over the Internet” (Winkler & Gunther, 2012). “The vendor delivers the bundle of IT infrastructure, software applications, and services to users through a network. Users pay a fee per transaction”(Ma D, 2007).

The literature defines the term SaaS as a software package that is offered and also hosted by the software provider. Usually the client buys licenses to work with the software for a certain amount of time and for a certain amount of users. Typically the software is accessed over the internet.

Examples of SaaS services include enterprise-level applications such as Salesforce or Netsuite to personal applications such as Gmail or LinkedIn. (Marston, Bandyopadhyay, Zhang & Ghalsasi 2011. p.178)

1.2.

Stealth adoption (stealth SaaS-ing)

Zainudding (2012) discusses in his article the concept of stealth SaaS-ing or also called “stealth adoption”. He describes stealth SaaS-ing as follows:

“(1) the act of adopting a particular innovation that is taken by organisational unit managers, who are the primary actors; (2) the groups in which the act is hidden from include top management and other organisational units that are typically held responsible for managing the innovation function (e.g., the organisation’s internal IT unit is responsible for managing the technology innovation, quality control unit is responsible for managing the quality management innovation); and (3) the act involves the decision to adopt a particular innovation.”(Zainudding, 2012)

Concluding, stealth adoption of SaaS (further referred to as stealth SaaS-ing) is the act of adopting a SaaS application by a business unit without involving the responsible ICT department and top management. Example: a project team within the organisation is working on a project for a year. The project members want to use SharePoint within their project. Since the organisation does not have SharePoint in its portfolio, the project manager has bought several licenses to the SaaS version of SharePoint, one for each project member. The licenses are paid out of the project budget. And since the application does not affect any other part of the organisation and is only used for a short period the project leader has neglected to inform either the top management and the responsible ICT department with the adoption of the SaaS application.

Next to the work of Zainudding not much research has been conducted in the field of stealth SaaS-ing. Even though it is believed that stealth SaaS-ing has multiple positive and negative impacts for the organisation (both for the business and ICT). However, no research has been conducted regarding these impacts. And it is here that we find a gap in the literature.

1.3.

Why stealth SaaS-ing?

Why is the focus of this research aimed at SaaS? As said in the introduction: there is an increase in SaaS adoptions amongst the organisations. Partly because the SaaS vendors are professionalizing. The SaaS market now also contains some software giants, like SAP or Oracle (Goth, 2008). This increase in SaaS adoptions leads to an increasing need to understand the impact of SaaS itself.

Also as discussed by Kappelman, McLeon, Luftman, & Johnson (2013) in the MIS Quarterly executive the alignment between ICT and business is, after years, still a big issue in most organisations. And even though the alignment is in the top 3 of priorities for years, companies are still not satisfied with the alignment of their ICT with their business. And now with the introduction of SaaS (Software as a Service) Winkler & Gunther (2012) argue: “a third party comes into play providing large parts of IT delivery, so that business departments may be more inclined to take over large parts of decision authority and application-related activities” (Winkler & Gunther, 2012).

It is believed that, with the rise of SaaS, the alignment of business and IT will become even more complex. And that SaaS could have as a consequence that the GAP between the ICT unit and the business unit could increase, resulting in less coordination between the two.

In other words: more research is needed in the field of SaaS so that organisations can better governance the implications. And although there are several researchers studying SaaS, there is still a lot to learn. As mentioned in the previous paragraph, there is a gap in the literature regarding stealth SaaS-ing. Besides the research of Zainudding not much can be found about stealth SaaS-ing. Most SaaS related literature assume a top down approach which is conducted with the approval and knowledge of the top management and responsible ICT unit (Zainudding, 2012). However, this is not always the case as this research will show. The amount of stealth adoptions within an organisation is hard to determine because of its nature, but during this study multiple cases came to light within all researched organisations.

This means that organisations not only are in need for information about SaaS governance, but also for stealth SaaS governance. Because in practice, organisations are confronted with the question whether they should allow or forbid stealth SaaS-ing within their organisation.

Therefore, it is valuable to gain more knowledge about the threats and opportunities of stealth SaaS-ing for organisations. So organisations can govern stealth SaaS-ing and determine if they should allow or forbid it.

2.

Research question

Stealth SaaS-ing itself is still a broad concept. And as said before more research could be done to improve the knowledge of this field. The lack of knowledge, about the impacts of SaaS-ing within the literature, is important for the field of practice to successfully govern SaaS and stealth SaaS-ing.

Of all organisation types the public organisations may be the most affected by the lack of SaaS governance. In contrast to private organisations, public organisations have generally more strict rules regarding information handling. The government demands certain rules in regard to data storage, archiving, handling of private data and allocating of software in general (Appendix 9.5.2..2 : Appendix 9.5.2.9). This is probably due to the fact that public organisations have sensitive information about most of the public itself. When talking to a ICT employees from a Provincie in the Netherlands, it became clear that the public service is also struggling with the lack of knowledge about stealth SaaS-ing.

Because of these reasons the public service is the starting point for building a better understanding about the impacts of SaaS-ing. And organisations who generally have less strict rules regarding information and/or less sensitive information, like some private organisations, could also benefit from the results.

The above information leads to the following research question for this research thesis: How does stealth SaaS-ing impact the public sector?

This is more specified by the following sub-questions:

o What are different kinds of characteristics and or types of stealth SaaS-ing? o What are the negative impacts of the different kinds of stealth SaaS-ing? o What are the positive impacts of the different kinds of stealth SaaS-ing?

First off, is it my believe that it is important to know if: a) there are multiple SaaS types, b) if there are differences in the stealth SaaS-ing processes, and c) what the characteristics are of those differences. Because, small SaaS applications with no confidential data will have a different impact than big applications with lots of confidential data. Also it is a good place to start, since there is not a lot known about the stealth SaaS-ing process itself. This is researched in the first sub-question. The outcome is a list of different SaaS types and a table of SaaS-ing characteristics that separate stealth processes. For the second and third sub-questions the different stealth SaaS-ing types are researched to look for both the positive and negative impacts of stealth SaaS-ing. The outcome of the second and third sub-question is a matrix of the selected cases and the impact it had to the public organisations, and a list of the risks, advantages and disadvantages of stealth SaaS-ing.

In the next chapter the research methods used during the thesis research will be discussed.

3.

Research methods

Maxwell (2005) states that quantitative research can answer the research questions ‘how much’ and ‘what’, and qualitative research can answer the ‘how’ and ‘why’ questions. Quantitative research explores the correlation and qualitative research explores the understanding of why things occur. Because of the nature of this research’s question – a “how” question to increase the understanding – a qualitative research approach like Maxwell suggested is used.

The thesis research is an exploratory research on the impact of stealth SaaS-ing for the organisations. According to Verschuren & Doorewaard (2010), there are two types of theory-oriented research. The first is theory testing, and the second is theory development. Since there is no literature about the impacts of stealth SaaS-ing to the public organisation, this research can be seen as a theory development research. As Verschuren & Doorewaard stated, the goal of theory development is to address a gap in existing theory. And this research is about addressing the gap in literature about stealth SaaS-ing.

Yin (2013) argues that there are three conditions for selection a research method. 1. The type of research question, 2. The control of the researcher on the environment, 3. The focus on contemporary as opposed to entirely historical events. (Yin, 2013). “The case study method answers how and why questions, it requires no control of behavioral events and it focuses on contemporary events” (Yin, 2013). This is exactly what is needed for this research. Because in this research a ‘how question’ is asked, and stealth SaaS-ing is becoming/if not is a contemporary event.

Also there is not much literature to be found and a method as case study can provided a broad span of information. For these reasons, the case study method is chosen.

Maxwell also addresses the importance of a suitable theoretical basis needed for a qualitative research (Maxwell, 2005). This is why, next to the case studies, a literature analysis is conducted. This literature analysis is used to explore already existing theories that can be used to explain and answer parts of the sub-questions.

According to Maxwell (2008), qualitative research requires a less restrictive research design. Maxwell (2005) says the following about the research design within qualitative research.“…an ongoing process that involves….tackling back and forth between the different components of the design, assessing the implications of goals, theories, research questions, methods and validity threats for one another” (Maxwell 2005, 3). Therefore this research design will never be final, during the research the research methods and/or the research questions where adjusted if needed.

In summary, the research is an qualitative research, with as goal to develop a better understanding of the implications of stealth SaaS-ing within the public sector. The research consist out of two parts: a literature analysis and case studies. The two parts will be further discussed in the next paragraphs.

3.1.

Research model

Before going deeper into the research methods, the research model used for this research is shown. Figure 2 is an illustration of the research path in model form.

The research is done in two phases: The first phase is to find a starting point for the case study research. This, to create a theoretical basis of the qualitative research, as suggested by Maxwell (2005). This is done with an analysis of the existing literature about stealth SaaS-ing, SaaS and Cloud applications in general. However it was expected that the literature was insufficient, therefore some preliminary interviews with the case study organisations are conducted to fill this gap in literature. The goal of the theoretical basis is to find a handhold that can help account for the differences in the types of stealth SaaS-ing, which can be found in practise. This handhold of characteristics are the basis for the case studies to find the impacts of these different types of stealth SaaS-ing.

In the second phase the case studies are conducted. Afterwards more literature was analysed. The analysis is more focussed on explaining and verifying the found conclusions of this research within the literature. The outcome of both methods result, in the end, in a better understanding about the impact of SaaS-ing to the public organisation.

To summarize, the research existed out of two phases, each with its own literature review. In the first phase interviews with the case organisations where conducted, and in the second phase the cases themselves where

researched. The first phase resulted in answering the first sub-questions. The second phase resulted in answers about the second and third sub-questions, and therefore also the research question itself.

Now let us dive deeper into the research methods: literature review and case studies.

Preliminary Interviews Preliminary Literature analysis Exploratory Case study Exploratory Literature analysis Starting point case study Understanding of the implications of stealth SaaS-ing Phase 2 Phase 1

Figure 2: Research model

3.2.

Literature analysis

Current literature is analysed to find some first answers to the three sub-questions: what are the characteristics/types of stealth SaaS-ing? What is the negative impact? And what is the positive impact?

The literature analysis is first used to explore the current literature about the SaaS types, stealth SaaS-ing and its characteristics. In the second phase (see figure 2) it is used to verify finding about the impact of stealth SaaS-ing that where found during the case study, it also helps give a new perspective on the findings. The literature analysis in the first phase is conducted before and alongside some interviews, and in the second phase after the analysis of the case study.

With the information, a categorization of the different kinds of effects of the types/characteristics of stealth SaaS-ing is made. This categorization help determine what kind of characteristics of stealth SaaS-SaaS-ing leads to opportunities for the organisation and which types leads to threats.

3.3.

Case studies

“Case studies can be seen as research strategies in which the researchers try to gain a profound and full insight into one or several objects or processes that are confined in time and space” (Verschuren & Doorewaard, 2012, p. 178). According to Flybjerg (2006), a case study is perfect for researching phenomena’s in their natural context. Flybjerg also stated, that a case study can be used for both theory testing and theory development. Since the goal of the research is to develop a new theory, a case study is a logical fit.

Within the case studies the following sub-questions are explored: What are the negative impacts of the different kinds of stealth SaaS-ing? and what are the positive impacts of the different kinds of stealth SaaS-ing?

The case studies is handled as followed: Within a case organisation there was a search for stealth adoptions of SaaS applications by which the responsible ICT unit was not involved or informed, but who found out later about the application. This way a research is done on the business side of the stealth adoptions, but also on the ICT side of the adoption. Provincie X is the biggest source of cases, because there ICT department has tracked and processed a lot a stealth adoptions of SaaS. Within two other organisations at least one real case is handled.

3.3.1. Case selection

According to Flyvbjerg (2006), there are two types of case selection: random sampling and information oriented selection. Since not all organisations are dealing with stealth SaaS-ing, the information oriented selection is chosen. This insured that the conducted case studies where beneficial for the research results. Because organisations that are occupied with dealing with stealth SaaS-ing or SaaS in general will have more knowledge about the subject, and will have more documentations that can be examined.

The case study was conducted amongst the following public organisations, see table 1. Table 1. Organizations of the case studies

Name* Provincie X Provincie Y Municipality Z Municipality A Size Overall = 1.000 FTE, 1.500 employees, ICT = 27 FTE, IM = 4 employees. Overall =1.500 FTE, ICT = 100 employees. Overall = 15.000 FTE, ICT = 250 FTE, IV = 500 FTE. Overall = 1.300 employees, ICT = 34 FTE. ICT characteristics No technical ICT department, only “regievoering”. With separate informative managers in the business Technical ICT department also concerned with information

Technical ICT is split up from information management (IM). IM is fragmented in the business. Technical ICT department also concerned with information ICT organisation archetype **

Centralized model Centralized model

Semi-Centralized model. Technical ICT is centralized, but IV is decentralized.

Centralized model

* The names of the organisations are for anonymity purposes withheld.

** ICT organisation archetypes are taken from Winkler & Brown (2014), figure 1.

Provincie X is chosen as case study organisations, because they are actively busy with the SaaS and stealth SaaS-ing. Meaning that they can provide a good source for information. Provincie Y is chosen to compare the findings with the findings of provincie X. This, to see which phenomena’s are similar and which are contradicting. Municipality

Z is chosen as a public organisation to see if the finding within the provincies also applies for other public organisation types. However municipality Z is only interviewed in the first phase. Municipality Z is replaced by municipality A, because they did not actively track stealth SaaS-ing applications. Meaning that municipality A provided a better source for information during phase 2.

3.3.2. Data collection

During the first phase interviews where held with four people out of three organisations:  Provincie X o ICT advisor o Business manager  Provincie Y o ICT architect  Municipality Z

o Manager technical application management (IT manager)

The goal was to get opinions about SaaS and stealth SaaS-ing from all perspectives within the organisations, to get insight in the organisations rules regarding SaaS and apart of the interviews also consist out of extracting real cases that have happened and that could be researched.

During the case study itself, interviews where held with different employees of the organisations. As said before, in the actual case study the municipality Z is replaced by municipality A. During the case study itself, two people are interviewed. From the business one employee is interviewed who was involved in the procurement of the SaaS application. This interview is about the motives of procuring a SaaS, the motives of not involving ICT and the advantages of that latter. The second person is one from the ICT department, someone who was involved with the registration of the SaaS application after it was discovered. This interview is about the changes they made in the application, contract or organisation and the disadvantages it had by not involving the responsible ICT unit. This means that for the case study, stealth SaaS application are researched that where discovered by the ICT unit. If the ICT unit did not yet discover the application, than the ICT side interview is with the person that already handled similar applications. Next to the interviews, also a document analysis is conducted amongst the provided data. The analysis is primarily focussed on retrieving information about the impact of stealth SaaS-ing, and to get more insights in the process of the procurement of the SaaS. The information out of the document analysis is mostly used as input for the case interviews.

In appendix 9.1 the three interview scripts are placed, one for the preliminary interviews, one for the ICT case studies and one for the business case studies.

4.

SaaS types and characteristics of stealth SaaS-ing

First, is it important to answer the first sub-question: What are different kinds of characteristics and or types of stealth SaaS-ing? The preferred outcome of this sub-question is a model or explanation of the different types of SaaS applications that are defined, along with a model of the different processes of the stealth SaaS-ing process. The outcome is important, because based on these models the opportunities and threat are categorized, making the result more detailed. Therefore the theory behind this sub-question is the basis of the other research questions.

The sub-question is further divided into two main categories: 1. The different kinds of SaaS application types, and 2. The different types and characteristics of the stealth SaaS-ing process.

4.1.

Types of cloud services

Since SaaS finds its origin in the cloud computing, mentioned in chapter 1, cloud computing is used as a starting point. Within the literature of cloud computing a separation is made between four layers (“Cloud Computer”, 2010). Each layer signifies a different service. IaaS (layer 4+3) is the offering of a infrastructure on which customers can run their own platform and in turn their own applications. PaaS (layer 2) is the offering of a platform on which customers can install their own services. And lastly SaaS (layer 1) is the offering of a specific applications to customers. This separation is illustrated in figure 1.

However this is still a very broad categorization of SaaS, and SaaS is here still depicted as one entity. Therefore the next perspective will be focussed on the first layer - SaaS itself.

4.2.

Types of SaaS

4.2.1. SaaS procurement and governance perspective

The perspective from cloud computing did not gave the expected results, therefore SaaS literature itself was reviewed. Hess and Buxmann (2009) researched the motivations behind the procurement of SaaS applications. This seemed a good place to start, since the motivations behind the procurement of SaaS applications differs from application to application. Hess and Buxmann made a research model based on the transaction cast theory, resource-based view and the theory of planned behaviour.

Their research concluded that the most important drivers for SaaS procurements are the social influences, the pre-existing attitude towards SaaS adoptions, adoption uncertainty and strategic value. Their research also concluded that company size does not matter in SaaS-adoption.

This last part is however not completely in accordance with a research of Benlian (2009). In this research he researched the understanding of the factors contributing to the adoption of SaaS as on-demand sourcing option. They found that application specifity is the most important factor in the adoption of SaaS-based applications in large enterprises. And environmental uncertainty is the most important factor in small- to mid-sized business. Overall firm size had no significant impact, but when analysing the sub samples they observed that the a lower numbers of employees have a higher SaaS-adoption rate.

However neither publications makes a distinctions within the term SaaS. Both articles talk about SaaS in general, and only Hess and Buxmann make a small remark towards the application types being used. “A broad

spectrum of application types have been offered as SaaS-applications so far, ranging from Office and Collaboration (e. g. Google Apps) to CRM (e. g. Salesforce.com) and ERP (e. g. SAP’s Business ByDesign (Zencke and Eichin 2008)), with mixed results”)” (Hess and Buxmann, 2009). However this is still not the preferred distinction between SaaS types.

Winkler and Brown wrote multiple papers about the different factors relevant to the governance of SaaS applications. In Winkler and Brown (2014) they developed a theoretically grounded research model, on which they explained application level governance and to plot their research findings on.

They conclude their research with the following statement “we found strong evidence that origin of initiative, scope of use, and business knowledge in IT units are significantly associated with application-level governance” (Winkler & Brown, 2014).

What the above researches did not investigate is the difference in the types of SaaS applications. Only the general term “SaaS” is used within the researches. Benlian & Buxmann (2009) only talk about the different application-types that they researched, for instance CRM or ERP. However to get conclusive research findings it is in my eyes important to have this distinctions between the different types of SaaS-applications. Because threats by large SaaS applications can have more effect on the organisation than the threats of small applications.

4.2.2. ASP Perspective

When focusing more on the marketing side of SaaS, an article came up written by Mager, Belomy & Rennhak (2014). That publication is focused on creating a new comprehensive model for SaaS marketing strategy decision-making. At first sight the subject has little to do with this research, but they did make a categorization of SaaS applications based on a ASPs categorisation model, see figure 3. They identified three types of SaaS: low touch, moderate touch and high touch. “The degree of touch represents the complexity, integration investment, and required service of the software” (Mager, Belomy & Rennhak , 2014).

Low touch SaaS application support basic core services, and have a low customization, low business

complexity. Moderate-touch SaaS application support core services and provides support, security, data redundancy and service level agreements, the applications also has a higher customization and complexity. High-touch SaaS application support even further extended services such as application configuration, strategy, or training and have high

customization and high business complexity (Mager, Belomy & Rennhak , 2014).

Figure 3: Categorization of ASP Offerings (Gillian & McCarthy 1999)

Going deeper in the ASP model, Gillian & McCarhy (1999) and Gillan, Graham, Levitt, McArthur, Murray, Turner, Vilars, McCarty (1999) wrote papers explaining the categorization of ASP offerings model. But first lets go deeper in ASP (application service providers):

“ASPs provide a contractual service offering to deploy, host, manage, and rent access to an application from a centrally managed facility. ASPs are responsible for either directly or indirectly providing all the specific activities and expertise aimed at managing a software application or set of applications. “ (Gillan, Graham, et al., 1999)

Examining the definition of Gillan, Graham, et al. one can see that there is a lot of communalities with SaaS. Both ASP and SaaS are offered as a contractual service, both are hosted from a centrally managed facility and with both the provider is responsible for the software. There are however also some differences: they have different data

structures, marketing structures, customer groups. SaaS customers uses the web to connect to the software. Whereas by ASP customers have their own servers and the ASP applications are hosted by a kind of service provider. (Liao, H., & Tao, C., 2008).

The model in figure 3 is a marketing model made for ASP offerings to separate the many ASP applications. The y-axis are the applications that are offered, and the x-axis are the services that are provided to the management and deployment of these application (Gillan, Graham, et al., 1999).

Now going back to the touch categorization made by Mager, Belomy & Rennhak (2014). Sesser (2013), also uses the touch categorization in his article. Sesser uses it to build three different SaaS company archetypes from the perspective of sales. These archetypes are comprised of the SaaS price, customer acquisition cost, and churn. The content of the article itself is not so interesting for this research, however the archetypes that he made provides a new layer in the characteristics of the SaaS types, see table 2.

Also when comparing the touch theory with the literature from the other perspectives some similarities arise. For instance both the model of Winkler and Brown and the model about the motivations talk about the scalability of application – called specifity, this can also be seen as a changing characteristics of the touch theory. High-touch has a higher customization characteristic than low-touch does.

In conclusion, this is exactly the kind of separation that is needed for the rest of the research. Because with these touch types: low, moderate and high, (or following the ASP labels: personal, collaborative and enterprise) the SaaS

applications within the SaaS-ing process can be categorized. Allowing to list the opportunities and threats per type of SaaS.

So for this research the different types of SaaS application will be based on the touch theory of Mager, Belomy & Rennhak (2014) combined with the work of Gillan, Graham et al., (1999). Meaning that there are three types of SaaS applications: Low touch (Personal SaaS), moderate touch (collaborative SaaS) and high touch (Enterprise SaaS). Each of these types have their own characteristics see table 2.

Table 2. Characteristics of the three SaaS types. Low touch / Personal SaaS

Moderate touch / Collaborative SaaS

High touch / Enterprise SaaS

Type of software B2C or B2B B2B B2B

Customization Low High High

Complexity Low Medium High

Support Basic core services + support, security and data redundancy

+ application

configuration, strategy and training

SLA’s No Yes Yes

Price range <5K 5K-25K >25K

Examples WeTransfer Product A Enterprise Risk

Management

This table is derived from the work of Mager, Belomy & Rennhak (2014), Gillan, Graham, et al., (1999) and Sesser B. (2013).

When the information is adopted in the ASP offering model, the model for SaaS will look like figure 4.

Figure 4: Categorization of SaaS types (Adopted from Gillian & McCarthy 1999) 4.3.

Validation of the SaaS types

The next thing to do was to check the validity of this model. Therefore, during the preliminary interviews, taken to understand the stealth process, this model is also shown and discussed. These interviews where held with an information advisor and a business manager form the Provincie X, an IT architect from the Provincie Y and a IT manager from the municipality Z.

The outcome was that figure 4 is a recognizable model. They could even categorize some of their own SaaS applications within the model. Most interviewees recognized only personal and collaborative SaaS-applications from their company. However one interviewee said also to have an Enterprise SaaS-application in house, and that was even one in stealth form.

The next step is to work out the different characteristics of stealth adoption of SaaS applications. 4.4.

Characteristics of stealth SaaS-ing

Now that there is a base categorization of the different types and characteristics of SaaS, the next step is to find the types and characteristics of the process of stealth SaaS-ing itself.

Other than the article of Zainudding (2012) not much is said in the literature about stealth SaaS-ing and especially not about different types of stealth SaaS-ing. Therefore this part is answered by means of interviews within the public organisations.

To find some answers, interviews where held with an information advisor and a business manager form the Provincie X, an IT architect from the Provincie Y and a IT manager from the municipality Z. The reason these people were interviewed was to get information from multiple perspectives. Both the information advisor and the IT architect are actively working on the question what to do with SaaS applications, and both have experience with dealing with stealth SaaS-ing. This will help with finding similarities within the provincies. The business manager is also familiar with SaaS projects within his organisation and provides a business perspective about stealth SaaS-ing. The IT manager within the municipality Z is a manager of the technical side of ICT, also the organisation within the municipality Z is of a different set-up than that of the two Provincies. This will provide a completely different viewpoint towards stealth SaaS-ing within the public sector.

These interviews resulted in different stealth SaaS-ing processes, each with different characteristics. These different kinds of characteristics are extracted out of those processes which resulted in table 3.

In the next couple of paragraphs the different kinds of characterises, which were found during the four interviews, will be further explored.

The interview scripts for the preliminary interviews can be found in appendix 9.1.1. The preliminary interview coding can be found in appendix 9.3.

Table 3. Characteristics of the stealth SaaS-ing.

Characteristic Possible values of characteristic

Initializer Government Chain partner (IT) suppliers

Employees External

employees End users Managers Kind of software Branch specialisation software Software for business processes Software that is helpful

Type of SaaS Personal Collaborative Enterprise

Procurement intention Solely a SaaS application A service with a SaaS application A project with a SaaS application

Motivation Ignorance Deliberate

Budget used ICT budget Central

budget Project budget Purpose of

the

application

Temporary

(project base) Long term

Type of data* Important confidential data Important data Non important data No data

* With data is meant the data that the organisation puts in the system. If the supplier provides the data, than that is not counted.

As is shown in table 3, multiple characteristics determine how the stealth process of a SaaS application looks like. Some of the characteristics will affect the advantages and disadvantages of stealth SaaS-ing. The possible impact that these characteristics have are later discussed in table 4. The cases that are selected contain most of these characteristics, this to get as much results as possible. But first a closer look is taken into these characteristics.

4.4.1. Initializer

Stealth SaaS-ing project are initialized by different kinds of actors. Zainuddin (2012) talks mostly about midlevel managers that are responsible for stealth SaaS-ing. “In stealth adoption, organisational unit managers decide whether to adopt a particular innovation. These organisational unit managers are operational, mid-level managers.”(Zainuddin, 2012) In practice, however, there are far more actors that are responsible for stealth SaaS-ing within a public organisation. Although within the employees it is often the unit managers that signs the papers.

During the interviews the government was appointed as one of the initializers of stealth SaaS-ing. The reason being that the government releases software that the provincies and municipality need to use. Nowadays some of these mandatory software is released in as SaaS form. Meaning that the provincies receives access to these SaaS applications. When the information goes directly to the business and the business neglects to inform the ICT department or does not recognizes it as software, we can speak of stealth SaaS-ing. Since it is the government that first introduces the SaaS application and made it mandatory, they will be seen as a initializer.

Chain suppliers can also be seen as initializer, mostly for collaborative applications. When an organisation works together with a chain supplier there is a chance that both organisation will either share a collaborative application or set up a collaborative application. Because of the accessibility and quick setup time SaaS will become more and more common for these kinds of purposes, examples are: Project Place or SharePoint. In some cases these kind of SaaS applications will be paid out of the project budget and the ICT department will not be informed. This can have several reasons, but often because the users did not see it as software that needs to be registered by the ICT department.

When delivering a service or a system, (IT) suppliers sometimes also give a maintenance tool or evaluation tool along with the main service or system. Since the SaaS-application is a by-product and not the main product it is, in some cases, not recognized as a ICT application by the business. Also when it is a continuation of a previous service, and the previous service did not have an ICT component and therefore no relationship with the ICT, the continuation can lead to confusion whether or not ICT needs to be involved.

Then there are the employees of the company. First, there are the external employees. These employees are hired for a certain period or project. When coming in the company they bring their experience of different SaaS applications along with them. Also their relationship with the company rules are often more temporary, which could result in a less obedient employee. If they have a budget available, than there is a chance that they will buy a SaaS application with which they have experience. Due to there more temporary attitude towards the rules they may try to bring in the application through a stealth way or because they are not familiar with the rules.

If given a budget or if it involves free SaaS-applications, internal end users can also be the initializers. The SaaS-application will most likely be personal SaaS applications, like Dropbox, WeTransfer or Google Calendar. Since these are often small applications most employees will not recognize it as something that needs to be mentioned or initialized by the ICT department or the purposely avoid the ICT to give them more flexibility in application choices.

Last, the biggest bulk of the stealth SaaS-ing application will come from, as Zainuddin (2012) mentioned , unit managers or mid-level managers. In the case of the Provincie X these are often project managers, that receive a separate project budget. Sometimes they use this project budget to buy licenses to collaborative SaaS-applications or they give the contractor the order to arranges those licenses. Because of the temporary nature of a project, often the SaaS application does not follow the “legal” steps when coming into the company.

4.4.2. Kind of software

During the interviews three kinds of software where distinguished: Branch specialisation software, software for business processes and software that is helpful. Branch specialisation software is software used only for a curtain project, project type or department. This is software that when it is down does not affect the whole company. Also this kind of software does not necessarily support a business process but could support a project for example.

Software for business processes is the software that is necessary for the business process to be executed. Think of a finance software to handle the payments of the employees. The impact of unavailability of these kinds of software could be problematic. Therefore this kind of software is important to determine the impact of unavailability of the SaaS.

The last kind of software is software that is helpful. These are the SaaS that make a user more efficient, but when it is not available it would not really matter. However, the data used in such a SaaS does matter. It is contains confidential data, than there should be some kind of warrant to save the data from leaking, misuse or loss of data. 4.4.3. Type of SaaS

This is explained comprehensively in chapter 4.2, so a short recap is listed here.

In literature there are three types of SaaS applications: Personal SaaS (also known as low touch), collaborative SaaS (also known as moderate touch and enterprise SaaS (also known as high touch). Each type of SaaS is more complex and support bigger functionalities than the previous one. The support delivered with the SaaS is also more comprehensive than the previous one. In general personal SaaS is simplistic and enterprise SaaS is complex. (Mager, Belomy & Rennhak, 2014; Gillan, Graham, et al., 1999; Sesser B., 2013). Personal SaaS, like WeTransfer, is also more common in use, which could mean that the users do not really realize what the risks are with such an application. Enterprise SaaS are usually purchased by the ICT department because of its size. But could be very harmful if there are stealth adopted, because they often support major business processes. Collaborative SaaS are often used for communication data between multiple parties, making it an ideal source for impacts related to confidential data.

4.4.4. Procurement intention

What was interesting to see during the interviews was that not all SaaS-applications were intended to be bought. In some cases the aim was for a service to be bought. For instance a card service in which their employees could travel with public transport. When this service was delivered, the supplier also gave the employees access to a portal in which they could register if the journey was for business or personal reasons. Since the main focus was the card service and not the portal, the portal did not gain much attention from the business and was therefore not mentioned to the ICT department. So the intention is also an import characteristics of stealth SaaS-ing, this is latter also explained. In other cases a contractor was asked to provide a collaborative tool in which the project members within the organisation could share documents with the contractor and his employees. In this case the demand for such a tool was written within the procurement process for the overall project. So also here the main focus is not the collaborative application, but the completion of the main goal of the project (building a piece of road or a bridge). Since they perceived the contractor as owner of the SaaS-application they did not think that their ICT needed to be involved also.

On the other end, there are also procurement process that are just for a piece of software. And here the main intention is the application. The reasons why in some cases this is a stealth adoptions depends on multiple aspects, which will be further discussed in chapter 5.2 – Results.

4.4.5. Motivation

As in the previous paragraphs also addressed, the motivations for not informing the ICT department differ from one and other. The pure motives of an initializer is always difficult to obtain., because not everybody will answer truthfully when asked. But within the interviews a distinction was found.

First of you have the people whose motives are deliberate. They know it involves a ICT system but they still do not inform the ICT department. This could either be for saving time, more flexibility in application choice or avoiding a complex process. During the case specific interviews the reasons behind these decisions were researched further, see chapter 5.2 - Results.

You also have the people that did inform the ICT department because of ignorance. This is mostly because of the characteristics of SaaS applications. Since SaaS-applications are accessed through a browser, users do not think that it is software. They see software more as programs that needs to be install on their computer. And since there is no installation process the users do not inform the ICT department. In some cases they are also not aware of the need for SLA’s and other contractual agreements with a supplier. Meaning that this is left empty in some cases.

More on this subject will be later handled in chapter 5.2 – Results.

The found motivation differ at some points from the research of Hess and Buxmann. This is likely because they researched the motivation behind the procurement itself. Although they did conclude that important drivers are the social influences and the pre-existing attitude towards SaaS adoptions. This can be also found back in the case

interviews later. Allot of the business interviewees have the attitude that SaaS is not really an application, and therefore ICT should not be involved. Later the same people say that in the future they will ask ICT for help. Meaning that the pre-existing attitude is also here behind the motivation for stealth SaaS-ing or not. And the deliberate adoptions could

be partly because of the social influences. If they want to avoid the ICT because of history that they have had or are less strictly with rules, then this is partly due to the social influences of the ICT department on them.

4.4.6. Budget

The budget used for the SaaS licenses can also be an important characteristic, depending on the rules within the company. During the interviews three separate sourcing came to light. First of, and this is probably the biggest for stealth SaaS-ing, is the project budget. Since the provincies deals with huge projects for building roads, bridges etcetera, they give those projects their own budget. And if an ICT tool is needed for that project, this is often paid from the project budget. Since SaaS is often quickly usable, the project manager or contract manager often only need to pay for a few licenses and they can get to work. Another way to do it, is by making the project contractor responsible for delivering the ICT tools, and the contractor is in its turn paid from the project budget.

Another way is by using the central budget of the organisation. It is here that some stealth application are found because one of the employees recognizes it. This all depends on the organisational rules about the finances of course. In case of Provincie X, they have a separate budget for ICT. All ICT cost and purchases need to be paid from the ICT budget. So it could raise some questions if an ICT purchase is paid from another budget.

One important note concerning budgets is the fact that governmental organisation have rules concerning procurement, see figure below.

Figure 5: Procurement rules for decentralized government, like provincies and municipalities (Sloots, A., Keulen, H., Koning-van Rutte M., Stuijts, M. & Hebly, J., 2013)

The problem here is, that if the same application is bought within multiple projects, those cost of the SaaS-applications needed to be added up. Meaning that, if there is no overview of the licenses, the organisation could break the rules without the cost of the project license(s) being over the procurement rules because the sum of all licenses in the organisation are over the procurement rules.

4.4.7. Purpose of the application

In the preliminary research there where two clear distinction in the purpose of the application: One group was for projects and had a temporary use, the other group was for a longer period of time, for instance to support a business process. This makes a difference in the impact that it has. With a temporary SaaS more details need to be given to an exit strategy. This to ensure that the data does not get lost, and the archiving laws are met. With a long term SaaS this will be later on a problem, however redundancy might be an issue. Also motive to stealth adopt may differ. For a temporary SaaS it will be more likely that it is done to save time or be more flexible in choice. And the motivation for a long term SaaS might be due to ignorance. A long term SaaS that is stealth adopted will probably, in the long run, have more problems with compatibility with the browser and the settings or with the policy of the company.

4.4.8. Data

The data stored in a SaaS-application also makes a difference in the SaaS-ing process. This is due to multiple rules and regulations. For one there is rule of archiving, meaning that the import documents also need to be stored locally. Then there is the law about private and sensitive data, for a public organisation this is an important law. This latter was also a problem for the Provincie Y, where they received image damage because one of their website was fraud sensitive.

When there is no data or non-sensitive data within a SaaS-application there is less urgency for heavy security, also other requirements can be applied. For instance, when there is no private data, the database of the SaaS-application may be outside of the EU.

“The architecture of cloud poses such a threat to the security of the existing technologies when deployed in a cloud environment. Cloud service users need to be vigilant in understanding the risks of data breaches in this new environment.” (Subashini, & Kavitha, 2011). Security has always surrounded ICT, but with the SaaS people need to be even more vigilant. However, SaaS also reduces the threshold for procuring applications. So as Subashini and Kavitha (2011) write in their paper, users need to understand the risks of leaking data in this new environment.

4.4.9. Relationship between characteristics and impact

Table 4 makes a link between the characteristics and possible effects on the impact. These possible effects are in some cases also explained in the paragraphs above.

Table 4. Link between characteristics and impact.

Characteristic Link between characteristics and impact

Initializer

Every kind of initializer has a different reason for implementing the SaaS, also the skills and knowledge about the organization differ. This could have a relationship with the SLA´s that are agreed upon with the supplier.

Kind of software

The kind of software has an important relationship with the size of the impact. An helpful tool will probably have a less lower impact than a SaaS for a major business process.

Type of SaaS

The type of SaaS could affect the impact in the way that it is complex or not. A less complex application has less problems with implementing and supporting than a more complex application. Personal SaaS will have less impact than an Enterprise SaaS for example.

Procurement intention

The procurement intention is most likely important for the impact. Because if it is solely a SaaS application, than the initializers will give it some thought. When it is a side product, than the chance is there, that the SaaS does not receive the attention it needs. Making the procurement intention important for the impact, because of the added risks of not spending attention on the SaaS.

Motivation

The motivation could be seen in two ways. First the ignorance adopters will most like not look as much at the security, continuity, archiving etc. Because they are not really treating the SaaS as a software. The deliberate adopters do it for a reason deliberate. Perhaps they know that the SaaS does not fit with the policies but implement it anyway. Both

motivations could have their own impact.

Budget used

How the budget affects the impact is not known at this time. But it could help with finding the stealth adoptions. If the ICT or central budget is used, than the chance increases that someone will notice the purchase. If a project budget is used, than this chance will be less likely.

Purpose of the application

The purpose of the application affects the attention that the SaaS needs. A temporary SaaS needs to have a solid exit strategy for when the SaaS is no longer needed. Also the data owners needs to be very clear. This is the same with long term applications, but with long term application it maybe more important how it fits with the policies and the ICT landscape. So if the attention details are not taken into account with the stealth adoption, than this could have mixed impacts depending on purpose of the SaaS.

Type of data

It is relatively clear that confidential data could have a large impact on an organisation when it is leaked. This is however not the case for a SaaS that does not use organisational data. Therefore the data that is used in the SaaS could change the impact of the stealth adoption.

It is however not as black and white as the table suggest. A stealth adoption has a combination of these characteristics, and it is the combination that determine the impact at the end. The table gives some insights into the possible impacts of the characteristics.

5.

Positive and negative impacts of stealth SaaS-ing

Selection & setup case study

One of the biggest challenges within this study is the fact that it concerns stealth adaptations. Meaning that the applications are most of the time not registered or that the ICT department is not informed. Therefore there is no clear overview of the applications that are adopted by the business. This means that, within this study, the focus lays on applications that are initially adopted by the business, but eventually where found by the ICT department. This challenge limits the possible cases to study, but should give enough information for the research. The other challenge is to find the correct persons who were involved in the first phases of the procurement process. Sometimes the ICT department finds out that an application is in use, but do not know who was responsible for the procurement of the application.

Most researched SaaS applications come from the provincie X. This is because: a) Provincie Y had just started with managing (stealth) SaaS-ing, meaning that they had not build a large history yet. And b) The ICT department within the municipality Z does not pay much attention to stealth SaaS-ing. They were the last stop within the procurement process, and when someone did ask for their help they assumed that the application runs correctly. Meaning that stealth applications are not registered. Instead of the municipality Z, a case of the municipality A was studied.

For this study multiple real cases are researched within a limited pool of SaaS applications. The selection of applications is made based on the fact that every application consist of different characteristics of the stealth process (described in chapter 4.3). The goal for the selection was to have as much widespread of research characteristics as possible, to have all the different kinds of characteristics represented in the research.

The following applications are researched: Table 5. Case information.

SaaS application Initializer Kind of software Type of SaaS Procurement

intention Budget Purpose Data

Product C External employee Branch specialisation software Collaborati ve A project with a SaaS application Project budget/cen tral budget Temporary Important data Product B Project manager Branch specialisation software

Enterprise A service with a SaaS application

Project

budget Long term

Important confidenti al data Product A Supplier/man ager Software for business processes Collaborati ve A project with a SaaS application Project budget Temporary Important data Product D Government Branch specialisation software Collaborati ve Solely a SaaS application Central

budget Long term No data Product H End users Software that

is helpful Personal

Solely a SaaS

application No budget Temporary Depends Product E End users/supplier Software for business processes Collaborati ve Solely a SaaS application Central

budget Long term Not known Product F Project manager / budget owner Branch specialisation software Collaborati ve A project with a SaaS application Project budget Temporary Non important data Product G Project manager/ budget owner Software for business processes Collaborati ve A project with a SaaS application Project budget Temporary Important confidenti al data * In appendix 9.2 a detailed description of the SaaS itself and the stealth SaaS-ing process can be found.

** Motivation is left out of the table, because a) they all said they did not think ICT was needed, and b) it is a sensitive subject, so the answers may not be fully truthfully.

For every SaaS-application two employees were interviewed. One interview was with a business employee, who was at the initial phase of the adoption of the system. The other interview was with a ICT employee who was “first on scene”, meaning the ICT employee that was responsible for checking and processing the application when it was found.

The purpose of the interviews was to get more insight in the adoption process and reasons why it was a stealth process. The questions for the business are mostly related towards the motive of the SaaS-application, the advantages it had and if they would do it again. The questions for the ICT employees were mostly related towards the change process that they set in motion, the disadvantages of that case and if they support the business if the business would do it again like this.

At the end of the interviews it is possible to extract the pros and cons of the different kinds of stealth SaaS-ing processes from these cases.

In appendix 9.1.2 and appendix 9.1.3 the interview scripts are listed for both the ICT interviews and business interviews. These interview scripts also compare the interview with the sub-questions and characteristic of stealth SaaS-ing.

5.2.

Results

In this chapter the results of the case studies are shown and discussed. The results give answers to the sub-questions: “What are the negative impacts of the different kinds of stealth SaaS-ing?” and “What are the positive impacts of the different kinds of stealth SaaS-ing?” The outcome (coding) can be found in appendix 9.4.

This chapter is divided in several sub chapters. The first chapter will discuss the direct outcome of the case studies. The other sub chapters will discuss the (in)direct findings of the cases. In chapter 5.3 the findings and the quality of the findings are analysed.

5.2.1. Outcome of the case studies

In the table below, the outcome of the individual cases is listed. For each case the positive and negative impacts are described. These positive and negative impacts come from the interviews that have been conducted and the documents that where delivered with some of the interviews. In the next paragraphs the impacts are divided into multiple categories since not all results are direct impacts.

Table 6. Impacts by case.

SaaS application Positive impact Negative impact

Product C

- Flexibility in application choice. - Time-saving. Compared to the time

it would have taken to arrange the application in a normal situation. - Good way to test the application

- Almost broke the procurement laws.

- They have some trouble complying to the archiving rules.

- Problem with archiving.

- Officially it has been paid from the wrong budget.

Product B

- Time-saving.

- When ICT learned about the application, it was already too to stop or hinder the process.

- Higher risk for problems in the future, because there were no SLA’s. This higher risk could result in reputation damage for the organisation when it is public.

- The ICT department needed to work very ad hoc all of a sudden.

- Possible risk for not functioning correctly which was never tested.

- Higher risk for problems in the future regarding continuity and availability, because there were never made any agreements on this. - They did not really thought about the data

security both internal as external.

- When users face problems with the application, than the users will contact ICT

who cannot help them.

- The supplier will do less effort to improve the SLA’s, because the licenses are already paid. - Risk in the future with compatibility when the

browser or SaaS is updated.

Product A

- More flexibility in product choice. - Less work for the ICT, because the

contractor is responsible. Saving money.

Could not be found. However the ICT side was not interview for this specific case.

Product D

- It would have slightly saved some time to procure the application

- In case of questions ICT was not informed and could otherwise not help.

- In the future, ICT cannot test the application when doing a browser update.

Product H

- The freedom to use it. - People do not realise that they are sending provincie data. So the chance exist that people send confidential information.

Product E

- Probably time saving - And saving in budget costs. The business could not be interviewed for this case.

- Small possibility of unnecessary risk increase.

Product F

- Less workload on ICT department. - And time-saving in the

procurement of the application.

- They probably did not look at: How maintainable is the application, what if we want connections,

- They probably did not think about an exit-strategy, security, and which data do they actually save.

- They probably only looked at the functionalities.

Product G

- Less workload on ICT department. - And time-saving in the

procurement of the application.

- They probably did not look at: How maintainable is the application, what if we want connections,

- They probably did not think about an exit-strategy, security, and which data do they actually save.

- They probably only looked at the functionalities.

- Stealth adoption also brings more risks since the application is used in core processes and contain important data.

As said before, not every outcome of the case studies are a direct impact to the organisation. Therefore the outcome is split into three categories: 1. Direct impacts, 2. Added risks, and 3. Advantages and disadvantages.

5.2.2. Direct impacts

This paragraph describes the direct impacts that were extracted from the outcome of the cases studies. The found positive impact are:

1. Reduces procurement time of SaaS application.

It is found that ICT forms a big delay in most procurement processes of ICT applications. Therefore avoiding ICT saved time for most of the stealth SaaS-ing processes.