Service Oriented Modelling

(1)

Date : 10 June 2009

Place : Groningen

Company : N.V. Nederlandse Gasunie Author : Sander Huizinga BICT

Principle : P.M. Baard MSc, ICT-architecture manager

Document : Master Thesis

Version : V1.6

Status : Final

University : University of Groningen (The Netherlands) Faculty : Economics and Business

Graduation : MSc Business Administration; Business & ICT

1st_Supervisor _{: ir. F.B.E. van Blommestein} 2nd_Supervisor _{: dr. H. Balsters}

E-mail : s.huizinga@gasunie.nl Student Identifier : S1654837

Service Oriented Modelling

For Process Integration

(2)

Preface

This thesis is the result of six months of hard work conducted at the N.V. Nederlandse Ga-sunie in the integration- and architecture team. I was given the opportunity to continue in the area of (enterprise) integration after the successful and double awarded thesis back in 2006. I’m grateful that Gasunie and the team allowed me to do my research in a relative un-explored area of standardisation of service oriented process integration and I’m proud that the results are used at Gasunie and inspired others as well.

None of this could be accomplished without the support of a fantastic team of people at Ga-sunie that is in my opinion one of the best integration teams in The Netherlands and beyond. I want to thank the following persons in particular for the input, comments and discussions:

• Peter Baard, ICT-Architecture Manager – “A though debater and inspiring speaker” • Remco Schellekens, Project Leader – “The most substantive project leader I ever met” • Erik ter Veld, Integration Team Coordinator– “A calm and sensitive supporter”

• Jan de Jong, Integration Analyst – “The best ‘coach’ I ever had”

• Edwin van Slooten, Integration Analyst – “The man that kept my feet at the ground” • Frank Driesens, Technical Integration - “A gentlemen and enthusiastic supporter” • Arjan de Boer, Technical Integration – “The happiest SAP techie I ever met”

• Bart de Groot, Intern – “The first one who figured out the UN/CEFACT Modelling Method-ology”

From the University of Groningen I want to thank the following persons for their unlimited support. Without them this thesis could never be accomplished:

• ir. F.B.E. van Blommestein, Assistant Professor • dr. H. Balsters, Associate Professor

• prof. dr. E.W. Berghout, Professor

Thank you all for all the support and I hope the readers will enjoy reading as much as I en-joyed writing.

(3)

Summary

Gasunie is currently moving towards a more service oriented approach for process integra-tion. The question was asked: “Why is Service Oriented Architecture (SOA) of interest for the company?” Services can be seen as a value-adding product for the business partners. By ex-celling on the competence of rapidly identifying and unlocking these services, Gasunie could position itself more distinctively from its competitors. Looking from an operational perspec-tive it reduces the complexity of integrations by shifting the focus from the transactions and onto the actual meaning of the transactions. An other argument is, that Service Oriented Ar-chitecture can facilitate the continuing divesting and merging process for (internal) process integrations and therefore it supports the current more dynamic and competitive business strategy.

The analyses explains that the same issues experienced in the past during the EAI-era are now experienced with the service oriented process integrations; The first major issue is the poor and varying quality of the produced output of the analyses, design and implementation process. The second major issue is the duration and the unpredictability of the duration of the analyses design and implementation process. The main causes are that the current (modelling) methods used across the value-chain of Gasunie and its business partners are different, and in larger degree there is absence of use of any type of standard specification method. The current modelling method (based on UMM) is more oriented on transactions, and is limited to business-to-business information exchange. However, while progress has been shown, the current used method is too limited normative and results into a variety of specifications that is multi-interpretative and do not provide the opportunity to standardise the specification of a service oriented solution. This is translated into the following objective:

• The objective is to develop an efficient, consistent and repeatable analysis and design methodology, that can be used for both the business-to-business and internal service oriented process integration, resulting into one implementation design.

This research uses literature, interviews, desk research, tests and pilots. The results contain a comparison between the UN/CEFACT Modelling Methodology and research objective, a three layered model, two different oriented instruments and an accompanied process model. The solution supports the direction of service oriented architecture and it equalizes the speci-fication of the business-to-business and internal process integration. It is based and derived from international accepted open standards, is implementation (application) independent, and facilitates the reduction of the lead-time of service deployment by up to 25 percent of the original specification time when accompanied with an automated tool. The general rec-ommendations for the N.V. Nederlandse Gasunie are:

• Use the top-down oriented approach and evaluate the usage

• Develop (in the refinement of) tooling to support the creation of the specification • Share the results with business partners involved in information exchange

(4)

1 Introduction

This master thesis is conducted at the N.V Nederlandse Gasunie (Gasunie). Gasunie is a European (natural) gas infrastructure company and its main task is to construct and maintain (almost 16.000 kilometres of) gas transporting infrastructures across The Netherlands and northern Germany. Directly under the Board of Executives a centralized Business Intelligence (BI) department is present which is responsible for providing IT solutions. BI includes an IT-architecture process which is responsible for aligning IT policies with the business strategy and operational processes. One of the fields of expertise present is process integration1_.

Gasunie is currently moving towards a more service oriented approach for process integra-tion. However, due the new aspect of this approach, the development of service oriented process integrations is currently experienced to be slow and contains qualitative issues. The problem definition is as follows:

The development of service oriented process integrations is experienced to be slow and has qualitative issues.

Gasunie has requested the graduate Sander Huizinga to investigate the current situation and to formulate solutions for the problems encountered.

The first chapter will start with the explanation of the problem area. The following chapter will outline the targeted audience, the problem definition and the research goals. The third chapter will include an analyses of the current situation and presents the issues and underly-ing causes encountered. After the analyses the ‘variables of the solution’ will be given. These variables exist out of the central objective to achieve, the requirements for the solution and a set of test and pilots used for validation of the solution. The last chapter will contain the conclusions and recommendations.

1

(7)

2 SOA-based process integration

Gasunie is currently moving towards a more service oriented approach for process integra-tions. Immediately the question arises why Gasunie moves to a more service oriented ap-proach? This can be transformed into a more general applicable question: “Why is Service Oriented Architecture (SOA) of interest for the company?”.

[Question]

Why is Service Oriented Architecture (SOA) of interest for the company?

