Service-Oriented Architecture

(1)

Service-Oriented Architecture

Modeling profitability beyond the hype

J.W. Veneman Utrecht, August 2007

(2)

Service-Oriented Architecture

Modeling profitability beyond the hype

Master thesis

Author: J.W. Veneman - 1274546

University of Groningen, Faculty of Management and Organization Business administration

Financial Value Management and Business & ICT Company: IT-eye

Supervisors

Dr. P.E.A. Vandenbossche Ing. G.W.M de Ruijter, MBA University of Groningen Managing consultant and IT architect Faculty of Management and Organization IT-eye

Department of Information Systems Dr. B. Crom

University of Groningen

Faculty of Management and Organization Department of Financial management

2

(3)

The document lying in front of you is the result of ten months research into the financial implications of Service-Oriented Architecture. After my interest in this subject was raised by an interesting course by my first supervisor, my choice for a graduation subject was destined. After a short period of intensive research IT-eye turned out to be the most interesting organization to settle for an internship starting October 1^st 2006. Ten months later I am fulfilled with new knowledge, skills, experience and a thesis which accomplishes my study Business Administration at the University of Groningen.

During this period several people have assisted me and supplied me with advice and helpful feedback. Therefore I would like to thank all the people at IT-eye who supported me in achieving this goal; Ronald Doelen, Maarten de Waal, Mike van Alst, and not to forget my fellow intern Tim Pinchetti. But most gratitude goes out to my supervisors, Jules de Ruijter at IT-eye and Piet Vandenbossche and Bernard Crom at the university.

Last but not least, I want to thank all my friends who supported me during this period - especially those who are currently still struggling with their own graduation thesis- with their feedback, patience and advice.

Jasper Veneman

Utrecht, August 2007.

The author is responsible for the content of this thesis. No part of this publication may be reproduced or distributed in any form or by any means without the prior written consent of the author.

3

(4)

Management summary ... 7

1. Research design ... 10

Introduction ... 10

1.1 Situation... 11

1.2 Problem owner analysis... 13

1.3 Problem statement ... 14

1.3.1 Research objective ... 14

1.3.2 Research question ... 14

1.3.3 Research sub questions ... 15

1.3.4 Research methodology... 16

1.3.5 Preconditions and research scope... 21

1.4 Conceptual Framework ... 21

1.5 Concepts and definitions... 22

1.6 Research structure ... 23

1.7 Research relevance... 24

1.7.1 Research relevance for science ... 24

1.7.2 Research relevance for practice ... 24

2. The concept of Service-Oriented Architecture ... 25

2.1 Definition of Service-Oriented Architecture ... 26

2.2 General overview of a Service-Oriented Architecture implementation ... 30

2.3 Business flexibility layer ... 33

Introduction... 33

2.3.1 Location transparency ... 34

2.3.2 Time to Market ... 35

2.3.3 Increased business orientation of IT ... 36

2.3.4 Availability ... 38

2.4 IT infrastructure layer ... 40

Introduction... 40

2.4.1 Interoperability... 41

2.4.2 Loose coupling... 42

2.4.3 Scalability ... 44

2.4.4 Reuse... 45

2.5 Conclusion ... 46

3. Investment evaluation methods ... 49

3.1 General IT investments characteristics ... 50

3.2 Service-Oriented Architecture investments characteristics ... 51

3.2.1 Tangibility of SOA benefits and detriments ... 52

3.3 Theoretical models... 54

3.3.1 Model from Peffers and Saarinen ... 55

4

(5)

3.3.4 Resume... 60

3.4 Identifying applicable evaluation methods ... 61

3.4.1 Cost – Benefit analysis... 61

3.4.2 Internal Rate of Return... 61

3.4.3 Discounted Cash Flow ... 62

3.4.4 Net Present Value ... 64

4. Framework... 67

4.1 Applicable evaluation methods ... 68

4.2 Content of the framework ... 68

4.2.1 Business Flexibility components... 70

4.2.2 IT Infrastructure Components ... 74

4.3 Context of the framework... 79

4.4 Framework composition ... 82

4.4.1 Identification of cash flows... 82

4.4.2 Timeframe of cash flows... 83

4.4.3 Impact of cash flows ... 84

4.5 Applying the framework in practice... 86

4.6 Generalization of results... 87

5. Validation of the framework ... 89

5.1 Case overview... 89

5.2 Findings ... 92

5.2.1 Business flexibility components ... 93

5.2.2 IT Infrastructure components... 94

5.2.3 Additional findings ... 96

5.3 Analysis of discrepancies... 98

5.4 Adaptation ... 99

5.5 Generalization of results... 100

6. Conclusions and recommendations... 103

6.1 Conclusions ... 103

6.2 Limitations ... 106

6.3 Recommendations regarding the framework ... 107

6.4 Recommendations for future research ... 109

5

(6)

Index of terms and abbreviations... 113 Appendix A: Company profile ... Error! Bookmark not defined.

Appendix B: Financial concepts and definitions... Error! Bookmark not defined.

Appendix C: Reflection ... Error! Bookmark not defined.

Appendix D: Case study validation results ... Error! Bookmark not defined.

6

(7)

Management summary

