28 December 2012

Thesis chapter 3.1: Design research process

Blessing & Chakrabarti defines a design research process called the Design Research Methodology (DRM). The process emphasise the focus and goals of the research project, the study of factors contributing to the goals, the development of artefacts to support the goals, and the evaluation the developed artefacts (link).

The design process was scoped by the four stages of the DRM, seen in figure below, although the actual artefacts were developed in a nonlinear fashion. All four stages contributed to new learning, which is included in the respective chapters of the thesis.
The four stages of the Design Research Methodology by Blessing
and Chakrabarti

Criteria

The first stage in the design process defined the overall context, research questions and design goals based on cases~I-V in  together with selected problems form published literature, described in detail in chapter 2. Chapters 5 and 6 provides a rich insight into the industrial context of mass-produced embedded systems.

Descriptive Study I

The second stage investigated existing literature to further understand the problems, elaborated on evaluation criteria and guided to possible solutions, this is described in chapter 7. The aim of this investigation is to answer RQ1 and guide towards answers of answer RQ1.1 and RQ1.2.

Prescriptive Study

The third stage, the Prescriptive Study, investigated specific artefacts related to RQ1.1, RQ1.2, RQ1.3 and RQ1.4.
This resulted in a set of artefacts to achieve the goals and alleviate problems identified in the previous two stages. The artefacts fall into several categories of ways-of-working, model and architectures:
  • Chapter 7 describes a model of how individual teams interact with large projects, and based on this a method to facilitate a transition to agile development for individual teams.
  • Chapters 9 and 11 describe two architectures, for compositional architectures and embedded architecture for innovation experiment systems respectively.
  • Chapter 10 describes 5 activities to establish an open software ecosystem for MPES.

Descriptive Study II

The fourth stage evaluated the resulting artefacts, methods and ways-of-working in cases VI-VIII from the previous stage (also the focus of chapters 7, 9, 10 and 11).

Limitations

The artefacts were evaluated mainly through observational, analytical and descriptive methods as categorised by Hevner et al:
  • Observation through case studies
  • Architectural analysis of designed artefacts
  • Informed argument based on insider knowledge to show the artefact's utility
  • Scenarios describing the use of the artefact in the context
The evaluation was in all cases done qualitatively, i.e. answered that the design of the artefact works, not that it was optimal according to some quantitative measure.

The DRM process assumes an iteration of the last two phases to optimise the design of the artefacts against the design goals, in this project only one cycle was performed.

The set of artefacts is not sufficient for an organisation to evolve its R&D process, in practice there are numerous other factors affecting the efficiency of an R&D process at an OEM. Factors from almost every area of research, ranging from management theory via economics to semiconductor technology. The set of artefacts developed is thus shown to mitigate the investigated problems, but not necessarily solve them, at least not on their own.

27 December 2012

Thesis chapter 3: Research design and methodology

There are several research methods used when academia interacts with an industrial setting; experiments, design science or research, action research or participative case studies .

This thesis is in essence a design project; developing artefacts, processes and methods to create opportunities for business for embedded software in mass-produced systems in general, and automotive software in particular. Therefore design research was chosen as the research methodology.

26 December 2012

Thesis chapter 2.6: Research questions

To study the identified problems with software development of mass-produced embedded systems,  and at least partly solve, and to achieve the goals above a set of research questions was identified:
RQ1: What are the archetypical approaches for software development in the embedded domain?
RQ1.1 What ways-of-working in an R&D organisation for mass-produced embedded systems can create new options for business?
RQ1.2: What are the key properties of architectures for mass-produced embedded systems to create  business options?
RQ1.3: How can an OEM evolve the R&D process to support a transition from a closed to an open software ecosystem?
RQ1.4: How can an embedded architecture support innovation and delivery of new features of value to the customer?
The investigation of RQ1.1 support research goal G1 of leadtime reduction. The investigation of RQ1.2 and RQ1.4 support research goals G1, G2 and G3.

The project uses automotive software as a concrete example of mass-produced embedded systems. A question which might be answered during the project is if the context for the automotive industry regarding software development is so different it demands other ways-of-working and architectures compared to other business domains?

25 December 2012

Thesis chapter 2.5: Project goals


This research project started with the ambition to create opportunities provided by an R&D organisation in terms of new ways-of-working, new architectures, and possibly supporting new ecosystems. These opportunities could enable new business models for OEMs delivering mass-produced embedded systems.

This lead to three goals for an original equipment manufacturer aspiring to be world leading in software development:
  1. Minimise leadtime from idea to implementation of new software features.
  2. The ability to frequently deliver new software features to end customers
  3. Decoupling of software development from hardware and mechanical development, both in time and by the design dependencies

24 December 2012

Thesis chapter 2.4: Innovation

Innovative ideas for embedded products are typically collected and prioritized during the roadmapping and requirement management process as part of the yearly release cycle. This cycle is usually determined by manufacturing concerns of the hardware. Feedbacks on innovations from real customers are collected only on new product models, if collected at all.

Since more and more embedded products also are connected, it is conceivable to develop, deploy and measure usage on new software in iterations which lengths are determined by the speed of the software development teams instead of the setup of the manufacturing process, going from years to weeks.
Such an innovation experiment system (IES) would utilise feedback from real users of the embedded products in a scale comparable to the entire customer base. The notion of continuous innovation is not new (link to Ries, link to Bosch}, but the concept is novel in the embedded domain.

The driver for having such an IES is that business and design decisions should be based on data, not opinions among developers, domain experts or managers. The company running the most experiments among the customer base against the lowest cost per experiment outcompetes the others by having the decision basis to engineer products with outstanding customer experience.

The innovation experiment system focuses on incremental innovation according to the framework by Henderson and Clark. The short iterations of experiments are primarily aimed to refine and extend established designs. Improvement occurs in individual software parts, but the underlying design concept remain mostly unchanged, even if there is nothing that prohibits the evaluation of e.g. architectural innovations as well.

23 December 2012

Thesis chapter 2.3: Software ecosystem

Software ecosystems are characterised by a network of developers rather than a single organisation providing the final product to the customer. An example would be the app markets for Android and iPhone users, where 3rd party developers deliver applications directly to the end user based on a provided platform and through an established infrastructure and marketplace.

The strategic approach of developing software in an open ecosystem instead of as an integrator towards the customer is new in the domain of mass-produced embedded systems, but could provide some advantages also here, for example by extending the innovation base and sharing development risks.
The OEM would still play a vital role as keystone organisation in an open software ecosystem since it manufactures the product and delivers the platform underlying the ecosystem.