Study on cloud and service oriented architectures for e- government Final report

(1)

Study on cloud and service

oriented architectures for

e-government

Final report

05-12-2011

Framework Contract no: DI/06691-00

Authors: P. Wauters, K. Declercq, S. van der Peijl, P. Davies

(2)

The study has been commissioned by the European Commission, Directorate General for Information Society and Media, unit ICT for Government and Public Services. All views expressed in this document, however, are those of the authors and do not necessarily reflect the views of the European Commission.

Neither the European Commission nor any person acting on its behalf is responsible for the use which might be made of the information contained in the present publication.

The European Commission is not responsible for the external web sites referred to in the present publication.

A STUDY ON CLOUD AND SERVICE

ORIENTED ARCHITECTURES FOR

E-GOVERNMENT

Framework Contract no: DI/06691-00

Final report

5 December 2011

(3)

i

Table of figures

Figure 2 - Service Orchestration ... 8

Figure 3 – Service Integration Maturity Model (Open Group, 2009) ... 10

Figure 4 - Silo Approach... 11

Figure 5 - Silo Approach with Building Blocks ... 12

Figure 6 – Business and Infrastructure Services ... 13

Figure 7 – Cloud Model: Private Services ... 13

Figure 8 - Cloud Model: Public Services ... 14

Figure 9 – The Concept of a Cloud of Public Services... 14

Figure 10 – Existing Service Taxonomies... 18

Figure 11 - Three layers of SOA expansion (Josuttis, 2007)... 19

Figure 12 – Taxonomy of Public Services... 20

Figure 13 – SOA View of the Service Taxonomy based on Josuttis (2007)... 21

Figure 14 – Service-oriented Modelling and Architecture Methodology... 23

Figure 15 - Service Oriented Design and Development Method (SOADM)... 24

Figure 16 - Component Identification Methodology ... 25

Figure 17 – Three Step Service Decomposition Methodology ... 26

Figure 18 – Scope example: Life Cycle of a Business... 27

Figure 19 –The Concept of Nested Services (Peristeras 2006) ... 27

Figure 20 - eDepot Architecture ... 32

Figure 21 – Belgian Cross Roads Bank for Social Security (CBSS) ... 33

Figure 22 – Service Taxonomy with Fundamental Services ... 36

Figure 23 – Scope for Reuse... 43

Figure 24 – FSB: Task, Entity and Utility Services ... 44

Figure 25 – FSB: Multi-Partner Process ... 45

Figure 26 – Conceptual model for the design of a cloud of public services ... 46

Figure 27 - Conceptual model of ‘Ordering a travel trip’ ... 47

Figure 28 - eHealth Platform ... 48

Figure 29 - Conceptual Model of the eHealth platform... 49

Figure 30 - Conceptual Model of the Flu Prediction Service ... 50

Figure 31 – Conceptual Model of ‘One stop shop’ for company registration... 51

Figure 32 – Conceptual Model of a Bank as a ‘One stop shop’ for company registration ... 52

Figure 33 - Dutch Environmental Permit law ... 53

Figure 34 - Analytical Model of a Front office for permits and licences... 54

Figure 35 - FEDICT Architecture ... 55

Figure 36 – FEDICT/FSB - layered or multiple service buses... 56

Figure 37 - NORA chain of activities ... 57

(6)

iv

Figure 39 - SAGA Architecture... 59

Figure 40 - eGEP Measurement Framework... 63

Figure 41 - Impact Categories ... 64

Figure 42 - eDepot Architecture ... 66

Figure 43 – Expansion of the eDepot to Real Estate... 67

Figure 44 – Expansion of the eDepot to VZW/ASBL... 68

Figure 45 - Cross Roads Bank for Social Security... 69

Figure 46 - German Administration Services Directory ... 70

Figure 47 - Danish Registration of Land and Property ... 72

Figure 48 - Danish Registration of Land and Property (Third Parties)... 73

Figure 49 – Predicted Impact of the ‘Flu prediction’ Service ... 74

Figure 50 – Predicted impact of the Bank as a ‘One stop shop’ for company registration .... 75

Figure 51 – Predicted Impact of a front office for permits and Licences ... 77

Figure 52 – Sweden - Service Decomposition – Starting Up... 90

Figure 53 – Italy - Service Decomposition – Starting Up... 92

Figure 54 – Belgium - e-Depot SOA platform... 93

Figure 55 – Belgium - Service Decomposition – Starting up ... 95

Figure 56 – Sweden - Service Decomposition – Managing – Accounts ... 96

Figure 57 – Sweden - Service Decomposition – Managing – Tax ... 97

Figure 58 – Sweden - Service Decomposition – Managing – Staff ... 99

Figure 59 – Sweden - Service Decomposition – Managing – Land and Property ... 101

Figure 60 – Italy – Service Decomposition - Managing – Land and Property... 103

Figure 61 – Italy – Service Decomposition - Managing – Tax... 104

Figure 62 – Belgium – Service Decomposition - Managing – Accounts ... 105

Figure 63 – Belgium - Service Decomposition – Managing – Tax... 107

Figure 64 – Belgian Cross Roads Bank for Social Security (CBSS) ... 107

Figure 65 – Belgium - Service Decomposition - Managing – Social Security ... 109

Figure 66 – Belgium - Service Decomposition - Managing – Land and Property ... 110

Figure 67 – Sweden - Service Decomposition – Expanding – Mergers... 112

Figure 68 – Sweden - Service Decomposition – EU Market – Import/Export... 113

Figure 69 – Italy – Service Decomposition – EU Market – Import/Export ... 115

Figure 70 – Sweden - Service Decomposition – Responsible Business – Environment ... 117

Figure 71 – Sweden - Service Decomposition – Exit Strategy – Winding up... 118

Figure 72 – Italy – Service Decomposition - Exit Strategy – Winding Up... 120

(7)

v

Table of tables

Table 1– Building blocks for the Service Decomposition Methodology ... 28

Table 2 – Total Identified Services in three Member States... 35

Table 3 – Identified Fundamental Services – Starting Up ... 36

Table 4 – Identified Fundamental Services – Managing ... 37

Table 5 – Suggested reporting template... 40

Table 6 – Indicators of Impact... 64

Table 7 – Impact of the eDepot ... 66

Table 8 – Impact of the Cross Roads Bank for Social Security... 69

Table 9 – Impact of the German Administration Services Directory ... 71

Table 10 – Impact of the Danish Registration of Land and Property ... 72

Table 11 – Comparison of the Danish Registration of Land and Property ... 72

