Keywords

1 Introduction

The business processes in the service-oriented computational model are modelled and implemented from the perspective of services. Services are autonomous and platform-independent computational entities. Services can be described, published, discovered, and dynamically assembled to develop distributed, interoperable and evolvable systems. Service-oriented computing (SOC) utilizes services as basic constructs to support the rapid development of low cost and easy composition of distributed applications even in heterogeneous computing environments. SOC is intended to make services available, where applications are assembled with little effort in a network of loosely coupled services, to create flexible business processes and agile applications that can span different organizations and computing platforms [1].

The government, in general, appears as a high potential scenario for the service-oriented solutions deployment, especially due to the large number of existing applications, technological diversity, the need for interaction between these applications and the need for service quality management. However, the scenario described does not exempt the government from the challenges related to the paradigm of service-oriented development.

In the electronic government (e-government) context when the term service is used, it easily relates to the term electronic service directly provided to the citizen, through an end-user interface. In this paper, the term service is used to represent a software interface, provided by a government, to be consumed by applications from governmental institutions or non-governmental institutions.

Currently a large number of information systems are created and developed in the three Brazilian government levels (Federal, State and Municipal) and its various sectors (Executive, Legislative and Judiciary), but the services are generally created as from basic principles, without considering the reuse of service-oriented solutions by other public entities. Thus, efforts to devise solutions through the paradigm of services are not taken advantage of. Although there are electronic means to disseminate services, such as the Federal Government interoperable service catalog, these are not disclosed in order to reuse the solution, but in order to consume those services. What is observed is the lack of support to encourage the reuse of service-oriented solutions designed for business processes related to electronic government.

The reuse of solutions that have already been devised and that worked in the past is a good practice in the development of systems, regardless of the paradigm this implies. Although Gamma et al. [2] address the object-oriented paradigm, they point out that the best designers know they should not solve a problem based on basic principles or from scratch.

Research related to e-government is mostly multidisciplinary [3], involving several areas of study, such as politics, management and information technology. In that sense, this paper presents a research related to SOC in the e-government scenario. The goal is to define a method to support the reuse of the service concept in the setting of e-government. To achieve this goal, the use of service patterns for government scenario is suggested.

2 Interoperability and Service-Oriented Architecture

The government to government (G2G) interaction is classified as back office while government to citizen (G2C) and government to business (G2B) interactions are front office. The back office interactions are considered problematic due to different difficulties of interoperability [4].

It is often difficult to achieve interoperability in government organizations. In some situations, government agencies are reluctant to change existing work processes, make their data and services available to external partners and renegotiate their transactions with external parties [5].

Aguair et al. [6] emphasize that the definition of patterns, norms and methods facilitates and improvement the interaction among the various sectors and levels of government, as well as with society in general. It is essential that there is communication and integration between management and technological aspects to proceed with the actions of e-government.

Several interoperability standards for e-government have been defined, e.g., e-Government Interoperability Framework (e-GIF) defined by the United Kingdom [7]. The e-GIF has become a reference standard for interoperability of e-government.

The Brazilian Federal Government developed the Interoperability Standards of Electronic Government (e-PING) which defines a minimum set of premises, policies and technical specifications governing the use of Information and Communication Technology in the federal Government, establishing the conditions of interaction with the other sectors and levels of government and society in general [8]. The areas covered by e-PING are: Interconnection, Security, Means of Access, Information Organization and Exchange, and Integration of Electronic Government. Specifically in the area of integration for Electronic Government, the goal is to approach and to explore the boundaries between the technological, semantic and organizational guidelines and policies seeking public management improvement from the view of an interoperable technology platform. Some products available are: Interoperability Guide and Catalog of Interoperability composed of Services Catalog (Web Services) and Data Standard Catalog.

According to the e-PING [8] reference document the clearly defined policies and specifications for interoperability and information management are essential to facilitate the connection of government, both internally and in its contact with society, and at a higher level scope, with the rest of the world—other governments and companies in the global market.

The e-Government Interoperability Guide provided by the United Nations Development Program [9] has suggested that a Service-Oriented Architecture (SOA) is the best underlying paradigm with which to begin to roll out e-government services that can be used in cross-agency and cross-border situations. The use of SOA is also recommended by e-PING [8], as a technical guideline for the integration of information systems.