The emergence of Service-Oriented Architecture (SOA) as a concept for rethinking the essence of an Information Technology (IT) architecture has affected the software market severely. Due to the increased interest in SOA, IT service organizations are rapidly altering their product-lines in alignment with the concept of SOA. However, this increased interest also calls for more research into the financial implications of a SOA implementation. In particular the interests of IT service organizations can be served by generating specific knowledge on the financial implications of a SOA implementation which can improve marketing related activities on this field.

The objective of this research is derived from this knowledge gap and focuses on the design of a framework which enables IT service organizations to calculate and document the expected financial implications of a SOA implementation for customers in more detail.

First, an in-depth analysis of the concept of SOA is conducted to assure a comprehensive definition and to explore what the concept implies. The working definition which is composed based on input from several sources implies that ‘a Service-Oriented Architecture is an architectural style, which enables loose coupling of services, reuse of functionality and has the ability to separate capabilities into composite functions to support business processes’. The general consequences of a SOA implementation can be modeled using a two-layer model which distinguishes Business Flexibility consequences and IT Infrastructure consequences. This model includes eight sub consequences;

Location Transparency, Time to market, Business orientation of IT, Availability, Interoperability, Loose coupling, Reuse and Scalability. All eight consequences have financial implications varying in measurability and tangibility.

The way in which the financial implications of an investment in SOA or general IT can be assessed varies per method. Regarding the scope of this thesis, only financial evaluation methods are taken into consideration. Despite the differences in investment

(8)

Service-Oriented Architecture: Modeling profitability beyond the hype 8 characteristics, two financial investment evaluation methods apt for general IT are applicable for SOA investments as well. Based on the outcomes of three theoretical models, the Net Present Value (NPV) and the Discounted Cash Flow (DCF) method turn out to be most applicable in evaluating an investment in SOA in a pre-investment stage.

In order to develop a comprehensive framework, all eight SOA benefits and detriments have to be linked with the relevant financial implications they cause. Utilizing the NPV and DCF method requires the operationalization of the inputs in terms of incremental cash inflows and cash outflows. Next to the specific financial factors, the impact and timeframe needs to be addressed in order to arrive at meaningful and comprehensive outcomes. The impact distinguishes the size of the cash flows, and the timeframe distinguishes the time span in which the cash flow occurs which is either the initial phase or the exploitation phase.

In summary, ¾ of the business flexibility benefits and detriments increased cash inflows and ½ of the business flexibility components decreased cash outflow in the exploitation phase. In the initial stage, no significant change in cash flows was identified. Regarding the IT Infrastructure, a striking distinction between the financial implications in the initial phase and the exploitation phase was identified. The initial phase is characterized by cash outflow increases for all benefits and detriments. The exploitation phase instead, compensates the increased outflow severely with decreased cash outflows caused by cost savings. With this information IT service organizations can calculate and document the financial implications in more detail using the DCF and NPV method. Customers involved in a SOA investment appraisal can benefit from this information.

The framework is utilized in a case situation to assess the external validity. The results implied an overall confirmation of the predicted results. Four out of eight SOA benefits and detriments showed the behaviour as predicted based on the use of the framework.

Two SOA benefits / detriments could not be validated because it was not applicable in the case organization. The remaining two benefits showed a slight deviation from the predicted financial implications. Reuse and loose coupling did not turn out to perform as was predicted. The expected decrease in cash outflow had not been realized. Reuse

(9)

Service-Oriented Architecture: Modeling profitability beyond the hype 9 seemed more complicated then expected which eliminated savings on the software development costs. Loose coupling also did not life up to the expectation of a high decrease in cash outflow. The associated complexity of loose coupling reduced the ability to cut costs on maintainability. Consequently, the framework was adapted based on the findings in the case validation.

The conclusion of the research is considered an answer in twofold. First of all, the financial implications of a SOA implementation are best described in terms of incremental cash flows. Overall the business flexibility benefits and detriments cause substantial increases in revenues and relatively smaller decreases in costs in the exploitation phase. IT Infrastructure benefits and detriments in contrast have a focus towards costs. The initial phase is characterized by investments in IT assets whereas the exploitation phase shows a significant decrease in costs. In total, a positive financial result in terms of cash flows can be generated by implementing a Service-Oriented Architecture, on the condition that the relevant characteristics regarding limitations are covered. Second, the integration of SOA benefits and detriments as well as investment evaluation methods has lead to research results which can be extrapolated, regarded the applicable limitations and recommendations.

However, the current knowledge regarding the alignment between SOA and business processes requires more future research in order to improve the knowledge on the financial implications of a SOA implementation. Also emergent conflicts of interest in the implementation trajectory of SOA is a topic which requires further research. The same applies to the recurrence of case studies which will benefit the validity of the framework.

(10)

1. Research design

Introduction

The software market is recently subjected to turbulent changes due to the emergence of the concept of Service-Oriented Architecture¹. Several major IT service organizations are expressing their vision and expectations regarding Service-Oriented Architecture in numerous publications varying from articles, books and whitepapers till electronic journals and blog postings. Determining the relevance and scientific value of all publications requires a thorough understanding of the contents of SOA and its influence on the business.