Table 12 – Potential Impact of Flu Prediction Service ... 74

Table 13 - Potential Impact of ‘one-stop-shop’ company registration ... 76

Table 14 - Potential Impact of Front Office for Licences and Permits ... 77

Table 15 – Overall impacts of a cloud of public services... 79

Table 16 – Taxonomy and Method Summary... 80

Table 17 – Sweden - Starting Up... 90

Table 18 – Italy - Starting Up ... 91

Table 19 - Belgium - Starting Up ... 94

Table 20 – Sweden - Managing – Accounts ... 95

Table 21 – Sweden - Managing – Tax... 96

Table 22 – Sweden - Managing – Staff... 98

Table 23 – Sweden - Managing – Land and Property... 100

Table 24 – Italy – Managing – Land and Property ... 102

Table 25 – Italy - Managing – Tax ... 104

Table 26 – Belgium – Managing - Accounts... 105

Table 27 – Belgium – Managing - Tax ... 106

Table 28 – Belgium - Managing – Social Security ... 108

Table 29 – Belgium - Managing – Land and Property ... 109

Table 30 – Sweden - Expanding – Branch and Mergers... 111

Table 31 – Sweden – EU Market – Import/Export ... 113

Table 32 – Italy – EU Market – Import/Export... 114

Table 33 – Sweden - Responsible Business - Environment ... 116

Table 34 – Sweden – Exit Strategy – Winding Up ... 117

Table 35 – Italy – Exit Strategy – Winding Up ... 119

(8)

vi

Glossary

Abbreviation Full expression

ACID Atomic, Consistent, Isolated and Durable

ASA/DAV Agence pour le Simplification

Administrative/Dienst Administratieve

Vereenvoudiging = Agency for Administrative Simplification

BDS Basic Data Service

BLS Basic Logic Service

BPS Basic Public Service

BTEP Business Transformation Enablement Program

CBE Belgian Crossroads Bank for Enterprises

CBSS Belgian Crossroads Bank for Social Security

CIP Competitiveness and Innovation framework

Programme

COFOG UN Classification of Functions of Government

CPS Composed Public Service

DVDV German Administration Services Directory

eGEP eGovernment Economics Project

EIA European Interoperability Architecture

eID Electronic identity

eIDM Electronic identity management

EIIS European Interoperable Infratsructure Services

EIS European Interoperability Strategy

eSignature Electronic signature

eTL Danish system for the Registration of Land and

Property

FEDICT Belgian Federal Institution for Communication

and Technology

FSB Federal Service Bus

(9)

vii

ICT PSP ICT Policy Support Programme

IDABC Interoperable Delivery of European eGovernment

Services to public Administrations, Businesses and Citizens

ISA Interoperability Solutions for European Public

Administrations

IT Information Technology

NORA Reference architecture for the Dutch government

OSIMM Open Group's Service Integration Maturity Model

PPS Process Public Service

PSC Point of Single Contact

Saas Software as a Service

SAGA German Standards and Architectures for

eGovernment Applications Guideline

SOA Service Oriented Architecture

SOADM Service Oriented Design and Development

Method

SOMA Service-oriented modeling and architecture

methodology

(10)

1

1 Introduction

1.1 Objectives

The objective of this study is to identify ‘Fundamental Services’ in the context of new "Universal or Global" SOA approaches to the provision of eGovernment services. The key questions which it addresses are: at which level of granularity can ‘Fundamental Services’ be defined? Which ones have the highest potential for reuse? And what are the possibilities for and the potential impacts of delivering public services in line with the concept of a ‘cloud of public services’?

In this context and against the background of significant recent policy and technological developments, the study developed a service taxonomy and methodology in order to identify the ‘building blocks’ of public services delivered online for citizens and businesses. The proposed taxonomy and methodology, which are based on a review of existing SOA-related literature, were then applied via case studies within the scope of the life cycle of a business in three Member States (Sweden, Italy and Belgium) in order to develop a definition of a ‘Fundamental Service.’ Finally, based on real-life approaches to the provision of online public services for reuse by different actors (public administrations and third parties), as well as suggested future scenarios, the study analysed the possibilities for the design of a ‘cloud of public services’ and of the impact of offering public services in this way. The main conclusions of the study are then presented and a number of recommendations for future activities are made.

1.2 Context

1.2.1 eGovernment

The end of the first decade of the 21st_{Century has been described as both a ‘historical turning point’ in} the development of eGovernment and its ‘coming of age.’1_{These statements, contained in a 2009} working document by the European Commission’s eGovernment Sub-group, are corroborated by both the increase of policy measures in this field and the changes in the availability and use of Information and Communication Technologies (ICT) for public service provision.

At the launch of the 2011-2015 eGovernment Action Plan for Europe,2 Digital Agenda Commissioner Neelie Kroes outlined its aim to ”help public authorities to use ICT to offer better services at lower cost, while making life easier and better for citizens and businesses”.3_{Her words reflected the evolution in} the factors motivating the development of eGovernment over time:

Initially, the introduction of ICT in government was driven by the need for greater efficiency. Subsequently, the effectiveness of public service provision was included as a goal.

Latterly, good governance has been added as an objective in its own right.

This sequence of drivers can be observed in the Action Plan’s four priorities, which are based on the 2009 Ministerial eGovernment Conference Declaration at Malmo, Sweden.4 It set out actions which aim to: empower citizens and businesses, reinforce mobility in the Single Market, enable efficiency and effectiveness, and create the key pre-conditions for eGovernment. The Action Plan also supports

1_{Visions and priorities for eGovernment in Europe: Orientations for a post 2010 eGovernment Action Plan, European}

Commission eGovernment Sub-group, Working Paper (20 March 2009)

2_{The European eGovernment Action Plan 2011-2015: Harnessing ICT to promote smart, sustainable & innovative Government,}

European Commission COM(2010)743 (15 December 2010)

3_{Digital Agenda: eGovernment Action Plan to smooth access to public services across the EU, European Commission}

IP/10/1718 (15 December 2010)

(11)

2 and complements the recent Digital Agenda5, which seeks to contribute towards the development of open, flexible and personalised eGovernment services for citizens and businesses.

In particular, the current eGovernment Action Plan for Europe mentions the need for eGovernment services to “rely on and benefit from innovative technical approaches, such as clouds of public services and service-oriented architecture (SOA) to build open, flexible and collaborative eGovernment services while at the same time lowering ICT costs”. Such innovative eGovernment is based on developments in recent years in which ICT in government has shifted from more ‘silo’ government approaches with a focus on the back-office, towards more back- and front-office integration, via a collaborative approach, third party involvement and public private complementarity (also referred to as Tao government) 6_.

