Software Business

Workarounds have existed in software from the very beginning. Being a formalized collection of knowledge rather than a physical artifact, software allows shortcuts in its development process. The shortcuts serve various purposes, like releasing a product to the market faster or postponing the solution of a problem. In this article, we present the findings of an investigation of workarounds in two software companies. Our analysis reveals that the decisions to take a workaround to resolve a technical issue are often intentional and forced by time-to-market requirements. However, the stakeholders are not always familiar with the negative consequences of taking workarounds, like additional hours, costs, and poor quality. We argue that the decision to take a workaround is often made by business managers who see short-term benefits only while developers have to deal with negative consequences in long-term.

The use of lean software development methodology and business model experimentation has become popular in software companies in recent years. Business model experimentation is used to validate assumptions made on a product from real customers before the actual product is created. A minimum viable product is used to test the business model by gathering and measuring customer feedback. However, in many cases creating a minimum viable product requires the development team to take shortcuts and workarounds in the product. This phenomenon in software development is called ‘technical debt’, where companies trade long-term software quality to short-term gain in time-to-market. We investigated four software companies and conducted nine interviews to understand the relationship between business model experimentation and technical debt. The goal was to study how business model experimentation is affecting to technical debt. The results showed that business model experimentation has a clear relationship to technical debt.

Software platform providers are often seen as the cornerstone of their business ecosystem, where the other ecosystem players utilize the platform’s standardized components together with complementary components for making applications. These platforms are also becoming a cornerstone of the emerging Internet of Things (IoT) business ecosystem comprised of the companies who provide Internet-enabled devices, applications, connectivity solutions, and the platforms for the IoT usage. While a number of enabling technologies for IoT is available, the question remains what kind of ecosystem emerges around IoT platform providers and whether this ecosystem is evolving in line with the theoretical models describing business ecosystem development. In order to address this question, we constructed a network model for the IoT ecosystem and considered how it had changed over the period of a year and a half. Our findings indicate that the ecosystem is still in early evolutionary phase, although some signs of consolidation are starting to appear. A mainstream solution is still missing and many vendors are trying to make their platform a dominating one.

In today’s product software market, the practices of re-use, partnering and 3^rd party contracting give rise to complex software ecosystems. Over the duration of a product life-cycle, product software vendors build up relationships with their suppliers and other partners, which range from informal acknowledgements of each other’s presence to strategic alliances. There is still a lack of understanding surrounding the roles, connections, relationships, and resulting networks within software ecosystems. Using modelling techniques and statistical analysis, these networks can be used as tools to further that understanding. In this paper a collection of 67 software supply networks will be modelled as a network graph. Using clustering and two extensions of basic software supply network data, we identify several major players and domains in the Dutch software industry. Three business strategy perspectives are then related to the data to provide an example of their potential practical use.

Traditionally, software engineering has been dominated by stand-alone development organizations and collaborations between contractors, integrators and suppliers. In the last decade, the notion of software ecosystems has been established as a new paradigm in software engineering. In its essence it proposes participative engineering across independent development organizations centered on a common technology.

This paper reviews the current state-of-the-art and presents a first step towards a typification of successful software ecosystems. We discuss key characteristic of the ecosystem types and present a set of example cases. The characterization reviews and consolidates existing research and discusses variations within the key building block of a software ecosystem. It further enables sharpening the borders of what an ecosystem is (and what not) and how the individual types can be differentiated. Thus, this paper contributes to widening the understanding of software ecosystems and serves to prepare a software ecosystem taxonomy.

Context. Innovation is promoted in companies to help them stay competitive. Four types of innovation are defined: product, process, business, and organizational. Objective. We want to understand the perception of the innovation concept in industry, and particularly how the innovation types relate to each other. Method. We launched a survey at a branch of a multi-national corporation. Results. From a qualitative analysis of the 229 responses, we see that the understanding of the innovation concept is somewhat narrow, and mostly related to product innovation. A majority of respondents indicate that product innovation triggers process, business, and organizational innovation, rather than vice versa. However, there is a complex interdependency between the types. We also identify challenges related to each of the types. Conclusion. Increasing awareness and knowledge of different types of innovation, may improve the innovation. Further, they cannot be handled one by one, but in their interdependent relations.

This paper surveys work on ecosystems and open innovation of systems in the context of software engineering for embedded systems. The primary research goal is to develop a research agenda based on the topics identified within the research publications on the topic. The agenda is based on a systematic mapping study of 260 publications obtained from digital libraries and is influenced by a set of areas of interest, i.e., product lines, open source, third party, business models, open innovation, and strategy. The results from the study include analysis of the type of research conducted in the field, its origin and research contribution. The study identifies the need for more solutions to specific open innovation problems such as mapping business models to technical platforms; defining open ecosystem processes that foster open innovation; and improving how ecosystem players can leverage on tool support for open innovation. A direction for future research is also provided.

