Factors Affecting the Organizational Adoption of Service-Oriented ...

Factors Affecting the Organizational Adoption of Service-Oriented Architecture (SOA) Elzavita MacLennan and Jean-Paul Van Belle* University of Cape Town, Private Bag, Rondebosch, 7700, South Africa *Correspondence to: [email protected] Tel +27-21-6504256 Fax +27-21-6502280.

Abstract Service-oriented architecture (SOA) takes an architectural approach to designing and implementing IT solutions. Although it is fast emerging as one of the major architectural styles to execute enterprise architecture management, academic empirical research on SOA adoption is scarce, with most studies focusing on qualitative analysis. This study investigates organizational SOA adoption in South Africa and combines the perspectives of the diffusion of innovations theory and the technology-organization-environment framework into one comprehensive model of SOA adoption. In order to validate the research instrument and to gauge the state of SOA adoption, an online survey was conducted among enterprise architects in South African organizations. The survey provides insights in the perceived risks, obstacles but also expected benefits of SOA adoption. The results also highlight a number of factors significantly influencing SOA adoption in South Africa. Use of multiple standards and platforms, compatibility, top management support, good governance and strategy, adequate human and financial resources, vendor support for integration and development tools are all significant factors for a fruitful SOA implementation. Finally, all of the above adoption factors as well as cost and complexity were also found to correlate significantly with the degree of success of the SOA implementation as perceived by the IT or EA department.

Keywords: Service-oriented architecture (SOA); SOA and EAM; Service-oriented applications architecture; Enterprise architecture; IT adoption; SOA success; South Africa.

Introduction Modern economies are characterized by increasing competitiveness, globalization and ever-faster innovation. Consequently, organisations require a high degree of flexibility allowing them to move quickly into new markets, to change their business strategies responsively, or to react effectively to competitive pressures (Barry 2003). The discipline and practice of Enterprise Architecture (EA) addresses this by providing a holistic view of all aspects of the enterprise and, in particular, by aligning IT and business. Here, the role of adopting a service-oriented architecture (SOA) as part of the EA can provide huge impacts (Kistasamy et al. 2010). Service oriented architecture (SOA) is currently the favoured architectural style to provide organizational agility, to improve applications adaptability and systems interoperability, and to allow the reuse of legacy assets (Lewis et al. 2007). In fact, it has been argued that SOA, together with Business Process Management, form the two fundamental tools to implement EA strategy and policies (Shankararaman and Kazmi 2011). Given that SOA is a fairly recent phenomenon, its integration in EA practices and frameworks has been surprisingly swift (Khoshnevis et al. 2009). However, as a fastemerging architectural style for Enterprise Architecture Management (EAM), it is equally

1

In: Information Systems and e-Business Management, 12(1), p71-100 DOI 10.1007/s10257-012-0212-x

important that EAM takes full cognisance of SOA adoption issues and trends so that the SOA/EA linkages can be fully understood (Ayed et al. 2011a, b). For instance, implementation issues such as complexity, cost, and the effort required for achieving even moderate improvements in the implementation of SOA can easily be underestimated (Lewis et al. 2007). While SOA may increase interoperability, extensibility, and modifiability, at the same time it can reduce systems performance, testability, auditability, and security (O’Brien, Bass and Merson 2005). This research1 focuses on the factors influencing organizational adoption and implementation of SOA and perceived success of adopting SOA. This study identifies factors critical for the adoption of SOA as an IS innovation from a review of SOA and other IS innovations literature. Using the technology-organization-environment (TOE) framework, the uncovered factors are grouped into three major categories: technological, organizational and environmental. This study suggests a research model for SOA adoption using those factors based on the TOE framework. We empirically test the proposed framework by means of surveying South African enterprises regarding factors influencing adoption of SOA at an organizational level and the possible impact of these factors on the perceived success of the SOA projects. Two research objectives drove this study. Firstly, what are the critical factors for the successful adoption of SOA that can be identified within the framework? Secondly, which implementation challenges do South African organizations face when adopting SOA? Although the research questions are framed for a South African context, it is believed that most of the findings will be generalizable to other emerging and developed country contexts.