In addition to facilitating the delivery of public services by public administrations, this signifies a shift away from the question of who produces public services per se, to the problem of how to distribute value in society in an optimal way. This is emphasised by the Malmo Declaration’s call for ”collaboration with third parties for example businesses, civil society or individual citizens, in order to develop user-driven eGovernment services” and the Action Plan’s focus on the priority of the ‘Collaborative Production of Services’.

This approach is in line with what Commissioner Kroes referred to in a speech launching the eGovernment Action Plan as ‘weGov’.7_{In the context of Public Service Information (PSI), the ‘weGov’} vision aims to ‘open data’ so that, as well as public administrations, citizens and businesses can make use of it. In terms of public service provision, public-private complementarity, enabling government and third parties to work together and share responsibility for the production and provision of services is compatible with these goals.

Putting this vision into practice requires a flexible and open ICT architecture and innovative

technological approaches that enables the reuse of public services and data. This will not only benefit the provision of internet-based government 'one stop shops’, it also allows for third parties to embed public services into other platforms and combine them, thus acting as an intermediary gateway or independent provider of services to the user (e.g. citizens and businesses).

The move towards this increasingly participatory ICT model, is also evidenced by the following of main trends:

A shift from using ICT for supporting or replacing existing administrative processes, towards process re-engineering and reorganisation of institutional and administrative boundaries; A growing interest in technologies (e.g. eIDM, eSignature, eAuthentication) that allow for a

better integration of administrative processes and for the delivery of personalised services; A strong interest in technologies that integrate internal/external processes (back/front office) The growing need to harmonise rules and procedures and to give more priority to

interoperability, exploiting the use of 'open' environments (e.g. open standards and source); In this context, this study seeks to examine the potential for and impact of offering public services in an open and interoperable way. The reuse of public services by both different public administrations and third parties could make a significant contribution to the move towards the collaborative model of eGovernment and the reorientation of online service provision towards the creation of ‘public value’ shared by all actors in society.

1.2.2 Service Oriented Architecture

The SOA Work Group of the Open Group, a global consortium which leads the development of open, vendor-neutral IT standards and certifications, defines SOA in the technical sense as follows:8

It ‘is an architectural style that supports service orientation. Service orientation is a way of thinking in terms of services and service-based development and the outcomes of services. [...] SOA is an architectural style that is defined as the combination of distinctive features in which the architecture is performed or expressed. The SOA architectural style has the following features:

5_{A Digital Agenda for Europe, European Commission COM(2010) 245 final/2 (26 August 2010)}

6_{Visions and priorities for eGovernment in Europe: Orientations for a post 2010 eGovernment Action Plan, European}

Commission eGovernment Sub-group, Working Paper (20 March 2009)

7_{‘My vision for eGovernment, and how to make it real,’ European Commission Vice-President Neelie Kroes, SPEECH/10/752,}

"Lift-Off towards Open Government" Conference (15 December 2010)

(12)

3 It is based on the design of the services – which mirror real-world business activities –

comprising the enterprise (or inter-enterprise) business processes.

Service representation utilises business descriptions to provide context (i.e., business process, goal, rule, policy, service interface, and service component) and implements services using service orchestration.

It places unique requirements on the infrastructure – it is recommended that implementations use open standards to realize interoperability and location transparency.

Implementations are environment-specific – they are constrained or enabled by context and must be described within that context.

It requires strong governance of service representation and implementation.’

Already widely employed in the private and public sector, SOA, according to Josuttis (2007)9_{is based} on three main concepts: services, interoperability through an enterprise service bus, and loose coupling. An enterprise service bus is the infrastructure, which enables high interoperability between distributed systems for services. It makes it easier to distribute business processes over multiple systems using different platforms and technologies. Loose coupling is the concept of reducing system dependencies.

SOA enables developers to reuse existing functionality to create new applications based on existing software services. The marginal cost of developing new applications via SOA is therefore relatively low, as the components and software already exist and have been tested. This is technically known as ‘orchestration’ or ‘aggregation’, a method in which new business processes and applications are combined and built from existing services. Figure 2 below, shows that different steps of a business process can be can be implemented by reusing or combining Services A and B.

Figure 2 - Service Orchestration

In the government context, a public service is a ‘real life’ business process, which can be delivered in many ways. Public services can be provided directly - in person, remotely or electronically - or via in the ‘back-office’ of public administrations without the citizens or businesses’ awareness or involvement. This study focuses on eGovernment: the provision of public services online.

An important concept in online service delivery is the notion of ‘life events’. According to Trochidis, Tambouris, and Tarabanis (2007),10_{a life-event includes all public services which are related to a} specific situation that citizens and businesses face. Many EU Member States have adopted this approach to organise their online public service provision in an understandable and logical way. These findings are corroborated by the development of electronic Points of Single Contact by Member States in compliance with the 2006 ‘Services Directive,’11_{which follow life events for businesses.}

9_{SOA in Practice: The Art of Distributed System Design, Josuttis, N.M., (2007)}

10_{An Ontology for Modeling Life-Events, Trochidis, I., Tambouris,E., and Tarabanis, K.A., (2007)}

(13)

4 Indeed, the 2003 IDABC Report on ‘Harmonizing 'life events' online across Europe’12_{concludes that} ‘Europe's public administrations are increasingly defining eGovernment services around 'life events', i.e. important stages in a citizen's life, such as school, marriage, or buying a property. […] 'Life events' package government services which are usually provided by multiple government agencies around a subject that makes sense to the citizen. The IT systems of the participating government agencies then co-operate (i.e. interoperate) for the seamless delivery of the e-service.’ For this reason, the 2010 report on ‘User expectations of a life events approach for designing e-Government services’13_was based on user experiments, assessing four cross-border scenarios, which aimed to identify the ways in which people approach a life event and how they use the available online sources to find appropriate solutions. Subsequently, four life event scenarios for future eGovernment services were developed. These (stolen valuables abroad, studying abroad, working abroad and pandemic flu) served to provide a future vision of service delivery in which a combination of services, government and private, are linked to a single life event and provided in a single online application. This highlights the potential for the reuse of eGovernment services.