Ecosystems are an important aspect of today’s software business, and can be beneficial to companies that can create and organize such ecosystems around their products. Unfortunately, creating such ecosystems is not an easy task. The value blueprint is a tool created by Adner, that allows a company to identify the different types of risks to be faced during the establishment of an ecosystem. In this paper we describe a case study conducted to assess the value blueprint as an effective tool to help in the design of new ecosystems. This case study is based on data about the Apple Watch. We report our evaluation of the value blueprint tool and provide recommendations for practitioners interested in establishing their own ecosystems and researchers interested in the design of ecosystems.

This paper contains an empirical analysis of acquisition dynamics in the electronic design automation (EDA) industry. Using qualitative and quantitative data, we show that particular groups of EDA firms strongly contribute to acquisition activity in the industry at specific times. Based on this we provide empirical evidence that specialized firms pursue focused and ‘defensive’ acquisitions during times of uncertainty, indicating that concentration on existing competencies is preferred over diversification into promising new, but unfamiliar markets.

The benefits and barriers that software development companies face when moving beyond agile development practices are identified in a multiple-case study in five Finnish companies. The practices that companies need to adopt when moving towards innovation experiment systems are recognised. The background of the study is the Stairway to Heaven (StH) model that describes the path that many software development companies take when advancing their development practices. The development practices in each case are investigated and analysed in relation to the StH model. At first the results of the analysis strengthened the validity of the StH model as a path taken by software development companies to advance their development practices. Based on the findings, the StH model was extended with a set of additional practices and their adoption levels for each step of the model. The extended model was validated in five case companies.

Globally distributed software development projects are on the rise. However, 69% of cross-regional projects fail completely or partially, because of lack of cross-cultural understanding. This paper presents a qualitative study of the impact of communication on Global Software Development (GSD) within firms due to cultural differences. In particular, we provide a model of problems and solutions related to communication of German/Chinese and American/Chinese collaborations in GSD. The model was derived using grounded theory to study six globally distributed software development projects. The results may not only help companies understand cultural problems, but also help them overcome these problems. To this end, we discuss the solutions adopted by the multinational software companies that we studied.

In many companies, product management struggles in getting accurate customer feedback. Often, validation and confirmation of functionality with customers takes place only after the product has been deployed, and there are no mechanisms that help product managers to continuously learn from customers. Although there are techniques available for collecting customer feedback, these are typically not applied as part of a continuous feedback loop. As a result, the selection and prioritization of features becomes far from optimal, and product deviates from what the customers need. In this paper, we present a literature review of currently recognized techniques for collecting customer feedback. We develop a model in which we categorize the techniques according to their characteristics. The purpose of this literature review is to provide an overview of current software engineering research in this area and to better understand the different techniques that are used for collecting customer feedback.

Software-intensive product companies are becoming increasingly data-driven as can be witnessed by the big data and Internet of Things trends. However, optimally prioritizing customer needs in a mass-market context is notoriously difficult. While most companies use product owners or managers to represent the customer, research shows that the prioritization made is far from optimal. In earlier research, we have coined the term ‘the open loop problem’ to characterize this challenge. For instance, research shows that up to half of all the features in products are never used. This paper presents a conceptual model that emphasizes the need for combining qualitative feedback in early stages of development with quantitative customer observation in later stages of development. Our model is inductively derived from an 18 months close collaboration with six large global software-intensive companies.

Along with the connected car, previously isolated business models of traditional goods-producing industry melt together with those of software businesses. It is becoming apparent that software businesses may have to play an important role, provided that they are capable of building up competencies in engineering business models for this emerging and converged market. We identify and cluster business model patterns that we rate as being capable of transforming product innovations, enabled by abilities and characteristics of cyber-physical systems and the underlying technical platforms, into business model innovations. We discuss further the pattern cluster Data Orchestrator.

The transformation of physical products into product service systems offers possibilities for delivering benefits to customers and increases the value for them to use the products. Therefore these products are charged with services [1]. This transformation is not only a chance but also a challenge for several industries – not only but especially in Germany where automotive manufacturers and machine manufacturers as long as the ecosystems of these industries account for a huge part of the gross national product (GNP) [2].

The High-Tech Strategy which was developed by the German Federal Government in 2011 including the future project Industry 4.0 was initiated to promote informatization of manufacturing technology and to pave the way for intelligent production and thus intelligent factories. The goal of Industry 4.0 is to ensure the future viability of the German manufacturing economy through digitization, so that this economy plays a leading role in the international environment in the future [1].

Most enterprises producing and offering high-end customized products face major internal communication and alignment issues. Typically, these occur in the context of individual projects within the organization consisting of various sites, plants or other points of operation (e.g., engineering companies, customer sites,…) where valuable experience and knowledge is gained. The source of the issues is that projects are conducted within a project team’s horizon and are not supported by a systematic and easy-to-use way of reusing knowledge gained in the past. This is confirmed by the statement of Mr. Banus, Country Business Unit Head Compression at Siemens Nederland NV, saying that “[Every project] has to start from an empty paper towards a package, but following a formalized procedure”. Especially in customisation projects, where every project team is continuously developing new product features, new processes, or handling the use of diverse materials, the knowledge alignment issue leads to the frequently occurring problem of re-inventions and re-developments [2]. Referring to Nonaka-Takeuchi’s SECI model [8], there are established theories of how to improve and persist organizational knowledge. However, in the large organizations we visited there is currently no satisfactory systematic way to store existing knowledge gained in previous projects. For example, files are often stored in a variety of ways, and most of the company’s intellectual capital is under-used or even lost. There are existing content management systems (CMS) like Livelink [4], Microsoft SharePoint [5] and ShareNet [10] that have already existed for years, but none meets and exploits the needs of global enterprises. This mismatch leads to the conclusion that organizations face the central problem of poor knowledge sharing, leading to repetitive and costly re-inventions of the wheel [2].