Service orientation is not considered a product but more of a concept. It is not something which was developed in a specific time span; rather it has evolved from its elements like component-based, object-orientation and service orientation towards the concept of a Service-Oriented Architecture experts are now referring to. Because some of these elements emerged already halfway the nineties it is not a new concept. Therefore placing it in a product lifecycle is not applicable because SOA cannot just be considered a product. Due to its characteristics of a concept, applying a change adoption model (see figure 1.1) is more valid (Erl, 2005, p. 53). Because Service-Oriented Architectures are currently tested and –on a very small scale- implemented within diverse companies, the change adoption model generates a comprehensive assessment. Although the details of the underlying concepts are being debated, Service Orientation has passed the understanding phase because the overall picture of the underlying concepts seems agreed upon. The current state –early 2007- in which SOA can be categorized is the trial use phase due to the several pilots and try-out projects taking place in several organizations (Gartner, Predicts 2007: SOA Advances, p. 5)

1 Service-Oriented architecture is abbreviated as ‘SOA’ in the remainder of this thesis

(11)

Service-Oriented Architecture: Modeling profitability beyond the hype 11

Figure 1.1 Adoption Curve, Adapted from Patterson & Conner, 1982,

“Building Commitment to Organizational Change”

Currently a small number of SOA pilot projects and a couple of companywide SOA projects have been implemented by IT service organizations in the Netherlands (Van Heur, 2006). The majority of these projects focused on the implementation of a SOA in either a small part of the client organization, e.g. a department or on behalf of a specific functional product or service. A much smaller number of SOA implementations focused on a companywide scale.

As we will see in chapter two, the concept of a SOA has not been well defined in detail yet. A wide array of IT service companies, research institutes and scientists claims to have all crucial knowledge about SOA, but some skepticism here can be wise. Not only has SOA not been adopted on a wide scale, the fact that there is still not a well defined and widely accepted definition of SOA strengthens the idea that there is no consensus about what it could set of for organizations. Therefore chapter two will elaborate further on the contents of the concept of SOA.

1.1 Situation

The implementation process of a SOA involves the interests of various stakeholders.

These stakeholders involved in SOA projects can roughly be divided in two categories.

One category contains IT service organizations, software vendors, hardware vendors and

(12)

Service-Oriented Architecture: Modeling profitability beyond the hype 12 IT consultants. These can be considered the selling party because they deliver products and services. The other category contains various organizations referred to as ‘client organizations’. Client organizations can be companies from varying industries and branches but with one common characteristic; they see additional value in implementing a SOA.

Due to the fact that it is quite unclear how further adoption of Service-Oriented Architectures will get shape, additional knowledge is needed for IT service organizations aiming to establish a firm position on this market. In particular, the knowledge on the financial consequences which companies will face when switching to a SOA is insufficient and currently not adequate for supporting investment decisions. Financial consequences can be predicted and documented with modeling tools in order to arrive at a satisfying outcome. Outcomes will then be represented in the form of an investment evaluation technique, such as a Return on Investment (ROI), Net Present Value (NPV) or Discounted Cash Flow (DCF). Several authors have contributed with specific knowledge on IT investment evaluation, and have come up with recommendations for miscellaneous techniques (Farby et al. 1993; Boddy et al, 2005; Van Grembergen, 2001). These recommendations are limited to IT investments in general and can be extrapolated to SOA investment proposals to a certain extent. The level to which extrapolation can take place depends on the similarities between SOA investment characteristics and general IT investment characteristics.

The lack of knowledge on financial implications applies to IT service organizations whose objective is to sell SOA solutions to their customers. In order to improve their SOA marketing propositions specific knowledge on the financial implications of a SOA implementation needs to be developed. Therefore this research aims to close this knowledge gap and shall uncover essential information in terms of financial implications for enhancing marketing propositions.

In brief, the general question is: ‘Which SOA-related factors are affecting an organization’s financial performance, and which associated propositions should therefore be emphasized in marketing activities’?

(13)

Service-Oriented Architecture: Modeling profitability beyond the hype 13 1.2 Problem owner analysis

A problem is seen as a subjective uncomforting feeling with the intention to change that (De Leeuw, 1996, p. 36). Hence, an individual or an organization has to meet both criteria in order to be regarded as a problem owner. Main problem owner in this research is the branch of industry of IT services organizations who wish to gain extra insights on the financial implications which organizations can suffer after implementing an SOA.

Detailed information about these financial implications represents a high value to IT service organizations because it enables them to adjust their policy of the sales process of Service-Oriented Architectures towards client organizations. More knowledge on this field can eventually lead to better results on the sales of SOA solutions. Before starting and during pre-sales activities, knowledge on the financial implications can be a decisive element for customers in the investment decision for implementing a SOA. This decision is made by the client organization based on several elements, which includes a tender from the selling party, e.g. an IT service organization. This tender is an important element and should therefore be calculated and documented with profound knowledge in order to persuade client organizations to start a SOA implementation process.

Among the IT service organizations offering SOA based solutions is the Dutch company IT-eye. IT-eye currently has implemented a companywide Service-Oriented Architecture with one of her customers which is now fully operational. IT-eye is particularly interested in the proceedings of this research, which include valuable knowledge and insights on the financial implications of a SOA implementation. They follow a focus strategy (Porter, 1998), which implies a strict focus on a specific market or product. Due to this strategy which emphasizes selling SOA solutions to the business, their performance can be affected. For example, the pre-sale activities and tenders for selling SOA can be improved using the research proceedings.

According to former definition, both criteria mentioned above are met, because there is a need to gain knowledge for future policy and there is an intention to change that situation.

(14)

Service-Oriented Architecture: Modeling profitability beyond the hype 14 1.3 Problem statement

