Implementation of the Design Science Paradigm Design Science ProcessDesign Science Process

This dissertation project follows the DS process model that was introduced in the last subsection except for one additional phase concerning the Metrics Operationalization and Testbed Implementation. Such efforts are also present in the model proposed by Peffers et al. (Peffers et al. 2008, p. 54), however, they are not explicitly presented as a distinct phase, which underrepresents their value to the overall process in my opinion.

The complete process as adopted for this thesis is shown in figure 1.3:

As a first step, the research problem has been identified (it has already been detailed in section 1.1): the lack of mechanisms for a comprehensive and fully automated dis-covery and flexible negotiation of SLAs in distributed settings such as the IoS. It has been deduced from a detailed scenario model for the IoS after investigating respective literature on service-based systems as well as the research problems stated within current national and international research projects.

The problem addressed in this thesis clearly fulfills at least some of the criteria Hevner et al. (Hevner et al. 2004) impose on a DS project. The complex nature of service-based settings and the intricate interactions and dependencies between the different components of the IoS can probably be seen as the most prominent one.

Next, the objectives for solution to the respective problem are stated in 2.1. They primarily originate in a thorough analysis of scientific literature about the stated scenario and research problem.

After the objectives for this DS project are defined, two basically independent phases can begin: the design and development of the actual artifact (i.e. the SLA management infrastructure) as well as the definition of the evaluation metrics and the testbed imple-mentation. These two phases have no actual contact points, so they can be conducted independently. The only requirement regarding the overall process is that the testbed, within which the designed and implemented artifact is to be assessed, must be finished before starting the demonstration and evaluation phases. The testbed used within this

6Having produced an expository instantiation does not necessarily render a design effort to be valid DS, as in the case of just having such an artifact without an appropriate theory of design “the level of knowledge is that of a craft-based discipline” (Gregor and Jones 2007, p. 329).

Problem

Figure 1.3.: Research Process applied for this Thesis

thesis is the IoS simulation toolkit SimIS (“Simulating an Internet of Services”)⁷ (K¨onig, Hudert, and Eymann 2010), which I co-developed. In parallel, the metrics to be used within the demonstration and evaluation phases, are derived on the basis of the research question and scenario definition at hand.

During the design and development of the actual artifact, the mechanisms and data structures needed for solving the stated research problem are defined and subsequently implemented in a proof-of-concept prototype.

Once both this expository instantiation as well as the testbed are finished, the demon-stration and evaluation steps are undertaken. To this end, the developed software com-ponents are deployed in a simulated IoS scenario (as parameterized using SimIS) and subsequently assessed regarding the requirements defined before.

Following Bucher et al., simulation is a valid evaluation (and demonstration) technique within DS whenever the application of a prototype in a real-world experiment is impos-sible (see for example Bucher, Riege, and Saat 2008; Hudert, Niemann, and Eymann 2010). This can be due to pragmatic (e.g. investigations on fluid behavior in the core of

7http://sourceforge.net/projects/simis

the sun), theoretic (e.g. what-if questions on different values for natural constants) or ethical reasons (Hartmann 1996, p. 87). In the case of this project a pragmatic reason is present, as a global IoS as I envision it, is still only a vision for future systems and not already implemented reality in IS. Initial steps towards this vision can already be observed in current infrastructures (for example SAP’s BusinessByDesign⁸, Enomaly’s SpotCloud⁹ or SalesForce¹⁰), but the comprehensive IoS vision in its entirety is not present yet. Simulation therefore represents an appropriate evaluation tool for exploring these scenario settings, “that cannot (yet?) be investigated . . . by experimental means”

(Hartmann 1996, p. 87).

As a conceptually last step the results of this project are communicated in the form of scientific publications (see Hudert (2006, 2009, 2010); Hudert and Eymann (2010, 2011a,b); Hudert, Ludwig, and Wirtz (2006, 2007, 2008, 2009); Hudert et al. (2009)) in both, the computer science and business communities, contributions to conjoint research projects as well with the publication of this thesis as a whole.

Resulting Design Theory

In order to describe all relevant input and (intermediate) results of my research project, the remainder of this thesis is primarily structured according to the research process just sketched. Nevertheless, I also tried to incorporate Gregor and Jones’ structure of a design theory when presenting my results. In the following I very shortly want to provide some overview information on where in this thesis which of the mentioned theory components can be found. These remarks can thus act as an alternative approach for an outline of this thesis and are supposed to guide the reader whenever she is particularly interested in a distinct aspect of the theory resulting from my work.

• The Purpose and Scope of my work can be found in section 1.1 and more particu-larly in 1.1.1, where my actual research goal is presented.

• Next, the Constructs used within this thesis are implicitly introduced in section 2.2. In this section also the Justificatory Knowledge is described as an input for my work and whenever a distinct construct, that is needed in the further thesis, is introduced, it is highlighted respectively.

• The main part of this thesis, the design of the SLA management infrastructure in chapter 3 basically comprises the Principles of Form and Function, whereas the Testable Propositions can be found in 4 as part of the demonstration and evaluation experiments.

• Also located in chapter 4 is the description of the implemented proof-of-concept prototype (Expository Instantiation).

8http://www.sap.com/germany/sme/solutions/businessmanagement/businessbydesign/index.epx

9http://www.spotcloud.com/

10http://www.salesforce.com

• The last two aspects of a design theory are concerned primarily with the time after the actual research process and are thus mentioned in chapter 5: A short guideline for how to use my system in a productive environment is given in 5.3 (Principles of Implementation) and finally the system’s capability to cope with changing environments and potential extensions to the system to increase this capability are sketched in 5.4 (Artifact Mutability).

In this chapter the objectives of my work as well as the conceptual foundations upon which this thesis builds are presented.