In this chapter the first step will be to define ‘process integration’ to give a clear definition of what is meant by process integration in this thesis. The second step will be to explain the move to service oriented architecture. The chapter will conclude with answering the question mentioned.

2.1 The definition of process integration

Finding an already predefined and agreed upon definition in scientific literature could not be achieved. Process integration is mentioned from business process modelling (Grüninger et al., 2000) to Information Technology (IT) related subjects like enterprise application integra-tion (Johannesson et al., 2000). While this range seams wide, it is far from coincidental and also uncovers a significant business strategic aspect of process integration. From a concep-tual perspective the research of Grüninger et al (2000:388) explains that process integration is characterised by; (1) the relationship between the processes and the organizational struc-ture and constraints of the enterprise, (2) the ability to perform activities which effects achieve the goals of the enterprise, and (3) the relationships between the enterprise and its environment. These concepts resemble Porter’s research on business strategy. According to Porter (Porter et al, 1985:150) a company can create competitive advantage by; (1) coordi-nating and optimizing the linkages (= relationship) between the value chain activities (= processes), (2) Aligning the optimized value chain activities with the strategy of the company (= goals of the enterprise), (3) Optimizing and coordinating linkages with suppliers and/or buyers(= enterprise its environment). This match illustrates that process integration has a significant relation with, and impact on, the business strategy of a company.

The earlier noticed range can be explained by Porter’s research on why information technol-ogy can give a competitive advantage. According to Porter (Porter et al, 1985:150) informa-tion technology transforms the way value chain activities are performed and the nature of the linkages among the value chain. It changes the competitive scope and it reshapes the way products meet the needs of the customer. Because of this impact of information tech-nology the act of integrating business processes is, in most occasions, heavily intertwined with information technology. This intertwined relationship is observed as present at Gasunie as well; almost any integration of business processes involves the utilization information technology.

Therefore in this research process integration is defined as:

[Definition of ‘process integration’ in this research]

(8)

2.2 The move to service oriented architecture

In the past few years the (international) business-to-business information exchange at Ga-sunie has increased in complexity and volume. Overlooking those integrations a large con-trast between the past and the current situation is starting to emerge. In the past the inte-grations where mainly oriented to the beginning (f.i. nominations; information from the cli-ent to request gas at a certain time and place) or end of the value chain (f.i. allocations; the results of the actual transported gas). The electronic information exchange was merely ‘a tool’ for automating the transmission of the old paper order and bill. Today a steady growing amount of business-to-business integrations are related to information from processes inside the value-chain of the company.

[Example 1]

Today, business partners are requesting ‘on-going’ metering information from the network points. This information was previously only used for operating the gas flow by Gas Transport Services (A subsidiary of Gasunie), and for calculat-ing the final bill at the end. Now this information can be used by the business partners to make last minute adjustments to their new transport nominations. This ‘service’ is experienced as ‘added value’ by the business partners.

The resulting situation is that this ‘service’ provided by a process inside the value-chain of the company itself, is now part of the trading process of the business partners. For some this even means it changes their core-business activities, like for instance broker-like companies. In essence this service can be seen as a value adding ‘product’ provided to the business partners by Gasunie. Overseeing this situation a conclusion can be made; Service oriented process integrations can add value to the value-chain of the business partners and therefore developing the competence of rapidly identifying and unlocking business services can be a source of competitive advantage. It qualitatively tightens the relationship with the business partners and by excelling on this competence Gasunie could position itself more distinctively from its competitors.

Developing the competence of rapidly identifying and unlocking business ser-vices can be a source of competitive advantage.

Because these services add value to the value-chain of the business partners, a rising pres-sure from the business partners is already felt to unlock the demanded services. Therefore Gasunie has not only the desire to use the service orientation as an (technical) implementa-tion method, but also to use it as a design method for developing business services to unlock the benefits associated with a service oriented environment. Initiatives like the Klic-online project proves the situation where (collectives) of business partners are demanding the unlocking of information from several parts of the value-chain of Gasunie. This pressure is also induced by (European) regulators an legislation where in the KliC-online project a law has passed to demand the unlocking of geographical information of pipelines to prevent damage and risk of life during excavations.

(9)

partner) is not longer depending on the actual reuse of the complete transaction sequence, technology and facilitating application, which may vary among the different business part-ners while functionally they require or provide the same service.

[Example 2]

This (simplified) example is drawn from the Klic-online project during 2008 at Gasunie. In the future Gasunie must examine and verify if their pipelines are in-volved during a third party excavation. This requires several integrations be-tween information systems owned by Gasunie to provide the Dutch land registry organisation (Kadaster) with the examination results.

From a transactional perspective this is specified as the following:

sd Transaction Based

Kadaster BizTalk SAP-PM EAGLE FileNet

Digging Notification Digging Notification ACK ACK Digging Notification Digging Notification Confirm Administer Information Administer Information Administer information ACK ACK

From a service perspective this is specified as the following:

sd Klic-Online

Prov ide examination of digging notification

(10)

A large contrast between the two methods is that the focus shifted from ‘how’ the transactions are taking place, to ‘what’ each business application will do or ac-complish to fulfil the service to Kadaster. When specified in this service oriented principle, the actual transactions can be varying in different implementations. Even the actual business applications that will provide the services are irrelevant for the requester of the service (Kadaster).

This ‘loosely coupled’ flexibility provides the opportunity to increase the efficiency of service deployment because different transactions do not automatically result into new integrations but in reusing an existing service with a few individual adjustments.

The service oriented architecture principles have benefits for both business-to-business inte-grations and internal process inteinte-grations. The loosely coupled characteristic can be used to unlock, reposition and merge parts of the value-chain for different parts of the own (chang-ing) organization like it can with the business-to-business integration. Existing automated processes can be reassigned or reused by changed, different or new parts of the organiza-tion.

[Example 3]

Currently, Gasunie is developing a service for the Dutch land registry organisa-tion to examine if Gasunie is involved during digging activities (example 2). However, Gasunie itself has operatives in the field that are monitoring when third parties are digging near Gasunie interests without permission. When they spot an excavation near a pipeline, the same service will be used to start a ex-amination. This shows that a service provided to a business partner of Gasunie can be reused by another business process of the own organization. In other words; When another part of the organization has the same or similar request or input, the already automated service can be (re)assigned to this (new or changed) part of the organization.