SOA definition and related adoption research SOA definition and concepts SOA provides the foundation for an on-demand operating environment (Schmidt and Kalyana 2004). Systems built on service-orientation principles are becoming the solution of choice to “bridge the gap between business models and the technical solution to support and adapt changing business needs” (Kontogiannis, Lewis and Smith 2007, p.1). Service-orientation is a “prerequisite for rapid integration of data and business processes; it enables situational development models, such as mashups; and it is the foundational architecture for SaaS and cloud computing” (Manes 2009a). Services are most commonly described using the following set of characteristics and attributes: services are reusable, composable, discoverable, autonomous, stateless, loosely coupled, hiding underlying logic and exposing a formal service contract which defines the terms of information exchange (Erl 2005, Papazoglou and van den Heuvel 2007). There is no consensus on a SOA definition between industry practitioners, vendors, standardization organizations such as W3C (2004) and OASIS (2006), or academics (Ren and Lyytinen 2008). Early definitions stressed the technical perspective of SOA by focussing on the characteristics of services, whereas more recent publications take a wider business perspective by looking at the architectural benefits offered from a services paradigm (Ayed et al. 2011a, b, Demirkan et al. 2008, Löhe and Legner 2010). In this paper, the following definition is adopted: SOA is “an open, agile, extensible, federated, composable architecture comprised of autonomous, QoS-capable, vendor diverse, interoperable, discoverable, and potentially reusable services” (Erl 2005:54).

1

This article is an expanded version of a PACIS conference paper (MacLennan and Van Belle, 2012).

2


Consequently, our survey was prefaced with the following, more technical descriptor for SOA: “Service-oriented architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains (OASIS, 2006). A service is an abstract resource that has a name, a job, job tasks, contract information and policies regarding security and service levels. A service is invoked by a request message, which is issued in accordance to the contract information and policies. If the request is appropriate, service sends back a reply message. SOA is most commonly implemented using Web services, however, other implementation technologies could be utilised.” However, web services technologies still continue to evolve (Phippen, Taylor and Allen 2005). Major standards categories are business processes, management, reliability, security, transportation, interoperability, and messaging. Standards and specifications are developed by standards bodies, such as W3C, OASIS, Web Services Interoperability Organization (WS-I) and the Internet Engineering Task Force (IETF) (Papazoglou and van den Heuvel 2007). Major IT vendors are also actively involved and promote their own specifications. Some of the specifications have become industry standards (Papazoglou and van den Heuvel 2007). It is important to note that, although SOA as an architectural style does not have to be grounded in IT-based processes in principle, currently most of the SOA projects are ITdriven. The interpretation of SOA in this paper is thus from an IT perspective; a number of questions refer specifically to issues relating to the application of SOA to the development of applications (e.g. use of platforms and standards) and in that case the term “Service-Oriented Application Architecture” (SOAA) might be more appropriate. However, the term SOAA does not (yet) enjoy a wide usage in the academic literature and SOA shall, in this paper, refer to both (IT-based) SOA and SOAA. SOA adoption research SOA adoption necessitates a significant change in a business’ process philosophy and technology infrastructure. This effort is driven by the promise of significant benfits (Erl 2005). SOA adoption will provide organizations with improved interoperability, re-use, composability, legacy integration, organizational agility, standardized data representation and vendor-neutral communications infrastructure (Demirkan et al. 2008). These translate into specific business benefits such as improved flexibility, increased speed to market, incremental deployments, and improved productivity were among the other expected benefits (Walker 2007). Although the economic value delivered by SOA drives adoption organisational decisions, this value is not easy to assess or even specify (Mueller et al. 2010; O’Sullivan, Butler and O’Reilly 2012). Organizations often embark on SOA projects without proper up-front analysis and understanding of all the implications of their decisions (Lewis et al. 2007). IBM summarized their experience with a number of organizations adopting SOA and suggested four areas of adoption challenges: technology, program management, organization, and governance (Varadan, Channabasavaiah, Simpson, Holley and Allam, 2008). Organization and governance challenges are considered to be the most difficult, as they require the entire organization to “change their methods, modes of communication, means of cooperating, and methods of reporting relationships” (Varadan et al. 2008). Some of the more common problems of adopting SOA include misunderstanding the differences between SOA and distributed architecture, building SOA in an old-fashioned way, misunderstanding SOA performance requirements and Web services security. Committing to SOA without a clear strategy and transition plan, not embracing different platforms and standards, not setting SOA standards within an organization and not using

3


