Not the holly supper, but a gathering of experts from several information and social scientific domains. The discussion stream is published below:
Question 1
What is missing from the EISB picture? Where do you think we should put more effort? *
David Chen: "We need MEASUREMENT methods. Also, what are NOT EI problems"
Lars Taxen: "You will have to select, to pickout things from EI SB". Sort out the "EISB picture"
Petra Ahrweiler: " the key will be in collaboration with other communities and further justification"
Question 2
What would you need as a researcher, industry representative, SME to get convinced? What is your opinion on how enterprises should be approached to collaborate / adopt the EISB?
Antonio Grillo: "You need a killer app - something socking. A way to demonstrate - simulate - convince !"
Arne Berre: "We need to create a 'package' with EISB offerings and put it into the big picture"
Arne Berre on the 3-top EISB elements: (1) best practices leading to immediate results (put online)
... and link to projects, solutions, contact points, to the 'big picture'
Arne Berre on the 3-top EISB elements: (2) convince communities and funding ORGs
David Chen: "We cannot 'sell' the EISB as a science. Industries need practical methods to solve real problems"
David Chen: "Maybe you should wait to 'sell' results of the Science (the final thing - if there) and not the scientific base"
Lars Taxen: "EISB should have an aspect of training / guidelines"
Lars Taxen: "Research wise, the EISB should be made more robust, using existing formal methods and tools"
Petra Ahrweiler: "3 cases in SCM and their analysis, together with a what-if analyser (excel). But, calculate EUR. And get industry support."
Question 5
Laws are generally applicable observations or guidelines ("do’s and don’t") which are grounded in observation and rationalisation from cases. Such laws must be confirmed and broadly agreed upon through the process of inductive reasoning.
Arne J. Berre (to All - Entire Audience):
For ideas about laws - there are some current discussions about laws for software engineering that could be similar.
Arne J. Berre (to All - Entire Audience):
See The
Grand
Unified
Theory
of
Software
Engineering,
http://books.google.com/books?id=TLcceL3NEiMC
Arne J. Berre (to All - Entire Audience):
See also Software engineering method and theory at www.semat.org
Me (to All - Entire Audience):
Lars Taxen: "Laws ... are difficulkt. Maybe is better to talk about observations"
Me (to All - Entire Audience):
Pierluigi & Yannis: "top-down or bottom-up" in order to make a law ? - both
Me (to All - Entire Audience):
An observation: "Human intervention or need for human action in any step of a service brings completion time at the level of minutes - hours - days - months -> .... Full interoperation of digital services and systems bring completion times at the levels of seconds -> milliseconds -> nanoseconds -> ...."
Me (to Fenareti Lampathaki - Private):
Lars Taxen and Pierluigi A. : "Difference is not the problem (that "causes" lack of interoperability). Ignorance on ways and tools to overcome difference is the problem ...
Me (to Fenareti Lampathaki - Private):
A law must also have some practical results
Me (to Fenareti Lampathaki - Private):
Petra Ahrweiler: "Laws in sociology look like very abstract forms. Laws in networks might be bettter field to look around"
Arne J. Berre (to All - Entire Audience):
See the book here:
Arne J. Berre (to All - Entire Audience):
http://www.e-booksdirectory.com/details.php?ebook=4487