These benefits match with the direction Gasunie is currently heading. In the past view years Gasunie is transforming from a steady operational environment to a more dynamic competi-tive environment. Its core business activity changed by divesting half of the company,which proceeded as GasTerra. Gasunie divided processes under several subsidiaries and has re-cently taken over a part of the German natural gas transport network. Because service ori-ented architecture can facilitate this continuing divesting and merging process, the use of service oriented architecture supports directly the current (more dynamic and competitive) business strategy.

(11)

2.3 Conclusion

Gasunie is currently moving towards a more service oriented approach for process integra-tion. The question arose why Gasunie moves to a more service oriented approach. This was transformed into a more general applicable question: “Why is Service Oriented Architecture (SOA) of interest for the company?”.

First a definition of process integration has been given followed with the explanation of the move and the related advantages of service oriented architecture for the company.

In this research process integration is defined as the act of integrating separated but interre-lated activities into one or more holistic operating business process(es) with the use of in-formation technology.

1) In the past, the electronic information exchange was merely ‘a tool’ for automating the transmission of the old paper order and bill. Today a steady growing amount of business-to-business integrations are related to information from processes inside the value-chain of the company. The resulting situation is, that this ‘service’ provided by a process inside the value-chain of the company itself, is now part of the trading process of the business partners. In essence these services can be seen as a value adding ‘product’ provided to the business partners; this qualitatively tightens the relationship with the business part-ners and by excelling on this Gasunie could position itself more distinctively from its competitors.

2) Looking from an operational perspective the service oriented architecture principle has benefits as well. It reduces the complexity of integrations by shifting the focus from the transactions and onto the actual meaning or reason of the transaction. This provides the opportunity to increase the efficiency of service deployment, because different transac-tions do not automatically result into new integratransac-tions but in the reuse of existing im-plementations with few individual adjustments.

3) The loosely coupled characteristic can also be used to unlock, reposition and merge parts of the value-chain for different parts of the own (changing) organization like it can with the business-to-business integration. Existing automated processes can be reassigned or reused by changed, different or new parts of the organization. Because service oriented architecture can facilitate the continuing divesting and merging process, the use of ser-vice oriented architecture supports directly the current (more dynamic and competitive) business strategy.

(12)

3 Research design

In this chapter the research design will be described. First the targeted audience will be ex-plained followed by the initial motive for research. The third paragraph will contain the re-search objective agreed between the graduate and Gasunie. The following paragraph will ex-plain the research method used and the last paragraph exex-plains the scope.

3.1 Target audience

This research is targeted to a wide area of audiences. First it’s targeted at academic and pro-fessionals in the field of;

• Process integrations, • Application integration, • Service oriented architecture.

For this audience it will be of interest to see the issues and solution presented. Second it’s targeted at academic and professionals in the field of;

• Management of (process) integrations, • Business (IT-) strategic decision making.

For audience from management of integrations and business (IT-) strategic decision making it’s of interest to see the advantage of service oriented architecture for developing added value for the own and business partners its value-chain and the achievable operational im-provements.

3.2 Problem definition

Gasunie is currently moving towards a more service oriented approach for process integra-tion. However, partly due the new aspect of this approach, the development of service ori-ented process integrations is currently experienced to be slow and contains qualitative is-sues. This results into the following problem definition:

• The development of service oriented process integrations is experienced to be slow and has qualitative issues.

3.3 Research goal

The research goal exists out of two main goals to achieve:

• An analyses of issues and underlying causes during the analyses, design and imple-mentation of service oriented process integration.

• The formulation of a solution (or solutions) for the issues encountered, which can be practically applied in the process of analysing and designing and implementing ser-vice oriented process integrations.

3.4 Research method

(13)

mo-tive/problem definition has been given in the previous paragraph. In the analyses chapter a diagnose will be given of the functional issues encountered. In the ‘variables of solution’ chapter the design and plan for a solution will be given, containing the research objective (=proposed solution for the functional issues mentioned) and the requirements for the solu-tion, which characterize/limit the solution. The change/intervention will be explained and evaluated in the results chapters (Concepts Results, Results of instrument, Results of ac-companied process model). For validating and developing the solution an iterative process will be used. The following figure will show the ‘cycles’ between the research methods.

act Research methods

Literature study

Interv iew s

Desk research

Tests/ Pilots Dev eloping solution

solution

best practices experiences scientific knowledge

current situation

Figure 1: Graphical overview of research methods

The main argument for using these cycles is because of the risk that methodical-wise a solu-tion can be found, but the resulting solusolu-tion is too impractical. This research method is used to try to avoid such a situation, by iterative translating the concepts into an solution and to validate it in tests and pilots and using the feedback to complement or change the concepts.

Essentially, the research methods will supply the concepts with information and arguments for defining multiplicities, type of relations and compositions of concepts. During the creation of the concepts, relations may be confirmed from several research methods, or may differ, which is a reason to feedback these differences into the research methods for further inves-tigation. During these cycles, the concepts will be translated into (parts of) a solution that will be tested and piloted. The feedback will be used to complement the concepts and the fi-nal composition of the practical applied solution, until the objective is accomplished within the limits of the requirements.

(14)

integra-tion ontology’s, scientific research in the area of methodologies for process integraintegra-tion seams to be a limited developed subject, especially for service oriented process integration. The lit-erature that is available is in the same direction Gasunie is already heading and based on the UN/CEFACT standards.

During this research several interviews of professionals in the field of (process) integration, standardisation and service oriented architecture will be conducted. These are the ICT-architecture manager, the Integration Analysts, the project leader of the Service Bus project and members of the technical integration team. These interviews will be mainly focussed on the current situation and related experience on ‘hard’ and practical circumstances of process integrations. Complementary to this, a desk research will be conducted which contains an in-vestigation into several real world examples of ‘hard’ but common circumstances in process integrations. The results of this approach will be consolidated into several test and pilots which are based on ‘real world’ examples (Appendix 5/8).

3.5 Scope

The scope of this research will be limited with the following restriction:

• The research is restricted to the internal and business-to-business area of Gasunie.

(15)

4 Analyses