XML as a standard and foundation for SOA architecture are among the major reasons for SOA project failures (Erl 2005). Typically held misconceptions about SOA are that SOA provides a ready-made architecture for a system that can be bought and implemented off the shelf, that legacy integration is easily achieved, that SOA is only about standards and technology, that interoperability is guaranteed if standards are used, and that testing of SOA applications is similar to testing of standard applications (Lewis et al. 2007). “The lack of planning and clear business case, lack of understanding of what services are available, the lack of governance, and the lack of standards” (Ren and Lyytinen 2008) were mentioned as reasons for dissatisfaction among organizations adopting SOA. Despite the presence of many compelling SOA adoption success stories of individual organizations in the trade press (e.g. Schindler 2008; Flowers 2009), it is somewhat difficult to get an accurate and more representative picture of SOA adoption and success, especially since much of the academic SOA research uses secondary data (Löhe and Legner 2010) or a qualitative approach (Becker et al. 2011). Two eminent exceptions are the surveys by Kumar et al. (2007) and Oh et al. (2007) but they focussed on interorganisational benefits. Although organisations of all sizes can use SOA, it is argued that small and medium-sized companies can benefit the most from SOA, since it gives them an opportunity to provide fee-based services (Barry, 2003). However, the 2009 Forrester SOA survey showed that SOA adoption is much lower in smaller organizations viz. those with less than 1000 employees (McKendrick 2009). SOA adoption in the industry appears to be slower than desired (Kontogiannis et al. 2007; Haines 2007). Some industry reports suggested that SOA failed to deliver its promised benefits and is too expensive (Gartner 2009; Meehan 2008). The CA Wily (2008) SOA adoption survey results demonstrated that different countries were at different stages of SOA adoption. A significant number of organizations in the USA (40.6%) and Australia (32.9%) had deployed a business-unit SOA application under IT control, while many of the organizations in the UK (40.6%) had deployed a SOA application that is part of an enterprise-wide initiative. The largest number of the organizations in France (45.2%) and Germany (30.6%) had their SOA applications in the pilot stage. The South African context South Africa is the youngest member of BRICS and, although it has the smallest economy and population of the five BRICS countries, it has the largest and strongest economy of the African continent. Like a typical emerging economy, it displays characteristics of both first and third world realities. The country faces challenges such as high rates of crime, poverty, unemployment and inequality (Edigheji 2010). However, much of the corporate sector is internationally competitive and it has a sophisticated and advanced ICT industry and infrastructure (Marais 2009). Due to the open economy and the growing local economy, the corporate sector is innovative and dynamic in its adoption of information and communication technologies, and many of the larger companies have aggressively pursued formal and large-scale enterprise architecture initiatives. Thus adoption patterns of SOA are likely to be comparable with that in much of the rest of the world. However, specific contextual and structural factors playing an important role in South Africa are the high tariffs and limited bandwidth with, up to very 2009, a very limited capacity for international bandwidth (Horwitz and Currie, 2007). Another constraint is the talented but shallow pool of ICT skills: although world-class skills are available to develop and deploy sophisticated and complex SOA implementations, they are relatively scarce and come at a relatively high cost (Kraak and Press 2007).

4


Since there is virtually no academic research on SOA adoption in the South African context available, this research can provide valuable insights into the state of SOA adoption in the South African context. However, it is believed that most of the findings which are not specifically implicated by the South African context will be generalizable to other country contexts.

Theoretical framework The lack of research and conceptual frameworks to explain the adoption of SOA has been lamented widely (Demirkan et al. 2008, Luthria and Rabhi 2009, O’Sullivan et al. 2012). Many of the traditional technology success, adoption and diffusion models such as the various Technology Adoption Models such as TAM and UTAUT (Davis 1989; Venkatesh et al. 2003) and the IS success model (DeLone and McLean 1992) take individuals as their unit of analysis and, although they often incorporate some technical aspects, they do not take into account the organisational perspective. Muller et al (2010) integrated the key adoption factors of a number of other organisation adoption models such as the transaction costs model, resource-based and capabilities models (e.g. Peppard and Ward 2004) and benefit frameworks (e.g. Gefen and Ragowsky 2005). However, since their focus was on the economic potential of SOA, most of the factors they identified had an internal organizational benefit focus. As shown in Rogers’s (2003) Diffusion of Innovations (DOI) theory and Swanson’s (1994) typology of IS innovations, technological and external factors can be as decisive as organisational factors in technology adoption. Teo et al. (2003) developed a model based on institutional theory which highlights the importance of external industry pressures on technology adoption. Basaglia et al. (2008) highlighted the fact that technology-specific characteristics such complexity can play an important role. We therefore opted to use the Technology-Organization-Environment (TOE) framework (Tornatzky and Fleischer 1990) as the organising framework for this study, and populate it with “first-order” factors lifted from the academic SOA literature (Fig.1). The advantage of the TOE framework is that it also allows for the easy inclusion of additional factors.