A problem statement implies a research objective, a research question and underlying sub questions which define in detail what is being researched, how it’s being researched and under which preconditions the research is conducted (De Leeuw, 1996, p. 50).

1.3.1 Research objective

The research objective of this thesis is derived from the problem owner analysis which clearly states that additional knowledge on the expected financial implications for organizations implementing a SOA is needed. Thus, the research objective is as follows:

Designing a framework which enables IT service organizations to calculate and document the expected financial implications of future Service-Oriented Architecture implementations for customers in more detail.

The highest level objective is to develop a framework which will function as a comprehensive tool for calculating the expected financial consequences of a SOA implementation. This framework can be utilized by IT service organizations to improve the quality of their services towards their customers. The framework will serve in a pre- investment moment in time prior to the effective investment in a SOA which allows them to improve their presales activities. In this way the preconditions outlined in § 1.3.5 will be met.

1.3.2 Research question

The main research question is as follows: ‘What are the financial implications of a Service-Oriented Architecture implementation for a customer, and how can these implications be modeled into a framework, in order to calculate and document future implementations in more detail’?

(15)

Service-Oriented Architecture: Modeling profitability beyond the hype 15 1.3.3 Research sub questions

The sub questions are derived from the conceptual framework and are meant to break down the main research question into smaller subjects for uncovering the necessary information. The first sub question handles the general context of SOA.

1. In what way does a Service-Oriented Architecture affect organizational performance in general, and which benefits and detriments determine the financial implications relevant for SOA?

The sub question following on the first one continues with the relevant financial implications and emphasizes the evaluation methods required to assess an investment appraisal.

2. Which financial investment evaluation methods are most applicable for a pre- implementation assessment of a Service-Oriented Architecture investment appraisal?

Regarding the third sub question, the obtained knowledge on the financial implications of SOA and applicable evaluation methods will need to be merged into a framework.

3. How can financial investment evaluation methods and SOA benefits and detriments be modeled into a comprehensive framework in order to improve calculations and decision making on Service-Oriented Architecture investment proposals?

A fourth sub question is necessary to judge the validity of the framework which enables the author to postulate valid statements on the generalization of research results.

4. To what extent does the developed framework prove its validity in a specific case situation?

The four sub questions reveal essential information necessary for answering the main research question. Therefore the answers to the sub questions will be summarized in the conclusion of every consecutive chapter in order to serve as input for the final conclusion.

(16)

Service-Oriented Architecture: Modeling profitability beyond the hype 16 1.3.4 Research methodology

The methodology for this research needs to support a strategy in which all activities, data collection methods and reporting tools are mentioned and which structures the research as an integrated process. Yin (2003, p. 5) describes five possible research strategies. Every single strategy contains a standard set of tools including data collection methods and associated activities (see table 1.1).

Strategy Form of research question

Requires control of behavioral events?

Focuses on contemporary events?

Experiment how, why? Yes Yes

Survey

who, what, where, how

many, how much? No Yes

Archival analysis

who, what, where, how

many, how much? No Yes / No

History how, why? No No

Case study how, why? No Yes

Table 1.1 Relevant situations for different research strategies (adapted from Yin, 2003, p. 5)

Identifying the applicable strategy requires an analysis of the form of the main research question. Considering the main research question a twofold in the question can be recognized. The first phrase of the question focuses on the What part of the financial consequences (What are the financial [...] customer?) and the second phrase focuses on the How part of these consequences (how can […] detail?).

This twofold in the research question implicates that two strategies will be used conducting this research. The first part of the research question -What- including sub question number one and two will therefore make extensive use of archival analysis, such as literature. The choice for archival analysis is based on the fact that conducting a survey is not possible. The second part of the research question –How- includes sub question four. For answering this sub question case study research shall be conducted. Case study research is defined as an empirical inquiry that (1) investigates a contemporary phenomenon within its real-life context, especially when (2) the boundaries between phenomenon and context are not clearly evident (Yin, 2003 p. 13). For this question applies the same fact that conducting a survey or experiment is not possible.

(17)

Service-Oriented Architecture: Modeling profitability beyond the hype 17 This leaves sub question three unanswered in terms of an applicable research strategy.

Sub question three focuses on the composition of the framework, therefore design oriented research is applicable. The content of this strategy is outlined further on in this sub paragraph.

For adequately applying case studies, five components are especially important (Yin, 2003, p. 21). These five components cover all important elements a scientific research should meet.

1. A study’s questions

This component focuses on the establishment of clear and unambiguous research questions in the form of how, what, where, how many and how much. The research questions are described in paragraph 1.3.2 and 1.3.3.

2. Study propositions

Research in general can include propositions in the form of hypotheses which direct the research in a certain direction. In this case explicit hypotheses will not be posed due to the high level of exploration. Therefore expectations cannot contain realistic hypotheses due to the lack of relevant information.

3. Units of analysis

The component of units of analysis is related to the fundamental problem of defining what the “case” is. This situation handles the financial performance of an organization after the implementation of a SOA and is therefore considered a single unit of analysis.

4. Logic in linking the data to the propositions

This component says that careful consideration should be given in connecting a conclusion to the discovered data. Although certain patterns and relationships seem obvious at first sight a second opinion can always reveal connections that place the discovered relations in a different light.

5. The criteria for interpreting the findings

