Consultation on Future Research Priorities on Software & Services

Welcome to the On-line Consultation process of the European Commission, DG Information Society and Media, Service and Software Architectures and Infrastructures Unit (INFSO D3). This is a consultation on the 7th Framework programme of Research and Development in Information and Communication Technologies.

Through this consultation process you are able to provide your input to the definition of the Work Programme for 2011-2013 in the field of software and services. This Work Programme will be the basis for the next calls of proposal in this area.

The forum-based consultation tool allows you to provide your comments, contributions and suggestions in a simple format. Inserted contributions can be publicly displayed on-line in one of two ways – either as an anonymous contribution or including your name and organisation. Or you can choose to include your contribution in the data provided to the EC but not be publicly visible on-line.

The consultation is now closed.For further information please contact sandro.delia (at) ec.europa.eu.

The European Commission services are pleased to acknowledge the facilities offered by ECSS for its consultation. ECSS will not filter or process the data that is submitted to this consultation, but will deliver it unchanged to the Commission.

• 2009-10-27 12:07:02
  In my opinion, an interesting research topic is related to the message flow analysis and presentation. There is an increasing attention about people message flow management (for example see Google Wave, https://wave.google.com/wave or Mozilla Weave and Raindrop, http://labs.mozilla.com/projects/) and similar approaches could be applied to service messages also. Even if the Cloud hosting environments offer API to monitor the status of the services, the message flow monitoring could contribute to give to the service administrators a single point of view on all their services, scattered among heterogeneous systems. The possibility to control the service message flow would allow a user to consider his/her service requests on the same level of mails, with search and filter capabilities. Moreover the development of a data flow analysis in service environments could open the way to other interesting experiments such as the use of infographics (http://en.wikipedia.org/wiki/Information_graphics) concepts in those contexts which could improve the user interaction; or the dynamic creation of services based on the requests and the expected responses.
• 2009-10-26 12:05:16
  In our opinion services development is strongly related to the customer environment; so we think that the interaction with customers and how to describe services should be understandable by them. we intend to do services development in interaction with customers (and most of the time at their premises) to be able to measure results and successes. So also the customer activities in this field should be fundable. what we have in mind with respect to content of our plans at least the following seem relevant: 1.the (change in ) user interest in paper based vs. electronic information gathering, handling and management. also the balance between the two will be relevant. 2. the way to describe these services both in customer as in ICT language 3. understanding what change in revenue model are possible/necessary 4. learning to realise that some functionality should be delivered by the own organisation and some by partners (which ones and why?)
• 2009-10-19 13:59:37
  Why Software Engineering is not Engineering Yet? Recently in the field of software engineering there is a rather diffused perception that traditional engineering thinking is not productive in the software field. In an oversimplified version, it is possible to state that Software Engineering may not be engineering after all. At least, not yet. In fact, the evolution from the waterfall model toward iterative, agile methodologies has stressed that the typical engineering view of planning everything from the beginning to pave a predictable, clear path to success cannot survive the high level of uncertainty that plagues the field of software production. It is a common experience to have components that, although perfectly compatible from the syntactical interface point of view, when integrated reveal unexpected and pathologically disruptive side effects. Some authors argue that this is a reason to move from engineering approaches toward economy like approaches based on a steer-as-you-go behavior, and this has actually had the benign effect of forcing software projects to integrate system parts as soon as possible to expose inconsistencies before a major scrap and rewrite effort is needed. Nonetheless, our position is quite the opposite: the solution is not to abandon the engineering approach because of high level of uncertainty in software component interaction, on the contrary, the solution lies in a deeper architectural knowledge of the system and the software platforms involved to greatly reduce the above mentioned uncertainty. A typical artifact of the engineering mindset is the use of black box components. To build a bridge, an engineer does not need to know all the nitty-gritty details of how a girder is built, he relies on the component data-sheet. This is a tried and true approach, nonetheless it shows an unpleasantly high failure rate when applied to software components. We argue that this is due to the fact that the equivalent of a girder data-sheet is a set of UML diagrams that describes only the formal aspects of the component with no relation to its architectural behavior (the “implementation is not an issue” tenet) and even those are strictly valid only as long as the component is used exactly in the expected way. Thus our position is that to achieve a true “Software Engineering” we need a new generation of component definition tools and a systematic study of the effects of run-time platforms on the behavior of software components.
• 2009-10-08 12:21:59
  In my opinion the ECSS white paper currently does not cover a fundamental aspect: the development of agile and dynamic composite applications. I try to briefly explain my statement. In a SOA ecosystem we can distinguish two main components: 1) a service exposure layer, 2) composite applications that execute business tasks using the services offered by exposure layer. The ECSS Whitepaper covers very well, in my opinion, the service exposure layer. However, if also the other component (composite applications) is not agile and dynamic the whole ecosystem won’t be. Here is an example: very often a composite application developed for a company (a Telco operator, an Insurance Company, a Bank, a Manufacturer) or for a public authority is strictly dependent on the characteristics of the specific products/services they offer to customers/citizens. The product/service business logic is often “hardcoded” in the programming code. Simple products/services characteristics can be described with some kind of parameterization but the complex ones require coding, today. This brings to long time-to-market, costs, inflexibility. BPM languages like BPMN and BPEL fulfil the need to describe business logic in terms of process activities to execute, but do not cover many other aspects (i.e. the intrinsic characteristics of products/services like interdependencies among optional product components, pricing, user presentation, billing, provisioning, shop floor control, …). I tried to explain this concept in my blog: http://mauriziobarioglio.wordpress.com/2009/05/19/bpm-is-a-too-tight-dress-on-soa/ . In my opinion researchers should investigate how to model complex business logic in order to obtain immediate IT solutions for the business specifications without software coding. I have in mind the CAD-CAM paradigm: as soon as you model an object you can produce it. Moreover business models should be non-procedural (explain “what” is required and not “how” to obtain it) in order to build dynamic adaptation to exceptions and therefore self-healing solutions. BPMN and BPEL are procedural, inflexible languages. As far as I know MDA covers only partially these requirements and focuses on code generation. In my opinion models should be directly executed and call existing, reusable SOA services. Moreover different aspects of business require different but consistent representations. A sort of “UML for business modelling” is in my dreams.
• 2009-09-22 16:40:16
  The cloud paradigm was mainly coinceived and implemented by industrial players. The IT scientific community had a secondary role in this area. The delay of the EU research community in this field should be overcome with a significant effort of EC and the scientific community cooperation by implementing R&D activities with a long term horizon that aim to provide new visions and solutions in the area of cloud computing and services. New models, architectures and services for inter-clouds for e-science, pervasive architectures embodying clouds and ubiquitous devices, and knowledge-oriented clouds must be designed to support disruptive solutions for future user communities and innovative ecosystems. Service oriented solutions able to address integrated uses of clouds and pervasive systems need to be addressed as contributions to Future Internet.
• 2009-09-18 09:39:50
  Software vendors lack the perspective to develop software within a software ecosystem. The inability to function in a software ecosystem has already led to the demise of many software vendors, leading to loss of competition, intellectual property, and eventually jobs in the software industry. In this paper we present a research agenda on software ecosystems to study both the technical and the business aspects of software engineering in vibrant ecosystems. The results of such research enable software vendors to develop software that is adaptable to new business models and new markets, and to make strategic choices that help a software vendor to thrive in a software ecosystem.