The analyses chapter will start with a brief history of process integration at Gasunie. This his-tory will act as a ‘reminder’ and acts as a similar case for the (expected) issues currently ex-perienced with service oriented process integration. The second paragraph will contain the analyses of the current issues. The third paragraph will explain the already taken steps for improvements. This chapter will end with a summary and conclusion.

4.1 The history of process integration at Gasunie

This history will act as a ‘reminder’ and presents a similar case for the (expected) issues cur-rently present with service oriented process integration. Although this history is about the past of Gasunie, Chief Information Officers, ICT-architect managers and integration special-ists from other companies will likely to recognise the issues encountered.

In 2006 a research was conducted inside the Gasunie about the problems encountered with Enterprise Application Integration (Huizinga, S., Koning, T, 2006). Enterprise Application In-tegration (EAI) is an IT area that is specialised in integrating applications inside a company, to support process integrations. At Gasunie a central element of the EAI environment is the exchange of documents between applications with a central message broker, instead of point-to-point information exchange.

The implementation of the EAI environment inside the company was completed in 2004, but the expected improvement (cost reduction, more dynamic and maintainable IT landscape that approaches closer the dynamic of the business process) was absent and a research was conducted. Although this research was first oriented to technical issues, most of the issues found where surprisingly (business) process related.

Huizinga and Koning concluded that the main cause was the lack of one analysis, design and implementation methodology and process used across the EAI environment. While the cen-tral message broker cencen-tralises the information exchange between the applications on a technical level, the analysis, design and implementations of the integrations, the documenta-tion, responsibilities of the information and guidelines were still different and fragmented over all the different process areas and applications. In many situations the documentations among the different areas and applications about the same implementations were different or even absent, and the documentation was different from the real technical implementation due the high degree of freedom of interpretation and implementation directions.

This resulted into two major issues. The first major issue was the poor and varying quality of the produced output of the analyses, design and implementation process. The second major issue was the duration and the unpredictability of the analyses, design and implementation process caused by the low degree of repeatability. Technically the EAI environment was wired up, but functionally it didn’t change. A rightful conclusion can be made:

Integration is more than just a technical implementation of ‘a tool’; the whole process around integration must be engaged to successfully unlock the added business value of an integrated environment.

(16)

direc-tives was developed. This procedure is formalised into a document called the Integration Scenario Design (ISD) in which the focus was changed from a technical oriented design into a business context related information exchange. However, two years later the mentioned is-sues are becoming applicable in the field of service oriented process integration.

4.2 The move to service oriented architecture

In the previous chapters it’s explained why Gasunie is moving to a more service oriented ap-proach for process integration. Looking at the current situation a disturbing and familiar pic-ture is starting to emerge. Like in the past with the EAI oriented environment, the process and methodologies used for analysis, design and implementing a service oriented solution are not standardised among and across the business partners and the value-chain of Ga-sunie. Although similarities exist, it’s evident that the methods and process are different be-tween the business partners and Gasunie.

Learning from the past, this situation unwraps a need for one efficient, consistent and re-peatable analysis, design and implementation method and process. During the interviews the same major issues are noted:

• The first major issue is the poor and varying quality of the produced output of the analy-ses, design and implementation process.

• The second major issue is the duration and the unpredictability of the duration of the analyses, design and implementation process.

Adding to this in regular intervals analyses of business requirements are not even specified at all, especially when the integration concerns process integrations inside the own value-chain of Gasunie. The communication between the ‘customer’ and the integration analyst is oriented on technical aspects of design and the technical specifications are therefore leading. This approach results into a situation where the requirements are translated into a technical solution, but the business user cannot recognize the solution offered.

While ‘everyone’ agrees on the technological part of the service oriented environment like using eXtended Markup Language (XML) and Web Service Description Language (WSDL), the methodology for process integrations is still a ‘work in progress’ subject. Like in the EAI era, the absence of use of standardised methodologies has the potential to undermine the bene-fits associated with a (service oriented) integrated environment.

Like in the EAI era, the absence of use of standard methodologies has the potential to undermine the benefits associated with a (service oriented) integrated environment.

4.3 The efforts for standardisation of methodologies

Fortunately this situation is recognized by Gasunie and several of its (international) business partners. Gasunie is a key player in the European energy sector where multiple national and international standardisation organisations exist (ebIX2, ETSO3, EASEEGAS4, EDIG@S5,

2_{European forum for energy Business Information eXchange} 3

European Transmission System Operators

4

(17)

EDSN6_{, NEDU}7_{, UN/CEFACT, IEC TC57}8_{). These organisations are extensively occupied to find} solutions. Gasunie has taken steps in the direction of UN/CEFACT Modelling Methodology (UMM 2.0). Parts of the UN/CEFACT Modelling Methodology has been used by several stan-dardisation organisations related to the energy sector and therefore Gasunie is currently committed to make use of UMM. In UMM it’s possible to specify the requirements of each of the related actors and contains a standardised documentation-, analysis- and implementa-tion design. In this method the business partners specify agreements about the communica-tion without specify each others implementacommunica-tion. Adding to this, the UN/CEFACT Core Com-ponents Technical Specification (CCTS 2.01) is used which uses standardised semantic build-ing blocks (for the data model and document structure) which are exchangeable with other (related) types of businesses.

However, the literature of UN/CEFACT Modelling Methodology has already been proven diffi-cult and the practical usefulness is debated by integration related professionals at Gasunie. Especially the fragmentation of UMM is cumbersome in the development of a service oriented solution. UMM is explicitly developed for business-to-business information exchange. This creates an issue because the methodology should be useable for both the business-to-business and internal process integrations in identical manner (see example 3). The main ar-gument is that if services provided from inside the value-chain need to be unlocked to the outside, differences between business-to-business and internal process integration methods are severely reducing efficient service deployment. Different methods mean that the service deployment will be mainly a refitting and reinterpreting procedure from business-to-business to inside and vice-versa, while the service is already available. In practical terms: the meth-ods used for business-to-business process integrations should be the same as internal proc-ess integrations to efficiently unlock identified services.

The analysis and design methods of business-to-business and internal proc-ess integrations should be the same to facilitate effective service deployment for the business partners and the own value-chain.