Using existing software components is a key factor when it comes to increasing productivity and improving the quality of software. It can be regarded as a mean to manage the increasing complexity of software, as software has become prevalent in most areas of our life. Thus, this study seeks to better understand the reuse of external software components. Based on two different theoretical lenses, non-rational effects on decision-making and the transaction cost theory, we analyze the degree of external reuse in software development projects. We tested our theoretical model empirically, with data collected in Germany. The empirical evidence is generally supportive of the theory with some exceptions. We find out that the not-invented-here bias plays the most important role in this strategic decision. Whereas, transaction cost constructs show mixed results. For example, technical uncertainty does not play a role, whereas business uncertainty positively influences the degree of external reuse.

Independent software vendors need to grow beyond their domestic markets. Software producing organizations are faced with a great number of options and opportunities on how they choose to conduct internationalization. Interestingly, efforts conducted have a high failure rate and software companies rarely succeed at first. In this paper we present a systematic mapping study and the results of 20 interviews with CEOs in the Dutch software sector. This study highlights the most important decisions made during the process of internationalization: the drivers, the process planning, market selection, and the followed market entry strategy. The choices available to the key decision makers in the right market selection and entry strategy are most strongly influenced and limited by the product architecture, characteristics of the product and company, and the level of internationalization experience located within the independent software company. The findings from this research support decision making in internationalization projects by software firms and policy makers in finding support strategies for export missions.

This paper addresses the factors that determine the survival of young software firms and startups. It specifically focusses on the role of venture capital and organizationally radical innovation in this. The interaction of venture capital investment with the type of innovation pursued by the software firm is shown to jointly increase survival in terms of time to acquisition.

This paper offers blueprints for and reports upon three years experience from teaching the university course “Lean Software Startup” for information technology and economics students. The course aims to give a learning experience on ideation/innovation and subsequent product and business development using the lean startup method. The course educates the students in software business, entrepreneurship, teamwork and the lean startup method. The paper describes the pedagogical design and practical implementation of the course in sufficient detail to serve as an example of how entrepreneurship and business issues can be integrated into a software engineering curriculum. The course is evaluated through learning diaries and a questionnaire, as well as the primary teacher’s learnings in the three course instances. We also examine the course in the context of CDIO and show its connection points to this broader engineering education framework. Finally we discuss the challenges and opportunities of engaging students with different backgrounds in a hands-on entrepreneurial software business course.

Background – Startup companies are becoming important suppliers of innovative and software intensive products. The failure rate among startups is high due to lack of resources, immaturity, multiple influences and dynamic technologies. However, software product engineering is the core activity in startups, therefore inadequacies in applied engineering practices might be a significant contributing factor for high failure rates. Aim – This study identifies and categorizes software engineering knowledge areas utilized in startups to map out the state-of-art, identifying gaps for further research. Method – We perform a systematic literature mapping study, applying snowball sampling to identify relevant primary studies. Results – We have identified 54 practices from 14 studies. Although 11 of 15 main knowledge areas from SWEBOK are covered, a large part of categories is not. Conclusions – Existing research does not provide reliable support for software engineering in any phase of a startup life cycle. Transfer of results to other startups is difficult due to low rigor in current studies.

Software as a Service (SaaS) development projects run for an unbounded amount of time, and it is important to continuously offer customers increased value from using the solution. Otherwise, a one-time payment for using a similar product would appear more attractive. Uncritically implementing value-adding ideas might however not always be in accordance with the business interests of the SaaS development company. We take a look at a small software development company with a SaaS business model and propose an approach to facilitate coordinated innovation on two levels: Business model and software development. We use the approach on an ongoing case from this company. Our results indicate that the case has benefitted from using the toolset presented here. The approach is designed for small SaaS companies with 5-10 developers using agile development methods.

The health of a software ecosystem is argued to be a key indicator of well-being, longevity and performance of a network of companies. In this paper, we address what scientific literature actually means with the concept of ‘ecosystem health’ by selecting relevant articles with systematic literature review. Based on the final set of 38 papers, we found that despite a common base, the term has been used to depict a wide range of hoped characteristics of a software ecosystem. However, the number of studies addressing the topic is shown to grow while empirical studies are still rare. Thus, further studies should aim to standardize the terminology and concepts in order to create a common base for future work. Further work is needed also to develop early indicators that warn and guides companies on problems with their ecosystems.