In order to facilitate the reuse of public services, a number of elements must be in place. As stated in the 2010 European Interoperability Strategy, interoperability can be achieved at the legal, organisational, semantic and technical level.14_{For the latter, the EIIS study suggests that application of} a SOA approach to eGovernment is a key enabler of reusable public services.15_{It acts as ‘a service} platform consisting of many services that signify elements of business processes that can be combined and recombined into different solutions and scenarios, determined by business needs.’16

1.2.3 ‘Universal’ or ‘Global’ SOA

Despite the growing use and recognition of SOA as an important driver of open and interoperable service delivery in both the private and public sector, a review of related articles online, particularly specialised technology blogs, underlines the constant evolution in the ICT world. In response to the increasingly often-cited claim that ‘SOA is dead’17_{, already surpassed by new and innovate} architectural approaches including Mashups, Software as a Service (SaaS) and Cloud Computing itself, proponents argue that the principles on which SOA is founded remain valid. Whilst the acronym may become outdated and the deployment mechanisms will change, the architectural approach of reusing existing services functionality to create new applications is durable.18

In this context, Web 2.0 technologies have an increasingly important role to play in the move towards ‘Universal’ or ‘Global’ SOA. Indeed, Web 2.0 has been described as being about ‘the entire Web being a reusable, shareable, public SOA.’19_{Already widely employed by citizens and businesses for social} networking and other online interaction online tools and platforms have the potential to alter the dynamics between public administrations and third parties in terms of public service delivery. Indeed, the report on ‘User expectations of a life events approach for designing e-Government services’ found that social networks, crowd-sourcing, rich content, blogging, and social bookmarking can offer public administrations immense opportunities in providing user-centric, collaborative online services, which are new and easy-to-use and create more value for society as a whole.

Facilitated by Web 2.0 technologies, the evolution towards ‘Universal’ or ‘Global’ SOA highlights the different levels of SOA maturity which can be identified. The Open Group has developed a seven level and seven dimension Service Integration Maturity Model (OSIMM)20_{as is illustrated in Figure 3 below.}

12_{‘Harmonizing 'life events' online across Europe, IDABC European eGovernment Services (2003)} 13_{User expectations of a life events approach for designing e-Government services, Deloitte (2010)}

14_{'Towards interoperability for European public services', European Commission COM(2010)744 final (16 December 2010)} 15_{European Interoperable Infratsructure Services: Study on reusable systems components, IDABC (2009)}

16_{Service Oriented Architecture Compass: Business Value, Planning, and Enterprise}_{Roadmap, N. Bieberstein (2006)} 17_{SOA is Dead; Long Live Services, Thomas Manes, A., (5 January 2009)}

18_{4 SOA Myths Busted, InfoWorld (23 June 2009)}

19_{Is Web 2.0 the Global SOA? Ria News Desk (17 February 2006)}

(14)

5

Figure 3 – Service Integration Maturity Model (Open Group, 2009)

The OSIMM specifies:

A model against which the degree of service integration maturity of an organization can be assessed;

A process for assessing the current and desired degree of service integration maturity of an organization, using the model.

It has seven levels of maturity and seven dimensions across which maturity should be considered. Each level represents a significant increase in the level of maturity necessary to realise service orientation. The set of dimensions are considered essential indicators for effective SOA adoption. Whilst the first ‘Silo’ level of maturity, in a similar way to the Silo Government scenario above, represents a situation in which ‘application architectures and topologies are monolithic and lack integration between other systems across the enterprise’, the seventh Dynamically Re-configurable Services level of Maturity is a scenario in which ‘application architecture supports dynamically reconfigurable business and infrastructure services and SOA solution for internal or external partner consumption.’ At this level of maturity, this means that public services can be provided in an open and interoperable way so that different actors (public administrations and third parties) can reuse these services and create new services based on them, using existing services as building blocks. ‘Universal’ or ‘Global’ SOA has been described as "outside-in" SOA,21_{which means reusing services} within an organisation (e.g. a public administration) as well as services not created by that organisation, by connecting internal SOA to the internet

This model is also in line with the findings of the recent study on ‘User expectations of a life events approach for designing e-Government services’22_{in which the shift towards Gov 2.0 is found to entail a} shift towards a more open approach to service delivery in which ‘separate information or services ‘atoms’ that are made openly available and can be re-used and mashed up’, thereby ‘will enable[ing] third-party collaboration and [..] facilitate[ing] services when and where the citizens or businesses need them’.

