Service-Oriented Design and Development Methodology by Papazoglou and Van Den Heuvel (2006)

Service-Oriented Design and Development Methodology by Papazoglou and Van Den Heuvel (2006) Eline de Haan - 4183134 Method Engineering - Group B Final paper April 11 th 2014 Notice of Originality I declare that this paper is my own work and that information derived from published or unpublished work of others has been acknowledged in the text and has been explicitly referred to in the list of references. All citations are in the text between quotation marks ( ). I am fully aware that violation of these rules can have severe consequences for my study at Utrecht University. Signed: Date: Name: Place:

Introduction The rapidly changing business environment forces enterprises to be capable of quickly adapting their operations to the various kinds of demands. Due to the dynamic environment, process models and services need to be adjusted occasionally (Pesic & van der Aalst, 2006). An approach to respond to this challenge is the Service-Oriented Architecture (SOA) approach. SOA is centered around the idea of using loosely coupled and distributed components that provide or consume services (Bass, Clements, & Kazman, 2012). A service is defined by Papazoglou and Van Den Heuvel (2007, p. 389) as: a well-defined, self-contained module that provides standard business functionality and are independent of the state or context of other services. However, the use of SOA entails a challenge given the fact that the existing processes and software of most enterprises need to be adapted or redesigned which is a time-consuming and complicated task (Papazoglou & Van Den Heuvel, 2007). Therefore, the authors established the Service-Oriented Design and Development method which provides guidelines to design business processes and services. The objective of the method is to assist designers and developers to perform service-oriented development projects for service integration and service interoperability. Two concepts underlie this method namely 1) service coupling and 2) service cohesion. Papazoglou and Van Den Heuvel (2006, p. 4) define service coupling as: the degree of interdependence between two business processes and service cohesion as the degree of the strength of functional relatedness of operations within a service. The Service-Oriented Design and Development method distinguishes nine different phases (see Figure 1). The first phase of the method is the planning phase, which is considered as a preliminary task of the organization. The aim of this phase is to outline the subsequent phases by determining among other things the project s scope, business environment, objectives, budget, guidelines and requirements. Thereafter, the analysis phase is performed which involves an extensive analysis of the business case and the as-is situation. This analysis provides insight for modeling the to-be situation by focusing on the reuse of current available functionalities, web-services, or business processes. Four subactivities can be designated in this phase which are performed by business analysts and developers: 1) Process identification, 2) Process scoping, 3) Business gap analysis, and 4) Process realization analysis. During the next phase, the design phase, the business processes and services are being identified and specified by the developers. These specifications are utilized for the service construction phase, that entails the implementation of the web-services and business processes. Both the provider side as the service requesters side are taken into account by the developers involved in this phase. Subsequently, the testing phase is executed by testers to check if the constructed web-services and business processes meet the set requirements. In the service provisioning phase, the deployment aspects of the web-services are examined with regard to revenue generation. After the service provisioning, the created processes and services are rolled out to all stakeholders during the deployment phase. Finally, the processes and services are executed in the execution phase and their service levels are measured and evaluated based on a Service Level Agreement (SLA) in the monitoring phase. The previous description of the phases implies a linear process. However, this method is not linear but an iterative and incremental approach. 2

Figure 1. Phases of the method inspired by Papazoglou and Van Den Heuvel (2006) The method is devised by two professors, Michael P. Papazoglou and Willem-Jan van den Heuvel, employed at the University of Tilburg in the Netherlands. Currently, prof. Papazoglou holds the chair of Computer Science and is director of the INFOLAB at the Tilburg University. His work comprises the creation of fifteen books and many journal articles and papers related to the following areas: Service-Oriented Computing and web-services, information systems, enterprise application integration, and technologies regarding e-business and Information Discovery (Papazoglou, 2014). Prof. van den Heuvel is a full professor in Information Systems at the Tilburg University and holds the position of Managing Director of the European Research Institute of Services Science (ERISS). His prior research work covers among others the following topics: software service systems, serviceoriented computing, business process management, service engineering, and legacy system modernization (Van Den Heuvel, 2014). Example In this section, an example is given to provide insight into the application of the method. For this example, an imaginary company (IC) is used which aims to become more flexible for the customer. To achieve this aim, IC decides to perform a software development project to (re)-design their business processes according to the Service-Oriented Design and Development method. In order to explain the specific workings of each phase of the method, the example is used to go through each phase step by step based on the cycle as depicted in Figure 1. The project starts with the planning phase, during this phase IC determines the scope and goals of the project. Furthermore, a development plan is made to prepare for the subsequent phases and a financial analysis is performed that serves as indication of the costs and benefits. In the analysis phase, the business analysts and developers of IC perform four main activities. During the first two activities, process identification and process scoping, a model of the as-is situation is established which functions as portfolio of the current processes and services. To create this portfolio, both the scope and the services that should be covered by a process are identified by taking the two main concepts coupling and cohesion into account. Subsequently, this portfolio is analyzed to determine on which business processes the focus should lie in order to achieve the business goals. Then, the analysts create a model of the to-be situation showing the processes which can be reused or require to be re-designed. For this example, it is considered that only one business process will be affected namely: the Permit Request process. The third and fourth activity involve a business gap and process realization analysis. Both analyses are used to select an appropriate realization strategy or a combination of strategies for the development of new business processes and web-services. The following realization options are available: Green-field, Top-down, Bottom-up, and Meet-in-themiddle (Brittenham, 2001). For this example, the Green-field development strategy is chosen because it is suggested that the Permit Request business process and its related services need to be built from scratch. 3