The learning curve of UMM is experienced to be steep and the orientation of UMM is experi-enced to be more directed to message transactions and state changes, than to the develop-ment or deploydevelop-ment of services. Fortunately UN/CEFACT has recognized some of the difficul-ties of the fully-fledged UMM and has development the UN/CEFACT Business Requirement Specification. It states (p4): “In order to successfully introduce a normalized form of busi-ness requirements specifications based on the UMM philosophy, it will be necessary to de-velop and put into place a phased approach that gradually enables TBG business groups to learn and take increasing advantage of the of UMM.”

Gasunie has already taken the first steps to use the UN/CEFACT Business Requirements Specification in their integration design specification. However, while progress has been shown and the potential is recognized by the integration professionals at Gasunie, the cur-rent ISD (and the related Business Requirement Specification) is too limited normative. The UN/CEFACT Business Requirement Specification merely focuses on the use of actors, used cases, activity diagram, class diagrams, and does not provide a thorough (narrowing down)

5

Electronic Data Interchange standardisation group for European gas transporting companies.

6_{Energie Data Services Nederland} 7

Nederlandse EnergieDataUitwisseling

8

(18)

description/limitations. The current method used result into a variety of specifications that are multi-interpretative and do not provide the opportunity to standardise the specification of a service oriented solution.

The current method used results into a variety of specifications that are multi-interpretative and do not provide the opportunity to standardise the specification of a service oriented solution.

This situation unwraps a need for one efficient, consistent and repeatable analysis and de-sign methodology, that can be used for both the business-to-business and internal (service oriented) process integrations, resulting into one implementation design.

4.4 Conclusion

The history of (process) integration has shown that integration is more than just a technical implementation of a tool; the whole process around integration must be engaged to success-fully unlock the added business value of an integrated environment. The same issues experi-enced in the past during the EAI-era are now experiexperi-enced with the service oriented process integrations:

• The first major issue is the poor and varying quality of the produced output of the analy-ses, design and implementation process.

The main causes are that the current (modelling) methods used across the value-chain of Gasunie and its business partners are different, and in larger degree there is absence of use of any type of standard specification method. The current modelling method (UMM) is more oriented on transactions, and is limited to business-to-business information exchange. UN/CEFACT has recognized some of the difficulties and has developed the UN/CEFACT Busi-ness Requirement Specification. Gasunie has taken the first steps to use the UN/CEFACT Business Requirements Specification in their integration design specifications. However, while progress has been shown, the current used method is too limited normative and results into a variety of specifications that are multi-interpretative and do not provide the opportunity to standardise the specification of a service oriented solution.

(19)

5 Variables for solution

This chapter will start with the explanation of the objective to achieve. This research objec-tive is the proposes solution for the (functional) issues encountered in the analyses. In the following paragraph the requirements to complete the objective are explained. These re-quirements determine the characteristics and limitations of the solution. The last paragraph contains the tests and pilots cases which will be used to validate the solution.

5.1 Research objective

Like in the past with the EAI oriented environment, the process and methodologies used for analysis, design and implementing a service oriented solution, are not standardised among and across the business partners and the value-chain of Gasunie. The following issues are encountered:

• The first major issue is the poor and varying quality of the produced output of the analyses, design and implementation process.

The analyses concluded that there is a need for one efficient, consistent and repeatable analysis and design methodology, that can be used for both the business-to-business and in-ternal service oriented process integration, resulting into one implementation design. This is translated into the following research objective to counteract the issues encountered:

[Research objective]

The objective is to develop an efficient, consistent and repeatable analy-sis and design methodology, that can be used for both the business-to-business and internal service oriented process integration, resulting into one implementation design.

This research objective contains several requirements. These requirements are presented in the following paragraph.

5.2 Research objective requirements

For finding a solution a list of requirements is developed based on the analyses and limita-tions required by Gasunie. This list of requirements is used as a measurement tool for ac-cepting or rejecting the completion of the objective. The list of requirements is placed below.

• R-1: The solution supports the direction of service oriented architecture

(20)

should fit the direction of implementing service oriented architecture for achieving these benefits.

• R-2: The solution equalizes business-to-business and internal process integration

For efficient and effective unlocking of the services to the business partners, the current methods of gathering the business requirements and designing, the specification should be equalized. Different specification methods mean that the service deployment will be for a larger part a refitting and reinterpreting procedure from business-to-business to inside and vice-versa, while the service is already available. The solution should eliminate the differ-ences by defining general applicable concepts.

• R-3: The solution must not be Gasunie specific

Business-to-business integration is as much dependent on the use of a well defined method-ology as the use of one and the same model and instrument by both parties. To fulfil this re-quirement the solution should not be Gasunie specific. It would even be in the interest of Ga-sunie to share the results without restrictions.

• R-4: The solution is based on international accepted standards o The solution is usable in combination with CCTS

o The solution is based on the UN/CEFACT Modelling Methodology 2.0 (UMM 2.0) o The solution is based on the Unified Modelling Language (UML)

The main motivation is related to the requirement of creating a solution that must not be Gasunie specific. By using international accepted standards a wider acceptance can be achieved with business partners and other companies. The second argument is that it is bet-ter to reuse existing solutions than to reinvent them.

An extra restriction is added related to the use of UN/CEFACT Core Components Technical Specification (CCTS). Currently Gasunie is implementing the CCTS for defining parts of their data-model and promises the option of higher interoperability of defined entities between dif-ferent businesses and data-models. Gasunie has demanded to base the solution as much as possible on the UN/CEFACT Modelling Methodology 2.0 because of the already developed level of acceptance in and outside the organisation about this methodology. Any deviation must be made clear and therefore the first chapter of the results will be a comparison be-tween UMM 2.0 and the proposed solution. Another restriction is the use of the Unified Mod-elling Language (UML) because UML is already an international accepted standard and is used at Gasunie in the current best practises.

• R-5: The solution is implementation (application) independent

(21)

• R-6: The solution reduces the lead-time of service deployment

The final instrument should reduce the lead-time of the service deployment for facilitation of process integrations. One of the major issues is the limited reuse of existing designs and im-plementation. The main focus is cost reduction. The instrument should limit the amount of redundant information and reduce the amount of labour. According to the integration special-ists the current amount of time needed for creating a specification is around 40 hours. The goal is set to reduce this time at least with 20 hours.

• R-7: The solution must be accompanied with a practical applied process model

