Towards an Understanding of Enterprise-Level SOA adoption: A South African Case

Proceedings of the

3rd International Conference on Information

Management and Evaluation

Atilim University

Performance Management and Applications Research Centre,

Ankara, Turkey 16-17 April 2012

Edited by

Dr Turan Erman Erkan Atilim University

Turkey

Copyright The Authors, 2012. All Rights Reserved. No reproduction, copy or transmission may be made without written permission from the individual authors. Papers have been double-blind peer reviewed before final submission to the conference. Initially, paper abstracts were read and selected by the conference panel for submission as possible papers for the conference. Many thanks to the reviewers who helped ensure the quality of the full papers. These Conference Proceedings have been submitted to Thomson ISI for indexing. Further copies of this book and previous year’s proceedings can be purchased from http://academic-conferences.org/2-proceedings.htm CD version ISBN: 978-1-908272-34-8 CD version ISSN: 2048-9862 Book version ISBN: 978-1-908272-35-5 Book Version ISSN: 2048-9846 Published by Academic Publishing International Limited Reading UK 44-118-972-4148 www.academic-publishing.org

Towards an Understanding of Enterprise-Level SOA Adoption: A South African Case Study

Shirley Lavin and Lisa Seymour Information Systems Department, University of Cape Town, South Africa [email protected] [email protected] Abstract: Service oriented architecture (SOA) is an emergent style of computing architecture that embodies the use of independent services as re-usable building blocks from which business systems can be composed. SOA is regarded by Gartner as representing a “durable change in application architecture” and as a base architecture for a number of contemporary Technologies, IT Methodologies and Management Disciplines. This seemingly simple description of SOA masks a complex web of interrelated requirements in respect of enterprise architecture and technology infrastructure which have yet to be unanimously defined and agreed upon. Prior investigations into SOA adoption noted that respondents claiming such adoption have often not implemented SOA-compliant technologies to the degree that justifies such a claim. Researchers have argued for moving beyond implementation issues in respect of SOA research, with a view to a new focus on non-vendor studies to produce “concrete guidance” for organisations wishing to adopt this architectural paradigm. In light of this need for contextualised, non-vendor, post-implementation focussed SOA research, this paper explores what it means to adopt SOA at an enterprise level in terms of both its scope and its inter-relationships with other organisational elements. The vehicle for exploration is a single organisation case study undertaken at a South African Insurance Company that was some way on its SOA adoption journey at the time that the research was conducted. The research was conducted qualitatively, and with an inductive approach, in order to identify the various affected organisational elements through the experiences of the participating actors themselves. The results of the research identify a series of inter-related layers which combine with organisational elements to contribute to the unique nature of each SOA adoption journey. It is suggested that it is the unique nature of each SOA adoption case as well as its on-going nature that contributes to the lack of a common understanding of what is meant by ‘adopting SOA’. The contribution of this research is in the form of a conceptual model, ‘The Inter-related Layers of SOA Adoption’, which can be used by organizations to assist with understanding and planning their own journeys to SOA adoption. Keywords: SOA, service oriented architecture, IT adoption, IT management, IT architecture

1. Introduction

Service oriented architecture (SOA) is a style of computing architecture that embodies the use of independent services as re-usable building blocks from which business systems can be composed. A number of business benefits have been documented as arising from such an architecture, for example, improved integration between inter- and intra-organisational systems, legacy system integration with new technology systems, business and systems agility and flexibility, and cost-savings due to service re-use (Lewis, Kontogiannis & Smith, 2010; McCoy & Cantara, 2010). In spite of a lack of a universally accepted definition, SOA is regarded by Gartner as representing a “durable change in application architecture” (McCoy & Cantara, 2010, p. 68). However the literature also reveals an area of concern in terms of a shared understanding of what is meant by “SOA Adoption” (Beimborn and Joachim, 2010). A clearer understanding of this concept is necessary in order to move beyond “over-heated rhetoric and vendor hype” (Lewis et al., 2010, p. 11) with a view to a new focus on non-vendor studies to produce “concrete guidance” (p. 35) for organisations wishing to adopt this architectural paradigm. In light of this need for contextualised, non-vendor, post-implementation focussed SOA understanding, this paper reports on research undertaken to explore and explain the concept of enterprise-level SOA Adoption. The remainder of this report is made up of a summary of the in-depth literature review of SOA scope and elements, followed by a description of the research objectives and method, the two-part analysis and discussion, and the conclusion.