Since the focus and development strategy are made clear, IC can start with the design phase. This phase is divided into two sub-phases: 1) specifying services and 2) specifying business processes. During the first sub-phase, the services are specified by means of a service specification. This service specification includes three elements: structural specification, behavior specification and policy specification (Papazoglou & Van Den Heuvel, 2006). Furthermore, the service programming style should be determined. To create the services, the designers should take three design principles into account: granularity, reusability and composability. In the second sub-phase, the business processes are designed based on the conceptual models conceived in the analysis phase. This sub-phase should also consider the non-functional requirements, which could be captured in a Service Level Agreement (SLA). In the paper, the Business Process Execution Language (BPEL) is used for modeling the example process. However, for the creation of this example the Business Process Modeling Notation (BPMN) is applied, given the fact that this is a standard of the Object Management Group (OMG) for process modeling (Object Management Group, 2011). Figure 2 shows a detailed example of one deliverable of the design phase of the method. The figure depicts the process flow, functions, and roles of the Permit Request business process which was selected for re-design in the analysis phase. Figure 2. Permit Request process The project continues with the construction phase, in this phase the designed services and processes will be implemented based on the process realization scenario identified in the analysis phase. In this case, it corresponds to the Green-field development strategy. Then, the service implementation will be validated in the test phase. The test team will select certain kinds of tests to perform. The aim of these tests is to assess if the established service-oriented solution meets the customers requirements. During the next phase, provisioning phase, the governing body of IC should consider several implications in relation to service provisioning namely: service governance, service certification, service enrolment, service auditing, metering, and billing as denoted by Papazoglou and Van Den Heuvel (2006). Next, the deployment phase is executed in which the processes and services are implemented by all parties involved such as other organizations. The deployment phase is logically followed by the execution phase, this phase makes the services and processes operational thus making them available to all users. Then in the monitoring phase, the run-time behavior of the services and processes are constantly evaluated by means of an established list of Quality of Service (QoS) metrics. The aim is to improve the overall quality of the service-oriented solution. As mentioned previously, the above described example is used to explain the application of the method and gives an explicit instance of one deliverable resulting from the design phase. This deliverable is a business process model. In order to reproduce this deliverable, a template is provided in Appendix 1. This template focusses on the creation of a business process according to BPMN, and contains the main elements of this modeling language. In other words, not all existing elements are considered only a subset of BPMN elements is included which comprises the following: pools, lanes, activities, sequence flows, gateways, and events (see Appendix 1). 4

Pools and lanes are used to denote who performs what during a process. Pools usually represent organizations, and lanes usually represent departments or roles within these organizations. Activities can be categorized into tasks or sub-processes (Dijkman, Dumas, & Ouyang, 2008). A task is defined as an atomic activity standing for work to be performed, and a sub-process is defined as a compound activity; a flow of other activities by Dijkman et al. (2008). This distinction is denoted by including a plus sign in the rectangle for the latter one. The activities are connected through sequence flows that show the order in which the process should be executed. Gateways are used to model business decisions made during the process. Different types of gateways exist, but for this template only a parallel (AND) gateway is shown which either splits a flow into concurrent flows or synchronizes two or more concurrent flows into one flow. Moreover, a process model contains events which affect process flows either by triggering a process flow (start events), or events ending a process flow (end events). The flow of a process is built up by modeling the events that occur to start a process, the activities that get performed, and the end result of the process flow. In summary, this template can function as basis for the establishment of business process models. If a more complex model should be created, this template can be extended with the disregarded elements of BPMN. However, these elements are outside the scope of this paper. For a whole overview and explanation of these BPMN elements, see Silver (2009). Process-Deliverable Diagram In this section, the Process-Deliverable Diagram (PDD) of the Service-Oriented Design and Development method is provided along with a description. Furthermore, the corresponding activity table and concept table are included in the succeeding sections. The necessity of capturing methods is derived from the method engineering domain. Method engineering is defined by Brinkkemper (1996) as: the engineering discipline to design, construct and adapt methods, techniques and tools for the development of information systems. In order to be able to execute a method, it needs to be defined for which various modeling techniques are available (Van de Weerd & Brinkkemper, 2008). In this case, the meta-modeling technique proposed by Saeki (2003) is applied which is partly based on Unified Modeling Language (UML) (Object Management Group, 2004). By means of this technique a PDD is created to depict the meta-model of the method. A PDD is compiled from two models: a meta-process model and a meta-data model. The meta-process model is positioned at the left side, which represents the process side containing the activities and transitions of the method. This part of the PDD is based on a UML activity diagram (Object Management Group, 2004), which is defined by Booch, Rumbaugh, and Jacobson (1999) as: a diagram that shows the flow from activity to activity; activity diagrams address the dynamic view of a system. On the right side of the PDD, the meta-data model is positioned which depicts the deliverable view comprising the deliverables of the method. This right part of the PDD is partly based on a UML class diagram (Object Management Group, 2004), which is a diagram that shows a set of classes, interfaces, and collaborations and their relationships according to Booch et al. (1999). Figure 3 shows the specific PDD of the Service-Oriented Design and Development method. 5

Figure 3. PDD of the Service-Oriented Design and Development method 6