The current analysis and design process is underdeveloped. As stated in the introduction, in-tegration is more than an implementation of a tool, the whole process around it must be en-gaged to successfully unlock the added value of an integrated environment. The resulting in-strument should be accompanied by a process model to actively support the use of the solu-tion offered and to create a higher degree of acceptance with the integrasolu-tion specialists of both Gasunie and business partners.

5.3 Tests and pilots

As described in the research, design test and pilots will be used to validate part of the solu-tion. These test and pilots cases are based on real-world examples and try to create a hard but common test ground to reflect on. These ‘real world’ examples include the KliC-Online service that provides a requester with geographical information (to examine if it is save to dig on a certain location), the service for publishing of gas related allocation information, and the service for publishing (gas transport related) weather information to business partners. The resulting tests and pilots are:

• TP-1: Integrations containing multiple requesters with different business contexts

Integrations, containing multiple requesters with different business contexts, may result into a large number of requirement specifications while the specifications and requirements are in most occasions equal or just limited different between the service requesters. This type of in-tegrations should be used to reflect onto the model and instrument to see if the business re-quirements can be reused, without the need of re-specifying the rere-quirements over and over again for functional (near) identical implementations and to create a loosely coupled integra-tion. An example is placed in the appendix (appendix 5: “Integrations containing multiple re-questers with different business contexts”).

• TP-2: Integrations containing multiple participating actors for the requested service

(22)

• TP-3: Services containing implementations with manual (human) activities

Integration with manual interventions split-up time frames of processes. An example is given in the appendix (appendix 7: “Services containing implementations with manual (hu-man) activities”) where a design of an implementation has a ‘gap’ in the process flow be-cause manual interaction is taking-over the initiative. This gives an unclear situation of who is responsible of delivering the actual result to the initial requester.

The model and instrument should cope with this situation affectively so the initial provider stays responsible for delivering the actual information to the original requester. This com-plies with the service oriented architecture principle of requesting and delivering the service by one provider.

• TP-4: Integrations containing a trigger that is not initiated by a document transfer

(23)

6 UN/CEFACT Modelling Methodology 2.0

This chapter contains an overview of the UN/CEFACT Modelling Methodology (UMM) and a comparison between UMM and the research objective, goals, scope and service orientation limiting the solution. As mentioned in the requirement for the solution, any deviation must be made clear between UMM 2.0 and the presented solution. This chapter will contain a comparison between UMM 2.0 and the proposed solution.

The original development on UMM started in 1998 and is currently maintained and extended by the Technology and Methodologies group of UN/CEFACT (Huemer et al, 2008:p1). During this period an UN/CEFACT Modelling Language profile was created (Huemer et al, 2008:p1) and a software add-in was developed (Liegl, F., Schuster, R., 2006) to cooperate with the model in an automated environment. Currently UMM 2.0 is in public review and this re-view/comparison is based on the 2.0 version. Refers will be made to the UMM 1.0 when they are still applicable on the new version of UMM. The current draft version of the UMM 2.0 de-scribes UMM as follows:

• “UN/CEFACT’s Modelling Methodology (UMM) is a UML modelling approach to design the business services that each partner must provide in order to collaborate. It provides the business justification for the services to be implemented in a service-oriented collabora-tion architecture.( UN/CEFACT, 2008:p7)”

6.1 Foundation of the UN/CEFACT Modelling Methodology

The foundation of the UN/CEFACT Modelling Methodology is the Open-edi Reference Model. “The UMM is the formal methodology for describing any Open-edi scenario as defined in the ISO/IEC 222 14662 Open-edi Reference Model (UN/CEFACT, 2003:p8)”. “An Open-edi sce-nario is a formal means to specify a class of business transactions having the same business goal(-).(UN/CEFACT, 2008:p7)”. A figure is presented of this Open-edi reference Model be-low.

(24)

The Open-edi Reference Model has two main views; the Business Operational View (BOV) and the Functional Service View (FSV). The BOV is defined as “a perspective of business transactions limited to those aspects regarding the making of business decisions and com-mitments among organizations (UN/CEFACT, 2008:p7)”. BOV related standards are for in-stance the UN/CEFACT Core Components, and the RosettaNet Business Transactions Pat-terns. The FSV contains the implementation specific information and technical aspect of the related information technology. Examples of FSV related standards are eXtended Markup Language (XML) for the use of documents and the Hyper-Text Transfer Protocol (HTTP) for sending the documents.

6.2 Scope of the UN/CEFACT Modelling Methodology

UMM 2.0 is placed within the Business Operations View of the Open-Edi Reference Model (UN/CEFACT, 2008:p8). Within the Business Operation View UMM 2.0 has placed three main views, the Business Requirements View, the Business Choreography View and the Business Information View.

• Business Requirements View

“The Business Requirements View is used to gather existing knowledge. It identifies the business processes in the domain and the business problems that are important to stakeholders. (UN/CEFACT, 2008:p8).”

• Business Choreography View

“The Business Choreography View is used to define and document the global choreogra-phy between collaborating business partners in an inter-organizational business process (UN/CEFACT, 2008:p8).”

• Business Information View

“Within the Business Information View the business documents, which are exchanged in different business Transactions are defined (Huemer et al, 2008:p6).”

6.3 The Functional Service View related Vs the research requirements

UMM 2.0 is placed within the Business Operations View and not in the Functional Service View (FSV) of the Open-Edi Reference Model (UN/CEFACT, 2008:p8). As mentioned earlier the FSV contains the implementation specific information and technical aspect of the related information technology. The objective of this thesis is to create a solution for use in the analysis, design and implementation process. While this research also has the requirements that the solution is implementation (application) independent, this is mainly oriented on the implementation specific information that can be made applicable on a variety of business ap-plications.

This research produced a concept ‘integration design’ in the resulting model, containing a framework for gathering information for an application independent and service oriented im-plementation. This is translated into a worksheet placed in the appendix (appendix 2: “Inte-gration Design”).

6.4 Business-to-business process integration Vs Intra process integration

(25)

• UMM focuses on developing a global choreography of inter-organizational business proc-esses and their information exchanges (UN/CEFACT, 2008:p7).