2. SOA scope

In order to identify the constituents of SOA adoption in an organisation, one must first analyse the organisation’s understanding of SOA. The organisation’s particular SOA definition, together with the

174

Shirley Lavin and Lisa Seymour

particular viewpoint of the organisation in respect of its motivation for adopting SOA, determines the range of elements that are likely to be affected. In 2009, Kohun, Wood and Laverty (2009) synthesized a list of ten SOA “definitional characteristics” (p. 5) from a number of sources. This list includes service-specific characteristics, environmental requirements and technological requirements. Kohun et al. (2009) note that no single SOA definition incorporates all these characteristics, yet each of these characteristics appear across a number of definitions. This diverse set of SOA definitions illustrates the importance of mutually agreed SOA principles as a key precursor to contextualising an organisation’s SOA adoption journey.

Table 1: SOA definitional characteristics (adapted from Kohun et al., 2009)

A more complete understanding of SOA is obtained by combining the array of definitional characteristics listed in Table 1, with an appreciation of the different organisational levels at which SOA adoption can take place. Welke, Hirschheim and Schwarz (2010) describe a unique set of criteria representing the organisational motivation for SOA adoption in terms of IT and Enterprise Level motivations, and within these terms, in order of increasing levels of maturity (see Figure 1). For the purposes of this report, the Enterprise Level motivations in order of increasing organisational SOA maturity are described below:

SOA is adopted in order to develop an organisational capability for real-time analysis of operational processes.

SOA is adopted as an organisational strategy in order to respond to changes in the extra-organisational environment in a flexible and agile manner.

SOA is adopted as a transformational strategy for the enterprise as a whole.

Welke et al.’s Maturity Model (2010) explains that organisations will experience the effects and benefits of SOA adoption in different measures based on their motivation for such adoption.

3. Organisational elements affected by SOA adoption

A holistic model on which to base a discussion of organisational elements affected by SOA adoption is Scott-Morton’s (1991) conceptual framework of the organisational forces that maintain dynamic equilibrium among themselves in reaction to influences from a volatile external environment. The model illustrates the impact of external drivers, in the form of socio-economic changes and extra-

175


organisational technology developments, on the key internal organisational elements of organisational strategy, organisational technology, and organisational culture.

Figure 1: Enterprise-level SOA Adoption Motivations (Adapted from Welke et al. (2010))

3.1 SOA and the external technological and socioeconomic environment

When SOA is adopted as an intra-organisational technology choice it is likely due to the external socio economical or technological environment engendering a need for the organisation to become more flexible and agile, and/or to improve organisational returns through a reduction in technology integration costs, and through service re-use.

3.2 SOA and organisational strategy

Scott-Morton (1991) refers to the ultimate aim of organisational strategy in terms of seeking competitive advantage through using IT to meet “the customer’s real needs” (p. 22). SOA provides IT assets in the form of services, and such assets can be deployed strategically for competitive advantage. As it could be argued that the business processes within an organisation are the mechanism for aligning organisational resources to best meet such ‘real’ needs of the customer, SOA-enabled business processes are discussed under Scott-Morton’s (1991) element labelled as organisational strategy. Trkman et al. (2011) refer to a number of examples in the literature when discussing the close link between business processes and SOA. They explain that a substantial challenge lies in the area of mapping business processes to services and it is the establishment of this relationship that is the key to a mutually beneficial process ecosystem.

3.3 SOA and organisational culture

A culture change in favour of service re-use is imperative (Zhao et al., 2008) but of even greater importance is the requirement for mutual co-operation and collaboration between IT and the business, and for the business to take ownership of projects and programmes that might traditionally have fallen within the domain of IT (Lawler, Benedict, Howell-Barber & Joseph, 2009).