PDD description The Service-Oriented Design and Development method consists of nine main phases, of which the design phase consists of two sub-phases labeled as: the service design phase and business process design phase. In Figure 3, these phases and sub-phases correspond to the ten main activities of the PDD depicted as grey boxes: 1) Planning phase, 2) Analysis phase, 3) Service design phase, 4) Business process design phase, 5) Construction phase, 6) Test phase, 7) Provisioning phase, 8) Deployment phase, 9) Execution phase, and 10) Monitoring phase. The first main activity consists of four subsequent sub-activities: analyze business needs, review current technology landscape, conceptualize requirements, and perform financial analysis. Firstly, the project manager analyzes the business needs to establish measurable BUSINESS GOALs. Secondly, he reviews the CURRENT TECHNOLOGY LANDSCAPE. Thirdly, each REQUIREMENT is conceptualized by the project manager which results in a REQUIREMENT LIST. Finally, he performs a FINANCIAL ANALYSIS of the benefits and costs. All previous mentioned deliverables are part of the PROJECT PLAN. It is assumed that these four sub-activities consist of other sub-activities, however this information is not available. Therefore, they are modeled as closed activities. The second main activity also consists of four sub-activities. The first two sub-activities, identify processes and scope processes, are strongly interconnected and are performed in parallel. During these sub-activities, the business analyst and developer identify the CURRENT BUSINESS PROCESSes and CURRENT WEB-SERVICEs, at the same time the SCOPE of each BUSINESS PROCESS is determined. This results in the CURRENT PORTFOLIO of the organization. Then, they perform a business gap analysis whereby a GAP ANALYSIS STRATEGY is created. Subsequently, the last sub-activity perform process realization analysis is executed. This activity involves that the business analyst and developer define every NEW BUSINESS PROCESS and NEW WEB-SERVICE, which will be included in the DEVELOPMENT PORTFOLIO. Furthermore, they select one or more REALIZATION OPTIONs which are also part of the DEVELOPMENT PORTFOLIO. Four REALIZATION OPTIONs are defined, namely: GREEN-FIELD DEVELOPMENT, TOP-DOWN DEVELOPMENT, BOTTOM-UP DEVELOPMENT, and MEET-IN-THE-MIDDLE- DEVELOPMENT. The third and fourth main activity are executed in parallel. During the main activity service design phase, three sub-activities are performed in sequence: the developer defines the STRUCTURAL SPECIFICATION, thereafter he defines the BEHAVIORAL SPECIFICATION, and as last he defines the POLICY SPECIFICATION. These three specifications are aggregated into a SERVICE SPECIFICATION. During the other main activity business process design phase, also three subactivities are executed in sequence: the developer describes the BUSINESS PROCESS STRUCTURE, thereafter he describes the BUSINESS ROLEs, and as last he describes the NON-FUNCTIONAL CHARACTERISTICs. A BUSINESS PROCESS STRUCTURE and a BUSINESS ROLE are both a specific kind of FUNCTIONAL CHARACTERISTIC. Both the FUNCTIONAL CHARACTERISTICs as the FUNCTIONAL CHARACTERISTICs are part of a BUSINESS PROCESS MODEL. The fifth main activity includes three sub-activities. Firstly, the developer develops the WEB- SERVICE(s). Secondly, he defines the WEB-SERVICE INTERFACE DEFINITION(s). Lastly, he defines the WEB-SERVICE IMPLEMENTATION DEFINITION(s). The sixth main activity comprises two sub-activities: select test(s) and execute test(s). As first, the tester selects one or more TESTs. He can choose between the following types of tests: DYNAMIC TEST, FUNCTIONAL TEST, PERFORMANCE TEST, INTERFACE TEST, ASSEMBLY TEST, NETWORK CONGESTION TEST, SECURITY TEST, INSTALLABILITY TEST, COMPATIBILITY TEST, USABILITY TEST, and UPGRADE TEST. After the tester has selected one or more TESTs, he will execute the TEST(s) which results in a VALIDATED SERVICE- ORIENTED APPLICATION. 7

The seventh main activity covers three sub-activities. Firstly, the project manager establishes a SERVICE GOVERNANCE MODEL which can be either a DISTRIBUTED GOVERNANCE MODEL or a CENTRAL GOVERNANCE MODEL. Secondly, he establishes a SERVICE CERTIFICATION. Thirdly, he establishes a SERVICE METERING MODEL, a SERVICE RATING MODEL and a SERVICE BILLING MODEL. The latter one is associated with the SERVICE RATING MODEL, because the SERVICE RATING MODEL serves as foundation. All previous products are aggregated into a PROVISIONING MODEL. The eighth main activity exists of two sub-activities: publish web-service interface definition(s) and publish web-service implementation definition(s). The developer first publishes the WEB-SERVICE INTERFACE DEFINITION. Then, he publishes the WEB-SERVICE IMPLEMENTATION DEFINITION. The first sub-activity produces a PUBLISHED WEB-SERVICE INTERFACE, and the second sub-activity eventually leads to a DEPLOYED WEB-SERVICE. The ninth main activity consist of only one activity called execute web-service(s). During this activity, the user executes the WEB-SERVICE which then becomes a RUNNING WEB-SERVICE. The tenth main activity includes three continuous activities: measuring, monitoring and reporting the quality of service (QoS) which are performed by the continual service improvement (CSI) manager. The first sub-activity results in a QUALITY MATRIX, the second sub-activity in a SERVICE LEVEL AGREEMENT (SLA), and the third sub-activity in a QUALITY REPORT. These three deliverables report on the QoS level of the RUNNING WEB-SERVICE. If it turns out that the measured QoS level complies to the required performance level, the quality is approved and the process is ended. Else, the process will return to the construction phase and the developer has to re-develop the WEB-SERVICE. In the following sections, the above mentioned activities and concepts are explained in more detail (see Table 1 and 2). 8