This component follows those mentioned under number four and is quite ambiguous because there are not clear rules for the extent of causality or numbers of founded matches in order for a theory to be ‘proven’. The relation between

(18)

Service-Oriented Architecture: Modeling profitability beyond the hype 18 revealed data and the associated conclusions stays subjective. This research aims to draw valid conclusions according to these criteria.

Among the different case study strategies, four types of case study design can be distinguished (Yin, 2003, p. 39). Placed in a framework perspective, two dimensions can be recognized; the number of case studies used and the number of units of analysis (See figure 1.2). For both dimensions, the selection of a typical case study depends on either one or multiple case studies used in a research. The resulting types of case study research are subsequently single-case (holistic) designs, single-case (embedded) designs, multiple- case (holistic) designs and multiple-case (embedded) designs.

embedded

(multiple units of Analysis)

holistic

(single- unit of Analysis)

single case designs multiple case designs

Context

Case

Embedded unit of Analysis 1

Context

Case

Context

Case

Embedded unit of Analysis 2 Embedded unit

of Analysis 1

Context

Case

of Analysis 1

Context

Case

of Analysis 1

Context

Case

of Analysis 1

Context

Case

Context

Case

Context

Case

Context

Case

embedded

(multiple units of Analysis)

holistic

(single- unit of Analysis)

single case designs multiple case designs

Context

Case

Context

Case

Context

Case

of Analysis 1

Context

Case

of Analysis 1

Context

Case

of Analysis 1

Context

Case

of Analysis 1

Context

Case

of Analysis 1

Context

Case

of Analysis 1

Context

Case

of Analysis 1

Context

Case

of Analysis 1

Context

Case

of Analysis 1

Context

Case

of Analysis 1

Context

Case

of Analysis 1

Context

Case

of Analysis 1

Context

Case

Context

Case

Context

Case

Context

Case

Context

Case

Context

Case

Context

Case

Context

Case

Figure 1.2 Basic design types for case studies. Source: Adapted from Yin 2003, p. 40.

(19)

Service-Oriented Architecture: Modeling profitability beyond the hype 19 The research into the financial implications of a SOA will be a single-case holistic design because it meets the rationales determining a single-case design as well as the rationales for a holistic design (Yin, 2003: p, 53). According to Yin (2003, p. 39) a single case design is analogous to a single experiment. In this particular research the requirements for a single case are satisfied due to the fact that only one organization will be analyzed. In chapter five this organization, NAK will be described. The requirement for a holistic design (single unit of analysis) is satisfied because the unit of analysis only concerns the financial implications of an organization. If multiple units of analyses were included other aspects would be taken into account as well.

The rationales for a single-case study are the following: One rationale is the case of a critical case where a well-formulated theory is tested on a single case. A second rationale could be the situation where a case represents an extreme or unique case. In this instance the characteristics are so rare that a single situation is worth investigating. A third rationale occurs when there is a representative or typical case that can be seen as a commonplace or everyday situation that is informative about an average person or institution. The fourth rationale for a single-case study is the revelatory case. Such a case exists when a researcher has the opportunity to observe and analyze a phenomenon previously inaccessible to scientific investigation. The fifth and last single-case study rationale is the longitudinal case. This situation applies to researches conducted at two or more different points in time on a single case. Especially the changes of certain conditions over time justify the use of a single case.

Elaborating on a single-case design in this specific research is justified by the first rationale which entails that the critical case can be used. Regarding the critical case a well-formulated theory is confirmed, challenged or extended. The theory in this situation is the new framework which is composed using literature and interviews and has the objective to test if the framework’s propositions are correct. In this way the single case can represent a significant contribution to knowledge and theory building, as well as refocusing future investigations in an entire field (Yin, 2003, p. 40).

(20)

Service-Oriented Architecture: Modeling profitability beyond the hype 20 Next to the case study research as methodology, another methodology shall be utilized as well. Design oriented research applies to sub question three which entails the design of a framework. The overall objective is to develop a system which serves as a model of reality, to predict future patterns. According to De Leeuw (1990) embedding, retrieval and dissemination of knowledge can be conducted in organizations using, theories, models, instruments, methods and prototypes. Regarding the objective of this research a model is the applicable way for embedding knowledge. The practical approach as well as the possibilities for practical utilization of models (De Leeuw, 1990, p. 47) supports this claim. Based on two parameters, four types of models (De Leeuw, 1990, p. 46) can be distinguished. a) An abstract model of an abstract system, b) an abstract model of a concrete system, c) a concrete model of a concrete system, d) concrete model of an abstract system. Option b, an abstract model of a concrete system is most common because it aims to simplify an empirical phenomenon into a theoretical model to obtain insight into the parameters that influence the state of a system. Examples of these types of models are: models to predict the future liquidity of an organization, or meteorologist models to predict future climate changes.

Model

Concrete system

Model building, abstraction Estimation of parameters, measuring Validation

Assessment Realization Implementation

Model

Concrete system

Model building, abstraction Estimation of parameters, measuring Validation

Assessment Realization Implementation

Figure 1.3 Model cycle, De Leeuw, 1990, p. 48.

Model building will take place in chapter four where the framework is composed from the proceedings from chapter two and three (figure 1.3). Estimation of parameters is done in chapter two and three where respectively the concept of SOA and the investment evaluation methods are elaborated. Validation will be conducted in chapter four where the framework is assessed in a case validation. The steps assessment, realization and