3.4 Structure

Zhao et al. (2008) refer to “Disruptive Effects” (p. 297) in terms of both the aims of service-orientation, and the degree to which the related effects permeate an entire organisation. Trkman et al. (2011) identify the requirement for different departments within an organisation to treat each other as service providers and consumers, thus facilitating an agile response to changing business requirements. Demirkan, Kauffman, Vayghan, Fill, Karagiannis & Maglio (2008) similarly state that business processes that previously belonged in particular organisational departments will need to be re-packaged as ‘black box’ services.

176


3.5 Management processes

Scott-Morton (1991) describes the element management processes in his 8-forces model in terms of “methods of planning and control” (p. 22). As such, this element is regarded as an appropriate heading for a discussion of SOA governance requirements. As pointed out by Ott, Korthaus, Bohmann, Rosemann and Krcmar (2010), adoption of SOA introduces a whole new set of IT challenges which require the oversight of firm and coherent governance if such adoption is to be successful in the long term. Further indication of the importance of SOA governance is indicated by the fact that governance failures are cited as the highest reported reason for failure of post-adoption SOA projects (Malinverno, 2006).

3.6 Individuals and roles

Zhao et al. (2008) emphasise the increase in importance of IT staff having the capability to understand business needs, and for business to likewise be educated to understand the implications of SOA. Business and IT Managers are required to mutually fund SOA. To do this they need to be jointly cognizant of, and take responsibility for, both functional and technical requirements of SOA (Maurizio, Sager, Jones, Corbitt & Girolami, 2008). In an organisation that has adopted SOA, knowledge of web service standards, technologies and tools become a key responsibility of SOA software developers.

3.7 SOA and organisational technology

Popular SOA-related IT tools and techniques discussed by Beimborn and Joachim (2010) include the following (p. 11):

Use of Web Services and Related Standards

Use of Model Driven Development (MDD) and Related Standards

Use of the concept of an Enterprise Services Bus (ESB)

Use of Service Registries and/or Repositories

Beyond tools and techniques there is a requirement for a fundamental adaptation of systems development methodologies in order to cater for SOA principles (Brahe, 2007).

3.8 Summarising SOA organisational elements

It is clear that the adoption of SOA has the potential to affect many key elements of an organisation. Such a pervasive effect is inevitably beset with challenges that need to be addressed if a SOA adoption project is to deliver on its intended benefits. The first step towards meeting such challenges is to be pre-armed with knowledge gained through exposure to the experiences of organisations that have already travelled some way on their SOA adoption journey.

4. Research question and method

The primary research question was framed as: What are the elements of enterprise-level SOA adoption, how are these elements related to each other, and what is the effect of SOA adoption on these elements? The exploratory case study was conducted at a leading South African Insurance Institution which will hereafter be referred to as SASure. The lead researcher had been fulfilling the role of an ERP process analyst at SASure for some time prior to conducting this research but was not a permanent member of staff and had not had any involvement in SASure’s SOA adoption project. Primary data was derived from semi-structured interviews held with 18 individuals occupying SOA-related roles (Table 2). Data analysis followed the general inductive approach (Thomas, 2006).

5. Background to the SOA adoption project at SASure

SASure is a leading insurance company in South Africa. The vehicle that SASure chose for the initial SOA implementation was a strategic project undertaken due to a business requirement to optimise SASure’s claims processing system. The technology base selected was BPM underscored by SOA principles. The project (hereinafter referred to as ‘the claims project’) was initiated in 2008 although actual development commenced early in 2010 after some time was spent getting to grips with SOA and BPM at a technical level. At the time that the research was conducted, 2 phases of the project had been implemented and phase 3 was about to ‘go live’.

177


Table 2: Participants

SASure established its definition for SOA through the adoption of a set of principles indicating a commitment to theoretical SOA in terms of loose coupling, a standardised service contract, encapsulation, reusability, statelessness, autonomy, discoverability and composability. SASure’s motivational lens for SOA adoption was that of developing an organisational capability for real-time analysis of operational processes.