Activity table Table 1 shows the activity table which corresponds to the left-hand side of the established PDD as depicted in Figure 3. The activity table provides a specification and consists of three columns. The left column lists the main activities, the middle column lists the sub-activities, and the right column includes a short description of the (sub-)activities and their connection to the concepts. Activity Sub-Activity Description Analyze business needs Planning phase Analysis phase Service design phase Review current technology landscape Conceptualize requirements Perform financial analysis Identify processes Scope processes Perform business gap analysis Perform process realization analysis Define structural specification Define behavioral specification Define policy specification At this sub-activity, the business needs are converted to measurable BUSINESS GOALs by the project manager. These BUSINESS GOALS are aggregated into a PROJECT PLAN. The project manager assesses all IT-assets and their relations in use by the organization, in order to establish the CURRENT TECHNOLOGY LANDSCAPE which is also included in a PROJECT PLAN. The REQUIREMENTs are gathered and conceptualized into a REQUIREMENT LIST by the project manager. This REQUIRMENT LIST is also incorporated into a PROJECT PLAN. The last part of the PROJECT PLAN is a FINANCIAL ANALYSIS of the costs and benefits, which is performed by the project manager. This sub-activity is performed in parallel with the sub-activity scope processes by a collaboration of the business analyst and developer. In this sub-activity, they develop a CURRENT PORTFOLIO by identifying the CURRENT BUSINESS- PROCESSes and CURRENT WEB-SERVICEs. In order to support the identification of processes, the SCOPE of each CURRENT BUSINESS PROCESS is determined in this subactivity. The SCOPE ensures that a BUSINESS PROCESS does not become too small or too large and complex. A GAP ANALYSIS STRATEGY is established by performing a business gap analysis, which involves the comparison of in-house service functionality with available service functionality. The business analyst and developer perform a process realization analysis in order to identify the NEW BUSINESS PROCESSes and NEW WEB-SERVICEs that have to be developed, which are aggregated into a DEVELOPMENT PORTFOLIO. Furthermore, they select one or more REALIZATION OPTIONs for the development of these NEW BUSINESS PROCESSes and NEW WEB-SERVICEs. They can choose between the following four REALIZATION OPTIONs: GREEN-FIELD DEVELOPMENT, TOP-DOWN DEVELOPMENT, BOTTOM-UP DEVELOPMENT, and MEET-IN-THE-MIDDLE DEVELOPMENT. The data interchange, service and port types, and operations of the NEW WEB-SERVICEs have to be specified by the developer. This results in a STRUCTURAL SPECIFICATION which is included into a SERVICE SPECIFICATION. The second part of the SERVICE SPECIFICATION is also established by the developer and corresponds to the BEHAVIORAL SPECIFICATION. This defines the semantics of the operations of WEB-SERVICEs. The third part of the SERVICE SPECIFICATION is the POLICY SPECIFICATION in which the developer defines the policy 9

Business process design phase Construction phase Describe business process structure Describe business roles Describe nonfunctional characteristics Develop webservice(s) Define webservice interface definition(s) Define webservice implementation assertions. To design BUSINESS PROCESSes, first the BUSINESS PROCESS STRUCTURE has to be determined by the developer. This BUSINESS PROCESS STRUCTURE is a special type of FUNCTIONAL CHARACTERISTIC. After the BUSINESS PROCESS STRUCTURE of each BUSINESS PROCESS is clear, the developer should assign BUSINESS ROLEs. BUSINESS ROLEs are also a special type of FUNCTIONAL CHARACTERISTIC. Besides the FUNCTIONAL CHARACTERISTICs, the developer considers and specifies the NON-FUNCTIONAL CHARACTERISTICs of the BUSINESS PROCESSes. The established SERVICE SPECIFICATION and designed BUSINESS PROCESSes are used by the developer as input for coding the WEB-SERVICEs. After the WEB-SERVICEs are developed, the developer creates the WEB-SERVICE INTERFACE DEFINITIONs. Based on the WEB-SERVICE INTERFACE DEFINITIONs, the WEB-SERVICE IMPLEMENTATION DEFINITIONs are described by the developer. definition(s) Test phase Select test(s) The tester first has to choose one or more types of TESTs he wants to perform. The following test types are defined: DYNAMIC TEST, FUNCTIONAL TEST, PERFORMANCE TEST, ASSEMBLY TEST, INTERFACE TEST, NETWORK CONGESTION TEST, SECURITY TEST, INSTALLABILITY TEST, COMPATIBILITY TEST, USABILITY TEST, and UPGRADE TEST. Provisioning phase Execute test(s) Establish service governance model Establish service certification Establish service metering and rating model The developed WEB-SERVICEs, WEB-SERVICE INTERFACE DEFINITIONs, and WEB-SERVICE IMPLEMENTATION DEFINITONs have to be tested in order to check if they meet the set REQUIREMENTs. The tester performs the selected TEST(s), which results in a VALIDATED SERVICE-ORIENTED APPLICATION. By performing internal reviews and using the GAP ANALYSIS STRATEGY, the project manager creates a SERVICE GOVERNANCE MODEL. Two types of GOVERNANCE MODELs exist: 1) a DISTRIBUTED GOVERNANCE MODEL and 2) a CENTRAL GOVERNANCE MODEL. This SERVICE GOVERNANCE MODEL is included in the PROVISIONING MODEL, and helps to align the business strategy with the IT initiatives. The project manager defines the required properties of the WEB- SERVICEs in a SERVICE CERTIFICATION. This SERVICE CERTIFICATION is added to the PROVISIONING MODEL. Subsequently, the project manager makes a SERVICE METERING MODEL in order to meter the usage of WEB- SERVICEs by a client. After the SERVICE METERING MODEL is established, the SERVICE RATING MODEL is created to charge for the usage. Then, the SERVICE BILLING MODEL is made to associate the rating information with the correct client account. All these models are integrated into the PROVISIONING MODEL. 10

Deployment phase Execution phase Monitoring phase Table 1. Activity table Publish webservice interface definition(s) Publish webservice implementation definition(s) Execute webservice(s) Measure quality of service (QoS) Monitor quality of service (QoS) Report quality of service (QoS) The first step to realize DEPLOYED WEB-SERVICEs is to roll out the WEB-SERVICE INTERFACE DEFINITIONs, that are defined during the construction phase. This action results in PUBLISHED WEB-SERVICE INTERFACEs, which ensures that the service requester can determine how to bind to the WEB- SERVICEs. The second step to finalize the deployment, is to implement and publish the defined WEB-SERVICE IMPLEMENTATION DEFINITIONs. After this step, the WEB-SERVICEs are fully DEPLOYED WEB-SERVICEs. During this sub-activity, the user will run the DEPLOYED WEB- SERVICEs which then become RUNNING WEB-SERVICEs. The quality of service (QoS) of the RUNNING WEB-SERVICEs has to be measured. This is done by the continual service improvement manager. The outcome of this measurement is represented by a QUALITY MATRIX. Besides measuring the QoS of the RUNNING WEB-SERVICEs, it has to be monitored. Monitoring is ensured due to the creation of a SERVICE LEVEL AGREEMENT (SLA) by the continual service improvement manager. The measuring and monitoring activity serve as input for reporting on the QoS. The continual service improvement manager makes a QUALITY REPORT in this step. 11

