Some months ago, Kelly Lyons recommended me as a panelist for a workshop at Cascon 2008 on “SOA Research Challenges: Current Progress and Future Challenges”, on the topic of Service Science, Management and Engineering. I found that Cascon workshops share existing knowledge and develop new knowledge — in contrast to paper presentations about completed work. The workshop was described in the following way:

This workshop will identify critical SOA research challenges that need to be addressed by the research community for SOA to fulfill its promise. The workshop will present a taxonomy of SOA research issues that will be used to frame the rest of the discussion. The workshop will focus on research needs that are currently causing the greatest pain for SOA practitioners. Topics will include “hard problems”, tooling issues, governance challenges, monitoring through the life cycle, and the longer-term evolution of SOA. The workshop will include presentations by practitioners and the research community in addressing critical unmet issues.

Most of the time, my research work and day job are only loosely coupled. In the Cascon context, my longer-horizon organizational and economic thinking was to be applied with more immediate question issues related to technology. I was given the following outline to as a suggestion for my talk:

• Overview of the topic, in this case SSME
• Why is it important to talk about this (rationale)
• How it relates to SOA
• What are current efforts in establishing this relationship
• Challenges and gaps. This could apply to SSME, SSME and SOA, and/or education/training for people developing service-oriented systems

I responded to the speaking opportunity with a new presentation. Some themes I’ve covered in previous talks, e.g. ICT capital, a new science of service systems, and T-shaped professionals. Some new ideas that I added were:

• An expansion from SSME to SSMED, as Service Science, Management, Engineering and Design: This is based on an upcoming article by Jim Spohrer and Stephen Kwan in IJISSS. In addition to the fields of science, management and engineering, the recognition of design – as an abductive mode of reasoning — can free us from constrained and legacy thinking to get “outside the box“. The rise of D-schools (i.e. design schools) was described in Business Week in 2005. In Finland, Aalto University is notable as an innovation university merging three institutions, previously distinct schools of economics, engineering and design.
• As an emerging new body of knowledge, SSMED has issues similar to those of SOA: the challenge may not be the end point, but instead the entry point. A few projects may have the benefit of starting as greenfield, but the most significant systems have a legacy currently operating — and often operating well. Russell Ackoff would describe this challenge as a mess, or problematique (i.e. a systems of problems).

During the workshop, I wrote up a digest as I listened to the other panelists. Some things that I learned during the afternoon were:

• As a new technology, a lot of the body of knowledge about SOA has been developed in the field. Academics have the opportunity to “catch up”, and validate some of the intuitions and practices in rigourous and scientific ways. A validated body of knowledge enables education in a more formal way. (It’s more effective to educate students in university programs, rather than situation by situation “on the job”).
• SOA was initially viewed as way to couple information systems asynchronously. The success of the architecture is driving demands towards coupling nearer to real-time, with a higher level of reliability. Modeling and designing for this context is more challenging.
• As SOA systems are becoming more dynamic, they’re dealing not only with the anticipated, but also the unanticipated. Design and governance for the unanticipated requires more thinking.
• Service Oriented Architecture is a style. Service Component Architecture is a specification, and Open SCA is under review by standards bodies. In nascent technologies, vendors may implement a style in a variety of ways. As the technology matures, convergence towards a standard improves productivity.
• Testing on SOA components is a matter of course, but testing of whole systems composed of SOA components is a hard problem. Finding out about failures at run-time isn’t the best way to instill confidence.
• The constraint on SOA adoption is the number of qualified and knowledgeable people. Making SCA models and implementations simpler are a promising way to speed up adoption.

Although I generally focus on the aspects of SSME that are human (social and economic) systems, the discussion of SOA reminds me that technical components are also systems. The challenges of SOA are also challenges of service systems.