The term SOC is often confused with the term Service-Oriented Architecture and sometimes used interchangeably, although they are distinct. SOC is a paradigm of distributed computing. This computing model is composed of several elements, including the service-oriented design paradigm, the proper services, service composition, services inventory and SOA. SOA is characterized by the introduction of new technologies and platforms to support the creation, implementation and evolution of service-oriented solutions. A SOA implementation is unique to each company and may have different combinations of technologies, products, APIs and supporting infrastructure [10].

According to Sommerville [11], the principle of service-oriented software engineering is building a program by composing independent services that include reusable functionalities.

The most recommended technology for interoperability is SOA, implemented using Web Services [12].

The interoperability of services is a key goal of service orientation and it lays the foundation to achieve the strategic benefits of SOC [10].

Challenges of developing services for the purpose of implementing G2G interoperability are dealt with by Klischewski and Askar [13]. These challenges are related to several factors, including the definition of service scope and the definition of the service interface granularity.

3 Service Patterns

Generally speaking, patterns are reusable solutions for recurrent design problems [14]. The concept of service patterns used in this study is similar to that defined by Fki et al. [15] an abstract service representing a generic and reusable description. Besides this definition, service patterns must contemplate the description of atomic services and compound services, as well as the interactions between services. Thus, the service patterns will be able to meet a government task or business process.

Table 1 illustrates some differences in the terms services and service patterns used in this study.

Table 1 Services and service patterns
Full size table

In the service-oriented development process, the unit of software to be reused is the service. When inserting the concept of service patterns in the process of service-oriented development, the goal is to reuse the service concept and service logic represented by the pattern.

The use of the design principles of service orientation (e.g. Standardized Service Contract, Low Coupling, Service Reuse Capability) assists in defining how the logic should be decomposed and modeled into services. These principles support or contribute to the interoperability of services. The goal is to produce inventories of highly reusable services to meet new business demands. In this sense, the organization must adopt methods that help identifying services to build their inventories.

The goal of using service patterns is to assist the specification of new services from existing services in the government, aiming at the reuse of already devised solutions. The goal of SOC is to have service inventories that can meet business processes. Therefore, based on the modelled business process the service patterns catalog should be consulted in order to locate service patterns that may be suitable for the business process.

The service pattern should serve as a reference for the specification of a service. Figure 1 shows a conceptual view of service patterns and related elements. The catalog consists of service patterns, each of which contains a description, a service interface, and each service capability contains an activity diagram that represents the behavior of that capability.

Fig. 1
figure 1

Elements related to service pattern

Full size image

4 Proposed Method

Considering the redundancy of functional characteristics in the government scenario, this research aims to: (1) provide mechanisms to support the reuse of e-government service concepts; (2) add value to service specification activity in the life cycle of services in e-government scenario and (3) reduce redundancy of efforts in the design of new services for the same purposes in other levels and sectors of the government.

The Service Specification Method for e-Government (SSMe-Gov) was proposed in order to assist the specification of e-government services. In this method, the service patterns are defined from existing services in the government. The service patterns should be cataloged in a repository to serve as a reference for the creation of new services. Figure 2 illustrates an abstract view of SSMe-Gov.

  1. (a)

    Definition of Service Patterns: in order to define service patterns, the concept linked to a service should be abstracted and represented as a service pattern. The service patterns are documented using the Service Pattern Description template and service patterns are cataloged in the service pattern repository.

  2. (b)

    Creation of new services: in order to create new services cataloged service patterns should be used as reference.

Fig. 2
figure 2

Proposed method

Full size image
Fig. 3
figure 3

Government services by area

Full size image

4.1 Definition of Service Patterns

This activity consists in abstracting concepts linked to a service and representing it as a service pattern. For this activity some government services were identified and analyzed, and from this analysis it was possible to generalize the concept and represent it as a service pattern allowing the concept to be reused.

Among the principles of service-oriented design, the capability of service reuse is strongly bonded to the research described in this paper.

The service pattern description structure should contain a set of aspects that supports the understanding of the pattern. According to Li et al. [14], the main advantage of a pattern description structure is that it introduces a structured way to understand, explain and reason out patterns. Also, it allows for more effective communication between software engineers and domain experts, because a pattern description structure in particular provides a common language to talk about patterns.

There is no established rule on the format used to describe a service pattern, therefore this work defined a template named Service Pattern Description, as shown in Table 2. This template was defined from the analysis of the works, such as Tchuta and Chunhua [16], Li et al. [14] and Fki et al. [15].