(21)

Service-Oriented Architecture: Modeling profitability beyond the hype 21 implementation will not be elaborated in this thesis because they fall outside of the scope of this thesis.

The quality of models can be measured according to two parameters: relevance and soundness (De Leeuw, 1990, p. 50). In case of models this quality issue is converted into the question: What is the quality of the predictions resulting from the model? This question will return in the remainder of this research to assess the quality of the framework.

1.3.5 Preconditions and research scope

In order to set boundaries for the research, preconditions as well as a clear scope have to be set. This will avoid unnecessary expansion of the research activities.

• In order to verify the framework, financial data has to be collected from an organization which has recently implemented a SOA environment and which can generate sufficient financial data to pose relevant and plausible claims.

• The resulting thesis will generate knowledge for IT-eye’s management in order for them to improve the marketing related activities for SOA propositions.

Taken into account these preconditions, assures clear guidelines for conducting the research.

1.4 Conceptual Framework

A conceptual framework is an explanation of empirical phenomena. It sets the scope for all the concepts that could be part of the research problem. Various information sources deliver input for this research, which is extensively described in chapter two. Based on this input, the elements in the conceptual framework can be determined. The elements in turn, determine the main research question and sub research questions. Modeling these elements into a conceptual framework, visualizes the relations between the underlying concepts.

(22)

Service-Oriented Architecture Implementation

Framework

Finance Cash flows

Revenues

Costs

SOA Benefits & Detriments Location transparency

Shorter time to market

Increased business orientation of IT

Improved availability

Reuse

Improved scalability Loose coupling Interoperability Service-Oriented

Architecture Implementation

Framework Framework

Revenues

Costs

Revenues

Costs

SOA Benefits & Detriments Location transparency

Reuse

Improved scalability Loose coupling Interoperability SOA Benefits & Detriments Location transparency

Reuse

Improved scalability Loose coupling Interoperability

Figure 1.4 Conceptual Framework

Figure 1.4 as a whole contains the benefits and detriments of SOA, the financial implication components and the framework. The lower left rectangle contains the financial implication components, divided into costs, revenues and cash flows. This subject is outlined in chapter three. The upper right rectangle contains the company benefits and detriments which determine the degree to which the financial performance is affected by a SOA implementation. This can be found in chapter two. The lower right rectangle represents the framework that shall be developed based on the input from the two green rectangles. The framework is described in chapter four.

1.5 Concepts and definitions

The following terms are most frequently used in this research. Therefore they will be explained in order to prevent ambiguity about the used concepts and definitions.

• Service-Oriented Architecture (SOA): The definition of SOA will be outlined briefly here because the current status of SOA requires a more thorough analysis of the SOA concept which can be found in chapter two. A definition to give an impression of SOA is the one from XML.com (He, 2006): SOA is an

architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners.

(23)

• Investment proposal: The definition of an investment proposal in the context of a SOA investment trajectory is the following: 1) It is focused on a delimited section of IT supplies. 2) Scarce financial resources will be devoted to these supplies for a certain amount of time. Financial resources are traded for fixed assets. 3) An investment project is characterized by certain life span. (Berghout, 2005, p. 26)

• Service: A service is a mechanism to enable access to a set of one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. A service is provided by one entity – the service provider – for use by others, but the eventual consumers of the service may not be known to the service provider and may demonstrate uses of the service beyond the scope originally conceived by the provider (OASIS SOA Reference model, 2006: p. 9)

1.6 Research structure

Facilitating a comprehensive sequence of necessary research sections enables a clear overview of these sections. Figure 1.5 summarizes them in a consecutive order.

Chapter 4 Chapter 1 Problem statement

Framework

Chapter 6 Conclusions

Chapter 5 Validation Adaptation

Chapter 3

Financial investment evaluation methods

Literature and Interviews Chapter 2

SOA Benefits and detriments Literature and Interviews

Chapter 4 Chapter 1 Problem statement

Chapter 1 Problem statement

Framework

Chapter 6 Conclusions

Chapter 5 Validation Adaptation Chapter 5 Validation Adaptation

Chapter 3

Literature and Interviews

Chapter 3

Literature and Interviews Chapter 2

SOA Benefits and detriments Literature and Interviews Chapter 2

SOA Benefits and detriments Literature and Interviews

Figure 1.5 Research framework

(24)

Service-Oriented Architecture: Modeling profitability beyond the hype 24 The structure of the thesis will follow the structure of the research framework which contains all research sub questions. Chapter one discusses the research design, including the research objective, questions and preconditions. Chapter two discusses the concept of SOA which entails definitions and a broad classification in layers. In chapter three a review of all relevant literature concerning investment evaluation methods is outlined.

Chapter four merges the SOA components and financial investment evaluation methods into a framework. The framework shall consequently be used to asses the financial performance of an organization after having implemented a SOA, which will be done in chapter five. After having verified the framework conclusions and recommendations will be outlined in chapter six.

1.7 Research relevance

This research aims to contribute to the knowledge base on the field of SOA and the associated financial evaluation methods used in capital budgeting decisions. The scientific and practical relevance can therefore be distinguished.

1.7.1 Research relevance for science

Results from the research will reveal new insights on the financial implications of a SOA implementation. These insights will contribute to the current knowledge on the field of SOA and IT investment evaluation. Researchers can use this knowledge as well as the recommendations for future research resulting from this report.

