Software Producing Organizations Research Articles

Harmonizing DevOps taxonomies — A grounded theory study

Context:DevOps responds to the growing need of companies to streamline the software development process and thus has experienced widespread adoption in the past few years. However, the successful adoption of DevOps requires companies to address important cultural and organizational changes. Nevertheless, it is crucial to recognize that various DevOps taxonomies exist, both from academic and practitioner perspectives, which may lead to misleading or failed adoption of DevOps. Objective:This paper presents empirical research on the structure of DevOps teams in software-producing organizations. The goal is to better understand the organizational structure and characteristics of teams adopting DevOps by harmonizing the existing knowledge. Methods:To achieve this, we employed a grounded theory approach with collaborative coding, involving two research groups. Inter-Coder Agreement (ICA) was utilized to guide the discussion rounds. We conducted a comprehensive analysis of existing studies on DevOps teams and taxonomies to gain a deeper understanding of the subject. Results:From the analysis, we built a substantive and analytic theory of DevOps taxonomies. The theory is substantive in that the scope of validity refers to the ten secondary studies processed and analytic in that it analyzes “what is” rather than explaining causality or attempting predictive generalizations. A public repository with all the data related to the products resulting from the analysis and generation of the theory is available. Conclusions:We built a theory on DevOps taxonomies and tested whether it harmonizes the existing taxonomies, i.e., whether our theory can instantiate the others. This is the first step to define which taxonomies are best suited to approach DevOps culture and practices according to the companies’ objectives and capabilities.Editor’s note: Open Science material was validated by the Journal of Systems and Software Open Science Board.

A Theory of Organizational Structures for Development and Infrastructure Professionals

DevOps and continuous delivery have impacted the organizational structures of development and infrastructure groups in software-producing organizations. Our research aims at revealing the different options adopted by the software industry to organize such groups, understanding why different organizations adopt distinct structures, and discovering how organizations handle the drawbacks of each structure. We interviewed 68 carefully-selected IT professionals, 45 working in Brazil, 10 in the USA, 8 in Europe, 1 in Canada, and 4 in globally distributed teams. By analyzing these conversations through a Grounded Theory process, we identified conditions, causes, reasons to avoid, consequences, and contingencies related to each discovered structure (segregated departments, collaborative departments, API-mediated departments, and single department). In this way, we offer a theory to explain organizational structures for development and infrastructure professionals. This theory can support practitioners and researchers in comprehending and discussing the DevOps phenomenon and its related issues, and also provides valuable input to practitioners' decision-making.

API-m-FAMM: A focus area maturity model for API Management

Organizations are increasingly connecting software applications using Application Programming Interfaces (APIs) to share data, services, functionality, and even complete business processes. However, the creation and management of APIs is non-trivial. Aspects such as traffic management, community engagement, documentation, and version management are often rushed afterthoughts. In this research, we present and evaluate a focus area maturity model for API Management (API-m-FAMM). A focus area maturity model can be used to establish the maturity level of an organization in a specific functional domain described through a number of areas. The API-m-FAMM addresses the areas Lifecycle Management, Security, Performance, Observability, Community, and Commercial. The model is constructed using established methods for the design of a focus area maturity model. It is grounded in literature and practice, and was developed and evaluated through a systematic literature Review, eleven expert interviews, and five case studies at software producing organizations. The model is described in detail, and its application is illustrated by six case studies. The evaluations are reported on, and show that the API-m-FAMM is an efficient tool for aiding organizations in gaining a better understanding of their current implementation of API management practices, and provides them with guidance towards higher levels of maturity. The detailed description of the construction of the API-m-FAMM gives researchers an example to further support the available methodologies, specifically how to combine design science research with these methodologies. Additionally, this study’s unique case study design shows that maturity models can be successfully deployed in practice with minimal involvement of researchers. The focus area maturity model for API Management is maintained on www.maturitymodels.org , allowing practitioners to benefit from its useful insights.

The orchestrator's partner management framework for software ecosystems

• A research-based methodology to assess partner management in software ecosystems. • A classification of knowledge and activities regarding partner management. • A starting point for the development of theory regarding partner management activities. • Case study findings of partner management. In software ecosystems, partner management concerns establishing and maintaining meaningful relationships with partners to improve ecosystem health. At the same time, software ecosystem orchestrators have insufficient insight into partner management tools. Because of this, they fail in attracting and maintaining partnerships with software producing organizations, ultimately hindering their ability to build healthy software ecosystems. This research presents a classification for partner management activities to aid orchestrators in establishing and maintaining partnerships. We contribute (1) a methodology to assess partner management in software ecosystems, (2) a classification of knowledge and activities for partner management, and (3) a starting point for the development of theory regarding partner management activities. The classification and the activities are evaluated in five case studies of software platform orchestrators.

The organization of software teams in the quest for continuous delivery: A grounded theory approach