6. Effects of SASure’s SOA adoption project in terms of Scott-Morton’s 8-forces Model

The first analysis cycle of the data used the Scott-Morton’s 8-forces model (Scott-Morton, 1991) as a lens and classification to view the impact of the SOA adoption project. The analysis revealed 85 codes and 15 groups discussed in this section.

6.1 External socio economic and technological environments

In terms of the external factors of Scott-Morton’s 8-forces model (Scott-Morton, 1991), the external effect of SASure’s SOA adoption project was perturbation of the insurance industry’s customer service space through improved efficiency of claims processing. This positive outcome resulting from the harnessing of modern technologies would of necessity have been noted by competitors in the industry and would therefore have affected the external technological environment.

6.2 Organisational strategy

Adoption of a SOA/BPM development strategy had resulted in competitive advantage arising from improved service to SASure’s claimants.

6.3 Organisational culture

In terms of a culture of re-use, it was felt that by the 3rd

phase of the claims project, the re-use of services was starting to play a positive role in terms of impact on costs and development time. However, business ownership of services was proving to be challenging. It was felt that each business process either had no owner or multiple owners leading to difficulties with assigning responsibility for service implementation and modification. In terms of co-operation and collaboration between IT and the business, difficulties were being experienced in terms of the business making the necessary shift to thinking in terms of services within business processes, and likewise in terms of IT appreciating the nuances of developing in the SOA paradigm.

6.4 Structure

In terms of an intra-organisational effect, where the internal IT organisational structure at SASure was affected by the claims project, various changes (described later in this report) had been implemented. In terms of an inter-organisational effect, there had been some planning done with the aim of implementing an integration point with another organisation using the SOA paradigm, but this had been de-scoped due to concerns about security and control.

178


6.5 Management processes

IT-enabled SOA governance at SASure was an area that was acknowledged as having been somewhat neglected due to more pressing strategic project imperatives.

6.6 Individuals and roles

In terms of individuals and roles, at the time that the research was conducted, the effect of SOA adoption on SASure was still very much contained within the scope of the foundation project. It is not possible to report on the impact on the business due to the lack of business participation in the research process.

6.7 Technology

SASure invested in a BPMS (Business Process Management Suite) from an international vendor to enable BPM, and SOA-enabling tools from the same vendor for service-enablement. A modelling tool was used for model-driven development. In terms of technology processes, simultaneously with the claims project, a new methodology for an integrated business architecture solution was being developed alongside the SDLC.

6.8 Summary of the impact of the SOA adoption project

The literature alludes to the “Disruptive Effects” (Zhao et al., 2008) of SOA adoption in terms of both the aims of service-orientation, and the degree to which the related effects permeate an entire organisation. Although there had been an effect on various organisational elements at SASure, the fact that SASure was still in the process of implementing its foundational SOA adoption project and therefore remained in its initial business domain had contributed to a limited impact when compared to the expectations engendered by the literature review. The origins of this aspect of SOA adoption, the extended timeframe to achieve SOA adoption, were therefore selected for further exploration.

7. The interrelated layers of a SOA adoption journey

“If I were to probably say one thing about the service orientation journey it’s that it just takes a lot [emphasized] longer than you think...” Technical Specialist 3

This section, arising from a subsequent analysis of the research data, highlights those causal effects that contribute to the length of time that it takes for an organisation to navigate a course through a SOA adoption journey, as well as the contributory factors that make each SOA adoption journey unique. As a result of this second analysis process, 124 codes and 38 groups were identified from the transcribed data, from which 6 final themes were synthesized: Context, Choices, Complexity, Change, Cost and Compromise.

7.1 SOA adoption context

At the outset of the project, the claims system at SASure was a procedural mainframe system written in Adabas Natural. The future vision was the adoption of a technical architecture designed in accordance with theoretically correct SOA Principles. This objective was challenging as the difference between mainframe procedural thinking and SOA thinking is vast.

7.2 SOA adoption discretionary choices

