A Case Study at Skatteverket
Ejnar Sörensen
Field of study: Information Systems Level: Master
Credits: 30 credits
Thesis defense: Spring 2021 Supervisor: Steve McKeever
Uppsala University
Abstract
Microservices is a new and trendy architecture in software development and amongst its features is the ability to open up for teams to more freely choose the tech stack and programming language that best fits their needs. This feature, termed language diversity for the purposes of this study, is described in literature as a key to optimization and flexibility but is also ripe with concerns of complexity. In this study the author seeks to explore what language diversity could mean for the Swedish IT giant Skatteverket, the Swedish Tax Agency, from an organizational standpoint and to understand how it can align with Skatteverket’s goals. To do so the author has performed a case study consisting of a questionnaire sent out to tech workers in four different sections, and interviews with two key individuals in the organization. The results show that a significant number of respondents
(p-value=0.003), consider that language diversity would improve Skatteverket’s attractiveness as an IT employer, the effects of which could be a competitive edge on the job market. It was also shown that most (p-value<0.001) believed it would lead to at least some problems for the organization. Amongst the respondents, more experienced tech workers showed a tendency (p-value=0.06) to believe it would have less of a positive impact on Skatteverket’s image and were more likely to believe that the problems it would lead to would be greater. Overall, the study showed that language diversity could offer other rewards than those proclaimed in literature, and that the modernization factor of it could play a big role for Skatteverket.
Acknowledgements
List of Figures 6
1. Introduction 7
1.1 Previous Research and Knowledge Gap 8
1.2 Purpose 8 1.3 Research Question 9 1.4 Delimitations 9 1.5 Ethics 9 1.6 Chapter Disposition 10 2. Background 11 2.1 Skatteverket 11 2.2 Programming Languages 13 2.3 Microservices 13 3. Theory 15
3.1 Software Development Efficiency 15
3.2 Programming Language Diversity 16
3.3 Programming Language Popularity 17
3.4 Fashion Theory 20 4. Method 21 4.1 Case Study 21 4.2 Questionnaire 22 4.2.1 Design 22 4.2.2 Participants 24 4.3 Interviews 25 4.3.1 Design 25 4.3.2 Participants 26 4.4 Quantitative Methods 26 4.5 Interpretive Research 27 4.6 Method Summary 28 5. Results 29 5.1 Questionnaire 29 5.2 Interviews 34 5.2.1 Product Owner/Architect 34 5.2.2 Section Manager 36 5.3 Summary of Results 37 6. Discussion 39
6.1 Internal Views of Language Diversity and Opportunities 39
6.2 Goals and Challenges 41
6.4 Limitations 44
7. Conclusion 46
8. Future Research 48
References 49
Appendix A Questionnaire invitation email (English) 52
Appendix B Questionnaire (English) 54
List of Figures
Figure 1. Skatteverket organogram. (Det här gör Skatteverket, 2019)
Figure 2. Graph showing the popularity of programming languages as based on search engine searches containing programming language names. (TIOBE, n.d.)
Figure 3. A semi-log plot showing the popularity of programming languages as percentages based off of the worldwide google search of tutorials. Python is currently the one highest up. (PYPL, 2020)
Table 1. Research interviews.
Figure 4. Background variables of participants
Figure 5. Languages in current use at Skatteverket, current competences and languages of interest to learn more about for employees.
Figure 6. Expected impact on Skatteverket’s image by introduction of language diversity in microservices.
Figure 7. Expected amount of problems to occur by the introduction of language diversity in microservices.
1. Introduction
Skatteverket, the Swedish national tax agency, is one the largest providers of IT services for both public and private sectors in Sweden. Their mission to secure public funding, handle population registries and oversee other civic duties sets the foundation on which Swedish society’s ability to function and provide welfare can exist. Much like the rest of today’s society, their duties are to an overarching extent subject to digitalization and automation, a trend that entails more and more digital tools being added each year. (Lindström, 2017) This growing demand for digital services is understandable. Not only is it popular to access Skatteverket’s services via apps and the internet; in the era of information technology, it is something the populace has come to expect from private companies and government agencies alike. In 2020, 4.1 million Swedes received their yearly income declarations in digital
mailboxes such as Kivra, a milestone of more than half of the working population and proof of a growing digital acceptance. (Rekordmånga deklarerade digitalt, 2020). The flip side of this is that delivery of these services come with a growing complexity that stems from the continuous renewal and rework required of legacy systems as well as the additions of new systems and capabilities. Difficulties like these are made harder still by the necessity for data security, availability and robustness expected of Skatteverket.
To manage this net of applications and services Skatteverket have adopted a microservices architecture, containerized on the OpenShift Container Platform (OCP). This architecture, used by many large and complex organizations such as Netflix or Amazon, works by turning monolithic applications into distinct self-serving and single-purpose services. (Microservices, 2014) Amongst other things this separation of services opens up the possibility for smaller divisions and teams working with microservices to develop their software using any preferred programming language as long as communication is done via technology agnostic protocols such as HTTP. (Balalaie, Heydarnoori & Jamshidi, 2016; Microservices, 2014)
difficulty Skatteverket has with attracting tech workers to sustain the innovation and skill they require. For the sake of Skatteverket and society at large, it is also crucial to contain the competence in order to provide continuity to their services. At a time when developers are hard to come by and competition on the market is fierce, job searchers may be prioritizing new exciting tech opportunities, and with reports of Java’s popularity waning, Skatteverket’s brand as a tech savvy employer could be suffering. (Cass, 2020; Ganesan, 2020) Relying on a single language for development of services and applications may also hinder improvements that come from making use of languages that may be better suited and efficient for certain tasks, leading to higher budgetary costs in development.
1.1 Previous Research and Knowledge Gap
Much is researched and published about software development and programming languages. (Brodie, Mylopoulos & Schmidt, 2012; Gordon, 1988) Microservices, a relatively new endeavor, has also been a popular topic of research following the spread of its
implementation. (Di Francesco, Malavolta & Lago 2017). It can be argued however, that less is known about the effects and potentials of using different programming languages in microservices. Authors promote this language diversity as a key feature of microservices, where teams can autonomously choose whichever language fits their needs best, and hail it as a reason to consider adopting the architecture. But from a larger scope, the effects of using more programming languages in software development teams writing code and companies trying to organize their development is mentioned in brief, if at all. How much of a motivator for the workforce is it to work with something that is regarded as hot, what risks are involved and to what extent is it actually feasible for Skatteverket?
1.2 Purpose
1.3 Research Question
With help from Skatteverket, this study proposes to explore the topic of language diversity with the following research questions:
● How is language diversity seen inside the organization and what opportunities are there for Skatteverket?
● How does language diversity connect with Skatteverket’s overall goals and challenges?
● What potential problems are there with language diversity and how well prepared is Skatteverket to deal with them?
1.4 Delimitations
In this study the topic of language diversity is explored from the perspective of Skatteverket. It has the intention of creating a better understanding of the impact of programming
languages in the context of microservices and the role it can play for the organization rather than comparing the intricacies of each language’s individual technical strength. While acknowledging that these strengths exist and are inherently relevant to the topic, the study’s focus is to look at language diversity through an organizational, managerial and information system lens.
1.5 Ethics
In working together with a company, it is important to adhere to the security of information of the company and their employees. Wohlin (2012) proposes four ethical guidelines when it comes to research in the field of information and computing science; (1) Informed consent; that subjects of the research have access to information about the study before they
1.6 Chapter Disposition
To structure the content of this study report in a coherent manner it has been split into chapters, descriptions of which are written below.
Chapter 2 - Background: The background for this study explains the setting of which it has taken place and begins with an introduction to the company at the center of this case study followed by background knowledge of the key topics of interest that are to be further explored in this study.
Chapter 3 - Theory: The theory chapter covers certain important areas linked to language diversity, software development management and information systems theory that are of relevance to be discussed together with the results of the study.
Chapter 4 - Method: The methods used for gathering data is presented and a discussion is held to evaluate the quality the study provides and how the gathered data can contribute to answering the questions that the study is set out to answer.
Chapter 5 - Results: The empirical results of the study are presented, and findings of interest are summarized.
Chapter 6 - Discussion: Comparisons are made between the different empirical findings of the case study and the theories explored in the theory chapter.
2. Background
For the purposes of contextualizing the setting of this research, key topics upon which the study is built are presented in short in this following chapter. At the heart of this study lies Skatteverket and it is therefore necessary to provide the reader with an idea of its size and structure to better understand its challenges and needs in the later chapters. It is followed by a short description of programming languages origin and the microservices architecture.
2.1 Skatteverket
The Swedish Tax Agency, Skatteverket, is the administrative authority tasked with handling all forms of taxation, population registration and property assessments in Sweden. As a government agency they work with the means of public funding and are therefore required by Swedish law to follow additional rules of documentation and to report the work they perform with a high level of transparency.
Figure 1. Skatteverket organogram. (Det här gör Skatteverket, 2019)
The agency is organized hierarchically, and the IT department reports upwards the chain of command. To effectively support the rest of the operations at Skatteverket, the IT department works closely together with other departments. As part of this, the IT department also
provides strategic support in management connected to the implementation of the Agile framework Scaled Agile Framework (SAFe). The development teams at Skatteverket also follow this agile methodology in the majority of their teams.
Developers at Skatteverket work mainly with the programming languages Java and
JavaScript, where JavaScript is used solely for client-side development. Besides developers, many teams also include other supporting and leadership roles, creating the mix of
competencies required for their development operations. Teams are of mixed sizes depending on the different tasks it is allocated, they can be as small as five people, up to above twenty. While some teams work solely on developing new software, other teams work with the maintenance, taking over the continued development of the service after its release.
2.2 Programming Languages
Over the years there have been hundreds of programming languages, and they have changed vastly over time. The reason why there are so many depends on many factors but is
summarized by author Robert Martin (Clear Coder Blog, 2015) as the fact that none of them are perfect. Different languages offer different features and are capable of creating different types of software. One way of grouping languages together has been to pair them by the similarities of their features, called paradigms. A problem with this method of grouping is that most popular languages support many different paradigms, and it therefore says little about how one differs in features to another. Therefore, other differentiating factors will be explored in the theory chapter.
2.3 Microservices
According to Fowler (2014) there is no formal definition of what a microservices architecture is, there are however a few common characteristics that many of the implementations share. He describes that the easiest way to grasp what a microservice is, is to compare it to a monolith. A monolith, being a complete system, includes a backend, a frontend and a database that can be deployed on a server and is capable of performing all the business
operations that the system requires. In comparison, a microservice is a standalone service, but only a part of the complete system, focused on operating a singular business operation. There are many positive aspects of this approach, one being scalability; a monolith scales
However, behind these positive aspects lies many complexities. Since microservices operate independently, the integration is not as simple as in monoliths, and more in line with how systems communicate with each other on the web and is therefore a distributed kind of system. A microservice communicates with other microservices by exposing endpoints to their operations, making use of message queues and other functionality that allow them to instead loosely couple together. This raises the demand for fail-safing the system, since there now must be safeguards for when individual microservices go down. Orchestrating the
system in containers also puts a higher demand on the platform than in monolithic approaches and leads to transferring some of the complexity to development operations (DevOps).
3. Theory
This chapter introduces different theories that are relevant to look at in relation to the results encountered in this research. To better understand what effects programming languages and language diversity has on a higher level, software development success factors are explored in the initial subchapter. It is followed by a dive into the topic of language diversity, seen both from a traditional perspective and from microservices, and language popularity; how
languages popularity fluctuates and an attempt to understand programming language
adoption. Finally, fashion theory seen from the information systems perspective is explored.
3.1 Software Development Efficiency
There are several complicating aspects to adhere to when attempting to make a comparison about programming languages in software development projects. Terms such as efficiency and decreased development costs are two general, degradable concepts; efficiency in this context can refer to anything from lowering energy consumption, minimizing memory use, or faster runtimes. Development costs are also multi-dependent, complex, and therefore abstract, costs, relying on everything from the experience of developers and team members to
planning, requirements and other more unpredictable external factors. Software development projects are also notorious for exceeding budgets and one of the reasons for this is the
aforementioned complexity. (Charette, 2005) As such, there is rarely a single reason a project misses its deadline. (Blackburn Scudder & Wassenhove, 1996) Due to the elusiveness, this problem can rarely be tied down to something like a programming language making or breaking software development projects. Evaluating the effects of for example an architecture like microservices or other programming methods are for these reasons not simple.
“Nobody builds the same exact system once as a monolith and then as a microservices architecture. Any increase in speed will be intuitively rewarding but unscientific.” (Mitra & Nadareishvili, 2020)
language efficiency in development projects relate to social factors. One such is talent. When it comes to development projects, Blackburn et. al. (1996) says that regardless of
management techniques, planning and other factors, a team cannot overcome a lack of talent. Finding creative and talented individuals should therefore be prioritized. This claim is also supported by Chow and Cao (2008) who point out that in agile projects, the leading cost and time reduction factor is the experience of a team. Another general phenomenon team
management often runs into is known as the developer ramp process, where adding new personnel to a project actually slows down productivity until new hires have transitioned into the new environment. A key factor in minimizing the slowdown of this effect is having an interest match between the new hires and the software system. (Sim & Holt, 1998)
In relation to software development project ramp-up theory, there is also the issue of architectural technical debt (ATD). Technical debt often comes as a result of introducing complexity to a system, such as the architectural changes introduced with microservices. (de Toledo, Martini & Sjøberg, 2020) The implications of technical debt is described as a reduced likelihood of development success due to costs inferred by slowed development and sets the need to recuperate from the complexity that has been introduced. (Besker, Martini & Bosch, 2018)
3.2 Programming Language Diversity
teams working in different languages could be very hard to control and maintain. One way to combat this was to create service templates that could provide a well-defined, common starting point for services. (Balalaie et. al., 2016)
One of the greater issues with language diversity in microservices theory appears to be the reusability of code. This was shown as researchers followed a microservices implementation and highlighted issues they came across. In the observed sample, services were developed by teams choosing their own languages as proposed by microservices literature, but ran into problems when libraries shared between teams, used for failure-handling, service discovery and communication boilerplates, increased in complexity. As reimplementing the libraries into different languages became increasingly difficult, it eventually caused them to abandon the idea of developers’ autonomy in choosing their own programming languages. (Jamshidi, Pahl, Mendonça, Lewis & Tilkov, 2018) It is also important that teams are competent in the programming language they have chosen to work with, especially when starting out with microservices as it adds an additional dimension of complexity. It can therefore be preferable to work with “boring” technology. (Mitra & Nadareishvili, 2020) One interpretation of this is that working with distributed systems such as microservices is difficult enough for many inexperienced teams.
The main proponent for language diversity in microservices is described as the added
flexibility that teams are offered. A team working autonomously can choose their own coding standards and ways of solving problems that they face. Languages such as C++ that operate on a low level can also offer certain solutions faster performance which may be a necessary optimization, as an example. (Fowler, 2014)
3.3 Programming Language Popularity
As new programming languages appear, older ones may be discarded over time. But there are also those that hang on or evolve and retain their user base. (Bissyandé, Thung, Jiang & Réveillere, 2013) Out of all the programming made with the existing hundreds of languages, one estimate says that about ninety percent is developed in the top 20 languages. And
languages see more use than others are not straightforward. When creating languages, designers make trade-offs to create desirable properties, such as speed instead of ease of use, but such technical aspects are only one of many factors when it comes to popularity. (Nanz & Furia, 2015) Analyzing programming language adoption, Meyerovich and Rabkin (2013) identify key features that can explain adoption of new languages; that what is learnt early on in the career or school can shape a developers perception and lead to preferring languages of similar paradigm and design in the future; that access to open source packages is important and that social factors such as team experience or large language development communities also plays a big role. Aside from these main factors, most languages differ syntactically, but linguistic features were not found to be of similar importance. From a technical perspective, one driving factor for adoption was connected to the flexible development style of dynamic languages. (Meyerovich & Rabkin, 2013) Though most of the commonly used languages all feature some extent of general purposeness, some exist in domains that leave very limited choices to choose from, such as iOS development. In these cases, a driving factor can be the domain. (Bissyandé et. al., 2013)
Figure 2. Graph showing the popularity of programming languages as based on search engine searches containing programming language names. (TIOBE, n.d.)
engines, while PYPL uses the number of search queries of programming language tutorials on Google. (i.e. “Java tutorial”) (Programming Languages Definition | TIOBE, n.d.; PYPL PopularitY of Programming Language Index, 2020) Because of the method variation behind their indexes, PYPL suggests that using their popularity chart based on tutorial searches gives a better picture of where the market is heading than TIOBE. (PYPL, 2020)
Figure 3. A semi-log plot showing the popularity of programming languages as percentages based off of the worldwide google search of tutorials. Python is currently the one highest up. (PYPL, 2020)
“Worldwide, Python is the most popular language, Python grew the most in the last 5 years (17.0%) and Java lost the most (-6.7%)”- PYPL (2021-05-11)
“...It [Python] might be even heading for the first place of the TIOBE index in the next half year, because C is (just like Java) losing popularity. … “- Paul Jansen CEO TIOBE Software.
(TIOBE, n,d)
Comparing the descriptions of their respective charts, popularity trends indicate a downward trend for Java, making room for newer languages and an increasing growth in popularity for languages such as Python. In the TIOBE chart newer languages such as Kotlin, Golang and Rust are not visible on the chart and first encountered much lower in the index. A
In summary, language preference is shaped by a developer’s past experiences and adoption into new languages stems from social factors as well as technical factors such as access to third-party software. There are however times when a particular task leaves little to no choice of language, and in such domains the choice of language comes naturally. General trends show a slow decline for Java and a growth for Python as well as a group of newer languages.
3.4 Fashion Theory
Incentives for change in organizations can come internally from the organization itself or externally when exposed to the competitiveness of being compared to other organizations in the same field. (Thompson, 2013) Digitalization and globalization are factors that further propel the need for change in organizations because of an increased demand for the products they supply as well as the adaptation needed by the products to reach more customers. Internally, one incentive can be cost reduction, whereby parts of the product’s life cycle is improved upon to attain budgetary savings, often monetary or in the form of human resources. (Thompson, 2013)
4. Method
For this study a combination of different methods was used. There are many different ways of combining methods, and for the purpose of this study a mix of quantitative and qualitative data was gathered. Using multiple methods can strengthen the results of data and, when used in combination, quantitative and qualitative methods can complement each other with their width and depth. (Hesse-Biber, 2010; Oates, 2005) To make use of this, data was gathered with both a survey and interviews. The questionnaire was used to get a wide understanding of opinions related to the research topic, whereas the interviews were used to better understand the why and how behind the general decisions that were made in the organization, as well as future goals.
The author acknowledges that this is one of many possible ways of exploring the topic and that there could be many that touch upon other angles of importance. As such, the method used in this study is neither declared as optimal nor a complete way of researching the topic, but the one to the best of the ability of the author. Possible alternatives and missed
opportunities are further discussed in the final parts of the study in relation to future research.
4.1 Case Study
According to Oates (2005) a case study is a type of study that focuses on a particular ‘thing’ of interest. This ‘thing’ can be an instance of anything from an information system to a department or a company. This particular instance is studied in depth, often with the help of multiple methods such as surveys, observations and documents for the purpose of gaining a rich and detailed understanding of it. One important aspect of this is to take into account the processes and relations surrounding the instance, which are seen as necessary to understand in this type of study. For this reason, case studies are often characterized by a holistic focus since they look at an object from many angles, attempting to research the full complexity of a phenomenon rather than a few isolated factors.
Oates (2005) also explains that when a particular topic is rare in research, an exploratory case study can be performed to gain a better initial understanding of something and make
other research and knowing exactly what to look for means it can be preferable to take some chances with the questions asked and explore factors whose relevance cannot be taken for granted. Since the operational language at Skatteverket is Swedish, data was gathered in Swedish and translated into English.
4.2 Questionnaire
4.2.1 Design
Designing a questionnaire that targets a large group of people requires consideration in regards to both the study and the participants. Oates (2005) warns researchers of collecting data with surveys that have data requirement issues, such as asking questions that are
imprecise or vague. In line with the more explorative approach the questions were formed as such to allow for some adaptation of new findings while remaining as concise and relevant as possible to the original topic.
A questionnaire consists of a number of predetermined questions presented in a fixed order where the purpose is to collect data that can be interpreted and analyzed. In this study, the questionnaire was used to explore the competences and opinions of tech workers in a number of projects. The information gained from the questionnaire was then contextualized through comparison with relevant theory and other findings from the study, either found through observation or interviews with the objective of answering the research questions.
Operationally, the questionnaire was created in a simple internal questionnaire tool provided by Skatteverket, a tool built by them for the purpose of safely and anonymously surveying the organization. The invitation was sent out via email, containing a description of the study and its purpose and a link to the survey. To ensure that participation was limited to the targeted projects, only the individuals from these projects were made eligible to answer, others accessing the survey were denied access. This was done by adding the projects in a members list of the tool. It was tested and shown to work as intended by providing the link to other individuals within the organization that were not to be part of the study. Since the
Questionnaires are an effective method of collecting data from many people and are best suited in situations where the answers from the respondents can be kept short and
uncontroversial and the questions can be clearly formulated and understood by the
respondents (Oates, 2005). The author took into account that the survey questions should not be leading, not addressing sensitive areas and be clear to the respondent. To ensure the quality of the questions they were shown to test individuals both within and outside the organization and updated based on the received feedback before they were sent out. For the format of the questions a mix of multiple-choice and free text answers was used. The free text answers were used as follow up questions, allowing the participants to answer more freely in regard to why they answered as they did, prompting more open ended answers that could be used qualitatively to explain the reasoning behind choices or opinions, an important aspect for the purpose of this study. The multiple-choice questions that targeted opinions were constructed to have an odd number of answer alternatives, making room for a neutral option so that the respondents would not be forced to take a stand on statements to which he or she is neutral. (Ejlertsson, 2005) These types of questions also included a ‘don’t know / no opinion’ option, which is useful as the respondents are expected to have different knowledge and experience backgrounds within certain areas. Throughout the questionnaire, it was the author’s intention to be open for answers from employees with different tech related roles.
amongst the predefined options. The most natural and theory-based option for making a list of languages was to add the popular languages from TIOBE and PYPL. Finally, the last questions of the questionnaire were associated with opinions and consisted of both semantic differential scale questions and follow up questions with free text fields to allow for more elaborate answers. The questions were about what impacts additional programming languages would have on Skatteverket’s image, what problems additional languages may cause and about the use of the vetting process for third-party packages that Skatteverket was observed to use. These questions are central to the study’s purpose.
4.2.2 Participants
The questionnaire was carried out in different stages over the course of a month as new participants were recruited. The initial invitation was sent out over the course of March, it gathered 29 respondents. In April a reminder was sent out which gathered an additional 17.
The four participating sections differ in their competence and composition as a result of the variety of their tasks and operations, but also in their progress of adopting the microservices architecture on OpenShift. Though it varies much between teams in each section, two of the sections can be seen as having a high level of adoption as all the components and services they build are run in containers on OpenShift, while one is mixed and the last relies more on other architectures for their development. Within these units many work with tasks not directly related to software development, such as design, ux, communication, management and business development. There are also other technical tasks that do not revolve around using programming languages.
4.3 Interviews
4.3.1 Design
In comparison to a questionnaire, where participants are questioned in a static manner with many limitations, interviews allow for discussions and delving deeper into certain areas with the participants. Therefore, interviews can be held as a complement to other survey methods to gain a deeper qualitative understanding of a topic. (Ghauri & Gronhaung, 2005) One type of interview that sees much use is the semi structured interview. In comparison with other formats, semi structured interviews are less strictly bound to the initial planned structure of the interview and allows for more adaptation and exploration of sidetracks, though still bound by the predefined themes of the questions. (Oates, 2005) Because of the relative lack of theory regarding language diversity and background knowledge of the organization,
semi-structured interviews were chosen as the interview style because of their more adaptive and explorative nature.
The themes of the interviews relate to observations and theory related to the research
questions; asking why they chose a certain development path, what problems they perceive or how they aim to deal with a potential problem brought up in literature. The questions are general, open and in the context of Skatteverket for the purpose of gaining an understanding of Skatteverket’s situation rather than individual opinions from the organization.
In order to gain valuable and accurate information Walsham (2006) explains that an
interviewer should start by ensuring confidentiality and describing the purpose of the study and the length of the interview should be controlled. The interviews were held online via Skatteverket’s meeting system and recorded. Walsham (2006) mentions that recording interviews can lead to unease for the participant, but it also means the interviewer can more actively participate instead of taking notes, something that was important because of the interview format.
makes use of an enterprise system and a vetting system for third parties, therefore this topic was explored to investigate its relevance to the topic of language diversity.
The more business and organization-oriented interview discussed questions of market trends, Skatteverket as a workplace, modernity and goals and challenges, as these would be
necessary to understand and put into perspective when discussing language diversity.
4.3.2 Participants
Persons of interest for the semi structured interviews are persons higher up in the hierarchy with section and unit management or lead architecture roles. The themes of interest for these interviews relate to follow up questions of the questionnaire results, observations or theory related to the research questions; asking why they chose a certain development path or how they aim to deal with a potential problem brought up in literature or what problems they perceive.
Role Date Length (minutes)
Product Owner/Architect 2021-05-03 30
Section Manager 2021-05-07 30
Table 1. Research interviews.
The two interviewees chosen for the study were a section manager and a product owner architect. The two participants complemented each other with one having deep social and organizational knowledge, tasked with leadership and recruitment, and the other having deep technical knowledge relating to microservices, programming and the OpenShift platform. There was an initial intention to interview more roles to widen the perspective, but after carrying out the interviews the author came to the understanding that widening the focus further would drift the conversation away from the original topic and leave too many angles to compare.
4.4 Quantitative Methods
generally to distinguish patterns in data and through technical analysis ascertain whether there truly exists a pattern or if the observation more likely occurred randomly. (Oates, 2005)
Statistical calculations and diagrams were performed and created in the program Graphpad Prism 9 (Graphpad Software, 2020). Binomial tests were used to test if a proportion deviated from an expected value; this test is used, for instance, to evaluate if a certain value comes up abnormally often when rolling a dice. (Körner & Wahlgren, 2015) Chi-square tests were used to detect deviations from the null-hypothesis in contingency tables; a test used to check if two or more categories of responders differ in their categorical responses, such as for instance, ‘are subjects with long work experience less interested in new programming languages in the work environment?’. (Körner & Wahlgren, 2015) Wilcoxon test was used to test if there were differences between quantitative responses between two different categories of responders. Wilcoxon test is a non-parametric rank test, meaning that all quantitative values are ranked from highest to lowest and then tested to see if one category had more or fewer values amongst the top half of the rank than the other category. The Wilcoxon test is often used when a Student T-test is inappropriate, for example when data is not normally distributed or when data is not on a continuous scale. In this study, and similar to how it is often evaluated in statistical tests, a two-sided p-value less than 0.05 was considered statistically significant. (Körner & Wahlgren, 2015)
4.5 Interpretive Research
Popularly used to understand organizational aspects of information systems and information systems development, interpretive research is a way of understanding a phenomenon by examining the near-real complexity of it without starting out with a priori determined
concepts. (Klein & Myers, 1999) At the heart of interpretive research human factors are often involved, and when making sense of data from respondents it is important to take into
analysis, wherein the author’s interpretation and analysis will be limited to the final discussion and conclusion chapters.
4.6 Method Summary
The method of this study was to exploratively investigate the topic of language diversity at Skatteverket via a case study with a mixed-method approach using a questionnaire sent out to participants and interviews held with key individuals. To understand the results, qualitative and quantitative methods were used and in turn interpreted by the commonly used
5. Results
In this chapter the results of the questionnaire and interviews are presented without discussion. First, the background variables of questionnaire respondents are shown. These variables are then used as part of the statistical analysis in finding patterns in the rest of the data. The following figures go on to display the answers of different questions, with a rundown of themes from qualitative text-based replies related to each question.
The interviews are summarized in the second subchapter, split up by interviewee and the different themes they were asked about. Finally, a summary of significant findings is presented.
5.1 Questionnaire
Figure 4. Background variables of participants
other related fields; architecture, technical test, management and DevOps (Figure 4A). As is shown in figure 4B, a majority of the participants were permanent employees working directly for Skatteverket, and (n=11) were consultants, meaning they were hired in via another company. Regarding the type of projects the respondents work with, most reportedly work with the development of microservices on the OpenShift platform.
Figure 5. Languages in current use at Skatteverket, current competences and languages of interest to learn more about for employees.
Out of the participants, 43 reported that they work with programming on a daily basis. Out of these, Java and JavaScript were the most common languages (Figure 5A) and it was not uncommon amongst the respondents to work with both. A significant portion of these developers (n=8) reported that they use both Java and JavaScript as well as a third and sometimes fourth language, commonly being the database language SQL and Groovy. A few individuals, mostly connected to the main occupations of technical test and DevOps work mainly with the automation and scripting languages of Groovy and Bash.
When asked what programming languages the participants had competence in using
Finally, when asked about what programming languages they had interest in learning more about (Figure 5C), many developers (n=11) showed no interest in learning more about any languages. Some showed interest in learning more about the main languages used today (Java n=7, JavaScript n=9). Out of the languages not in use, what most respondents showed interest in learning more about was Python (n=14), followed by Kotlin (n=7), Golang (n=7) and Rust (n=5). Two individuals also stated that they are interested in learning any language required of them.
Figure 6. Expected impact on Skatteverket’s image by introduction of language diversity in microservices.
In regard to how the image of Skatteverket as an attractive IT employer would be affected by having microservices in more programming languages, a statistically significant majority stated that it would have a positive impact (Wilcoxon test p-value=0.003, Figure 6). Distribution of views was not significantly associated with work position or employment. However, those that responded that it would have negative or no impact (n=7) tended to have more years of experience (p=0.06).
graduated developers prefer newer languages and that using more programming languages would open up for talented competences who would otherwise not apply. (n=5) said it was important for ‘personal development’ and ‘learning new things’ and one stated that opening up for new languages was ‘a necessity for flexibility’. One reasoned that it would help combat a general portrayal that Skatteverket does not work with modern technologies. From those negatively and neutrally inclined (n=7), concerns were brought up about untyped scripting languages and their effects on code structure, and that because applications at Skatteverket have long life cycles, maintaining competence would be problematic over time.
Figure 7. Expected amount of problems to occur by the introduction of language diversity in microservices.
When asked if they believed using more languages could lead to problems, a majority chose ‘Yes, minor problems’ (p<0.001). Persons who chose ‘Yes, major problems’ all had at least 20 years of experience.
When prompted to explain why they thought so, the potential problems behind using more languages were described as increased complexity in and between systems, reliance on competences that may be rare and harder to recruit for and decreased flexibility amongst the staff. The issue most commonly brought up was concerns associated with recruitment (n=7), where in a situation that a developer quit, replacing their competence would be difficult or costly, especially if the sought-after developer would need to be competent in several
concerning the lack of internal best practices for new languages, context-switching, increased DevOps and increased work in the transition period of languages being added. Related to the long term, (n=6) brought up problems about maintainability; that it would be harder to understand what others have done previously and to share experiences between teams, that it would be harder to manage life cycles and impair the reusability of modules. While most agreed that there would be at least some problems, (n=3) also stated that substantial change involves difficulties, and that it should be compared to potential long term gains.
Figure 8. Frequency of problems had with the vetting system for third-party software at Skatteverket.
Answering the question of whether the third-party assessment system had limited them in their work (Figure 8), most answered either rarely or never. ~24% said they don't know. There was no significant association with profession, employment or years of experience. Out of those answering ‘Often’ all the developers worked with JavaScript.
When asked to describe their opinions regarding the handling of third-party software at Skatteverket, those who often experienced problems said the waiting time was particularly cumbersome in regards to frontend development since third-party packages are often required in day-to-day tasks and a commonly occurring problem. Amongst those answering
checks. It is also brought up that the process feels smoother now than it did a few years back and that most of the packages that one needs are available in the system already. Twenty out of 46 provided answers.
5.2 Interviews
5.2.1 Product Owner/Architect
Third-party packages and software reuse
Generally, the architect felt that Skatteverket is in a good place when it comes to third-party software. Most large libraries and packages come from trusted sources, such as the large JavaScript frontend frameworks of Vue, React and Angular. When working with admission of third-party packages it is important that the installation and use of them can be automated, since manual work can be time-consuming. Large package platforms such as NPM or Maven represent barely any problems in this regard. One of the risks involved with third-party software and a reason for why having a vetting process is of importance is due to the possibility that packages can contain post-install scripts that can endanger user data and security. Using software that comes from trusted sources is therefore very important and a common issue amongst all companies. Although the architect sees it as a problem that can be found on all third-party platforms, he speculates that the problem may be the biggest with JavaScript on NPM. Overall, there are valid reasons to make use of a structured and well thought-out vetting process even if it may hinder developers at times.
Language diversity
languages that are growing in popularity such as Kotlin, Rust or Scala, the architect
speculates that they may be rising quickly now, but before they are entirely established in a particular niche they cannot know if they are going to last, and adopting languages before they reach that maturity presents a risk that is too large to take. Golang is a bit different, and more realizable for customization and configuration, since the container platform itself is built in it. Seen from the perspective of development of microservices, Golang presents the same issues as Node.js, he states. With Java being the enormous ecosystem that it is, he deems it unlikely to go anywhere any time soon, pointing towards the momentum that exists behind Java. He admits that Java may however not be the obvious first choice that it once was and may not be a language they can stick with forever. It will therefore be important to
continue testing and evaluating new languages as they go.
Currently there are a few legacy projects at Skatteverket built in Perl, a language that sees dwindling popularity and use, but that they still need competence in until it is rebuilt. In this case, finding competence in the long term can be hard and rebuilding it will present new costs. This is a type of risk that the architect sees with using more languages that may be popular today, but that may not last. He believes this to be a general issue for large enterprises and not just Skatteverket.
For the overall organization of microservices, strategic decisions must guide the
development. It will therefore not likely be possible for teams to make their own decisions of development paths regarding choice of programming language. Skatteverket does not want to stifle innovation, and the architect says that Skatteverket encourages teams to find new solutions and propose changes, but that it must fit into the general strategy of cost efficiency.
Maintenance
5.2.2 Section Manager
RecruitmentGenerally, the view of recruits was that younger developers have a good competence
connected to new technology and a high level of interest in learning new things, while older developers have more general experience and other types of competences, and as such both are constantly needed. Besides developer roles, other technical roles such as architects are also necessary to find, and Skatteverket is open for both consultants and permanent direct hires to make sure they have the expertise they need. The manager explains that there is currently a great need for finding new hires because of the giant systems they manage and that it poses a challenge that is believed to continue growing in time. Job searchers today are looking for fun and challenging work experiences that can further their careers, and getting to work with what is considered new is a big selling point and something that Skatteverket must make use of.
Complexity
Over the years, the manager described the projects as becoming increasingly complex, the reasons for this was because of the needed knowledge in microservices, the different tools and platforms surrounding the development as well as frontend and backend competence. Taking the step into working with microservices has also led to a transformation of the roles formerly known as quality assurance and test. These roles used to demand less technical prowess but have since been replaced by the new DevOps and technical tester roles. The DevOps role now works with pipelines and a lot of the configurations of the platform and the tester, who used to perform more manual integration checks, is now expected to write
automated unit and integration tests for services and their synchronization, which requires programming. A mentioned example was one of their recent recruitments for a technical tester role, for which a test was provided as part of the application process, and out of all the applicants only a tiny portion were able to complete the test provided to them.
Modernity
According to the manager, it is a constant process and requirement to stay modern in today's job market, both in tech and in everything else related to the workplace. Currently, amongst other things, the manager said, they are introducing new premises for an office in Solna that is attractive and interactive. They also offer flexibility in working from home. One of the main drives behind these measures is to improve Skatteverket’s branding, incentivize the current workforce to stay and to attract new employees. In technology, they are vigilant in understanding where the market is heading and prepared to adapt as it changes. When asked what the potential risks could be with technology changing too fast, the manager said that it was that the workforce competence must be able to keep up. Spending time on educating is one way of tackling technology change, but since it must be weighed against measures of cost efficiency and maintainability decisions it must be done with care. The manager points out that Skatteverket works heavily with measures of safety, since they work with such sensitive data and services that must be protected, so the risks with new changes must be well
understood in advance. Along with these overarching goals of safety and protection
Skatteverket also wishes to offer a humane and caring workplace for their employees. Cost efficiency is also a must since it is the taxpayers who in the end foot the bill.
5.3 Summary of Results
Findings from the results of the questionnaire show that:
● A significant majority stated that introducing new programming languages would positively impact Skatteverket’s image as an attractive IT employer and lead it to become a more flexible and competitive organization.
● Introducing new programming languages were believed to lead to problems, though a majority believed the problems to be minor ones and mainly associated with
maintainability and complexity.
● The more experienced or older developers were less likely to believe introducing new languages would have any positive impact on the organization's image and more likely to state that the problems it would cause would be larger.
The language interests showed a favor for other languages than the ones that were being used.
Out of the interviews it was found that:
● The main challenge that the IT organization was facing was related to recruiting new competence and maintaining the competence that they have; an issue that was further complicated by an increase in complexity that has come with microservices.
● Language diversity is approached carefully and mostly out of need when developing in domains where there are no feasible options. Java is likely to remain the business logic language of choice for the organization for the foreseeable future.
6. Discussion
In this chapter the empirical results of the survey are discussed together with relevant theories visited earlier in the study. The chapter begins with three subchapters, each covering one research question, starting out with research question one: ‘How is language diversity seen inside the organization and what opportunities are there for Skatteverket?’, followed by ‘How does language diversity connect with Skatteverket’s overall goals and challenges?’ and
finally ‘What potential problems are there with language diversity and how well prepared is Skatteverket to deal with them?’ The chapter is concluded by a subchapter about the study’s eventual limitations.
6.1 Internal Views of Language Diversity and Opportunities
With the results from the questionnaire it is clear that language diversity is a popular topic amongst the tech workers at Skatteverket, and that most believed it would positively impact Skatteverket’s attractiveness as an employer. Aside from improving competitiveness, there was a belief that it could lead to avoiding technology stagnation and to other appealing opportunities, such as increased flexibility in the workforce and chances of learning something new, as well as a possibility to make use of language specific strengths. In comparison to the features of language diversity, as proclaimed in microservices literature, there were some similarities in regards to language specific strengths and flexibility, but the flexibility mentioned in the answers referred to more inter-team collaboration than the team autonomy that literature speaks of. (Fowler, 2014) Though unrelated to other background variables taken into consideration for the questionnaire, the expectation of impact differed amongst those more experienced, as they were significantly more inclined to believe it would have either negative or no impact on Skatteverket’s image.
Balalaie et. al., 2016) Generally, the answers showed a lot of variety, perhaps implying that the topic has not been discussed in the organization.
The reason why more experienced developers were more likely to see language diversity as something leading to greater problems and without impact on Skatteverket’s attractivity could not be made clear with the data from the survey due to the types of questions that were asked. Looking at the reasoning behind their more negative answers, it can however be seen that there is a higher concern regarding technical aspects of using other programming paradigms and the longevity of systems. Developers and the section manager also mentioned that using newer languages would particularly entice younger developers, implying that it was of less interest to those more experienced.
As for the languages that the respondents showed interest in learning more about, Python stuck out as the language of interest, followed by the currently used languages of Java and Javascript and many newer languages that have grown in popularity in recent years. The interest in other languages such as PHP, C and C# was low and eleven developers (26%) expressed no interest in learning more about any languages. Since respondents were not offered to explain why certain languages were more interesting than others, it is difficult to say for certain why they felt this way. There was no particular association to paradigms, as they all consist of mixed types, but in comparison to language popularity charts from TIOBE and PYPL, where Python, Golang, Rust, Kotlin and Scala have been on the rise, the interests align well with popularity. A commonality between interest, novelty and modernity may therefore be one associating factor. Theory states that adoption in new languages is driven by factors such as a developer’s previous experiences and language features. (Meyerovich & Rabkin, 2013) There was however no clear difference in background for those interested in learning more about these languages, perhaps further implying there is something else that draws interest into languages.
Nadareishvili, 2020) Based on internal competence, C and C# may therefore be languages that could be used in microservices, but outside of potential technical gains that these languages could offer, they do not appear to be good choices in terms of interest. Based on interest, Python, and to a lesser extent Golang, Kotlin, Rust and Scala may be possible choices, but riskful seeing as there is a lack in competence. If Skatteverket should make use of other languages in microservices it would be important to take into consideration what interest and competences there are. And in order to make use of positive aspects such as allowing developers to learn new languages and enticing younger developers, it would be beneficial to choose a language that developers are interested in learning. The most promising language to choose in this scenario is Python, which not only scored highest in interest out of all languages but also showed some existing competence in-house.
In summary, views on language diversity are generally positive, and adopting it would, in regards to competence and interest, partially be a possibility for languages such as Python. Though most believed it would involve some problems, the problems and reasons to adopt it found in the questionnaire results swayed from the ones brought up by theory. The languages of interest also differed from the language adoption theories found in literature, and hint toward an association between language interest and factors of novelty and modernity as shown in popularity metrics. More experienced tech workers were generally less positive of the language diversity idea, and while the reason for this could not be determined, there was a common belief that younger individuals were more drawn towards popular languages.
6.2 Goals and Challenges
From the interviews it was shown that working with microservices had led to an increase in development complexity, comparable to what is described as technical debt in theory, where it was also described as often coming as a result of architectural change. (de Toledo et. al., 2020) This has led to requiring more out of their tech workers for both development and the areas around it, such as DevOps and technical testing. These statements also find support in theory as complexity is transferred from development to supporting roles. (Fowler, 2014)
This complexity was further problematized by the challenge of recruiting new competence, especially those already familiar to the technology Skatteverket uses. This issue of
problem amongst similar organizations, inferring that there is a strong competition for competence on the market. Metrics comparing salaries between private and state sector organizations in Sweden show that Skatteverket may be hindered by the fact that they cannot easily match the paygrade of private companies. (SCB – Hur mycket tjänar. . .?, n.d.) This difficulty in offering the same salary for the same work means Skatteverket is required to offer other types of incentives, such as additional vacation days and the like, but may nevertheless result in an uneven competition for competence. The efforts related to solving this at Skatteverket was modernizing the workplace in different ways to increase the workplace’s attractivity, to incentivise the existing workforce to stay and attract new competence.
According to information systems theory it is common for organizations to adopt ‘fashions’ as part of a modernization process. Fashions are referred to as managerial fads that often originate from IT, said to lead to improvements, but that do not always live up to what they promise. Fashions are therefore associated with negative connotation in IS literature, but do offer rewards in boosting an image of modernity. (Baskerville & Myers, 2009) Taking into consideration the novelty of the language diversity idea in microservices, combined with the fact that long term effects have not yet been established, it is reasonable to refer to it as a fashion. In line with this and the approving sentiment from the questionnaire results, adopting language diversity would lead Skatteverket to appear as a more modern employer in the eyes of potential recruits. This strive for modernization could therefore be a reason to make use of language diversity, and provide a useful edge on the job market. It is however a riskful endeavor, as fashions by definition are known to have unknown long term effects.
The main proponent for Skatteverket’s strategy was cost efficiency, which was something that all undertakings were compared against. Though it can be said that language diversity is likely to affect Skatteverket’s opportunities in recruitment by ways of modernization, and thereby provide some form of cost efficiency, the technical gains of making use of additional languages are harder to quantify and should be taken into consideration on a
To summarize, faced with growing complexity and market competition Skatteverket is pushed to modernize their workplace in order to meet their needs. Language diversity, as a fashion, can be deemed to be one piece in a modernization puzzle, though it is unclear to what extent it needs to be implemented and how it fits into the general strategy of cost efficiency.
6.3 Potential Problems and Solutions
The results show that language diversity is approached with caution at Skatteverket. In looking for new languages there was no intention of switching out Java for something else or adding other general purpose languages in the short term. The observed need for
diversification of languages at Skatteverket could instead be understood as domain driven, meaning they intend to pursue languages out of need.
The main concern of using several languages in microservices theory is found in software reuse. (Jamshidi et. al., 2018) Skatteverket makes use of many third-party packages as well as a large amount of their own internally created reusable components and libraries, but by enforcing firm boundaries between domains, these difficulties can be diminished since there is less need for reimplementation of packages in several languages if the domains are disconnected. (Martin, 2017) Skatteverket also makes use of what they call ‘chassis’, barebone boilerplates for creating new services, something that was also seen as a problem mitigation for language diversity in microservices. (Balalaie et. al., 2016) Finally, a problem that appeared was the separation of development and maintenance teams, but this problem is likely solved by the intention of transitioning into product teams for the services that are outside the languages currently being used. In relation to problems brought up by theory, Skatteverket can be seen as prepared and aware of the risks involved.
From the results of this study it is shown that there are fears that using more languages will further increase the complexity between systems and require even more from their
In summary, Skatteverket is cautious in its approach to language diversity. And plans to adopt new languages are well planned and safeguarded in accordance with literature.
6.4 Limitations
This study set out to explore the topic of language diversity at Skatteverket and starting out in this topic involved some challenges due to the limitations in available information. In
hindsight, it is possible that asking other types of questions would have provided more definite results, such as seeking deeper information into why languages were seen as more interesting than others. However, in accordance with explorative type research without settled a priori inclinations, it is not possible to explore all angles in-depth. Instead, it is the author’s hope that others will delve deeper into these aspects of the topic and discover more about the driving forces behind programming language evolution.
The respondent rate on the questionnaire can be seen as on the lower end in comparison to the number of people it was sent out to, and since it is not known exactly how many of the invited participants had the sought after competence, the true ratio is not known. In talks with managers, the response of the questionnaire was seen as high in proportion to the tech
workers, and the results are therefore deemed good.
When analysing answers from interviews and questionnaires it is important to acknowledge the bias that can appear when participants do not understand or misunderstand a question. In this study a separation was made between discussion and empiric results for this reason as to not apply any additional author’s bias to the equation. It is also important to recognize the fact that language competence and the understanding of its meaning can be interpreted in different ways, and that rating one’s own competence fairly is never going to be fully realizable. The only option that exists is to test individuals, but this is neither feasible nor likely to be bias-free.
A limitation of case studies is that they are not easily generalizable. (Oates, 2005) The results of this study may therefore not be transferable to other organizations without first making the same exploration in their local environments. There is no reason to believe that the
7. Conclusion
Skatteverket is undoubtedly an organization of importance in the IT sector of Sweden, since the success or failure of operations impact the society at large. Language diversity can be recognized as fashion and involves unknown risks. There are not many experiments showing that the full developer’s autonomy, where developers freely choose what language they want to use, works in practice. The risks that are known weigh heavily, but there are inclinations that show that Skatteverket is in a good place in terms of preparation and it’s approach to face these risks. Language diversity is also seen as positively impacting Skatteverket’s image and helping it appear more modern, which may bring some perks and prove valuable to
Skatteverket in relation to the challenges it is facing with market competition and modernization.
It is unclear to what extent language diversity needs to be implemented in order to make gain from these perks, but it is reasonable to believe that choosing languages that are considered interesting and popular in the market that it operates in has a greater positive effect than choosing languages that are regarded as less modern.
Language diversity also involves an increase in complexity, but from Skatteverket’s perspective this is likely minimized by choosing languages that exist in different domains since this is less likely to lead to as many problems in software reuse and will make it easier to establish boundaries.
Based on the factors explored in this study; interest, competence, fashion and domain separation, the most promising language to consider adding support for at Skatteverket is Python.
An interesting observation was the tendency amongst experienced developers to be less likely to believe that using more languages would positively impact Skatteverket’s attractiveness as an employer, as well as more likely to believe it would lead to greater problems compared to other respondents. Whether this is because they have a greater appreciation and
8. Future Research
Programming languages will likely continue to develop and languages will come and go. In terms of future research the author of this study would like to learn more about the
age-of-experience factor that was observed as well as a more technical approach to the topic, especially in the context of development in Sweden. Another area of interest would be to learn more about the driving force of language popularity and fashion in software
References
Balalaie, A., Heydarnoori, A., & Jamshidi, P. (2016). Microservices architecture enables devops: Migration to a cloud-native architecture. Ieee Software, 33(3), 42-52.
Baskerville, R. L., & Myers, M. D. (2009). Fashion waves in information systems research and practice. Mis Quarterly, 647-662.
Besker, T., Martini, A., & Bosch, J. (2018). Managing architectural technical debt: A unified model and systematic literature review. Journal of Systems and Software, 135, 1-16.
Berger, E. D., Hollenbeck, C., Maj, P., Vitek, O., & Vitek, J. (2019). On the impact of programming languages on code quality: a reproduction study. ACM Transactions on Programming Languages and Systems (TOPLAS), 41(4), 1-24.
Bissyandé, T. F., Thung, F., Lo, D., Jiang, L., & Réveillere, L. (2013, July). Popularity,
interoperability, and impact of programming languages in 100,000 open source projects. In 2013 IEEE 37th annual computer software and applications conference (pp. 303-312). IEEE.
Blackburn, J. D., Scudder, G. D., & Van Wassenhove, L. N. (1996). Improving speed and productivity of software development: a global survey of software developers. IEEE transactions on software
engineering, 22(12), 875-885.
Brodie, M. L., Mylopoulos, J., & Schmidt, J. W. (Eds.). (2012). On conceptual modelling:
Perspectives from artificial intelligence, databases, and programming languages. Springer Science &
Business Media.
Cass, S. (2018). The 2017 top programming languages. IEEE Spectrum, 31.
Charette, R. N. (2005). Why software fails [software failure]. IEEE spectrum, 42(9), 42-49.
Chow, T., & Cao, D. B. (2008). A survey study of critical success factors in agile software projects.
Journal of systems and software, 81(6), 961-971. Clean Coder Blog. (2015, April 27). Robert C. Martin.
https://blog.cleancoder.com/uncle-bob/2015/04/27/LanguageLayers.html
de Toledo, S. S., Martini, A., & Sjøberg, D. I. (2020, June). Improving agility by managing shared libraries in microservices. In International Conference on Agile Software Development (pp. 195-202). Springer, Cham.
Det här gör Skatteverket (2019). Skatteverket.Retrieved May 12, 2021,
https://www.skatteverket.se/omoss/varverksamhet/styrningochuppfoljning/dethargorskatteverket. 4.7856a2b411550b99fb780008148.html
Di Francesco, P., Malavolta, I., & Lago, P. (2017, April). Research on architecting microservices: trends, focus, and potential for industrial adoption. In 2017 IEEE International Conference on Software Architecture (ICSA) (pp. 21-30). IEEE.