The focus of the UN/CEFACT Modelling Methodology is therefore inherently different than the intended goal of this research. One of the requirements is that it can be used in a business-to-business process integration, but also for use in an internal process integration in an equal manner. During this research the actual differences in perspective rounded down on the in-terpretation of the actors involved. In UMM 2.0 the actors represent stakeholders and busi-ness partners (UN/CEFACT, 2008:p36). Busibusi-ness partners are ‘involved’ in a sense that they actively collaborate in a business transaction. But what are the actors that are actively col-laborating in an internal process integration? In cooperation with de Groot (Groot de, H.B. 2008) it’s examined how to answer this question. When an integration is taking place at business-to-business level the related business partners are representing the actors. From a practical perspective, internal process integrations are conducted between business applica-tions. The derived stakeholders are in essence the owners of these business applicaapplica-tions. In a practical setting these are departments in an organization responsible for the related proc-ess and services.

However, it’s very common in internal process integrations that the integrations are taking place between business applications owned by the same owner stakeholder actor. This prevents to use the department as an abstracting (non-implementation specific) representa-tive for internal process integrations because the integration between the business applica-tion from the same stakeholder would be completely invisible. This can be solved by intro-ducing a new term ‘service participant’. This will be explained in the following figure.

class UMM 2.0 and UMM-GM

Actor

Business Partner Stakeholder

Actor

Stakeholder Serv ice

Participant

Business Partner Business

Application

Unified Modelling Methodology 2.0 UMM in a service oriented based methodology

«include» 1..* «extends» «extends»

Figure 3: Introduction of the service participant concept

(26)

specialization of a stakeholder. A business partner includes at least one or more business ap-plications for providing or using a business service.

6.5 Business Transactions Vs Business Services

The first noticeable encounter in the literature of UMM is that UMM is based on a reference model (Open-edi) that takes the Business Transaction as the primary view. In the past UMM was described as follows:

• “The primary scope of the UMM is to provide "a perspective of business transactions lim-ited to those aspects regarding the making of business decisions and commitments among Persons, which are needed for the description of a business transaction (UN/CEFACT, 2003:p5)."

The UMM 2.0 Public Review (UN/CEFACT, 2008:p7) overview explains that the UMM 2.0 is used for designing business services that each partner must provide and that it provides the business justification for the services that need to be implemented in a service-oriented col-laboration. While this shift is apparent, the actual foundation of the UMM 2.0 is still based on the Open-Edi model (figure 2) for Business Transactions (UN/CEFACT, 2008:p7). This seams to contradict with the view of service oriented architecture and the gathering of requirements in a service oriented perspective, because the business service should be defined first. This will be explained next.

When gathering the requirements in UMM 2.0 the design will be done from an ‘as is’ perspec-tive. The relevant business processes are further detailed by an activity diagram (Business Process Activity Model). An emphasis is placed in modelling the relevant business process with shared business entity state changes between the actors. A simplified example is given in the following picture (figure 4).

act State

business partner 2 business partner 1

Business Process Business Process Shared state of

business entity focus

collaborative space

Figure 4: Shared state of business entity

What can be seen is that emphasis is placed on the state management of business entities and their lifecycles between the actors. This is strongly confirmed by the original develop-ment group that typifies UMM as follows:

(27)

However, during the tests and pilots interesting observation was noticed; state seems to be a lesser issue, when the resulting design is meant for a service oriented implementation. State changes focuses on the actual ‘state’ shared between two actors, while in services ori-entation, the general focus is on the actual service provider and on the resulting process it needs to provide. Modelling state changes have the general advantage to simplify complex transaction sequences. By focussing on the state changes instead of transactions, a high-level abstraction can be given. However, that is exactly what service orientated architecture is already accomplishing. As earlier mentioned, a service exists of a simple composition of someone that requires a service, and someone that provides it (Krafzig et al, 2005:14). Ga-sunie has not only the desire to use the service orientation as an (technical) implementation method, but also to use it as a design method for developing business services to unlock the benefits associated with a service oriented environment. When looking from this perspective, this changes the emphasis from the ‘middle’ shared business entities, to the front of the pro-viding process (figure 5). The previous business partner 2 will be the propro-viding actor, and the business partner 1 the requester of the activity. The front of the providing process is es-sentially the ‘front-office’ presented to the requester. This however, does not only replace the ‘view’ of the requirements alone. The following information that needs to be gathered for the requirement is the initiating trigger, and the actual result of the service. Essentially, looking from the actor who needs to provide the business service, he or she should at least specify how a requester can initiate this business service, and the actual output of the busi-ness service.

act Requester and Prov ider

focus prov ider requester Business Process trigger resul t

Figure 5: Requester and Provider

As shown in the picture the process of the requester is a ‘black-box’ because the reason why a requester triggers another process and needs the result, is not of interest for the providing actor when modelling the business process. This ensures the ‘loosely-coupled’ nature of a business service and can be reused by another actor with a different business context.

(28)

act Process and Task

focus

focus focus

focus

Business Process

Task Task Task

result trigger

trigger

result result trigger result trigger

Figure 6: Process and Task Services

The above business process can be called a ‘Process Service’, while the individual tasks used to accomplish this service are called ‘Task Service’. The resulting situation is that after gath-ering the requirements (trigger and result) of the initial business service, the business proc-ess is modelled. Until now the actual Businproc-ess Transactions are not mentioned. The last steps are the determining of the actual Business Transactions between each service (based on the transaction patterns of RosettaNet covered in the ‘service description’ concept in the resulting model of this thesis), and a short list of the sequence/choreography each transac-tion (covered in the ‘service overview’ concept). When reflecting this on the objective of this thesis and the scope methodology, the scope is placed between the initial trigger and result of the Process Service, and the triggers and result of the related Task Services. A design for implementation of this area is called an Integration Scenario.

act Scope of research obj ectiv e

Scope of research obj ectiv e (Integration Scenario)

focus

focus focus

focus

Process Serv ice

Task Serv ice Task Serv ice Task Serv ice

Figure 7: Scope of research objective

(29)

Busi-ness Process Use Case and BusiBusi-ness Activity Model are not modelled around shared state changes and the collaborative space between actors, but on the trigger and result of each service.

A critical note can be added that because of these differences, the choice of using UMM 2.0 as a base and requirement for creating a service oriented methodology is debatable.

6.6 Conclusion