Concept table The concept table is shown in Table 2, which matches to the right-hand side of the created PDD as depicted in Figure 3. The concept table lists every concept that is included in the PDD and provides a description of each concept. Concept PROJECT PLAN BUSINESS GOAL CURRENT TECHNOLOGY LANDSCAPE REQUIREMENT REQUIREMENT LIST FINANCIAL ANALYSIS CURRENT PORTFOLIO CURRENT WEB- SERVICE CURRENT BUSINESS PROCESS SCOPE GAP ANALYSIS STRATEGY DEVELOPMENT PORTFOLIO NEW BUSINESS PROCESS NEW WEB- SERVICE REALIZATION OPTION Description A PROJECT PLAN is a high-level plan which provides information about the major products of the project, the delivery times and the costs. It is a control document for comparing the actual progress against expectations (Office of Government Commerce, 2009). A BUSINESS GOAL represents a measurable business need, it is the end state that a stakeholder intends to achieve (The Open Group, 2012). A CURRENT TECHNOLOGY LANDSCAPE is the representation of all ITassets and their relations in use by an organization (The Open Group, 2012). A REQUIREMENT is a formal statement representing a business need which should be pursued by the development company (Office of Government Commerce, 2011). A REQUIREMENT LIST consists of all REQUIREMENTs that are conceptualized by the project manager (Office of Government Commerce, 2011). A FINANCIAL ANALYSIS provides an overview of the balance between costs and benefits of a project. A FINANCIAL ANALYSIS comprises a budget and a software development plan including a schedule, deliverables, and tasks (Papazoglou & Van Den Heuvel, 2006). A CURRENT PORTFOLIO includes the current available WEB-SERVICEs and BUSINESS PROCESSes in an organization (Office of Government Commerce, 2011). A CURRENT WEB-SERVICE is a WEB-SERVICE which currently exists in an organization, and is part of the CURRENT PORTFOLIO (W3C, 2004). A CURRENT BUSINESS PROCESS is a BUSINESS PROCESS which currently exists in an organization, and is part of the CURRENT PORTFOLIO. A BUSINESS PROCESS is the flow of activities that represent the steps required to achieve a business objective (Object Management Group, 2011). A SCOPE defines the starting and end point of a BUSINESS PROCESS. Furthermore, it specifies the users, input and output, and external entities of a BUSINESS PROCESS (Papazoglou & Van Den Heuvel, 2006). A GAP ANALYSIS STRATEGY comprises a recommendation with regard to the development of BUSINESS PROCESSes and WEB-SERVICEs (Office of Government Commerce, 2011). A DEVELOPMENT PORTFOLIO consists of the NEW BUSINESS PROCESSes and NEW WEB-SERVICEs that will be developed during the project (The Open Group, 2012). A NEW BUSINESS PROCESS is a BUSINESS PROCESS that is required in the to-be situation, and is part of the DEVELOPMENT PORTFOLIO (Object Management Group, 2011). A NEW WEB-SERVICE is a WEB-SERVICE that is required in the to-be situation, and is part of the DEVELOPMENT PORTFOLIO (W3C, 2004). A REALIZATION OPTION is an approach to develop BUSINESS PROCESSes and WEB-SERVICEs. There are four basic REALIZATION OPTIONs that a service provider can use: GREEN-FIELD DEVELOPMENT, TOP-DOWN DEVELOPMENT, BOTTOM-UP DEVELOPMENT, and MEET-IN-THE-MIDDLE DEVELOPMENT 12

GREEN-FIELD DEVELOPMENT TOP-DOWN DEVELOPMENT BOTTOM-UP DEVELOPMENT MEET-IN-THE- MIDDLE- DEVELOPMENT SERVICE SPECIFICATION STRUCTURAL SPECIFICATION BEHAVIORAL SPECIFICATION POLICY SPECIFICATION BUSINESS PROCESS MODEL FUNCTIONAL CHARACTERISTIC BUSINESS PROCESS STRUCTURE BUSINESS ROLE NON-FUNCTIONAL CHARACTERISTIC WEB-SERVICE WEB-SERVICE INTERFACE DEFINITION (Brittenham, 2001). GREEN-FIELD DEVELOPMENT is a specific REALIZATION OPTION for developing NEW BUSINESS PROCESSes and NEW WEB-SERVICEs. This option assumes that everything should be built up from scratch by starting with the creation of a NEW WEB-SERVICE and subsequently the WEB-SERVICE INTERFACE will be created (Brittenham, 2001). TOP-DOWN DEVELOPMENT is a specific REALIZATION OPTION, by means of this option a NEW WEB-SERVICE can be developed that corresponds to an existing WEB-SERVICE INTERFACE. Usually, a standard type of WEB-SERVICE INTERFACE is used (Brittenham, 2001). BOTTOM-UP DEVELOPMENT is a specific REALIZATION OPTION, this option is applied to create a NEW WEB-SERVICE INTERFACE for an existing application. In order to create the WEB-SERVICE INTERFACE, the application programming interface (API) of the application is used (Brittenham, 2001). MEET-IN-THE-MIDDLE DEVELOPMENT is a specific REALIZATION OPTION for developing a NEW WEB-SERVICE in case both the WEB- SERVICE INTERFACE and the application that will be used for the WEB- SERVICE already exist (Brittenham, 2001). A SERVICE SPECIFICATION specifies the NEW WEB-SERVICEs and consists of three specification elements: a STRUCTURAL SPECIFICATION, a BEHAVIORAL SPECIFICATION, and a POLICY SPECIFICATION (Papazoglou & Van Den Heuvel, 2006). A STRUCTURAL SPECIFICATION is part of a SERVICE SPECIFICATION and defines the data interchange, service and port types, and operations of WEB-SERVICEs (Papazoglou & Van Den Heuvel, 2006). A BEHAVIORAL SPECIFICATION is part of a SERVICE SPECIFICATION and defines the semantics of the operations and input and output messages of WEB-SERVICEs (Papazoglou & Van Den Heuvel, 2006). A POLICY SPECIFICATION is part of a SERVICE SPECIFICATION and defines the policy assertions and constraints on WEB-SERVICEs. Policy assertions correspond to the non-functional service concerns like authorization, security, manageability, etc. (Papazoglou & Van Den Heuvel, 2006). A BUSINESS PROCESS MODEL is a representation of a BUSINESS PROCESS (Object Management Group, 2011). A FUNCTIONAL CHARACTERISTIC is a property that deals with the functional aspects of a BUSINESS PROCESS (International Organization for Standardization, 2011). A BUSINESS PROCESS STRUCTURE is part of a BUSINESS PROCESS and refers to its logical flow. It provides the sequence in which the activities should be performed (Papazoglou & Van Den Heuvel, 2006). A BUSINESS ROLE corresponds to an organizational function which has specific responsibilities for performing activities in a BUSINESS PROCESS (Object Management Group, 2011). A NON-FUNCTIONAL CHARACTERISTIC is a property of a BUSINESS PROCESS MODEL which deals with transactional behavior (Papazoglou & Van Den Heuvel, 2006). A WEB-SERVICE is a well-described and self-contained software application including an open, internet-oriented interface (W3C, 2004). A WEB-SERVICE INTERFACE DEFINITION provides a description of the sequences of messages that a WEB-SERVICE submits and/or receives. Related messages are grouped into operations. An operation is a sequence of 13