Table 2 Service pattern description template
Full size table

The aim of the catalog is to bring together service patterns defined and documented in order to expedite the location of service patterns. Service patterns will be classified in the catalog according to government areas. Examples of government areas are education, health, finance, social security and work.

Services portfolio aims to ensure that services can be reused and shared. On the other hand, catalogs of service patterns, in this work, aim to support the reuse of the service concepts.

Obtaining reuse depends not only on technical issues; it is strongly related to the issues of management and organizational culture. While creating the service patterns catalog itself does not ensure the reuse, it can support reuse and service designing. The creation of service patterns can support the reuse of the concepts associated with the services.

4.2 Creation of New Government Services

Cataloged service patterns form the basis for the design of new services. Those interested can consult the catalog of service patterns and from the cataloged service patterns create a new service, using the selected service patterns as reference.

A service pattern can be used as a basis for designing services for multiple inventories or it can also be the basis for creating multiple services for a same inventory. The decision whether a service pattern will result in a service in an inventory or multiple services on the same inventory, will depend on the level of granularity required for the service to be created.

Although the discussion on the granularity of a service created from a service pattern is outside the scope of this research, it is worth noting the following considerations:

  • whereas public service inventories are to meet the business process of the government, such inventories should theoretically have a similar level of granularity;

  • there are currently no government guidelines regarding the granularity of services. Government entities are most frequently responsible for designing services and conducting SOA governance, it is their role to decide on the granularity.

4.3 Evaluation

In order to evaluate the proposed method, survey and experimental research approaches were used.

A survey of services was initially carried out with the aim of collecting information about the use of services (Web Services) and SOA within the Brazilian government.

Data collection was performed by means of an electronic questionnaire developed with the Emailmeform [19] tool. The questionnaire was sent to 125 organizations, out of which, 14 organizations responded to the questionnaire. These 14 organizations have described a total of 57 services and 97 capabilities. Several issues about the services have been raised, such as: service objective, system name of service supplier, government level that meets the service, if the service is composed, the service implementation technology (Fig. 4) and the government area where the service is used (Fig. 3).

Fig. 4
figure 4

Services using the Web Services technology

Full size image

Following the data collection, the experiment, divided into 2 stages, was conducted to apply the method in SSMe-Gov e-government scenario:

  1. 1.

    Definition of service patterns—The services listed in the survey were analyzed and subsequently service patterns were generated. Examples of service patterns created in this step are: Financial Entry and Electronic Tax Document Batch Reception.

  2. 2.

    Creation of new services—services were created from the patterns set in the previous step.

This experiment shows that it is possible to define service patterns from the analysis of existing services in the government and benefit from the experience of experts represented in the service patterns.

4.4 Service Lifecycle

Marks and Bell [17] state that the lack of interoperability can result from the differential applications of policies, standards, and process. The way to achieve interoperable services is to enforce a body of SOA policies across the service lifecycle: identification, design and implementation.

Several service life cycles have been defined, e.g. those defined by Marks and Bell [17], Arsanjani et al. [18], and Gu and Lago [19]. In general, all of these cycles include the following activities: business process analysis, identification, modeling (analysis and design), development and service management.

Thus the proposed use of service patterns presented in this paper aims to add an activity in the lifecycle of services, called “Location of Candidate Service Patterns”, as illustrated in Fig. 5.

Fig. 5
figure 5

Proposed lifecycle

Full size image

The activity “Location of Candidate Service Patterns” must be performed by consulting the catalog of e-government service patterns. The aim is to find patterns of services that meet the business process in question. The service patterns will be used as reference to create new services.

5 Conclusions

The SSMe-Gov method based on service pattern has been proposed in order to specify e-government services. The proposal of service designing allied to the concept of service patterns aims to reduce redundancy of efforts in the design and project of new services for the same purposes in other levels and sectors of the government.

Besides the SSMe-Gov, other items have been proposed: a conceptual view of the elements related to the service patterns and the use of service patterns in the lifecycle of services.

This solution was designed considering the lack of subsidies to encourage the reuse of oriented services solutions designed to meet the business processes related to e-government. To demonstrate the relevance of the proposal described in this work, the SSMe-Gov method was applied to a government scenario. From government services, service patterns have been defined and from these patterns, new services have been created.

Future studies may consider aspects of the creation and location of service patterns in the catalog of services, the level of granularity of the service to be created from the service patterns and other sources for the setting of service patterns, such as the business processes.