Science and Enginering

This week I presented an article at the DESRIST Conference in Las Vegas on the integration of IT and organizational design. This conference is the forum for Design Science research, which focus on the IT artefact and its process of construction. This community has its conceptual roots on Herbert Simon's work on the Sciences of the Artificial (1969).

I'm writing this post because I was struck by two different issues, a recurring discussion and an elegant formulation.

First the recurring discussion. During the two conference panels, it was referred the resistance of the academia to accept research on design. Fifteen years ago I remember being involved in similar debates in the context of the design patterns community. The design patterns community had a huge impact on software engineering. Today software developers use design pattern jargon to communicate their designs, the design patterns knowledge is part of the experts language. However, the design patterns community impact on academia is small and its publication outlets, the PLOPs conferences, are not the best forums to publish if you aim to get a PhD degree. Why this happen? An interesting article by Davenport and Markus (Rigor vs. Relevance Revisited: Response to Banbasat and Zmud, 1999) make it clear. Academia pursuit rigor (science) but has some difficult in accepting relevance (engineering) because of its "lack of rigor". Designing and building a system is a clumsy task which is difficult to assess. However, Davenport and Markus argue that the academia must find the means to reward the research on best practices. How? Well, the recurring discussions show that this is not an easy task.

On the elegant formulation, I was positively surprised by Alan R. Hevner formulation of design science research which integrates relevance and rigor in three feedback cycles (A Three Cycle View of Design Science Research, 2007).

Design Science Research Cycles (Hevner, 2007)

From a software engineering perspective, Hevner formulation covers from empirical software engineering, in the relevance cycle, to fundamentals of programming languages, in the rigor cycle. Besides, it gives design science a central role on bridging the gap between rigor an relevance.

I would not say that this perspective is the ultimate solution for the recurring discussions, but it provides  the lens through which we can view software engineering research, and design research in general.