Researchers must develop an understanding of the subjective meaning of the participants' own understanding (Lee, 1991). This triangulation of data is important for the reliability of case study results (Yin, 2003). In the presentation of our research, we distinguish between observations and hypotheses (respectively analyzing data and generalization) to increase the transparency and traceability of the procedure, even though they are closely intertwined.
As part of the Ad-hoc DAta Grids Environments (ADAGE) project, researchers at the University of New South Wales (UNSW) have implemented a service-oriented architecture for SIRCA, a data provider. As the paper focuses on methodological aspects, we partially omit more detailed descriptions of the case study data. The members of the project team wrote a large number of published and unpublished articles during the project.
Based on the collected case study data, we first aim to explore the subjective understanding of project members. Our observations attempt to structure the subjective meanings found in the raw data and support the perception of the project situation. In the following, we present our hypotheses and describe how the generalization and aggregation of observations is performed using the abstraction mechanisms described in Section 2.3.
The understanding of services affects both the fragmentation of services and the direction of the service identification approach.
The general context significantly influences the method of SOA development and service identification
By applying the classification of abstraction mechanism, we can generalize our concepts (instances) by determining abstract categories (types). For example, the category company size is the result of classification of the observed concept small company. The concept ADAGE context created by aggregation is transformed into the category general context by classification.
In particular, the aggregation that summarizes several concepts for the ADAGE context necessarily moves away from subjective meanings that served as a starting point for our analysis. Our observations show that the combination of a small company and employees with limited skills (which trumps the possibilities of a generous budget) leads to an absence of formal methods in service identification. This is in line with the subjective understanding of the project members (see 3.4) and certainly an extreme case.
However, it seems plausible to assume that contextual factors have a significant influence on the way services are identified. In what follows we will discuss the underlying mechanisms. So, for example, we can tentatively assume that large companies with highly skilled workers will use different methods for SOA development and service identification.
SOA project experience leads to a different understanding of services and thus affects success measures
The main difference is that an experienced project team with a broader understanding of SOA is free to choose an appropriate approach from a range of options. The only cause-and-effect relationship that can be established here is that more experience allows for different options, while little experience definitely leads to a technical understanding. 2005) argue that the degree to which enterprise architects, service developers and operational project staff in the IT department are skilled (i.e. their experience and subsequently their understanding of services) is a critical factor for web service implementation. Looking at our observations 5, 7 and 10, we can further hypothesize that SOA experience indirectly affects service reusability.
This is confirmed by Baskerville et al. 2005) who show that "very few web services could be reused exactly as they were originally implemented" (p. 7), so experience is essential for SOA implementations. 2009) state that "especially in the early stages of SOA maturity [ie with little experience] there is no experience of [what] a reusable service would look like". This is another indication that experience with a SOA project changes the understanding of services and increases the possibility of reuse.
The understanding of services affects both the granularity of services and the direction of the service identification approach
The right granularity of services affects multiple success measures and depends strongly on the project at hand
Some customers may not be interested in customizing the services each time they use them. A service generally supports a single distinct business concept or process.” (p. 38) In the case of ADAGE, precision services improved reusability and user satisfaction, ie. technical and business-oriented measures of success. In other cases, service fragmentation may be a trade-off because the effects on these two types of measures could be opposite.
Thus, a situation-specific approach to the choice of methods is important to allow for a sufficient granularity. In the following, we will describe phenomena that move beyond these data and reach another level of abstraction. Due to the fact that the categories are abstract placeholders and the hypotheses show possible and plausible causal mechanisms, we can now reason about further conceivable concepts in terms of alternative cases.
Since we assume that the hypotheses describe plausible mechanisms and the placeholders as well as the abstraction mechanisms guide the inference, this is not arbitrary but another generalization by abstraction. Because the observed concepts as well as the categories in the different hypotheses overlap, we are also able to combine the hypotheses into a model or into a small set of model fragments. Furthermore, they refer to selected aspects in the field of SOA development because we focus our analysis on the research questions presented in 3.2.
Our model fragments allow for further elaboration and the formulation and discussion of alternative theories. In the following subsections, three model fragments presenting an external, an internal and a success perspective are elaborated. All of them (the “general context”) influence the application of methods, communication and the general approach to the implementation of SOA projects.
We assume that alternative examples of the mentioned categories will result in different ways of SI/SOA development, as shown in Figure 4. For example, in a more business-driven SOA implementation project, the choice of a BPM software tool could influence the way SI/SOA development. Accordingly, the method of SI/SOA implementation will most likely include more categories than method orientation and communication, which we cannot observe.
General context
The contingency model in Figure 4 includes our observations from the ADAGE case (underlined concepts) and alternative concepts derived from the possible instantiation of categories using abstraction mechanisms. Therefore, the experience of the project teams affects the adaptability and reusability and the direction of the identification approach through the chain of cause-effect relationships, as shown in Figure 5. Finding further plausible and alternative cases for this MSFT is easier than in the case of the contingency model.
Only those concepts that help distinguish one project from another should be part of the framework. Several hypotheses and our models suggest that concepts such as fragmentation or the direction of the identification approach are more or less directly influenced by service understanding (which tends to change with increasing experience). Software development was mostly intuitive and tied to a small number of developers due to the limited scope of the project.
This would allow the search for patterns across cases and support the validity of the results (Eisenhardt, 1989). Below we discuss the main findings and limitations of the models and their possible interaction. An extension of the list of factors, which are part of the general context, will be left to future research and can be achieved, for example, through further case studies or interviews with experts.
Finally, it would be desirable to assess the importance of each concept (eg approach direction) and to what extent it affects the success of SOA. Furthermore, the way SI/SOA is developed in CM could be influenced by the direction of the identification approach, which is currently not part of the contingency model, but MSFT. Our research effort presented in this paper can be characterized in terms of the conceptualizations of generalization that we presented in Section 2.2.
In all likelihood, these mechanisms have previously been implicitly used by researchers, but an explicit description of the abstraction mechanisms aims to add rigor to the abstraction process to better justify the findings and to better support logical generalization and generalization by abstraction. From our point of view, this support in methodological work increases the reliability and traceability of our procedure and of the findings in the case study analyses. Based on an exploratory single case study, we developed hypotheses and model fragments abstracting from the subjective understanding of the project participants and observations made by the researchers.
By referring to the aforementioned conceptualizations and mechanisms, we tried to make the research process transparent and traceable, so that SOA researchers could assess the reliability of the results. 2009) "Building the Business Case for SOA: A Study of the Business Drivers for Technology Infrastructure Supporting Financial Service Institutes", in: Dennis Kundisch, Daniel J.
