In this paper, we propose a high level view of technological spaces (TS) and relations among these spaces. A technological space is a working context with a set of associated concepts, body of knowledge, tools, required skills, and possibilities. It is often associated to a given user community with shared know-how, educational support, common literature and even workshop and conference regular meetings. Although it is difficult to give a precise definition, some TSs can be easily identified, e.g. the XML TS, the DBMS TS, the abstract syntax TS, the meta-model (OMG/MDA) TS, etc. The purpose of our work is not to define an abstract theory of technological spaces, but to figure out how to work more efficiently by using the best possibilities of each technology. To do so, we need a basic understanding of the similarities and differences between various TSs, and also of the possible operational bridges that will allow transferring the results obtained in one TS to other TS. We hope that the presented industrial vision may help us putting forward the idea that there could be more cooperation than competition among alternative technologies. Furthermore, as the spectrum of such available technologies is rapidly broadening, the necessity to offer clear guidelines when choosing practical solutions to engineering problems is becoming a must, not only for teachers but for project leaders as well.
Yann-Gaël Guéhéneuc, 2014/02/04
A very intriguing paper, at the frontier between techologies, science, and education. The idea of a “technological space” is that of a “working context witg a set if associated concepts, body of knowledge, tools, required skills, and possibilities”. The paper gives several examples of such spaces, including (in Figure 2) MDA, XML, and AS. It also shows a comparison of these spaces based on seven characteristics. The objectives of defining and studying technological spaces is to give advice to developers when choosing the technologies encompassed by these spaces as well as making explicit the different trade-offs so that developers are not captive of their choices. They include also sharing best practices across spaces. The paper argues that research should focus on the frontiers among spaces as much as it focused on the content of each space.
The only limitations of this paper is that it does not clearly list all possible characteristics of the technological spaces: it provides seven of them without explaining where these characteristics come from. Also, it does not emphasise the importance of the bridges across spaces. Finally, it does not provide much “actionable” results although it is a very good start. I hope that in the near future, the authors will propose some in-depth study of some (few) spaces, making explicit their bridges and their pros/cons. They already mentioned the JUMP framework as one possible such bridge between the Java and the .NET spaces.