WEB-SERVICE IMPLEMENTATION DEFINITION TEST DYNAMIC TEST FUNCTIONAL TEST PERFORMANCE TEST INTERFACE TEST ASSEMBLY TEST NETWORK CONGESTION TEST SECURITY TEST INSTALLABILITY TEST COMPATIBILITY TEST USABILITY TEST UPGRADE TEST VALIDATED SERVICE- ORIENTED APPLICATION PROVISIONING MODEL SERVICE GOVERNANCE input and output messages (Brittenham, 2001). A WEB-SERVICE IMPLEMENTATION DEFINITION provides the definition of the network-accessible endpoint or endpoints where the WEB- SERVICE can be invoked (Brittenham, 2001). A TEST is an approach to verify if a WEB-SERVICE, BUSINESS PROCESS, etc. meets its specification or agreed REQUIREMENTs (Office of Government Commerce, 2011). A DYNAMIC TEST is a specific type of TEST that involves the real implementation of a WEB-SERVICE, and then testing if the actual behavior corresponds to its expected behavior before it is deployed (Papazoglou & Van Den Heuvel, 2006). A FUNCTIONAL TEST is a specific type of TEST that comprises testing the performance level of the required functions of a system. Functions include for example data manipulation and user commands (Papazoglou & Van Den Heuvel, 2006). A PERFORMANCE TEST is a specific type of TEST during which the system s online response times and transaction rates are monitored for different varieties of workloads (Papazoglou & Van Den Heuvel, 2006). An INTERFACE TEST is a specific type of TEST that verifies if interfaces interact in the right way with other service functions (Papazoglou & Van Den Heuvel, 2006). An ASSEMBLY TEST is a specific type of TEST which checks if the WEB- SERVICEs function properly once assembled into BUSINESS PROCESSes (Papazoglou & Van Den Heuvel, 2006). A NETWORK CONGESTION TEST is a specific type of TEST during which a lot of data is generated to determine the network s point of failure (Koomen, Van der Aalst, Broekman, & Vroon, 2006). A SECURITY TEST is a specific type of TEST which validates the capability of a software product s security mechanisms with regard to the protection of information and data against unauthorized persons or systems (Koomen et al., 2006). An INSTALLABILITY TEST is a specific type of TEST that tests the capability of the software product to be installed in a specific environment (Koomen et al., 2006). A COMPATIBILITY TEST is a specific type of TEST which tests the ease with which software can be transferred into its intended environment (Koomen et al., 2006). An USABILITY TEST is a specific type of TEST that tests the capability of the software product to be understood, learned, and used by the user (Koomen et al., 2006). An UPGRADE TEST is a specific type of TEST which validates the effects of updating a specific part of the software product (Koomen et al., 2006). A VALIDATED SERVICE-ORIENTED APPLICATION is an application that matches with its design specifications and will meet the BUSINESS GOALs (Office of Government Commerce, 2011). A PROVISIONING MODEL comprises the provisioning requirements for the deployment of WEB-SERVICEs. The PROVISIONING MODEL consists of a SERVICE GOVERNANCE MODEL, a SERVICE CERTIFICATION, a SERVICE METERING MODEL, a SERVICE RATING MODEL, and a SERVICE BILLING MODEL(Papazoglou & Van Den Heuvel, 2006). A SERVICE GOVERNANCE MODEL is part of the PROVISIONING MODEL, and defines the rules and organizational constructs required for 14