Figure 1: The Context of Technological Innovation: TOE framework (Source: Tornatzky and Fleischer 1990, p. 153)

5


The technological factors relate to the technology and information systems, as well as to the pool of technologies available to the organization. Technological factors often cited as important for successful adoption are: relative advantage, complexity, compatibility with existing infrastructure and perceived benefits (Tornatzky and Klein 1990). Organizational factors normally describe characteristics of the organization and include firm size, degree of centralization and formalization, organizational structure, skills and expertise of its human resources and the amount of slack resource available (Hackney, Xu and Ranchhod 2006). External factors relate to the environment in which an organization operates and include market conditions, regulatory influence, industry pressure and vendor influence (Basole 2005). Organizational factors can also subsume individual factors (Muller et al. 2010); this can be justified by the fact that end-users within an organization have to adopt a technology as well (Basole 2005). This individual technology adoption within an organization is referred to as “intra-organizational acceptance” (Frambach and Schillewaert 2002). While the claim that an adoption decision is made on behalf of an organization by a few individuals is valid, individual factors influencing organizational adoption are beyond the scope of this study. A list of factors was compiled based on six early key studies pertaining to Web services adoption and IS innovation literature (Table 1). Table 1: Factors used in empirical research on Web services adoption Chen 2003 Technology Relative advantage Compatibility Complexity Trialability Visibility/observability Divisibility Customizability Tool support Performance Security Standards maturity Organization Company size and industry type Organizational culture IT skills/ expertise Software development effectiveness IT architecture/ infrastructure Financial justification/cost Management awareness and support Financial and technology resources IT management maturity Environment Business partners demand/readiness Industry inertia/fragmentation Vendor support

6

Chen 2005

Chen et al. 2006

X X X X X

X

X X X X

Ciganek et al. 2005

Ciganek et al. 2006

Wu 2004

Influence

X

X X X

X X X

X

X

X X X

+ + + + + + + + + +

X

X

X

X X

X X X

X

X

X

+ + +

X X

X

X

X X

X

X X

X

X

X

X

+ + +

X

+

X

+ X

X

X

X X


+ +

A further review of the literature provides additional support for these variables. In respect of the technological factors critical for SOA adoption success, standards maturity was named by a number of researchers (Chen 2005; Chen et al. 2006; Ciganek et al. 2005; Ciganek et al. 2006, Lippert and Govindarajulu 2006). Complexity of SOA technology, resulting from a large number of overlapping or even competing specifications, was also cited as a major factor limiting adoption (Table 1). With respect to the organisational factors, many studies of organizational innovativeness found that large organizations are more innovative (Rogers 2003; Swanson, 1994; Frambach and Schillewaert 2002). This finding is surprising, especially in the light of the standard perception that small companies have less bureaucratic procedure and are more flexible in their activities. To explain this contradiction, Rogers (2003) suggested that size is acting as a surrogate measure of other variables that affect innovativeness, but have not been properly identified and adequately measured. These variables may include total resources, slack resources, employees’ level of technical expertise, organizational structure, and so on. Another major driver for technology adoption is its perceived value and potential benefits. As a result, tangible and intangible benefits of a new technology, its value and impacts require a careful evaluation (Basole 2005). A limitation of this study is that the many of the economic value-drivers are subsumed in a single construct, namely financial justification. However, many business benefits of SOA, and EAM in general, from competitive advantage to operational efficiency, are second-order benefits. Future research could perhaps look at a multi-layered approach, e.g. as in the SOA Economic Potential Model (Mueller et al. 2010). Amongst the external factors, industry pressure has been recognised to have a positive effect on adoption (Iacovou et al., 1995; Lippert and Govindarajulu 2006; Teo et al. 2003; Basaglia et al. 2008). Vendor support early on in the adoption process is also positively related to adoption (Zhu et al. 2006).