Certain key decisions and choices that arise early on in the journey to SOA adoption were identified as having a significant impact on the progression of the journey in terms of consequences (Figure 2).

7.2.1 Choice of foundation project, and project funding model

SASure chose a key strategic project with which to establish a SOA foundation – the optimisation of the claims system using BPM. The consequence of the choice of a strategic project was that the critical deadlines affected the quality of the initial artefacts detrimentally. A further consequence was the limited scope within which SOA thinking was applied. Any impact on artefacts beyond the claims environment was dealt with outside of the SOA paradigm. This kept the knowledge and skills related to SOA adoption within a constrained business and IT domain.

179


As the SOA paradigm had not permeated the organisation further than the claims project, the full costs of operational SOA were being borne by the project without any sign of additional developments having the potential to enter the SOA Space. This had led to concern on the part of the project sponsor that the operational costs would be rather more than had been anticipated.

7.2.2 Choice of resourcing

SASure chose to use in-house resources for the claims project. A consequence of the foundation project choice described in the sub-section above, and the choice to use in-house resources, was the reinforcement of constraints in terms of the diffusion of knowledge and skills. A further consequence of this skills constraint was on the morale of staff outside of the claims project who felt that they were being left behind.

7.2.3 Choice of SOA enabling tools

SASure purchased its toolset from a leading international vendor and the toolset included both BPM and SOA tooling. An issue that arose with this choice of tooling and tool vendor was the fact that the specific tool catering for service analytics was not yet mature, and the vendor’s development environment was unstable. This lack of maturity in key aspects of the tooling together with the lack of vendor support skills, not just nationally but internationally, had an impact on stability in the initial stages of the project.

Figure 2: SOA adoption choices

7.3 Consequences of SOA adoption choices

The consequences of SASure’s SOA adoption context and SOA adoption choices were felt in terms of the concomitant effect on the key organisational elements of SOA adoption complexity, changes and costs as shown in Figure 3.

7.3.1 SOA adoption complexity

At SASure, 3 main sub-themes in terms of the complexity of the SOA concept itself emerged from the interview data. Establishing Granularity of Services. The degree of service granularity which SASure adopted had been an issue from the outset of the claims project. SASure’s approach thus far had been to build an application out of services, resulting in the production of a large number of services. Although this approach had the potential to provide a great deal of flexibility, each service came with its own overhead of development, performance and monitoring. An unintended consequence of this was the resultant load on both the infrastructure and the enabling tools.

180


Figure 3: SOA adoption consequences

Ownership of Services. Ownership of services was an issue at SASure. This might have been compounded by the fact that the business was not yet aligned to business processes, and SASure could be regarded as still in the emergent stages of establishing SOA governance. SOA Theory versus SOA Practice. The opinion of SASure’s SOA specialists was that the variance between theoretical SOA, and actually implementing against these SOA principles, was an area of complexity that could only be appreciated by those who had actually had to do the job. Reasons provided were the impact of applying SOA principles from business services down into the technology, the performance difficulties arising from adopting a high level of service granularity, and the technological difficulties arising from the interactions amongst enabling tools and the infrastructure.

7.3.2 SOA adoption change

The model of the constituents of SASure’s SOA adoption project as illustrated in Figure 4 provides a framework through which to describe the many changes experienced at SASure.

Figure 4: Constituents of SASure's SOA Adoption Project

181


“SOA is not this compartmentalised thing that you can start up a competence in a corner somewhere...” Technical Specialist 3

The CIO was required to provide enterprise-level leadership in the quest for SOA Adoption, the Sponsor was required to accept an inflated project budget based on the promise of future returns, and the Project Manager role required getting into the detail of the solution and understanding the complications inherent in realising the SOA adoption vision. The term ‘Project Team’ encompassed a wide set of participants across both IT and the Business Change Divisions at SASure. The change at this level was in terms of soft skills: Perseverance in terms of learning how to use the many enabling tools, learning how to troubleshoot in a highly complex environment, and remaining positive that desired objectives would be met; Collaboration skills due to the fact that the SASure SOA adoption project team encompassed a disparate array of resources spread across a number of different teams. A lack of collaboration was regarded as a key risk to SASure’s claims project. It was acknowledged that the business did not have any understanding of SOA. This is an area that warrants attention as, in the paper “Critical Success Factors in the Planning of a Service-oriented Architecture Strategy for Educators and Managers”, Lawler et al. (2009) state that it is imperative for the business to exhibit leadership in driving SOA adoption in preference to such leadership residing in the IT department.