MODEL DISTRIBUTED GOVERNANCE MODEL CENTRAL GOVERNANCE MODEL SERVICE CERTIFICATION SERVICE METERING MODEL SERVICE RATING MODEL SERVICE BILLING MODEL PUBLISHED WEB- SERVICE INTERFACE DEPLOYED WEB- SERVICE RUNNING WEB- SERVICE QUALITY MATRIX SERVICE LEVEL AGREEMENT (SLA) QUALITY REPORT Table 2. Concept table control of the WEB-SERVICEs of an organization (Papazoglou & Van Den Heuvel, 2006). A DISTRIBUTED GOVERNANCE MODEL is a type of SERVICE GOVERNANCE MODEL which implies that the governance with regard to the DEVELOPMENT PORTFOLIO is distributed over the business units (Papazoglou & Van Den Heuvel, 2006). A CENTRAL GOVERNANCE MODEL is a type of SERVICE GOVERNANCE MODEL which implies that the governance with regard to the DEVELOPMENT PORTFOLIO is regulated by a central governing body of an organization (Papazoglou & Van Den Heuvel, 2006). A SERVICE CERTIFICATION is part of the PROVISIONING MODEL, and includes the contractual specifications of the provided WEB-SERVICEs (Papazoglou & Van Den Heuvel, 2006). A SERVICE METERING MODEL is part of the PROVISIONING MODEL, and provides information about the metering of WEB-SERVICEs by the service provider. This SERVICE METERING MODEL can result in a service contract for each new subscriber (Papazoglou & Van Den Heuvel, 2006). A SERVICE RATING MODEL is part of the PROVISIONING MODEL, and provides information about the rating (pricing) of WEB-SERVICEs by the service provider (Papazoglou & Van Den Heuvel, 2006). The SERVICE BILLING MODEL is part of the PROVISIONING MODEL, and provides information for the billing of WEB-SERVICEs (Papazoglou & Van Den Heuvel, 2006). A PUBLISHED WEB-SERVICE INTERFACE is a WEB-SERVICE INTERFACE which is rolled out. This publication assists a service requester to determine how to bind to the WEB-SERVICE (Brittenham, 2001). A DEPLOYED WEB-SERVICE is a service of which the WEB-SERVICE INTERFACE DEFINITION and SERVICE IMPLEMENTATION DEFINITION are published (Brittenham, 2001). A RUNNING WEB-SERVICE corresponds to a WEB-SERVICE which is fully deployed and operational (Brittenham, 2001). A QUALITY MATRIX is a table that explains the different quality characteristics and the corresponding scores (International Organization for Standardization, 2011). A SERVICE LEVEL AGREEMENT (SLA) defines the REQUIREMENTs of the provided WEB-SERVICEs. These REQUIREMENTs are established by encapsulating the concerns of both the service provider and client. A SERVICE LEVEL AGREEMENT can be used to monitor and to enforce the REQUIREMENTs (Papazoglou & Van Den Heuvel, 2006). A QUALITY REPORT provides qualitative and quantitative information, dealing with all important quality aspects of the output and process. It can also provide recommendations for quality improvements (European Commission, 2009). 15

Related literature The origin of the Service-Oriented Design and Development method is founded in an architecture principle and three development methods. The architecture principle corresponds to SOA, which is an method to (re)-design business processes compiled from independent and reusable components called services (Zimmermann, Krogdahl, & Gee, 2004). The central idea of SOA is packaging software as services in order to facilitate the distribution (Papazoglou & Van Den Heuvel, 2007). In addition to the usage of SOA guidelines, the method itself is based on three well-established development methods: the Rational Unified Process (RUP), Component-based Development (CBD), and Business Process Modeling (BPM). Each of these methods will be elaborated on in the subsequent sub-sections. Firstly, the RUP is a software engineering process maintained by IBM (Shuja & Krebs, 2007). It is an approach to support the creation, analysis and maintenance of models for a software development project (Zimmermann et al., 2004). Team productivity is a core aspect of RUP which is supported by a shared knowledge base including templates and guidelines (Shuja & Krebs, 2007). Secondly, Component-based Development (CBD) is an approach for software development applying component-based thinking (Herzum & Sims, 2000). CBD takes the whole software life cycle into account implying the design, implementation, deployment and evaluation stages. The predecessor of CBD is Object Orientation (OO) (Arsanjani et al., 2008). For a detailed description of OO, see Parnas (1972). Thirdly, Business Process Modeling is applied to design business processes in order to support organizations by managing and improving their operations (Van der Aalst, Ter Hofstede, & Weske, 2003). Business Process Modeling is covered within a larger domain known as Business Process Management (BPM). Given the long tradition of modeling business processes, a lot of process modeling formalisms are developed and available across the domain such as: BPMN, BPEL, Petri Nets, and YAWL (Van der Aalst et al., 2003). To position the Service-Oriented Design and Development method in the service oriented development domain, the survey conducted by Ramollari, Dranidis, and Simons (2007) is used. For this survey, the researchers compared ten different service-oriented development methods including the method of Papazoglou and Van Den Heuvel (2006). The remaining nine methods which were considered for the comparison are: IBM SOAD, IBM SOMA, SOA RQ, CBDI-SAE, SOAF, SOUP, Erl s method, BPMN to BPEL, and Jones SA. The methods were compared based on the following eight characteristics: 1) delivery strategy, 2) lifecycle coverage, 3) degree of prescription, 4) availability, 5) process agility, 6) adoption of existing processes/ techniques/ notation, 7) industrial application, and 8) supported role(s). For an in-depth explanation of the ten approaches and eight characteristics, see the paper of Ramollari et al. (2007). Furthermore, the previous mentioned paper provides a matrix with the individual scores of each method. To the knowledge of the author, there is no literature available in which the entire method is applied by means of a case study. However, different studies are found that incorporate the key aspects of the method to create a new approach. In other words, situational methods are created; methods that incorporate fragments of other methods (Brinkkemper, 1996). First of all, Ma and Leymann (2008) present a lifecycle model for creating business processes by means of process parts. The establishment of this lifecycle is based on one of the basic principles of the Service-Oriented Design and Development method. This principle implies that business goals should function as starting point for the design and development process to realize traceability of business requirements (Papazoglou & Van Den Heuvel, 2006). Furthermore, according to Zimmermann, Koehler, and Leymann (2007) current available design approaches provide a too high-level description of the technical design steps. Therefore, the researchers suggest a new engineering method to bridge this identified gap. The method is shaped as a decision tree including three levels: conceptual, technology and an asset level. It is positioned as complementary to the Service-Oriented Design and Development method of Papazoglou and Van Den Heuvel (2006). 16