21_{Outside - in SOA" ... Are you ready?, Linthicum, D., (21 November 2005)}

(15)

6

1.2.4 Building Blocks

According to a 2010 National University of Singapore/Microsoft study,23_{public administrations, the} traditional providers of public services, are ‘complex federated structures where individual government organizations work in their respective silos. This often leads to fragmented business processes and duplicated systems and technologies.’ Indeed, public services support the functioning of society and can therefore be observed across a range of policy domains: from crime and justice, education, employment and the environment, to health and well-being, tax and motoring, pensions and retirement, and travel and transport. This is reflected by the Silo Government scenario above, in which separate institutions monopolise their own ICT systems. The ‘silo approach’ is also illustrated in Figure 4 below.

Figure 4 - Silo Approach.

According to Peristeras, Loutas and Tarabanis (2008),24_{public services are part of a life event and are} defined by input, output and rules. In order to fulfil specific life events different online applications, represented by the green boxes, are provided to citizens and businesses. The individual components that make up these online applications are public services that serve as ‘building blocks’ of the final public service provided for citizens or businesses, which can be identified across different policy domains in the different silos of government. Duplication of services or systems may occur across these different silos, which leads to inefficiency and the duplication of effort. In the Figure above, those building blocks with similar functionality are represented by the dark and bright blue rounded rectangles. The ‘silo approach’ clearly provides scope for improvement by sharing these services as building blocks for the development and provision of other services which combine these. Through SOA-style architecture, these building blocks can be exposed or made available for other public administrations or third parties for reuse, as illustrated in Figure 5 below.

23_{Enterprise Architecture as Platform for Connected Government: Understanding the Impact of Enterprise Architecture on}

Connected Government – A Qualitative Analysis, Saha, P., National University of Singapore/Microsoft, (2010)

24_{Organizational engineering in public administration: the state of the art on eGovernment domain modeling. Peristeras, V.,}

(16)

7

Figure 5 - Silo Approach with Building Blocks

Despite the traditional ‘silo approach,’ the 2010 report on ‘User expectations of a life events approach for designing e-Government services’ highlighted the growing evolution from a closed ‘monolithic’ structure of public services delivery, towards a more open approach. The ‘atomic’ government model implies a move away from a top-down system, in which public administrations develop online services in a closed, non-interoperable way, towards a bottom-up approach in which small or ‘atomic’ services are developed as part of a distributed framework and offered in an open and interoperable way. This study seeks to categorise the building blocks of public services, which contribute to the fulfilment of life events and are found in different government silos in a cross-country context. It proposes a service taxonomy and decomposition model in order to identify those public services which can be reused and orchestrated by both public administrations and third parties, with a focus on developing the concept of ‘Fundamental Services’. Based on SOA-related literature and case studies in three Member States, this study has sought to define ‘Fundamental Services’ and the level of granularity at which these can be identified. This study also introduces the concept of a ‘cloud of public services.’ It is important to note that this study focuses in particular on Business Services which provide ‘business functionality,’ rather than Infrastructure Services, which provide a more generic ‘technical functionality. ’Business functionality’ is provided by a system to support one or more business processes and is tangible for end-users, whilst the ‘technical functionality’ of a system supports the delivery of one or multiple business services and is not directly accessible to end-users. A 2009 study on European Interoperable Infrastructure Services (EIIS)25_{investigates the reusability of Infrastructure} Services, and concludes that the ‘SOA paradigm appears as the more mature approach to reuse and will probably initiate more reuse.’ This holds both in the context of Infrastructure Services (the scope of the EIIS study) and Business Services (the scope of this study). Both are essential building blocks which can be reused, but Infrastructure Services provide a more generic technical support to Business Services as demonstrated by Figure 6 below.

25_{European Interoperable Infrastructure Services - Study on potential reuse of system components, IDABC European}

(17)

8

Figure 6 – Business and Infrastructure Services

1.2.5 A ‘cloud of public services’

The notion of the cloud is often associated with ‘cloud computing’ and the technical aspects of enabling a cloud environment. In this study, however, the ‘cloud’ refers to a collection of public services serving as building blocks, which can be offered in an open and interoperable way and reused and combined by public administrations and third parties as part of other services.

It is possible to illustrate the concept by drawing on existing examples of services provided in the private sector in a ‘cloud environment.’ For example, when booking a holiday on a travel website, the customer is able to put together a complete holiday package including a place to stay, a way to get there, what to do and how to get around. Travel agents often offer these services online. Through the website, a number of related services can be used to book the different elements of the holiday package, such as flights, accommodation, a visa, transport, insurance and cultural activities at the place of destination. Although each of these services is presented via a single online application, the actual service provision is undertaken by multiple providers, which offer their services in an open and interoperable way to the travel website. This facilitates reuse by different parties. The services provide the building blocks on which the overall service is based. This is illustrated in Figure 7 below.

Traveller Travel website

Figure 7 – Cloud Model: Private Services

This private sector example could also be applied to the delivery of public services. Online applications, which rely on public services as building blocks can be provided by public administrations or third parties in order to fulfil a life event for a citizen or business. In this way the ‘cloud of public services’ enables service provision by different public and private actors. This is represented in Figure 8 below.

(18)

9

Figure 8 - Cloud Model: Public Services

The ‘cloud of public services’ is linked to the concept of ‘Universal’ or ‘Global’ SOA in which services are provided openly for reuse by public administrations and third parties via the internet.

Figure 9 below illustrates the concept of a "Cloud of Public Services", which is also the framework within which the study has been performed. It focuses on the provision of the building blocks of public services in a ‘cloud of public services’ for reuse by public administrations and third parties, as illustrated by the blue arrows. In light of the factors motivating the development of eGovernment over time, as noted above, it can be expected that the ‘cloud of public services’ will have a significant impact for both service providers and the end users (citizens and businesses) in terms of Efficiency, Effectiveness and Governance. This latter factor, notably the move towards participatory systems for the collaborative production of public services by public administrations and third parties, is of relevance in the context of the Europe 2020 Strategy’s goal of ‘smart, sustainable and inclusive growth’ and jobs.26

Figure 9 – The Concept of a Cloud of Public Services

The study analyses the possibilities for the design of a ‘cloud of public services’ and of the impact of offering public services in an open and interoperable way. It covers the following main topics:

26_{Europe 2020: A Strategy for smart, sustainable and inclusive growth, European Commission COM(2010) 2020 final (3 March}

(19)

10 Chapter 2 develops a service taxonomy and methodology in order to identify the building

blocks of public services delivered online.

Following application of the service taxonomy and methodology via case studies to the life-cycle of a business in Sweden, Italy and Belgium, Chapter 3 presents the findings in terms of the public services identified. It also develops a definition of a ‘Fundamental Service’ and explores the relationship between granularity and reuse.

Chapter 4 investigates the possibilities for the design of a ‘cloud of public services’ and of the impact of offering public services in an open and interoperable way for reuse by public administrations and third parties.

(20)

11

2 Service taxonomy and

methodology to identify public

services

In order to identify the building blocks which make up public services for citizens and businesses, it is imperative to establish a common approach in terms of definitions and the categorisation of services (a service taxonomy) and a methodology to identify the different services which are part of the process of delivering an entire service to the end user (a service decomposition methodology).

This chapter describes the approach taken in this study, which comprises a review of existing SOA literature on service categorisations and SOA-related literature on methodologies to decompose a service process into different service components. The service taxonomy and the service decomposition methodology proposed allows for the identification and categorisation of services based on existing processes in the delivery of government services in three Member States (Chapter 3). This first step also facilitates an evaluation of the possibilities for the design of a ‘cloud of public services’ and the potential impacts of reuse within government or by third parties (Chapter 4).

2.1 Service

Taxonomy

The following section presents a set of existing taxonomies which have been reviewed for the purpose of this study. Based on these, a taxonomy of public services is proposed. It describes the building blocks of public services and contributes towards the development of a service decomposition methodology which, when applied to the case studies in different Member States, facilitates the identification of public services and the development of a definition of ‘Fundamental Services’.

2.1.1 Existing Service Taxonomies

In the SOA literature, there are a number of existing service definitions and classifications. A summary of a (non-exhaustive) number of different categorisations is elaborated below:

Application, Business and Process services (Erl, 2005); Entity, task and utility services (Erl, 2007);

Element and process services (Klose, Knackstedt, & Beverungen, 2009); Process, rule and entity services (Kohlmann & Alt, 2007);

Atomic and composite services (OASIS, 2009); Process, composed, basic services (Josuttis, 2007)

Application, business and process services

27

In the book ‘Service-Oriented Architecture: Concepts, Technology, and Design’ (Erl, 2005), the author makes a distinction between three classifications: application, business and process services.

Application services contain logic derived from a solution or technology platform;

Business services contain ‘business logic’ and can be divided into task-centric services and entity-centric services;

Process services represent a business process as implemented by an orchestration platform and described by a process definition.

(21)

12

Entity, task and utility services

28

In the book ‘SOA, Principles of Service Design’ (Erl, 2007), the author makes a distinction between three classifications that represent the primary service models: entity, task and utility services.

An entity service is a business centric service, which bases its functional boundary and context on one or more related business entities. It is considered a highly reusable service because it is agnostic to most parent business processes. As a result, a single entity service can be leveraged to automate multiple parent business processes.

A task service is a business service with a functional boundary, which is directly associated with a specific parent business task or process. This type of service tends to have less reuse potential and is generally positioned as the controller of a composition responsible for composing other, more process-agnostic services.

A utility service does not necessarily represent business logic, unlike the previously described service models. This essentially results in a distinct, technology-oriented service layer, which is dedicated to providing reusable, cross-cutting utility functionality, such as event logging, notification, and exception handling.

Elemental and process services

29

In the article “Identification of services - a stakeholder-based approach to SOA development and its application in the area of production planning” (Klose, Knackstedt, & Beverungen, 2009), the authors make a distinction between two types of services: elemental and process services.

Elemental services comprise atomic operations. They can however, be sub-divided into entity services and task services.

• Entity services contain operations for reading and writing data that is meaningful to an organisation (such as quotes, orders, customers, or suppliers).

• Task services comprise special operations (such as the calculation of an estimated delivery date).

Process services are more complex and incorporate operations of elemental services as building blocks. Due to their modular structure, they can be set up rapidly and with a high degree of flexibility. Designed in a more sophisticated manner, process services support rather comprehensive tasks as self-contained units of the company’s business processes.

Process, rule and entity service

30

In the article ‘Business-Driven Service Modeling - A Methodological Approach from the Finance Industry’ (Kohlmann & Alt, 2007), the authors identify three types of services: process, rules and entity services.

Process services support activities of the core processes of a company and include some reference to at least one activity of a business process.

Rule services encapsulate business and validation rules used by process services.

Entity services encapsulate core entities and business objects, such as contract, partner or order.

Atomic and composite services

31

In the text “Reference Architecture Foundation for Service Oriented Architecture” (Organization for the Advancement of Structured Information Standards - OASIS, 2009), the authors distinguish between two kinds of services: atomic services and composite services.

Atomic Services are visible to a service consumer (or agent) via a single interface and described via a single service description that does not use or interact with other services.

28_{SOA, Principle of Service Design, Erl, T. (2007)}

29_{Identification of services - a stakeholder-based approach to SOA development and its application in the area of production}

planning, Klose, Knackstedt and Beverungen, (2009)

30_{Business-Driven Service Modeling - A Methodological Approach from the Finance Industry, Kohlmann and Alt, (2007)} 31_{Reference Architecture Foundation for Service Oriented Architecture, Organization for the Advancement of Structured}

(22)

13 Composite Services are visible to a service consumer (or agent) via a single interface and described via a single service description that is the aggregation or composition of one or more other services. These other services can be atomic, composite, or both.

Process, composed and basic services

Of particular interest in the context of this study, is the distinction made in the book “SOA in Practice: The Art of Distributed System Design” (Josuttis, 2007), between three types of services: Process, Composed and Basic services.

Process Services which represent actual workflows (macro flow), combining other (basic and/or composed) services through service orchestration in a long-running flow of activities (or services) which can be interrupted by human intervention. Process services are therefore stateful meaning that they can preserve certain state across multiple calls of the service; Composed Services are based on other services which are combined into a new composed

service. Conceptually composed services are stateless and short-term running. They represent a micro flow comprising a short-running flow of activities (which are services) as part of a business process;

Basic Services implement basic business functionality which it does not make sense to split into multiple services. Basic services are also stateless and can be subdivided into two types:

Basic Data Services read or write data from or to one backend system. These services typically each represent a fundamental business operation of the back-end. Basic services encapsulate platform-specific aspects and implementation details from the outside world, so that the consumer can request a service without knowing how it is implemented. These services should provide some minimal business functionality. Basic Logic Services represent fundamental business rules. These services usually

process some input data and return corresponding results.

The service categorisations summarised above are interlinked, as illustrated by Figure 10 below.

Figure 10 – Existing Service Taxonomies

The term basic service as used by Josuttis (2007) is for example also referred to in other SOA-related literature such as Krafzig, Banke and Slama (2004).32_{Equally, alternative terminology is adopted for} such services, including for example ‘atomic services’ (Bloomberg and Schmelzer, 2006),33_‘elemental services’ (Kohlmann and Alt, 2007) or ‘business services’ (Erl, 2005). Similarly, Erl’s definition of process services covers both ‘composed’ and ‘process services’ in Josuttis’ definition. This term is also used in other SOA-literature, including Klose, Kanstedt and Beverungen (2009) and Kohlmann and Alt (2007). The term ‘composed service’ also reappears in the OASIS (2009) categorisation as ‘composite services’.

It is a common feature of the SOA-related literature that the different, but overlapping service definitions have been developed for the corporate or business domain. Whether applied to the business or the government arena however, services are generally implemented to support a certain process (a sequence of tasks or activities which is carried out in order to serve the end user, for example a client in a business environment, or in the case of government, a citizen or business). The

32_{Enterprise SOA: Service-Oriented Architecture Best Practices,} _{Krafizg, D., Banke, K., and Slama, D., (2004)}

(23)

14 challenge is therefore to investigate how these definitions can be used in order to propose a service taxonomy that will be useful in the public sector domain and for the purpose of this study.

2.1.2 Proposed Service Taxonomy

The aim of this study is to investigate and analyse the possibilities of a open and interoperable approach to the provision of eGovernment services, with a focus on ‘Fundamental Services.’ The core questions that arise therefore are: At which level of granularity can ‘Fundamental Services’ be defined? and: where is the highest potential for reuse? In this context, this section proposes a service taxonomy, based on the review of existing taxonomies, which provides both for the establishment of a certain level of granularity and for investigation of the potential for reuse.

The concept of granularity implies a certain hierarchy of services, within which there are services at higher and lower levels. This hierarchy is best illustrated by the concept of service orchestration, in which different services are combined to create a new service. In other words, the newly composed service depends on the underlying services of which it consists. Josuttis (2007) captures this idea well by introducing the different stages of SOA expansion. This is shown in Figure 11 below.

In the first stage of SOA expansion, Fundamental SOA, Basic Services are introduced which are provided through a service bus in order to provide functionality captured in a back-end (of any system - database, host, mainframe, SAP system etc. - responsible for a specific group of data and functionality);

In the second stage of SOA expansion, Federated SOA, a layer of Composed Services is added which makes use of other services (Basic or Composed) through service orchestration; In the third stage of SOA expansion, Process-enabled SOA, a layer of Process Services is

added which enable processes to be managed which may be started and controlled from different front-ends and can be interrupted by human intervention.

Figure 11 - Three layers of SOA expansion (Josuttis, 2007)

Approaching SOA and the different levels of granularity at which services are provided in this way is particularly useful given this study’s objective to identify the building blocks of public services, including ‘Fundamental Services.’

In addition, as mentioned in Chapter 1, when considering life events, it is clear that public services are often interlinked and from the perspective of the end users they are part of a process. During the life event ‘getting married’, for example, a couple needs to provide the relevant authority with a birth certificate of both partners. If getting married is a service, then ‘providing the birth certificate’ is a service that precedes the getting married service. In turn, the ‘register a marriage’ service depends on the ‘provide birth certificate’ service. This simplified example shows that there is scope to combine services or even identify a process which can have different states, such as ‘couple is married for the law’, ‘couple has provided birth certificates’ or ‘couple is registered as married in the population register’. Depending on how such services are implemented, composed and process services may be identified within this life event.

On this basis, the service taxonomy proposed in this study is based on the service categorisation provided by Josuttis (2007) and is defined as follows:

(24)

15 Process Public Services which represent actual workflows or business processes, combining

other (basic and/or composed public) services through service orchestration.

Composed Public Services: are based on other services which are combined into a new composed service.

Basic Public Services implement basic business functionality;

Basic Data Services read or write data from or to one backend system. Basic Logic Services represent fundamental business rules.

In Figure 12, the chosen service taxonomy is presented showing the relationships between the different services categories. This figure shows that a life event consists of Process Public Services. A Process Public Service is composed of Composed Public Services and/or Basic Public Services. As the name implies, Composed Public Services are composed of Basic Public Services.

These service definitions are also in line with the recommendations put forward in the European Interoperability Framework (EIF) that calls upon “public administrations to develop a component-based service model, allowing the establishment of European public services by reusing, as much as possible, existing service components”. The EIF defines basic public services as services “developed primarily for direct use by the public administration that created them, or by their direct customers, i.e. businesses and citizens, but are made available for reuse elsewhere with a view to providing aggregate public services”. According to the EIF, “aggregate public services are constructed by grouping a number of basic public services that can be accessed in a secure and controlled way [..] they can be provided by several administrations at any level, i.e. local, regional, national or even EU level"34. The service taxonomy proposed here is therefore in line with the EIF and provides a more elaborated distinction of aggregate public services into composed and process public services.

Life Event Process Public Service Composed Public Service Basic Public Service Basic Data

Service Basic Logic Service

consists of composed of composed of composed of is a is a

Figure 12 – Taxonomy of Public Services

A SOA view of the service taxonomy can also be developed. This is illustrated in Figure 13 below.

(25)

16

Figure 13 – SOA View of the Service Taxonomy based on Josuttis (2007)

Returning to two of the core questions of this study (At what level of granularity can ’Fundamental Services’ be defined? and where is the highest potential for reuse?), Chapter 3 presents the main findings of the implementation of this service taxonomy as part of the methodology (proposed in the next section) in order to develop a definition of a ‘Fundamental Service.’ Whilst Chapter 4 subsequently investigates the potential for the real-life reuse of these services, the SOA-related literature provides some more conceptual ideas for looking at the concept of granularity and reusability.

In the context of the proposed service taxonomy, an important distinction is made between ‘stateful’ and ‘stateless’ services. Stateless is defined by Colan (2004)35_{as the idea that a service should be} independent and return a response as an independent, self-contained request, which does not require information or state from one request to another when implemented. Process Services are required to keep track of a state because they represent actual, long-running workflows. Composed and Basic Services are stateless, because they need to return the result (storing some element in a database or calculating the result of a rule, for example) as soon as the services are executed and return in their original state. Stateless services are more likely to be reusable given that they perform an operation and return as an independent, self-contained request.

Josuttis (2007) also refers to Allen (2006), who defines a set of guidelines for ‘an optimum level of granularity for a lowest level service.’ Allen argues that:

It should be possible to describe the service in terms of function, information, goals, and rules, but not in terms of groups of other services.

The function set of a service should operate as a family unit that offers business capability. A single role should take responsibility for the service.

The service should be as self-contained as possible. Ideally, it should be autonomous.

Josuttis (2007) goes on to argue that Basic Services, which can be found in the lowest of the three layers of service expansion, the Fundamental SOA layer, should have the so-called ‘ACID’ properties:

35_{Service-Oriented Architecture expands the vision of web services, Part 1: Characteristics of Service-Oriented Architecture,}

(26)

17 Atomic: meaning that the call of the service either succeeds or has no effect. Ensuring this

property is the task of the backend that provides a service.

Consistent: meaning that after the service call, the backend is left in a legal, consistent state. Thus, no service call should be able to bring a backend into an inconsistent state.

Isolated: meaning that a service being processed by a backend is not influenced by other service calls running on the same backend at the same time. That is, a read service should return data that is consistent in itself.

Durable: meaning that after a service call succeeds, it is guaranteed that the effect is persistent. That is, no system failure is able to undo the result of the service call by accident. Allen (2006) further introduces the concept of service stability to indicate the level of reusability, by distinguishing between three key types of business services: Commodity, Territory and Value-Added services. The former are universal, stable services, sufficiently established to be used at a low-level of risk and with maximum reuse in mind. The latter are services which differentiate a company from competitors and usually are highly innovative.

With these theoretical concepts in mind, Chapter 3 explores the different types of services with the aim of establishing a definition of ‘Fundamental Services,’ following the implementation of the service taxonomy and methodology presented in the next section in three Member States.

2.2 Service

Decomposition Methodology

Based on the proposed service taxonomy, a decomposition of services must be undertaken in order to identify the different building blocks of public services, including ‘Fundamental Services’. The following section presents a set of existing service decomposition methodologies, which have been reviewed for the purpose of this study. Based on these, a new methodology to identify public services is proposed. The service taxonomy and methodology is then applied to three Member States, in order to identify public services and develop a definition of ‘Fundamental Services.’ This facilitates an analysis of the possibilities for the design of a ‘cloud of public services’ and of the impact of offering public services in an open and interoperable way for reuse by public administrations and third parties.

2.2.1 Existing Service Decomposition Methodologies

In the SOA-related literature, there are a number of existing methodologies, which aim to identify services. A summary of a (non-exhaustive) number of different categorisations is elaborated below:

Service-Oriented Modeling and Architecture (Arsanjani, Ghosh, Allam, Abdollah, Ganapathy, and Holley, 2008)

Business Transformation Enablement Program (Government of Canada);

Service Oriented Design and Development Method (Papazoglou & Heuvel, Service Oriented Design and Development Methodology, 2006);

Component Identification (Wang and Zhan);

Service-Oriented Architecture: Concepts, Technology and Design (Erl, 2005).

Service-oriented modeling and architecture methodology (SOMA)

36

The SOMA method is a process for the identification, specification and realization of services. It proposes a layered model, which uses both top-down and bottom up approaches, together with goal-service modelling. High-level business process functionality is externalized for large-grained goal-services. Smaller-grained services -- those that help realize the higher level of services -- are identified by examining the existing legacy functionality and deciding how to create adaptors and wrappers, or componentizing the legacy to externalize the desired functionality. This is illustrated in Figure 14.

36_{SOMA: A method for developing service-oriented solutions, Arsanjani, A., Ghosh, S., Allam, A., Abdollah, T., Ganapathy, S.,}

(27)

18

Figure 14 – Service-oriented Modelling and Architecture Methodology

Business Transformation Enablement Program (BTEP)

37

The BTEP provides a Toolkit enabling strategic planning and design across governments supporting interoperability and integration. It provides a ‘common language’ to identify programs and services that serve the same target groups. The tools enable different public sector actors to undertake collaborative alignment, analysis, and problem definition. This creates consensus about transformation opportunities, such as streamlining business processes and integrating services.

One of the tools in the BTEP Toolkit – the Governments of Canada Strategic Reference Models – provides ‘universal’ definitions for terms commonly used in the public sector, such as ‘program’, ‘service’, ‘need’, ‘output’ and ‘outcome’. This enables participants to produce models that graphically and ‘objectively’ depict different views of their business, allowing high level analysis. The Toolkit aims to enable governments to use the same approach to identify, design and implement change, resulting in greater consistency and reusability in business transformation across the public sector.

Service Oriented Design and Development Method (SOADM)

38

This SOADM is based on an iterative and incremental process which comprises one preparatory and eight distinct main phases that concentrate on business processes. These phases are planning, analysis and design, construction and testing, provisioning, deployment, execution and monitoring. The approach, illustrated in Figure 15 below, considers multiple realization scenarios for business processes and Web services that take into account both technical and business concerns.

37_{Business Transformation Enablement Program (ВТЕР), Government of Canada (n.d.)}

(28)

19

Figure 15 - Service Oriented Design and Development Method (SOADM)

During the Planning phase, the project feasibility, goals, rules and procedures are set and requirements are gathered. The Analysis and Design phase is based on a thorough business case analysis which considers various alternatives for implementing business processes. Service Construction and Testing involves coding web services and business processes using the specifications that were developed during the design phase. The service Provisioning phase then enforces the business model, which is chosen during the planning phase. Once the provisioning model has been established, the Web services may be deployed and advertised in a repository system. The final phase deals with the execution and monitoring of Web services. This phase includes the actual binding and run-time invocation of the deployed services as well as managing and monitoring their lifecycle.

Component Identification Methodology

39

Component Identification is a formal technique used to analyse domain business models to develop a set of business components with high reuse value and good reuse performance. Component Identification is a main task in domain engineering, in which a set of reusable components are obtained by analysis, clustering and abstraction from domain business models.

The identification process consists of the following steps, which are illustrated in Figure 16 below: Partition:

Abstraction:

Aggregation and decomposition: Structure design:

Performance evaluation:

In the figure below, a graphical representation of the Component Identification process is given.

(29)

20

Figure 16 - Component Identification Methodology

Service Oriented Architecture: Concepts, Technology and Design

This method identifies six steps in the lifecycle of an SOA delivery project: Service Oriented Analysis; Service Oriented Design; Service development; testing; deployment; and administration.

The first two phases are of particular relevance to this study. Service Oriented Analysis is where the initial scope of an SOA project is determined, service layers are mapped out and the individual services are modelled as service candidates that comprise a preliminary SOA.

The model considers three main types of service layers: Application, Business and Orchestration. The Application service layer abstracts non-business-related logic into a set of services that can be referred to as application services (or utility services). Their aim is to provide reusable functions that address cross cutting concerns by representing common enterprise resources and capabilities. The Business service layer represents a collection of services based on the business service model. It is through this service layer that a close alignment between an organization’s business and technology domains can be achieved. In most enterprises, designing a business service layer leads to the creation of two common business service models, each of which establishes its own sub-layer.

The Orchestration service layer introduces a parent level of abstraction. Within this service layer, process services comprise other services which provide a specific sets of functions, independent of the business rules and scenario specific logic required to execute a process instance.

Service oriented design is a heavily standards driven phase that incorporates industry conventions and service oriented principles into the service design process. It is the process by which concrete physical service designs are derived from logical service candidates and then assembled into abstract compositions that implements a business process.

To analyse the required services in an organisation, a strategy is needed. Three common strategies emerge, each addressing this problem in a different manner: Top down; Bottom up; and Agile.

2.2.2 Proposed Service Decomposition Methodology

Each of the existing methodologies assessed include a number of advantages and disadvantages. Whilst the Service-Oriented Modelling and Architecture methodology offers a pragmatic combination of a top down and bottom up approach to service identification, its focuses on a technical approach to implementation, which is beyond the scope of this study. The Service Oriented Design and Development Method, on the other hand, is well documented and offers an iterative approach to service identification, however fails to define an appropriate level of granularity. The Component Identification approach meanwhile provides an interesting component identification process, but its formality is at once a strength and weakness - it provides a proven approach, which is though difficult to understand for the non-initiated reader. Whilst the Service-Oriented Architecture methodology is very detailed and well illustrated by case studies, it lacks the necessary criteria for reuse. The BTEP is the only model which is already used in government context and therefore provides a common language, which is commonly used in the public sector. Its presentation as Toolkit, rather than a fully described methodology and lack of granularity represent however a disadvantage.

Study on cloud and service oriented architectures for e- government Final report