Service-oriented architecture (SOA) as an architectural style based on common principles and patterns such as Business Process Choreography and Enterprise Service Bus allows service engineers to effectively (re)organize and (re)deploy business processes, functional components, and information assets as business requirement-aligned and loosely-coupled software services. SOA is unique in that it aims at unifying various related, yet up to now largely isolated domains such as business process management, distributed computing, enterprise application integration, software architecture, and systems management.

Given the loosely coupled, heterogeneous, and dispersed nature of SOA, many of the assumptions underlying traditional approaches to software engineering are no longer valid; consequently, existing methods and tools have to be carefully revisited and possibly extended to be applicable to analysis, design, and construction of software services. Unfortunately, SOA research so far has mainly focused on runtime aspects such as protocol, container, and other middleware design. Initial research and development towards software service engineering has been conducted; however, there is a lack of comprehensive methods and tools consistently supporting all phases of software service engineering. Such methods and tools must be grounded both in scientific foundations and in industrial best practices.

It was the overall goal of this seminar to assess existing methods, techniques, heuristics, and practices from related fields such as requirements engineering, software engineering, Object-Oriented Analysis and Design (OOAD), Component-Based Development (CBD), and method engineering to harness SOA methods and tools and to define a road map for the creation of a unified software service engineering method. More precisely, the first objective of the workshop was to understand assumptions and impact of emerging runtime platform models on the engineering process, e.g., SOA principles and patterns such as loose coupling and programming without a call stack, ESB and service composition, Software as a Service (SaaS) and cloud computing, Web 2.0 and mashups, as well as mass programming.

Based on the results of this analysis activity, the second objective of the workshop was to define distinguishing characteristics of Software Service Engineering (SSE) and to assess the state of the art in SOA and service design methods. The third and last goal was to identify focus areas for future work and a roadmap for SSE. In particular, the following three questions were addressed: Are new methods and tools required? How can the existing body of knowledge in software engineering and SOA design be extended? Is method unification a la Unified Modeling Language (UML) [16] and Unified Process (UP) [12] desirable and feasible?

With this seminar we brought together researchers and practitioners from various industrial domains and research areas that work in the emerging field of software service engineering. In particular, we established linkages and enduring collaborations between the following three communities that operated in isolation before:

1. Requirements and software engineering including patterns.
2. SOA middleware and standards.
3. Industrial adopters of SOA .

The results of this seminar are core results in nature. During the seminar it became clear that the discipline of software service engineering is still in its embryonic phase, and further work is required in several directions. Firstly, the list of tenets has to be further explored, validated, and potentially refined or expanded. The presented list is derived from a literature survey, as well as expertise and experience from real-world SOA projects and discussions with leading industry experts and renowned researchers in the field of software engineering, software patterns and SOA; however, more case studies have to be analyzed critically to further validate this initial list.

As a follow-up activity, we have published the results of this seminar in an ICSE workshop paper [19]. The workshop paper extends the discussion in this executive summary and provides an example which illustrates the difference between SSE/SOA and traditional software engineering disciplines.