However, the greatest impact in terms of change was felt in the IT division of SASure. Four major changes were experienced.

IT Structure Changes. New roles were created to deal with SOA and usage of the enabling tools. The position of Enterprise Solution Architect was created to ensure enterprise-level architectural coherence in artefacts produced by the SOA Adoption project. A Centre of Excellence for Composite Systems was created within which all development of SOA services took place. Occasional consultants were contracted to assist with getting to grips with specific enabling tools.

IT Skill and Competency Requirement Changes. The view was expressed that the most important competencies for SOA were in the architecture and design arena. Consensus of opinion was that standard architecture best practice for distributed systems was what was required. In terms of design though, there was a requirement for improved business and systems analysis skills, and for the introduction of specific service designers. Whereas in the mainframe procedural environment developers had been accustomed to being provided with a technical or business specification and then designing and developing the required application to completion, in the new development paradigm developers were not aware of the context of each service that they were developing.

Testing in IT. SASure invested in a number of new tools to assist with testing artefacts produced out of the claims project. In addition, tester’s skills had to expand in order to appreciate the scope of impact of a SOA service change.

IT process changes. The methodology used for the SDLC during the course of the claims project was constantly evolving. The issue of the number of hand-off points was a particularly vexing one. Project managers had difficulty in accounting for the overheads of the multiple design steps required for SOA.

7.3.3 SOA adoption cost

SASure found that the methodology that they were following with its multiple hand-off points was more expensive than the traditional requirements gathering process. In addition, each service, when developed in the SOA paradigm, requires further additional services to cater for policy management and security thus adding to overheads in terms of cost.

7.4 SOA adoption compromise

“So, we’ve taken SOA seriously, OK, maybe too seriously...” Senior Manager 4

As a result of the issues that SASure had experienced in phases 1 and 2 arising from strict compliance with theoretical SOA, the organisation’s SOA principles were revisited. An understanding

182


was reached that designing in accordance with theoretically correct SOA principles was proving to be both costly and unnecessarily complex. The result of this review was to restrict low-level decomposition in the creation of services to integration points, and those areas where future re-use of such services was virtually guaranteed. This compromise is reflected in Figure 5.

Figure 5: SOA adoption compromise

7.5 SOA adoption conceptual model: the inter-related layers of SOA adoption

This second analysis of the research data was undertaken once it was realised that SASure’s SOA adoption project had had a limited effect in terms of Scott-Morton’s (1991) 8-forces model when compared to the expectations engendered by the literature review. The 6 Cs of SOA adoption that then emerged gave rise to a model entitled ‘The Inter-related Layers of SOA Adoption’ (see Figure 6). The various layers of the model are permeable and the movement between them dynamic, thus ‘change’ could feed back into ‘choices’, just as ‘complexity’ could affect both ‘change’ and ‘cost’, and could feed forward into ‘compromise’.

Figure 6: The inter-related layers of SOA adoption

183


Whereas Scott-Morton’s (1991) 8-forces model can be used to explain both the organisational context for a SOA Adoption Journey (the AS-IS situation), as well as an organisation’s SOA adoption vision (the TO-BE view), the new model of the inter-related layers of SOA adoption provides a useful framework for viewing the adoption journey itself. ‘The Inter-related layers of SOA Adoption’ model is regarded as simple in terms of interpretability, yet effective in conveying the many imponderables that affect the time that it takes to attain an organisation’s SOA adoption vision.

8. Conclusion