To accelerate time-to-market and improve customer satisfaction, software-producing organizations have adopted continuous delivery practices, impacting the relations between development and infrastructure professionals. Yet, no substantial literature has substantially tackled how the software industry structures the organization of development and infrastructure teams. In this study, we investigate how software-producing organizations structure their development and infrastructure teams, specifically how is the division of labor among these groups and how they interact. After brainstorming with 7 DevOps experts to better formulate our research and procedures, we collected and analyzed data from 37 semi-structured interviews with IT professionals, following Grounded Theory guidelines. After a careful analysis, we identified four common organizational structures: (1) siloed departments, (2) classical DevOps, (3) cross-functional teams, and (4) platform teams. We also observed that some companies are transitioning between these structures. The main contribution of this study is a theory in the form of a taxonomy that organizes the found structures along with their properties. This theory could guide researchers and practitioners to think about how to better structure development and infrastructure professionals in software-producing organizations.

Capturing software architecture knowledge for pattern-driven design

Context:Software architecture is a knowledge-intensive field. One mechanism for storing architecture knowledge is the recognition and description of architectural patterns. Selecting architectural patterns is a challenging task for software architects, as knowledge about these patterns is scattered among a wide range of literature. Method:We report on a systematic literature review, intending to build a decision model for the architectural pattern selection problem. Moreover, twelve experienced practitioners at software-producing organizations evaluated the usability and usefulness of the extracted knowledge. Results:An overview is provided of 29 patterns and their effects on 40 quality attributes. Furthermore, we report in which systems the 29 patterns are applied and in which combinations. The practitioners confirmed that architectural knowledge supports software architects with their decision-making process to select a set of patterns for a new problem. We investigate the potential trends among architects to select patterns. Conclusion:With the knowledge available, architects can more rapidly select and eliminate combinations of patterns to design solutions. Having this knowledge readily available supports software architects in making more efficient and effective design decisions that meet their quality concerns.

Decision Support for Blockchain Platform Selection: Three Industry Case Studies

Blockchain technology has received significant attention recently, as it offers a reliable decentralized infrastructure for all kinds of business transactions. Software-producing organizations are increasingly considering blockchain technology for inclusion into their software products. Selecting the best fitting blockchain platform requires the assessment of its functionality, adaptability, and compatibility to the existing software product. Novice software developers and architects are not experts in every domain, so they should either consult external experts or acquire knowledge themselves. The decision-making process gets more complicated as the number of decision-makers, alternatives, and criteria increases. Hence, a decision model is required to externalize and organize knowledge regarding the blockchain platform selection context. Recently, we designed a decision support system to use such decision models to support decision-makers with their technology selection problems in software production. In this article, we introduce a decision model for the blockchain platform selection problem. The decision model has been evaluated through three real-world case studies at three software-producing organizations. The case-study participants asserted that the approach provides significantly more insight into the blockchain platform selection process, provides a richer prioritized option list than if they had done their research independently, and reduces the time and cost of the decision-making process.

A focus area maturity model for software ecosystem governance

Increasingly, software companies are realizing that they can no longer compete through product excellence alone. The ecosystems that surround platforms, such as operating systems, enterprise applications, and even social networks are undeniably responsible for a large part of a platform’s success. With this realization, software producing organizations need to devise tools and strategies to improve their ecosystems and reinvent tools that others have invented many times before. In this article, the software ecosystem governance maturity model (SEG- M 2 ) is presented, which has been designed along the principles of a focus area maturity model. The SEG- M 2 has been designed for software producing organizations to assess their ecosystem governance practices, set a goal for improvement, and execute an improvement plan. The model has been created following an established focus area maturity model design method. The model has been evaluated in six evaluating case studies with practitioners, first by applying the model to their organizations and secondly by evaluating with the practitioners whether the evaluation and improvement advice from the model is valid, useful, and effective. The model is extensively described and illustrated using six desk studies and six case studies. The model is evaluated by both researchers and practitioners as a useful collection of practices that enable decision making about software ecosystem governance. We find that maturity models are an effective tool in disseminating a large collection of knowledge, but that research and creation tooling for maturity models is limited.

Analyzing and Managing Complex Software Ecosystems: A Framework to Understand Value in Information Systems

Managing complex software ecosystems, such as free open source software projects, is crucial for software-producing organizations. We present a framework that helps visualize complex ecosystem settings, gain insights on value engines, and describe relationships between the ecosystem partners.

Explaining the emergence of team agility: a complex adaptive systems perspective

Purpose Agile software development helps software producing organizations to respond to manifold challenges. While prior research focused on agility as a project or process phenomenon, the authors suggest that agility is an emergent phenomenon on the team level. The paper aims to discuss this issue. Design/methodology/approach Using the theory of complex adaptive systems (CASs), the study captures the multiple influencing levels of software development teams (SDTs) and their interplay with self-organization and emergence. The authors investigate three agile SDTs in different contextual environments that participate with four or more different roles each. Findings The results suggest self-organization as a central process when understanding team agility. While contextual factors often provide restriction on self-organization, they can help the team to enhance its autonomy. Research limitations/implications The theoretical contributions result from the development and test of theory grounded propositions and the investigation of mature agile development teams. Practical implications The findings help practitioners to improve the cost-effectiveness ratio of their team’s operations. Originality/value The study provides empirical evidence for the emergence of team agility in agile SDTs. Using the lens of CAS, the study suggests the importance of the team’s autonomy.