Research hypotheses and methodology For the purpose of studying factors influencing SOA adoption in the South African context, this research examines the problem from ontological position of realism and takes an epistemological stance of positivism. The research is explanatory in purpose and adopts deductive approach to theory. The study uses a survey research strategy and a quantitative approach to data collection and subsequent data analysis. It is cross-sectional in its time-frame. Initial research hypotheses Although the proposed research model was developed on the basis of the DOI theory and an extensive literature review, the research hypotheses can be classified by technological, organizational and environmental factors, according to the TOE framework. In this research, the following influencing factors related to the technological context are hypothesised: SOA adoption will be positively influenced by (1) a greater the degree of utilization of multiple standards and platforms, (2) a lower perceived complexity of SOA, (3) a higher compatibility between SOA and the existing enterprise architecture and infrastructure, (4) a lower cost of SOA implementation, (5) lower perceived implementation challenge; and/or (6) a greater relative advantage of SOA as a technology. In relation to the organizational context, the following influencing factors are hypothesized: SOA adoption will be positively influenced by (7) a larger firm size, (8) organisations belonging to certain industries/sectors, (9) lower perceived risks of SOA implementation, (10) high levels of IT skills and expertise with the organization, (11)

7


high levels of top management support for SOA initiatives, (12) more effective organizational SOA strategies, (13) more effective the SOA governance procedures, (14) more financial and technological resources available to the SOA initiatives, and/or (15) greater perceived SOA benefits by the organization. The following influencing factors related to the environmental context are hypothesized: SOA adoption will be positively influenced by (16) higher levels of support from vendors, (17) increased industry pressure, and/or (18) stronger perceived IT media influence. Instrument design and sampling frame In order to guide the questionnaire design, a number of available industry questionnaires were reviewed. They included the questionnaire from the Wily TechWeb survey (CA Wily 2008), the IBM SOA Maturity Assessment Tool (IBM, n.d.a), the 2008 AmberPoint “State of SOA Adoption Survey” (AmberPoint 2008), and the “SOA Implementation Survey” conducted by Forrester Research and the TechTarget Application Development Media Group (TechTarget 2010). A questionnaire from the Masters thesis “A Stage Maturity Model for the Adoption of an Enterprise-wide Service-Oriented Architecture” (Veger 2008) was also reviewed. Top management support questions were adapted from Boh and Yellin (2006). The Complexity section was adapted from Bradford and Florin (2003). Industry pressure questions were adapted from Kuan and Chau (2001). The remaining questionnaire items were developed by the author, taking into account the South African context. The instrument was then piloted with two industry practitioners. A definitive, consolidated and publically available database of South African businesses does not exist. In order to maximize the number of responses – the goal was to obtain at least 100 responses – a non-probabilistic sampling approach was taken using a combination of purposive and self-selection sampling. The survey was targeting Enterprise Architects although other decision makers responsible for the SOA strategic decision making were also included i.e. IT executives, the decision makers initiating SOA projects, IT architects, and senior IT staff members implementing SOA projects. The Computer Society of South Africa (CSSA) agreed to include the survey link in their newsletter; the two monthly newsletters were sent out to 2789 society members in June and July 2010. A respected private provider of IT Architecture courses, the Faculty Training Institute (FTI), also agreed to send out emails with the survey linked to their former “Practical TOGAF” course delegates. However, this did not yield a noticeable number of responses. Finally, South African members on the professional social network site LinkedIn (http://www.linkedin.com) were contacted. The criterion was to have a job title “architect” or “development manager” or to be a member of a relevant South African special interest group such as the “Enterprise Architecture Forum”, “The Enterprise Architecture Network”, “iCMG Architecture World”, “SOA Group”, “Service Oriented Architecture Special Interest Group”, “Cloud Computing”, and others. Apart from the CSSA newsletter, a total of 468 potential respondents were contacted over the period 26.05.2010 – 21.08.2010 in a number of waves. A total of 154 survey responses were collected, of which only 109 were fully completed, and two had only demographic data missing. As a result, the final data sample of 111 responses was obtained2. This is seen as a highly successful and significant representation given the relatively small size of the South African economy from a global perspective. Due to the non-probability sampling technique used, the results of the study cannot reliably be

2

In the spirit of Open Data, the questionnaire, full dataset and detailed research report are available from the authors on simple email request.

8


generalised to the whole population of the South African organizations. However, given the respondents profile (as discussed below), it is felt that the sample is quite representative of South Africa’s larger companies as well as the technologically more advanced smaller businesses. The questionnaire used in the study and the sampling approach were approved by the University of Cape Town’s Ethics Committee. The respondents were informed that their participation in the study was voluntary and their anonymity protected.

Data analysis and findings Profile of respondents More than one-third of the responses (34.2%) came from EA/IS/IT/Technical architects. The next largest groups of respondents were IT staff (17.1%) and CIO, CTO, and other C-level executives (16.2%). Consultants formed 12.6% of the respondents, while IS managers, directors, and planners were represented by 9%, and other IT managers in IS departments by 7.2% of the respondents. Nearly 60% of all the respondents were from large and very large companies: 27.5% (500 to 5000 number of employees) and 32.1% (5000+ employees) respectively. Medium size companies were represented by 22.5% of the respondents: 11.0% (50 to 99) and 11.9% (100 to 499) respectively. Small companies constituted 17.4% of the respondents. More than half of the respondents (51.4%) work in very large IT teams with more than 100 people in the team. IT teams with 50 to 100 IT staff members constitute 12.8% of all the responses, while teams with 20 to 50 IT staff form 13.8%. Small IT teams represent just under a quarter of all the responses: 10 to 20 - 6.4%, 5 to 10 – 8.3%, and less than 5 – 7.3%. While 28.8% of the respondents either did not know total revenue of their organization or opted not to answer the question, 36.0% of the respondents stated that they work for companies with total revenue exceeding R500 million: 3.6% - in companies with revenue of R500 million to under 1 billion, 11.7% - in companies with revenue of R1 billion to under R5 billion, and 20.7% - in companies with revenue of R5 billion and higher. Respondents that work for companies with revenue from R100 million to under R500 million constitute 8.1% of the responses. The remaining 27.0% of responses came from small and medium size organizations: 7.2% - under R5 million, 14.4% - R5 million to under R50 million, and 5.4% - R50 million to under R100 million. Unsurprisingly, there was a strong correlation between total revenue and total number of employees as well as total number of employees and number of IT staff. The largest number of responses (27.0%) came from financial services/banking industry. IT vendors represented 18.0% of the responses, consulting and business services - 14.4%, telecommunications/ISP - 9.9%, and government organizations - 8.1%. The remaining 22.6% of the responses were from various industries with less than 5% representation each. Almost all of the smaller organisations were the IT vendors. Overview of survey results A small majority of the respondents (60, 54%) indicated that they have SOA implementations in production. Seven respondents (6.3%) have their SOA projects in single department use, 17 respondents (15.3%) in multiple department use, and 36 respondents (32.4%) in enterprise-wide use. Nineteen respondents (17.1%) said that their SOA implementations are in development, while 10 respondents (9%) have their SOA projects in pilot stage. Nine respondents (8.1%) stated that they will pursue SOA within

9


the next 6 months, and 13 respondents (11.7%) indicated that they have no SOA plans. These figures suggest the presence of the adopter’s bias in the results: organizations that did not implement SOA were less likely to participate in the survey. Notwithstanding the huge methodological problems with measuring project success, the respondents were also asked to indicate the perceived success of their SOA project(s). Interestingly, the majority of the respondents (68.4%) indicated that they perceived their SOA projects to be either successful (37.8%) or partially successful (30.6%). Only 2.7% of respondents described their SOA projects as unsuccessful, while 28.8% of respondents said it is too early to tell. This should come as a surprise to practitioners used to the relatively high failure rate of IT architecture projects in general. It is clear that the response bias must play a major role here, i.e. respondents with successful SOA projects were more likely to respond. Secondly, the perception of success by the respondents may well differ from that of the other stakeholders (as in the old medical joke: “technically the operation was a success; unfortunately the patient died”.) Measuring EA project success will likely always remain subject to the intricate methodological issues of reconciling the views of the EA and IT professionals with those of the top management and the business owners and users. Finally, the category of ‘partially successful’ allows for significant leeway in interpretation. Half of all the respondents (56, 50.5%) started their SOA initiatives from IT (architecture) strategy. Top-down from business strategy approach was the next most prevalent at 21 respondents (18.9%), while bottom-up from IT projects approach followed with 13 respondents (12.6%). Consultant/vendor driven approach was used by 11 respondents (9.9%). Nine respondents (8.1%) indicated they used other approaches (e.g. combinations of options, no SOA roadmap, etc.). Two-thirds of the respondents (66.7%) use external services. A large number of respondents reported being providers of external services themselves (63.1%). Thirty six of the respondents indicated that SOA projects are owned by central IT departments of business units, while 29 respondents (26.1%) said that SOA projects are owned by business units. IT architects at a project level own SOA projects in 28 organizations (25.2%). Eighteen respondents (16.2%) stated that their organizations do not have SOA services yet. The majority of the respondents (68.4%) indicated that their SOA projects are either successful (37.8%) or partially successful (30.6%). Only 2.7% of respondents described their SOA projects as unsuccessful, while 28.8% of respondents said it is too early to tell. Given the large number of dimensions and possible viewpoints, no attempt was made to define success in an academically rigorous sense, i.e. the measure of success used in the survey is the degree of SOA success as perceived by the respondent. Implementing SOA in the realm of application development (i.e. SOAA) requires specific tactical decisions about standards and platforms. Two questions probed more specifically into these “Service Oriented Application Architectural” decision points. When asked for their SOA specifications and standards, the most used are XML, XQuery, XPath, XSLT – 87 respondents (78.4%), WSDL and SOAP – 79 respondents (71.2%) each, WS*standards – 45 respondents (40.5%), UDDI – 31 respondents (27.9%), REST – 20 respondents (18.0%), JSON – 18 respondents (16.2%), RSS – 14 respondents (12.6%). WADL, ATOM, and other scored 2.7%, 3.6%, and 5.45% respectively. Among the SOA platforms the most widely used are Microsoft .Net Framework (64 respondents, 57.7%), Sun - Java Web services developer pack (36, 32.4%), IBM Websphere (35, 31.5%), Eclipse - Web tools Platform/ SOA Tools Platform (27 24.3%), Apache- Axis (21, 18.8%), JBoss – Seam (19, 17.1%), Oracle SOA Suite/BEA WebLogic (18, 16.2%), Spring Framework (17, 15.3%), SAP NetWeaver and SOA Software (9, 8.1%) each. Other platforms were used by 10% of the respondents.

10


Given that cloud computing is an evolutionary component and possible technology option for SOA-based applications, a somewhat tangential question enquired about this technology option. Just over half of all the respondents (51.4%) do not use cloud computing options, while 27.4% of the respondents indicated that they are in the early stages of learning / testing cloud computing options. One-third of the respondents said that they use SaaS either for non-critical (13.5%) or for mission-critical (19.8%) applications. PaaS is used by 7.2% of the respondents (2.7% for non-critical and 4.5% for mission-critical applications), while IaaS is used by 10.8% of the respondents (3.6% for non-critical and 7.2% for mission-critical applications). The relatively high percentage of respondents already using cloud to run mission-critical applications was somewhat unexpected. The mission-critical SaaS applications run by respondents fall into various categories: ERP systems, CRM systems, HRM systems, PLM systems, etc. When asked to provide examples of mission-critical SaaS applications used by the organizations, the most frequently mentioned applications were Google Apps Premier, Google Docs, Salesforce CRM, and JIRA Confluence. Of the SOA projects risks examined in the questionnaire (security, performance, interoperability, reliability, and testing), the most important project risks identified were reliability (78.4%), security (73.9%), and performance (72.9%) (Figure 2). Controlling and mitigating risks in SOA projects

9

Interoperability Testing Performance Security Reliability 0% Not important

11

5

29

11

29

3 5

42

28

18

Slightly important

27

39

18

10%

23

38

20

2 5 22

37

54

34

20%

30%

Somew hat important

40% Important

53

50%

60%

70%

Moderately important

80%

Very important

90%

100%

Extremely important

Figure 2: Risks in SOA projects (N=111)

Ten SOA implementation challenges were offered as important/not important to the respondents in the questionnaire. A summary of the results is provided in Figure 3. The top five challenges, with more than 50% of the respondents identifying them as being extremely important and very important, are testing and deploying services, designing SOA security, ensuring run-time governance, designing high quality services, and standards stability and maturity. Note that SOA security is not only viewed as a major SOA implementation risk, but is also considered by the respondents to be a SOA implementation challenge.

11


SOA implementation challenges

10

Establishing baseline metrics

8

5

Crafting SOA development process

9

Integration with BPM, BI, etc.

4

6

Ensuring design-tine governance

3

Standards stability and maturity Ensuring run-time governance

7

3 3

7

3

5 2 5

Designing SOA security

5 3 4

Testing & deploying services 4 12

Figure 3:

7

20

33

23

19 26

32

25

27

34

30

25

25

31

20%

19

32

12

8

14

28

34

15

14

31

35

8

16

25

31

6

10%

22

26

8

36

36

30%

40%

Important

Somewhat important

Slightly important

30 32

14

7

Designing high-quality services

Not important

20

3 4

0%

16

7

10

9

Evaluating tools and frameworks

9

8

50%

29

60%


70%

80%

Very important

90%

100%

Extremely important

SOA implementation challenges (N=111)

One intention of the questionnaire was to examine whether SOA is viewed as a solution to existing IT issues, such as lengthy application development cycles, high cost of application development, inflexible, hard to integrate systems and restricted information flow. More than half of all the respondents (56.7%) rated addressing of inflexible and hard to integrate systems as extremely important and very important, in terms of influencing their organization’s decision to pursue SOA. High cost of application development and restricted information flow was rated as extremely and very important by 45.9% of respondents. A number of SOA benefits were examined in the questionnaire. The top five benefits, with more than 50% of the respondents identifying them as being extremely important and very important, are improved organizational agility (63%), reuse (58%), legacy application integration (54%), standardised data representation (54%), and improved business processes (53%) (Fig. 4). Perceived SOA benefits

5

Composability Improved B2B integration Reduced TCO within IT portfolio 2

5

Vendor neutral infrastructure

5

5

5 8 5

Improved business processes 2 3 5

3

Reuse

0%

12

Slightly important

14 18

23

10%

Somewhat important

Important

23

34

26

38

23

30%

30 37

32

20%

18

29

35 10

20

36

21

10

24

32

37

7

19

25

40

14

9

28

36

7

7

5 21

Improved organizational agility

Not important

4

29

33

9

5 13

Standardised data representation

44

15

8

Improved interoperability 2 3 5

Legacy application integration

14 3

26

38

40%

50%

32

60%


70%

Very important

80%

90%

100%

Extremely important


Figure 4: Perceived SOA benefits (N=111)

Distribution, item reliability analysis and construct validity To examine the distribution of the test items and variables, Kolmogorov-Smirnov and Lilliefors and Shapiro-Wilk tests for normality were conducted on each of the test items and variables. The results show significant p-values (p< .05), which means that the null hypothesis Ho about normality of data distribution is rejected for almost all test items and variables. Although the distribution in the data set is skewed and not normal, it has to be noted that Likert scales can generate skewed or polarised distribution (Jamieson 2004). This normally happens when respondents have strong opinions about a particular aspect of the model. In order to evaluate inter-item reliability, Cronbach alpha test was performed for each test construct. For each construct, the correlations between the respective item and the total sum score and the internal consistency of the scale (alpha) were examined. Implied reliability of the Cronbach alpha scores was evaluated according to DeVellis (1991). Almost all constructs have reliability that is “respectable” (0.7-0.8) or “very good” (>0.8). Two of the constructs (Compliance and Vendor Support) have “minimally acceptable” reliability (0.65-0.7), while the other two (Standards and IT-Media Influence) have “undesirable” reliability (0.6-0.65). Given that this is still above the 0.6 criterion used in some other studies (Ngai, Cheng and Ho 2004), those two constructs were kept in the instrument. To analyse the structure of the relationships between the variables and to test for a possibility of data reduction, factor analysis was conducted on the set of 62 items. Factor rotation Varimax normalised was used. The maximum number of factors was set to the number of variables (16), while the minimum eigenvalue was set to 1. Fourteen factors, which explain 74.98% of the variance in the data, were identified during the analysis. According to the Kaiser criterion, all the factors were retained as their eigenvalues were greater than 1. Nunnally (as cited in Ngai et al. 2004) suggested that an item is considered to load on a factor when the factor loading is 0.4 or greater. Using this criterion, factor loadings were analysed, and the instrument variables were adjusted to match newly discovered factors. On the whole, most test items loaded nicely onto their respective constructs. However, the test items for some similar variables loaded onto the same factor, and some test items for some constructs loaded onto different variables. This is not surprising since the survey instrument was composed from different sources and additional items were added. In light of the validity analysis, the initial model was reviewed slightly. SOA implementation challenges were separated into pure technological implementation challenges and implementation challenges requiring organizational change. Some SOA perceived benefits can be realised inside an organization (intra-organizational benefits), while the other benefits, such as increased B2B integration and organizational agility (time to market) can only be realised at the inter-organizational level. A number of constructs were merged, as it appeared that they measure similar concepts. Resources and IT skills and expertise were merged into one construct. Additionally, governance and strategy and plan constructs were considered to be measuring similar concepts, and, therefore, were merged into a single governance and strategy construct. Similarly, industry pressure and IT media influence were considered to represent industry pressure, whether it is coming from competitors, business partners or IT media. Hence, the two constructs were merged into the industry pressure and IT media influence construct.

13


Overall model testing Simple regression analysis To examine the relationships between the independent variables and the dependent variable “Use of SOA”, first a simple regression analysis was done for each independent variable separately. The summary of the analysis, sorted by p-value, is provided in Table 2. The results show highly significant (p