The intention of this research is to examine what it means to ‘adopt SOA’ at an organisational level. This is achieved through an exploration of both affected organisational elements, and the interrelationships of these elements in terms of the SOA adoption paradigm. In this report the findings are discussed based on the on-going SOA adoption journey of a single organisation. The contribution of this report is in the raising of awareness of the unique nature of each SOA adoption journey. Although Scott-Morton’s (1991) 8-forces model is useful in terms of establishing the context and vision for an organisation’s SOA adoption journey, Scott-Morton’s (1991) model does not cover the journey itself. To address this gap, a model of ‘The Inter-related layers of SOA Adoption’ is introduced. This layered model can serve as a basis for discussion amongst a variety of disparate stakeholders as to the possible effects of various alternative SOA adoption choices. Through these contributions, it is believed that this report provides for some understanding as to why a common appreciation of what it means to have ‘adopted SOA’, might not be shared.

References

Beimborn, D., & Joachim, N. (2010). The joint impact of service-oriented architectures and business process management on business process quality: An empirical evaluation and comparison. Information Systems and E-Business Management, 9(3), 333-362

Brahe, S. (2007). BPM on top of SOA: Experiences from the financial industry. Business Process Management, 4714, 96-111

Demirkan, H., Kauffman, R. J., Vayghan, J. A., Fill, H. G., Karagiannis, D., & Maglio, P. P. (2008). Service-oriented technology and management: Perspectives on research and practice for the coming decade. Electronic Commerce Research and Applications, 7(4), 356-376

Kohun, F., Wood, D., & Laverty, J. (2009). Systems oriented architecture, unified process life cycle, and IS model curriculum compatibility: Meeting industry needs. Information Systems Education Journal, 7(15), 1-9

Lawler, J., Benedict, V., Howell-Barber, H., & Joseph, A. (2009). Critical success factors in the planning of a service-oriented architecture (SOA) strategy for educators and managers. Information Systems Education Journal, 7(94), 1-30

Lewis, G. A., Kontogiannis, K., & Smith, D. B. (2010). A research agenda for service-oriented architecture (SOA): Maintenance and evolution of service-oriented systems. A Technical Report published by the Software Engineering Institute. Retrieved 11 April, 2011 from http://repository.cmu.edu/cgi/viewcontent.cgi?article=1028&context=sei

Malinverno, P. (2006). Service-Oriented Architecture Craves Governance, Gartner Research, ID Number: G00135396

Maurizio, A., Sager, J., Jones, P., Corbitt, G., & Girolami, L. (2008). Service oriented architecture: Challenges for business and academia. (HICSS), 2008 41

st Hawaii International Conference on System Sciences, 315

McCoy, D. W., Cantara, M. (2010). Gartner’s Hype Cycle for Business Process Management, 2010, Gartner Research, ID Number: G00200990

Ott, C., Korthaus, A., Böhmann, T., Rosemann, M., & Krcmar, H. (2010). Towards a reference model for SOA governance. Retrieved 11 April, 2011 from http://sky.scitech.qut.edu.au/~korthaus/papers/CAiSEForum-Ott-Korthaus-Boehmann-Rosemann-Krcmar-CAISE2010.pdf

Scott-Morton, M. S. (1991). The corporation of the 1990s: Information technology and organizational transformation, Oxford University Press, USA.

Thomas, D. R. (2006). A general inductive approach for analyzing qualitative evaluation data. American Journal of Evaluation, 27(2), 237-246

Trkman, P., Kova i , A., & Popovi , A. (2011). Service oriented architecture (SOA) adoption phases: A case study. Business & Information Systems Engineering (Wirtschaftsinformatik), 2011. Retrieved 11 April, 2011 from http://ssrn.com/abstract=1735666

Welke, R., Hirschheim, R., & Schwarz, A. (2010). Service oriented architecture maturity. Computer, 99, 1-7 Zhao, J. L., Goul, M., Purao, S., Vitharana, P., & Wang, H. J. (2008). Impact of service-centric computing on

business and education. Communications of the Association for Information Systems, 22(16), 295-310.

184

Towards an Understanding of Enterprise-Level SOA adoption: A South African Case

Documents