The following conclusions can be drawn when the UN/CEFACT Modelling Methodology is re-flected on the research objective and proposed solution:

1. The scope of UMM 2.0 does not cover the Functional Service View while the solution re-quirements covers the implementation specific aspect of the Functional Service View.

This research produced a concept ‘integration design’ in the resulting model, containing a framework for gathering information for an application independent and service oriented implementation.

2. UMM 2.0 is meant for business-to-business while the research objective covers both business-to-business and internal process integration.

The differences in perspective rounded down on the interpretation of the actors involved. In UMM actors are stakeholders and business partners are specializations on the stake-holders. This research introduces a new term ‘service participant’ which is a specializa-tion of the stakeholder concept, and a generalizaspecializa-tion of a business partner and business application concept. This gives the opportunity to use the modelling methodology in a business-to-business and internal process integration environment.

3. UMM 2.0 foundation is based on business transaction related literature and orienting on capturing the collaborative space between organizations, while the objective of this re-search is to develop business services based on SOA principles.

In UMM 2.0 the emphasis is placed onto gathering and modelling of business process re-quirements by looking at the shared entity states and their lifecycles between the actors. When looking from a SOA perspective, the emphasis shifts from the ‘middle’ (collabora-tive space) shared business entities onto the front of each providing actor.

UMM 2.0 first models the related business processes, second the collaborations and as third the business transactions. The result of this research (model and instrument) first models the boundaries (trigger and result) of a business service, than models the busi-ness process and as third the busibusi-ness transactions. Compared to UMM 2.0 the Busibusi-ness Collaboration View is kept empty, the actual business service requirements and related business process is described in the Business Requirements View, and the resulting busi-ness transactions in the Busibusi-ness Transaction View. The results of this thesis (model an instrument) place the Business Transactions in the ‘service description’ concept, and the chorography in the ‘service overview’ concept.

(30)

7 Concepts results

In this chapter the concepts will be explained. First the general highlights will be given in the ‘overview’ paragraph. This is followed by descriptions and motivation of each of the main concepts represented in the model. The main concepts are concepts that are requiring a thorough explanation of results. This chapter will end with the ‘other’ concepts that not re-quire a heavy explanation, and with the conclusion.

7.1 General overview

In this paragraph an overview is given of the model and concepts, including a comparison with three common modelling approaches. The blocks representing each concept and the ar-rows describe the type and the direction of relation between the concepts.

class Seperation Of Concerns - 3 Layers

Actor Role Business Process Eleboration Business Information M odel Information Flow Definition

Business Rule

Serv ice

Serv ice Description

- business transacti on

Integration Design

Canonical Model

Web Serv ice

Xml Schema Definition

Business application Organization

Target Technology Solution

Serv ice Ov erv iew

- choreography Business Requirements Service Design Implementation Design 1..* contains 1..* 1..* general ized to 1..* 1..* based on 1..* 1 transl ated into 1 1..* based on 1..* 1 transformed into 1 1..* owns 1 1..* speciali zes 1..* 1..* impl emented by 1..* 1..* contains 1..* 1..* uses 1..* 1..* contains 1..* 1..* appl icabl e on 1..* 1..* appl icable on 1..* 1..* make use of 1..* contains 1..* based on 1..* 0..*

requi rements for 0..* requirements for 1..* 0..* requirements for 1..* 0..* make use of 0..1 transformed into 1 contains2..* 1..* make use of 1..* 1..* speci fies 1..* 1 transformed into 1 1..* Linked to 1 1 extended with 1 1..* Linked to 1 0..1 transform ed i nto 1

(31)

The overview is split-up in three layers. This approach is based on the principle of “Separa-tion of Concerns” which was first introduced by Dijkstra (Dijkstra, E.W. 1974:p61). Dijkstra explains: “Even if not perfectly possible, it (Separation of concerns) is yet the only available technique for effective ordering of one's thoughts (-).” By separating concepts in different ‘concerns’, the complexity of relations and concepts can be effectively discovered from dif-ferent perspectives. In this design, the separation of concerns is represented in the layers ‘business requirements’, ‘service design’ and ‘implementation design’.

This structure resembles a model first mentioned by ANSI-SPARC (Brodie, M.L., Schmidt J. W, 1981) in which three layers are used representing the user view (business requirements), conceptual view (service design) and physical view (implementation design). In the psented model, the business requirements layer presents a business oriented view on the re-quirements. It contains and channelizes the ‘ingredients’ for designing a service oriented so-lution. It specifies the related business process, actors involved and information used, and may contain some requirements for the technology used during implementation. The second layer is the service design. This layer contains a conceptual design of the proposed service oriented solution. This design is independent of the implementation/physical aspects of a service oriented solution. The service design should match the user requirements specified in the first layer. The third layer contains the implementation related aspects of the service ori-ented solution. It’s specifies (the structure) of the used web-services (based on the Web Service Description Language), the implementation design of the business documents, XML Schema Definitions (XSD) and services.

Reflecting this on the Open-EDI model (UN/CEFACT, 2003:p8) the first two layers represent the Business Operational View containing the business aspects of the design, and the third layer represents the Functional Service View containing the technical aspects of the design. An other three layered model exists which is the Model Driven Architecture approach of the Object Management Group (OMG, 2003). This consists out of the Computation Independent Model (CIM), a Platform Independent Model (PIM), and Platform Model (PM) (OMG, 2003:p20). The requirements for the system are modelled in a CIM. The PIM describes the system, but does not show details of its use of its platform. The PM describes the system im-plementation on a specific platform/application. When reflecting this on the model of this thesis, the CIM is an equivalent of the business requirements layer, and the service design and implementation design are combined in the PIM layer. This is presented in the following picture (figure 9).

class Layers in different models

Platform Model Platform Independent Model Computation Independent Model

OMG MDA

Functional Service View Business Operation View

Physical View Conceptual View User View ANSI SPARC Business Requirements Service Design Implementation Design UN/CEFACT Open-EDI

The darker colored areas matches best with the related layer

Service Oriented Modelling

Service Oriented Modelling

Preface

Summary

Table of contents

1 Introduction

2 SOA-based process integration

3 Research design

4 Analyses

5 Variables for solution

6 UN/CEFACT Modelling Methodology 2.0

7 Concepts results