1.7.2 Research relevance for practice

As described earlier in the problem statement, the research should result in a comprehensive framework which enables IT service organizations to calculate and document the financial implications of a SOA implementation in more detail. This includes the benefits and detriments of SOA as well as investment evaluation methods.

This research is therefore relevant input for the scientific knowledge base as well as a helpful tool for IT service organizations serving them with a financial calculation model.

(25)

2. The concept of Service-Oriented Architecture

Introduction

This chapter describes the fundamentals of a Service-Oriented Architecture and the way in which it can change an organization’s general performance. An architecture is considered the artifact of every organization. A change in an architecture can cause substantial changes in the organizational performance. Therefore this chapter will elaborate on research sub question one: In what way does a Service-Oriented Architecture affect organizational performance in general, and which benefits and detriments determine the financial implications relevant for SOA?

Implementing a SOA results in miscellaneous consequences which all have different scales of measurability (Van Es et al, 2005, p. 85). Intangible changes in the general performance vary from improved customer satisfaction and higher response time till improved staff morale while tangible changes are for example increased sales or lower costs of maintenance. The case of tangible versus intangible benefits and detriments is not typical for SOA, it is a characteristic often associated with investments in Information Technology in general. In this chapter the generic consequences as well as the financial consequences of a SOA will be analyzed. The financial consequences are especially important regarding chapter three and four where they are integrated into a framework.

This chapter is structured as follows. Paragraph 2.1 starts with an exploration of the concept of SOA using data from several documents which all describe SOA characteristics from their own point of view. All literature is assessed according to the definition posed by the authors and distills a new working definition for the purpose of this research. Paragraph 2.2 builds a context in which the consequences of a SOA are structurally outlined. Using two theoretical models a new model is composed to analyze all relevant SOA consequences. The model divides a Business Flexibility layer and an IT Infrastructure layer. Paragraph 2.3 outlines all aspects considering the Business Flexibility layer whereas paragraph 2.4 elaborates on the IT Infrastructure aspects. The

(26)

Service-Oriented Architecture: Modeling profitability beyond the hype 26 conclusion in paragraph 2.5 summarizes the findings and answers the research question for this chapter.

2.1 Definition of Service-Oriented Architecture

The subject of this research, the concept of Service-Oriented Architecture, is still under discussion in relevant scientific journals. Scientists and market participants all share common ideas about the concept of SOA but a single accepted definition hasn’t been agreed upon. Therefore the definition that will define the scope of a Service-Oriented Architecture will be composed of elements from multiple sources. This composition of elements is not meant to be posed as a new definition added to the scientific knowledge base; instead it can be seen as a working definition primarily for this research. The selected sources are scientific researchers who have published about the concept of SOA, non-profit organizations, and marketing related companies working in the IT services field.

Thomas Erl (2005, p. 54) who wrote ‘Service-Oriented Architecture, Concepts, Technology, and Design’ defines SOA as follows:

Contemporary SOA represents an open agile, extensible, federated, composable architecture comprised of autonomous, QoS-capable (Quality of Service), vendor diverse, interoperable, discoverable, and potentially reusable services, implemented as Web services.

SOA can establish an abstraction of business logic and technology, resulting in a loose coupling between these domains.

SOA is an evolution of past platforms, preserving successful characteristics of traditional architectures, and bringing with it distinct principles that foster service-orientation in support of a service-oriented enterprise.

SOA is ideally standardized throughout an enterprise, but achieving this state requires a planned transition and the support of a still evolving technology set.

Dirk Krafzig (2005, p. 57) who wrote ‘Enterprise SOA, Service-Oriented Architecture best practices’ defines SOA as follows:

A Service-Oriented Architecture (SOA) is a software architecture that is based on the key concepts of an application front-end, service, service repository, and service bus. A service consists of a contract, one or more interfaces, and an implementation. […]

Actually, the SOA must decouple business applications from technical services […]

The Gartner Group is a marketing and consulting related company. They publish articles and whitepapers on relevant topics on a frequent basis in the IT industry, and are

(27)

Service-Oriented Architecture: Modeling profitability beyond the hype 27 therefore considered a major stakeholder in the IT services industry. Their definition of SOA is the following: (Cantara, M., 2005).

SOA represents a style of architecture, primarily for application development, that is typically multi-tier and based on the principle of dividing business processes into a series of subunits or services. The services can then be assembled and linked together in a loosely coupled environment to perform a desired application. The services are defined at a level above that of the traditional view of components. Re-use, speed of design and flexibility are the desired goals.

Eric A. Marks and Michael Bell, authors of ‘Service-Oriented Architecture: A Planning and Implementation Guide for Business and Technology’ (2006), consider the concept of SOA according to the following definition:

SOA is a conceptual business architecture where business functionality, or application logic, is made available to SOA users, or consumers, as shared reusable services on an IT network. “Services” in an SOA are modules of business or application functionality with exposed interfaces, and are invoked by messages.

The OASIS Group (Organization for the Advancement of Structured Information Standards) is a not-for-profit, international consortium that drives the development, convergence, and adoption of e-business standards. They define SOA as follows (Reference Model for Service-Oriented Architecture v1.0, 2006, p. 6):

A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

XML.com, an online community gathering place for people interested and involved in XML-related standards and specifications define the concept of SOA as follows:

(www.xml.com, available on 12/15/2006)

SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer.

Both provider and consumer are roles played by software agents on behalf of their owners.

Robert Uleman (2006, p. 31) defines SOA in his articles as:

A SOA is an enterprise IT architecture that supports business processes through solutions assembled from services, where a service is a well defined, repeatable business task.

The elaborated definitions from these seven major influential sources can now be analyzed to their respective elements. These elements are a good representation of the opinions of the major sources on the subject of Service-Oriented Architecture and are therefore a valid source for the composition of a working definition.

(28)

SOA entails: Thomas Erl

Dirk Krafzig

Erik A. Marks and Michael Bell

OAS IS

Gartner Group

XML.org Robert Uleman

# of hits

Architectural style + + + + + + ⁶

Reuse of

functionality + + + + ⁴

Separate capabilities into composite functionality

+ + + + ⁴

Enabling loose

coupling + + + + ⁴

Supports business

processes + + ²

Increased speed

of design + ¹

Using web

services + ¹

A level above traditional

components + ¹

Built in multiple

tiers + ¹

Bringing needs and capabilities

together + ¹

QoS-capable + ¹

Discoverable + ¹

Vendor diverse + ¹

Is a paradigm + ¹

Supports

interoperability + ¹

Table 2.1 Elements of a SOA definition, according to respective authors

After counting all the elements, we can distinguish the relevant and crucial elements and shift them from the more irrelevant elements. The elements that were mentioned most will be explained and placed into a comprehensive working definition. The term

‘working definition’ refers to the fact that this thesis does not aim to pose a new definition to the scientific knowledge base, rather it uses it to structure the concept of SOA throughout this research.

Summarizing all the elements and merging them into a phrase produces the following working definition:

‘ A Service-Oriented Architecture is an architectural style, which enables loose coupling of services, reuse of functionality and has the ability to separate capabilities into composite functions to support business processes’.

This former definition shall be used to define and set the scope for the concept of SOA used in this thesis. It contains a set of five elements which can be explained as follows.

(29)

Service-Oriented Architecture: Modeling profitability beyond the hype 29 Loose coupling refers to the act of joining things together, such as the links of a chain (Van Es et al, 2005, p. 59). In the software world, loose coupling typically refers to the degree to which software components depend upon each other. Loose coupling between two coupled entities is the absence of requirement of changing one entity when the other one changes. This is usually achieved by describing how to communicate with the entity without describing anything about the inner workings of it – this ensures that other entities cannot make assumptions about it. Striving to design the links between software modules in such a way that dependencies between modules will be minimized; this decreases the risk that a change in one module results in a change in another module (Van Es et al, 2005, p. 59).

Architectural Style is considered the fundamental organization of a system, embodied in its components, the relationships between the components and its environment, and the principles guiding its design and evolution (Van Es et al, 2005, p 62).

Reuse of functionality. “Reuse is the process of adapting a generalized component to various contexts of use” (Basset, 1997, p 44). Reusing services is deploying services multiple times for other purposes. This process fosters lower development costs for the services as well as the decreased maintenance costs, while the development time can be shortened and a higher level of quality can be achieved (Poulin et al, 1993, p. 573).

Separate capabilities into composite functions. Separate capabilities are considered the services that are used in a SOA. Composite functionality, is seen as a service in itself as well, which exists of multiple services being ‘organized’ to perform a certain task – effectively creating a tree structure. This matches the objectives of SOA and accurately describes the way SOA can combine services on all levels.

The support of business processes is an element which is not linked to a high number of hits in table 2.1. Although just two authors include this element in their definition it refers to an important aspect in this research. The emphasis on financial aspects of a SOA requires a thorough understanding of the value adding processes conducted in an organization. Therefore the element of business process support needs to be included in the working definition and falls within the scope of the research.

(30)

Service-Oriented Architecture: Modeling profitability beyond the hype 30 The working definition serves as a reference for setting the scope of SOA throughout this thesis but is an important input for the framework as well. After having established the working definition the scope has been set for the remainder of this research.

2.2 General overview of a Service-Oriented Architecture implementation

In order to pose valid conclusions on the financial implications of a SOA implementation, first the consequences of the influence of SOA on business processes need to be identified. Therefore literature research is conducted to explore which models are available to identify the general consequences a SOA inflicts on an organization.

Comprehensive models are needed to categorize these consequences and to provide a comprehensive overview. Among the scarcely available models are the ones from Rao et al. (2006) and from Marks and bell (2006). Rao’s model describes possible consequences from a commercial viewpoint where business benefits and cost savings are emphasized.

A pervasive aspect of this model is the distinction between tangible and intangible proceedings from SOA. Although intangible benefits often are often not taken into account in investment appraisals (Pearlson and Saunders, 2006, p. 262), quantified intangible benefits can adequately support decision making on IT investments.

IT Cost savings Top Line benefits

Higher productivity Time to market Low cost products Availability Shorter test cycle Process automation

Tangible

Improved connectivity Location transparency

Interoperability Better managed code base Reduced risk

Simpler compliance Customer satisfaction

Intangible

Transaction costs

Figure 2.1 SOA Benefits model, Rao et al. 2006

A second model developed to describe SOA consequences is from Marks and Bell (2006, p 344). Their SOA value model aims to distinguish all value drivers as well as the associated ROI models. The left column in figure 2.2 contains the relevant advantages