References Arsanjani, A., Ghosh, S., Allam, A., Abdollah, T., Ganapathy, S., & Holley, K. (2008). SOMA: A method for developing service-oriented solutions. IBM Systems Journal, 47(3), 377-396. Bass, L., Clements, P., & Kazman, R. (2012). Software Architecture in Practice. Massachusetts: Addison-Wesley. Booch, G., Rumbaugh, J., & Jacobson, I. (1999). The Unified Modeling Language User Guide. Redwood City: Addison Wesley Longman Publishing Co., Inc. Brinkkemper, S. (1996). Method engineering: engineering of information systems development methods and tools. Information and Software Technology, 38(4), 275-280. Brittenham, P. (2001). Web Services Development Concepts (WSDC 1.0). http://www.csd.uoc.gr/~hy565/newpage/docs/pdfs/papers/wsdc.pdf: IBM Software Group. Dijkman, R. M., Dumas, M., & Ouyang, C. (2008). Semantics and Analysis of Business Process Models in BPMN. Information and Software Technology, 50(12), 1281-1294. doi: 10.1016/j.infsof.2008.02.006 European Commission. (2009). ESS Standard for Quality Reports (ISSN 1977-0375). http://epp.eurostat.ec.europa.eu/portal/page/portal/ver- 1/quality/documents/ESQR_FINAL.pdf: Publications Office. Herzum, P., & Sims, O. (2000). Business Components Factory: A Comprehensive Overview of Component-Based Development for the Enterprise. New York: John Wiley & Sons. International Organization for Standardization. (2011). Systems and Software Quality Requirements and Evaluation (ISO/IEC 25010). https://www.iso.org/obp/ui/#iso:std:iso-iec:25010:ed- 1:v1:en: International Organization for Standardization. Koomen, T., Van der Aalst, L., Broekman, B., & Vroon, M. (2006). TMap Next. Den Bosch: Uitgeverij Tutein Nolthenius. Ma, Z., & Leymann, F. (2008). A Lifecycle Model for Using Process Fragment in Business Process Modeling. Proceedings of the 9th Workshop on Business Process Modeling, Development, and Support (BPDMS 2008), Montpellier, France, 1-9. Object Management Group. (2004). UML 2.0 superstructure specification (Technical Report ptc/04-10-02). https://www.utdallas.edu/~chung/fujitsu/uml_2.0/omg- UML_2.0_Superstructure_04-10-02.pdf: Object Management Group. Object Management Group. (2011). Business Process Model and Notation (formal/2011-01-03). http://www.omg.org/spec/bpmn/2.0/: Object Management Group. Office of Government Commerce. (2009). Managing Succesful Projects with PRINCE2. Norwich: The Stationery Office. Office of Government Commerce. (2011). ITIL Service Design. Norwich: The Stationery Office. Papazoglou, M. (2014). Short Biography. Retrieved February 10, 2014, from http://infolab.uvt.nl/~mikep/profile.php Papazoglou, M., & Van Den Heuvel, W.-J. (2006). Service-Oriented Design and Development Methodology. International Journal of Web Engineering and Technology, 2(4), 412-442. Papazoglou, M., & Van Den Heuvel, W.-J. (2007). Service oriented architectures: approaches, technologies and research issues. VLDB Journal, 16(3), 389-415. doi: 10.1007/s00778-007- 0044-3 Parnas, D. L. (1972). On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM, 15(12), 1053-1058. Pesic, M., & van der Aalst, W. M. (2006). A Declarative Approach for Flexible Business Processes Management. Proceedings of the Fourth International Business Process Management Conference, Vienna, Austria, 169-180. Ramollari, E., Dranidis, D., & Simons, A. J. (2007). A Survey of Service Oriented Development Methodologies. Proceedings of the The Second European Young Researchers Workshop on Service Oriented Computing, Oadby, England, 75-80. Saeki, M. (2003). Embedding Metrics into Information Systems Development Methods: An Application of Method Engineering Technique. Proceedings of the the Fifteenth Conference on Advanced Information Systems Engineering, Klagenfurt/Velden, Austria, 374-389. Shuja, A. K., & Krebs, J. (2007). IBM Rational Unified Process Reference and Certification Guide: Solution Designer. Indianapolis: IBM Press. 17

Silver, B. (2009). BPMN Method and Style. Aptos: Cody-Cassidy Press. The Open Group. (2012). Archimate 2.0 specification. Zaltbommel: Van Haren Publishing. Van de Weerd, I., & Brinkkemper, S. (2008). Meta-Modeling for Situational Analysis and Design Methods. In M. R. Syed & S. N. Syed (Eds.), Handbook of Research on Modern Systems Analysis and Design Technologies and Applications (pp. 35-54). Hershey: Idea Group Publishing. Van Den Heuvel, W.-J. (2014). Experts & Expertise. Retrieved February 10, 2014, from http://www.tilburguniversity.edu/webwijs/show/?uid=w.j.a.m.vdnheuvel Van der Aalst, W., Ter Hofstede, A., & Weske, M. (2003). Business Process Management: A Survey. Proceedings of the First International Conference on Business Process Management, Eindhoven, Nederland, 1-12. W3C. (2004). Web Services Architecture (TR/2004/NOTE-ws-arch-20040211). http://www.w3.org/tr/ws-arch/#whatis: W3C. Zimmermann, O., Koehler, J., & Leymann, F. (2007). Architectural Decision Models as Micro- Methodology for Service-Oriented Analysis and Design. Proceedings of the SEMSOA Workshop, Hannover, Germany, 1-15. Zimmermann, O., Krogdahl, P., & Gee, C. (2004). Elements of Service-Oriented Analysis and Design (ws-soad1). http://www.ibm.com/developerworks/webservices/library/ws-soad1/index.html: IBM developerworks. 18

Appendix 1 This appendix contains a template for the establishment of a business process model according to BPMN (see Figure 4). Figure 4. Template of business process model 19