After decades, the role of software-intensive business solutions is still growing in our society. There are many researchers and practitioners whose work is related to the field of software-intensive business.
An Approach for Software-Intensive Business Innovation Based on
Non-software-Intensive Companies
1 Introduction
Recently, several studies have proposed models to describe experimentation in software-intensive contexts (e.g. RIGHT [4] and HYPEX [5]). Our results showed that the company succeeded in creating software-intensive innovations that support the usability of the framework.
2 Background and Related Work
This study will therefore be guided by the following research question: How can software-intensive business innovation be pursued in a non-software-intensive company. Nevertheless, to our knowledge, there is no systematic approach to performing software-intensive innovation in non-software-intensive firms, highlighting the research gap we delve into.
3 Experiment-Driven Business-Oriented Innovation Approach
Roles
Sveningson et al. [9] investigated the use of continuous experimentation in companies with low roadmap control. The authors argued that there is a relationship between the control of the guide and the distance from the users in the use of continuous experimentation.
Steps
When the innovation team judges that the solution has been sufficiently explored, it follows to the final step: analyzing the results achieved. In this scenario, the innovation team should keep the knowledge gained in the project in a way that can be used in the future, and preserve valuable findings through the application of Knowledge Management techniques.
4 Case Study
Units of Analysis
After validation, it was integrated into the recruitment portal mentioned in the previous paragraph. The automation of this distance calculation is currently being used in the recruitment process and is being considered as the next step to optimize the workplace of the current employees.
5 Discussion and Conclusions
We intend to implement the same process in other companies, with the aim of generalizing practices, and identifying problems that may arise in a different context. Another future study could identify the differences and idiosyncrasies of non-software-intensive companies that are relevant to innovation projects.
The images or other third-party material in this chapter are included in the chapter's Creative Commons license, unless otherwise indicated in a credit line for the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by law or exceeds the permitted use, you must obtain permission directly from the copyright holder.
Practices for Early-Stage Startups
Below, we oppose this argument by arguing that innovation and market-driven are necessary and sufficient elements to characterize startups.
2 Necessity: Innovation and Market-Driven Context as a Challenge for Software Development in Startups
In a divisive paper, Klotins [10] argued that there is no characteristic unique to startups that is not observed in other teams that develop innovative, market-driven, software-intensive products.
3 Sufficiency: Innovation on Software-Intensive Market-Driven Products as Startups
4 Current Proposals and Future Directions
Our goal is to further explore our hypothesis by collecting data from initiatives in large organizations as well as from early-stage startups. Confirming our assumptions, we will work on a set of software engineering practices for these teams.
5 Conclusions
However, there is a lack of understanding of the ICO phenomenon, especially in relation to the business aspects. We are not aware of any integrative research on the platformization of consulting business. Hurni, T., Huber, T.: Intertwining power and trust in enterprise application software industry platform ecosystems.
NPT enables us to unpack the dynamic nature of large-scale agile transformations by focusing on the social organization of work (implementation) of making practices routine elements of everyday life (embedding), and of maintaining embedded practices in their social context (integration). The main explanation lies in the development of a shared mental model during the first phases of the project. Bass, J.M.: Future trends in agile at scale: a summary of the 7th international workshop on large-scale agile development.
Fulfilling the Product Owner role has been identified as critical to project success in large-scale environments. Anderson, N., West, MA: The Team Climate Inventory: Development of the TCI and its applications in team building for innovationness.
Migrations
We were able to significantly reduce these degradations by 1) instrumenting the application code for tracing purposes, 2) identifying the cause of the degradation in various third-party libraries and some sections of legacy code, and finally, 3) refactoring parts of the application architecture code and using third-party libraries.
2 Application and Migration Goal
In addition, to compare the behavior and responses of the migrated API with the original one, we have created and continuously expanded a rich set of end-to-end regression tests.
3 FaaS Migration Approach
Na¨ıve Migration
Regression Detection
We were able to quickly identify the root causes of the observed performance degradation based on the information gathered. In particular, we noticed that in the initial, close approach, the API implementation took considerable time to (re-)initialize certain libraries on every single request. Large portions of this initialization overhead can be attributed to Flask and the Cassandra driver.
Accordingly, the inefficient pattern of continuous reinitialization for both Flask and the Cassandra driver was a specific subject of refactoring, which is further described in the next section.
Refactoring
Precalculation: Based on a more in-depth analysis of the execution times, we identified that initializing both Flask and the Cassandra driver still created significant performance impacts during cold starts. Strip: To address the Cassandra driver performance issues, we noticed that the Cassandra driver was not being used for every request. So we decided to remove the Cassandra manager by splitting the Flask API into two functions.
However, to significantly reduce Cassandra-related overheads for time-series API methods, we would have had to replace or rewrite the Cassandra library.
4 Migration Tactics
It implies additional development effort and may modify the application on an architectural level. This tactic has no prerequisites and great potential for improvement, but can incur significant development costs. In addition, we argue that a high degree of automation is feasible to significantly reduce the development effort for the various tactics.
We argue that future work should discuss and provide guidance on the various associated trade-offs.
5 Conclusion
Kuhlenkamp, J., Werner, S., Tai, S.: If and but less is more: a serverless computing reality check. The study analyzing the impact of memory latency and memory bandwidth on workload performance is described in [3]. Memory Bandwidth Usage – exposed by Linux file system 'resctrl', data source is Intel RDT Memory Bandwidth Monitoring technology.
Memory bandwidth utilization – exposed by the CPU Performance Monitoring Unit (of the integrated memory controller), can be calculated from events collected, for example via the Linux perf tool.
Serverless Context
These efforts, and especially parallel development efforts to create WASI-compatible runtimes that can run in a variety of environments, are creating new opportunities and use cases for WASM, one of which is serverless. Serverless solutions today are closely related to Docker containers; WASM could provide an alternative or complementary runtime environment that is lightweight, works well with different developer toolchains, and could potentially be used on a variety of serverless platforms. 2 is a brief comparison of the different WASM runtimes that can be used on the server side.
This is followed in Section 3 by a discussion of various solutions for running WASM within serverless platforms.
2 Evaluation of Serverside WASM in Different Runtimes
Much of this work has been consolidated as part of the Bytecode Alliance's work in developing aWeb Assembly Systems Interface (WASI)3, which is a set of APIs available in the WASM runtime that can provide POSIX-style capabilities (file system access , network access, process management, etc.). Having some insight into how we might make this happen is the focus of this work. Figure 1 shows the time required to determine whether a large number is prime using different approaches.
It is also interesting to note that the time difference between the WASM executables and native C is not huge, with the WASM executables taking about 20% longer than natively compiled code.
3 Running WASM in Serverless Context
Therefore, the initial focus was on the problem of getting WASM code to work in docker container running in different serverless platforms using wasmeras the WASM runtime. The first approach to address the problem focused on using a Python-fles10 wrapper around the WASM executable; the wrapper provides hooks into the serverless platform, which provide a small number of HTTP endpoints that the platform can call to initialize the serverless function and to enable it with certain input parameters. To compare the different solutions, a simple WASM file was generated that performed a calculation of the 42nd number in the Fibonacci sequence.
The time taken to execute this function when implemented via the Docker/Python solution was compared to that of thenode.jssolution on different platforms.
4 Conclusion
For example, in 2020, management and leadership commentators report that we are in "the age of agile" and "without agile, human-centered organization is not possible at all"[2]. Recognise, identify and manage change fatigue Continually assess agility, set expectations, i.e. the time it takes, being a journey not a destination, etc. Focusing on agile transformation at the organizational level, the second panelist, Helen Sharp (The Open University, UK ) reflects on the drivers for transformation and the choices to be made (where/how to start? what to transform?).
It's a new thing...so everyone's trying to learn...the Scrum Master is new, so he has to learn more, the Product Owner has to learn about it, and of course all other parts of the organization...to get even with to communicate with each other." (software developer). To answer our research question – how to manage control in agile transformations – we reported findings from a cross-functional unit in the midst of an agile transformation. Our initial problematization therefore paves the way for future, more in-depth research contributions that examine each paradox - as an example of 'the dark side of Agile' - more closely.
![Table 1. Four coordination theories, adapted from [5]](https://thumb-ap.123doks.com/thumbv2/1libvncom/9201775.0/98.659.63.579.95.637/table-four-coordination-theories-adapted-from.webp)