The hunt for the guzzler: Architecture-based energy profiling using stubs

ContextSoftware producing organizations have the ability to address the energy impact of their software products through their source code and software architecture. In spite of that, the focus often remains on hardware aspects, which limits the contribution of software towards energy efficient ICT solutions. ObjectiveNo methods exist to provide software architects information about the energy consumption of the different components in their software product. The objective of this paper is to bring software producing organizations in control of this qualitative aspect of their software. MethodTo achieve the objective, we developed the StEP Method to systematically investigate the effects of software units through the use of software stubs in relation to energy concerns. To evaluate the proposed method, an experiment involving three different versions of a commercial software product has been conducted. In the experiment, two versions of a software product were stubbed according to stakeholder concerns and stressed according to a test case, whilst energy consumption measurements were performed. The method provided guidance for the experiment and all activities were documented for future purposes. ResultsComparing energy consumption differences across versions unraveled the energy consumption related to the products’ core functionality. Using the energy profile, stakeholders could identify the major energy consuming elements and prioritize software engineering efforts to maximize impact. ConclusionsWe introduce the StEP Method and demonstrate its applicability in an industrial setting. The method identified energy hotspots and thereby improved the control stakeholders have over the sustainability of a software product. Despite promising results, several concerns are identified that require further attention to improve the method. For instance, we recommend the investigation of software operation data to determine, and possibly automatically create, stubs.

Energy efficiency on the product roadmap: An empirical study across releases of a software product

AbstractIn the quest for energy efficient Information and Communication Technology, research has mostly focused on the role of hardware.However, the impact of software on energy consumption has been acknowledged as significant by researchers in software engineering. In spite of that, due to cost and time constraints, many software producing organizations are unable to effectively measure software energy consumption preventing them to include energy efficiency in the product roadmap.In this paper, we apply a software energy profiling method to reliably compare the energy consumed by a commercial software product across 2 consecutive releases. We demonstrate how the method can be applied and provide an in‐depth analysis of energy consumption of software components. Additionally, we investigate the added value of these measurement for multiple stakeholders in a software producing organization, by means of semistructured interviews.Our results show how the introduction of an encryption module caused a noticeable increase in the energy consumption of the product. Such results were deemed valuable by the stakeholders and provided insights on how specific software changes might affect energy consumption. In addition, our interviews show that such a quantification of software energy consumption helps to create awareness and eventually consider energy efficiency aspects when planning software releases.

Software-As-A-Service: Implications for Business and Technology in Product Software Companies

Many software organizations are currently transitioning from an on-premises deployment model to the Software as a Service (SaaS) model. If a company restricts changes only in the business or technical perspective, the transition leads to higher costs, poor adoption of the SaaS model, and in the worst case, the company can lose its business. Much literature focuses on changes within one domain and is generally also limited to one perspective. This paper provides stakeholders (i.e. product managers,and business managers) an integrated perspective (business and technological) with a comprehensive framework that covers changes in four domains: business/product structure, revenue logic, customer relationships, and partnerships. The applicability of the proposed framework is assessed with a case study of a large software product vendor. The paper also contributes by providing a new avenue to study SaaS, with an integrated perspective for the organizational transition period. For the industry, this paper suggests a way to assess the impacts of organizational transition towards the SaaS model. With this overview in hand, software producing organizations can use the comprehensive framework to successfully transition to become SaaS vendors.

Shades of gray: Opening up a software producing organization with the open software enterprise model

Software producing organizations are frequently judged by others for being ‘open’ or ‘closed’, where a more ‘closed’ organization is seen as being detrimental to its software ecosystem. These qualifications can harm the reputation of these companies, for they are deemed to promote vendor lock-in, use closed data formats, and are seen as using intellectual property laws to harm others. These judgements, however, are frequently based on speculation and the need arises for a method to establish openness of an organization, such that decisions are no longer based on prejudices, but on an objective assessment of the practices of a software producing organization. In this article the open software enterprise model is presented that enables one to establish the degree of openness of a software producing organization. The model has been evaluated in five interviews, is illustrated using three case studies, and shows that organizational openness and transparency are complex variables, that should not be determined based on belief or prejudice. Furthermore, the model can be used by software producing organizations as a reference for further opening up their business, to stimulate the surrounding software ecosystem, and further their business goals.

Software architectures: Blueprint, Literature, Language or Decision?

This study questions the traditional view of software architecture as a specification that needs only be understood by software architects and engineers. Based on an intensive study of three software-producing organizations, we identify multiple metaphors (‘Blueprint,’ ‘Literature,’ ‘Language’ and ‘Decision’) that stakeholders use to understand the term software architecture, which in turn, allows them to effectively participate in its creation and use. Our results point to new research directions that may better encompass a broader view of software architecture.