Linking service development methods to interoperability governance: The case of Egypt

Government Information Quarterly 29 (2012) S22–S31

Contents lists available at SciVerse ScienceDirect

Government Information Quarterly j o u r n a l h o m e p a g e : w w w. e l s ev i e r. c o m / l o c a t e / g ov i n f

Linking service development methods to interoperability governance: The case of Egypt Ralf Klischewski ⁎, Eman Askar German University in Cairo — GUC, Faculty of Management Technology, Al Tagamoa Al Khames, 11835 New Cairo City, Egypt

a r t i c l e

i n f o

Available online 9 September 2011 Keywords: G2G services Government interoperability Interoperability governance Service development methods Web services Egypt

a b s t r a c t While administrations, and especially e-government “followers,” have been recommended adopting serviceoriented architecture (SOA) for the purpose of implementing G2G interoperability, the challenges of reaching this objective remain significant. General guidelines for service development and SOA governance are published, but in view of many self-contained units and IT departments on all administrative levels as well as widespread outsourcing of software development there is a lack of sharing “best practices” how to implement SOA step by step in the area of e-government. In particular, it is unknown to what extent administrations are able to follow existing service development approaches, and there is no research addressing the contribution of service development methods towards governance, i.e. developing and managing government interoperability. In this research the case of Egypt, where SOA was chosen as the main interoperability approach, has been explored in terms of to what extent the current approach to service development supports the interoperability governance, and what kind of changes in the development methods and their application would yield improvements in interoperability governance. The case analysis on practical and strategic level leads to proposing success factors related to linking the methodology of developing G2G services to the overall effort of interoperability governance. These factors, divided into interoperability problem perception, method scoping and deliverables, measurement of goal achievement, and methodological commitment, can be used as hypotheses in future research and as guidelines for improving the interoperability governance in administrative practice. © 2011 Elsevier Inc. All rights reserved.

1. Introduction The label G2G (government-to-government) is used for efforts enabling different government agencies to share informational and functional resources and to cooperate based on a suitable IT infrastructure. G2G standards, frameworks and architectures have been developed throughout the last years, and from the technical perspective the adoption of service-oriented architecture (SOA) has been recommended especially for e-government “followers” (e.g. by a UNDP report (UNDP United Nations Development Program, 2007)). If governments were corporations, they could largely benefit from the advice provided by published SOA governance frameworks (e.g. Marks & Bell, 2006; Schelp & Stutz, 2007). And although enterprise architecture and IT governance guidelines are slowly making their way into the public sector, the road of achieving the required interoperability among public sector units is still difficult to go for most governments, and there is a lack of sharing “best practices” how to implement step by step. Confronted with numerous IT departments on each horizontal level (e.g. ministries, administrations of states, ⁎ Corresponding author. E-mail addresses: [email protected] (R. Klischewski), [email protected] (E. Askar). 0740-624X/$ – see front matter © 2011 Elsevier Inc. All rights reserved. doi:10.1016/j.giq.2011.08.001

governorates, even municipalities), all of which having specific leadership arrangements with the “business unit” they serve, any central unit in charge of IT governance struggles with multiple and largely uncontrollable stakeholders as in a “feudal system” or “anarchy” (as coined by Weill and Ross (2005)). The extant literature has pointed out a variety of challenges and needed capabilities for improving government interoperability, but it has not yet covered the role of development methodologies and their relation to the overall governance of the interoperability efforts. However, we assume this relationship to be crucial especially in the case of governmental SOA adoption because the decomposition from application systems into services leads to involving an increasing number of stakeholders as service providers, and additionally each service provider may be served by one or more remote service developers. Therefore this contribution focuses on the challenge of developing services for the purpose of implementing G2G interoperability. While there are basic approaches to service development in general, in the area of e-government it is unknown to what extent administrations as technology adopters are able to follow such approaches and reach a successful outcome within a reasonable frame of time and resources, or what the barriers are to applying state-of-the-art service development methodologies indicating the need for improvements (e.g. staff training).

R. Klischewski, E. Askar / Government Information Quarterly 29 (2012) S22–S31

Based on identifying already known challenges of government interoperability and service development, this research approach is exploratory. The case of Egypt, where SOA was chosen as the main interoperability approach, is investigated in terms of how services are being developed and what kind of methodological enhancements could be appropriate. The leading research question is to what extent the current approach to service development supports the interoperability governance, and what kind of changes in the development methods would yield improvements in interoperability governance. The case analysis on practical and strategic level leads to proposing success factors related to linking the methodology of developing G2G services to the overall effort of interoperability governance. These can be used as hypothesis in future research and also as guidelines for improving governance, staff development and change management in administrative practice. The remainder of the paper is structured as follows; the literature review covers the challenges of and capabilities required for improving government interoperability as well as the approaches to implementing a service-oriented architecture; after clarifying our case study approach, the following subsection presents the case findings; we conclude with the lessons learnt, identify possible generalizations, and point to future research. 2. Meeting the challenges of government interoperability In the context of e-government, many authors refer to interoperability as the “ability to exchange information and mutually to use the information which has been exchanged” (a 1991 definition of interoperability by the European Commission; cited from (Guijarro, 2005, p. 163). E-government research has made some effort to gain insights on how governments manage to increase their interoperability among governmental institutions as well as with external partners and other peers. This section identifies critical issues and major challenges in establishing and improving e-government interoperability. The main driver for government interoperability is considered to be the need for interorganizational information integration (cf. Klischewski, 2004; Pardo & Burke, 2009; Pardo, Cresswell, Dawes, & Burke, 2004). The integration processes as such need to be studied from multi-disciplinary perspectives (Pardo et al., 2004; Pardo & Tayi, 2007) because organizational and technical resources and artifacts are framing and are formed by the social processes making use of these. Achieving interoperability is not a simple task and it is usually faced by many challenges and/or constraints on a variety of levels such as legality, jurisdiction, organizational aspects, information exchange, technology, management, collaboration, performance, and cost (Guijarro, 2009; Lam, 2005; Pardo & Tayi, 2007; Scholl & Klischewski, 2007). In view of the diverse challenges, all authors concede that government interoperability can only be adequately understood in view of higher-level integration concepts (e.g. information and process integration (Klischewski, 2004)) and the challenges can only be met within the scope of a comprehensive framework. What often is coined as a Government Interoperability Framework (GIF) comprises of a set of standards and guidelines defined by a government to describe the best practices to be followed in order to enable communication between its agencies, citizens and associates (Guijarro, 2009; Kubicek & Cimander, 2009). What can be observed as government interoperability is an outcome of this dynamic multiparty and multi-level interrelation, in which interoperability frameworks, standards and architectures play a major role. Usually open standards are being enforced throughout all frameworks, however de facto implementations reveal that often proprietary technologies and specifications are used (Guijarro, 2005). The degree of interoperability can be measured against defined maturity levels of organizational interoperation. For example, Gottschalk (2009) presented a maturity model for e-government interoperability

S23

defining the levels of computer, process, knowledge, value, and goal interoperability. Pardo and Burke (2009) proposed a “Government Interoperability Improvement Framework” including three maturity levels aiming at enhancing the government leaders' understanding of interoperability and providing guidance for assessing current government interoperability level and making decisions regarding investments in capability development. Throughout the last couple of years, governance has been identified as the most critical issue in developing and managing interoperability (e.g. Abramowicz, Bassara, Wisniewski, & Zebrowski, 2008; Kubicek & Cimander, 2009; Pardo & Burke, 2009). In the context of government interoperability many authors refer to Weill and Ross conceptualizing governance as “specifying the decisions, rights and accountability framework to encourage desirable behavior in the use of IT” (Weill & Ross, 2004, p. 8), demanding to clarify the decisions to be made, the decision makers, the mode of decision making, and the process for monitoring results. In the context of interoperability Pardo and Burke (2009) define governance as “the existence of appropriate decision making rules and procedures to direct and oversee government interoperability initiatives that are planned or underway” (p. 1) and describe it further as a “sorting process” by which the issues to be tackled are distributed for decision making to the concerned entities according to the selected governance approach. In search for more clarification, Kubicek and Cimander (2009) distinguish between the negotiation and enactment of interoperability standards (as the “political governance” from the institutional perspective) and the organization and management for the effective operation and maintenance of the data exchange (as the “IT governance” from the IT service perspective). Other authors suggest focusing on the governance of interorganizational network infrastructures, e.g. Markus and Bui (2011) identified interpersonal interactions, financial ownership, and legal forms as the three relevant perspectives. Pardo and Burke (2008) seek to identify the sources of governance from the managerial perspective and recognize nine dimensions of capability relevant to working in a network to develop and manage government interoperability (governance, strategic planning, business case development, project management, resource management, stakeholder identification and engagement, leaders and champions, business and technology architectures, performance evaluation) as well as eight dimensions of capability relevant to information sharing (collaboration readiness, organizational compatibility, information policies, change acceptance, technology knowledge, data assets and requirements, secure environment, technology compatibility). Summing up, meeting the challenges of government interoperability is recognized to require multi-dimensional effort of governance, however, the discussion on how to best conceptualize the dimensions is still ongoing. A significant observation is also that a wide range of technical and managerial issues are raised and debated, for example we do find architecture (e.g. SOA), data formats etc. recognized as a key static element of standardization, but not the dynamic dimension of how to implement these elements. There is no research addressing the contribution of development methods towards governance, i.e. developing and managing government interoperability. This paper intends to address this gap through a case exploration. 3. Implementing service-oriented architecture Describing the interrelation of G2G-related components through an appropriate architecture has been identified as one of the key capabilities required for G2G interoperability management. This section recalls service-oriented architecture as the most widely recommended to improve G2G interoperability, identifies challenges of service development as highlighted by existing methodologies, and clarifies our understanding of service development methods as the basis of the subsequent case investigation.

S24

R. Klischewski, E. Askar / Government Information Quarterly 29 (2012) S22–S31

3.1. Business and technology architecture Aiming at comprehensive standardization to support all levels of interoperability, governments increasingly develop so-called enterprise architectures (EA) which can be viewed as a coherent set of principles, methods and models enabling comprehensive use of the IT and other resources for supporting the business objectives. Developing and implementing EA in e-government comes along with specific challenges such as handling the complexity (Janssen & Kuk, 2006) as well as economic and political factors (Hjort-Madsen, 2006). Isomäki and Liimatainen (2008) followed up establishing an EA within Finnish state government and identified the challenges from the point of view of the different stakeholders involved. The authors conclude that the main challenges are the implementation ability and governance, followed by legislative and socially rooted boundaries of the government structure, and, last but not least, the lack of a shared infrastructure. The case study shows that architecture development can be a beneficial approach also to providing interoperability, but it needs to be adequately adjusted and enforced as a tool for the development of business operations. Many e-government implementations distinguish between front office and back office service delivery; the front office includes interaction between citizens and civil servants, while the back office includes registration and other activities. Back office cooperation is considered a serious bottleneck in e-government because of interoperability problems (Gottschalk, 2009). In order to address such problem, the e-government interoperability guide provided by the United Nations Development Program also emphasizes EA and recommends 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” (UNDP United Nations Development Program, 2007, p. 23). The report, supported by IT vendors such as IBM and Oracle, seeks to give advice especially to e-government adopters, i.e. governments that want to benefit from technological experience of precedents. SOA can be defined as a system design of loosely coupled software components (alias services) designed to communicate with end user applications and/or with other services, either to process data or to carry on a certain activity (Britton & Bye, 2007; Declercq, Vincent, De Backer, & Loterie, 2009; Papazoglou, 2008; Papazoglou, Traverso, Dustdar, & Leymann, 2007; Papazoglou & van den Heuvel, 2007). As described in Hirschheim, Welke, and Schwarz (2010), SOA is an IT architecture that views data and logic functionality as a black box, in other words, they are encapsulated with only their input and output exposed for others to use. Placing data and application functionality into service containers have benefits such as “(i) the ability to re-use them; (ii) the flexibility to reconfigure, improve and re-assign them without breaking the overall delivered functionality; and (iii) the ability to provide transparency across multiple (legacy) applications and data sources at a lower unit operating cost” (Hirschheim et al., 2010, p. 38). The challenge of interoperability is addressed by the SOA approach because it allows flexible communication between services that are independent of each other. Theoretically, services of different platforms, languages and operating systems can still exchange messages with each other. Technically, some kind of middleware has to exist in order to allow for such communication. For a given organization, or a stable network of service provider and consumers, the Enterprise Service Bus (ESB) can serve as a messagebased backbone as it is a collection of middleware services providing various integration capabilities (Declercq et al., 2009; Papazoglou & van den Heuvel, 2007). A highly distributable communications and integration backbone is essential when building SOA and the ESB was designed to be responsible for messages transmission between

different components of the SOA eliminating the need for point-topoint connectors. However, implementing SOA is a difficult task for any government. And the UNDP guidelines (UNDP United Nations Development Program, 2007) conclude also with the message “policy, not technology, matters”, calling for designing what is needed for and by the public (and not designing based on technology that is available) as well as governments' strategic framework and the vision of its leaders. After all, when implementing SOA (or any other business and technology related architecture) it needs a continuous link between technically developing and deploying services on one side and the overall interoperability governance on the other side. This link has to be maintained by the service development methods to be employed within the interorganizational network. 3.2. Approaches to service development In general, services are the mechanism by which needs and capabilities are brought together (Lee, 2005). “A service is an abstract resource that represents a person or organization in some collection of related tasks as having specific service roles. The service may be realized by one or more provider agents that act on behalf of the person or organization — the provider entity.” (W3C glossary) In other words, services are a couple of tasks implemented and processed by a service provider to satisfy the need of a service requester by offering the demanded output, which is the service itself, from the user's perspective. A service in an SOA is described as a bound pair of a service interface and a service implementation (Papazoglou & van den Heuvel, 2007). The service interface is where the service identity and its invocation logistics are defined, and during service implementation the main functional design of the service is implemented. Interfaces are platform independent, enabling clients with different communication devices using different computational platforms, operating systems, or programming languages can still use the service. A service provider may be a service requester at the same time. This is because some services may need to be broken down into more than one part where the service requested requires other services from different sources. This is referred to as “service cascade”. Theoretically, this cascading has no depth limit, so a provider may call another, which calls another, and so on. There is also “parallel cascading”, where a requester could request the services of a number of providers in parallel. And the requesters and providers do not have to belong to a single entity (Britton & Bye, 2007). A service can be partially or completely automated. The requester may use a human intermediary to handle the IT part, for example, an agent for train tickets reservations. During service development and implementation, a number of specific, but important practical questions appear such as: Who/what are the users of this service? What is the scope of the service? What is the mode of service interaction? How should the service interface be designed? Etc. The most recurring challenges to be addressed can be summarized as follows: (1) Service scoping and modularization: Service scoping includes determining the process being supported by the service, the events that initiate the service, where it begins and where it ends, entities involved in the process and their roles, also typical users of the service and what the inputs and outputs of the process are. Visualization of underlying concepts is essential clarifying the service features and for service developers to understand and achieve user satisfying results. To this end diagrams and tables are used, for example (Britton & Bye, 2007) process implementation diagrams (showing activities and tasks involved in a process as well as how services depend on other services and data) and task/message

R. Klischewski, E. Askar / Government Information Quarterly 29 (2012) S22–S31

(2)

(3)

(4)

(5)

diagrams (identifying service users and their scope of tasks, depicting user-application interaction as dialogs, and showing usage of persistent data and records). Service interface granularity: Interface granularity refers to the concept of dividing up a service into more than one service operation. The issue of fine grained versus course grained granularity has been discussed from various perspectives (Erl, 2006; Genkin, 2007; Lee, Chan, & Lee, 2006; Papazoglou & van den Heuvel, 2007), agreeing that achieving an appropriate balance is a key to success. When there are too many fine grained services (each containing one or few operations), possible drawbacks are that many interfaces and many services use these interfaces, resulting in service governance problems such as difficulties to pursue effective code reuse, slow performance, and expensive message-based invocation of service operations. On the other hand, when one service or a few number of services contain a high number of operations, the drawbacks of such course-grained granularity are that more functionality is exposed than actually needed, and it is more difficult to understand and use. As there is no standard granularity and it all depends on the type of service and the type of operations it involves, Erl (2006) for example recommends developers to group operations not only based on their physical system they are targeting but on the semantic relationship between those operations as well. Process orientation (choreography): The nature of services creates the opportunity for building composite services by combining existing elementary or complex services from different enterprises and in turn offering them as high-level services or processes. Such services need to be “orchestrated,” i.e. it must be described how services can interact with each other at the message level, including the business logic and execution order of the interactions from the perspective and under control of a single party. However, in multi-party environments (such as in egovernment) achieving a collaborative “choreography” is more important, by which each involved party describes its part in the services interaction. Interaction modes: Interaction modes for web services can vary in terms of synchronous interaction (i.e. request and wait for response) or asynchronous interaction (i.e. fire and forget), or the service itself soliciting response interaction or sending notification; and determining the interaction modes needed in the service process affects the design of the service (Lee et al., 2006). Semantics: Formal service representation languages (namely WSDL) are used to describe the details of the service interfaces exposed. And taxonomies are used in service registries so that information can be discovered on the basis of such categorization. However, not only service identification but also all the payload of exchanged messages have to be machine-processable which poses again a significant challenge in a multi-party environment where each party is committed to a certain interpretation of data exchanged.

Most of the answers regarding the aforementioned challenges can be obtained from the stakeholders involved (potential service users, service providers etc.). However, in order to meet the practical challenges in an orderly fashion, service development is usually conceptualized like any software implementation, i.e. it is modeled based on a software development life cycle (SDLC). Accordingly we understand ‘service development method’ as a defined and repeatable process-oriented approach that aims to develop and deploy services while addressing the specific challenges related to such an endeavor. A number of life-cycle-based models for web service development have been proposed, typically structured phases such as (e.g. Lee, 2005; Lee et al., 2006):

S25

Requirements: The scope of the service is to be described, i.e. what is the purpose, what are the entities involved, how they are involved and what information they exchange. The original work flow of the service should be known in order to identify the existing processes and the changes that shall be applied. In this phase, meetings with stakeholders are held to gather their functional and non-functional requirements which are then translated into service requirements in terms of features. Analysis: Service requirements are to be refined and translated into features to be understood by technical developers. The service providers and consumers should be clarified and conceptual models are created (e.g. process implementation diagram and the message diagrams; see later text). Design: This phase is concerned with the service interface granularity and service interaction modes challenges. It is where the service is designed and the technical implementations are selected. In this phase, design details such as interface granularity and service interaction modes are identified. Implementation: This phase is where the service is created. It is also referred to as “coding” phase. In this phase, the service is implemented and developers start coding and debugging activities. Testing: During this phase the service is subjected to functional, interoperability, and performance testing. Deployment: This phase is where the service is configured. After implementation and testing, the service is ready to be properly deployed and ready to be used. A comparison of nine service-oriented development methods from science and industry reveals that, when applying a variety of general and SOA-specific criteria, the characteristics in detail are significantly different (Thomas, Leyking, & Scheid, 2010). Accordingly, there is choice of methods which makes a difference, but it remains to be discussed how such choice of methodology affects the governance of the interoperability efforts. Specifically in e-government (i.e. in contrast to most business scenarios) we find always a unique environment of dispersed stakeholders. That means for any collective endeavor it is a tremendous challenge to reach a level of maturity in service development which is characterized by well-defined processes, proactive project management, and use of measurements and controls. The link between interoperability governance and service implementation should be framed by an explicit service development method which as accepted and adopted by the networked stakeholders who participate in development, provision, and consumption of government related services.

4. Case study: G2G service development in Egypt In this paper we focus on the establishing G2G interoperability of Egypt — a country which can be considered an e-government adopter, which has already made remarkable progress in the area of e-government and is ambitious to continue a “fast pace development” (Darwish, 2008). The case has been selected not only because of ease of access (proximity of the researcher), but because the Egyptian government has made an initial strategic decision on the statewide implementation of a service-oriented architecture (SOA) to support its e-government interoperability efforts. After briefly following up past activities in adopting and implementing SOA, we focus on the current challenges of service development in the context of interoperability governance. Initially we describe our research methodology.

S26

R. Klischewski, E. Askar / Government Information Quarterly 29 (2012) S22–S31

4.1. Research methodology The research method is exploratory, employing a single case study approach focusing on the initial stages of G2G service development in Egypt. According to our main research interest we seek to explore how stakeholders involved in the case perceive and maintain the link between service development methods and interoperability governance, and to what extent service development methods in use actually support the interoperability governance. Thus, the case exploration focuses on two levels of activities which follow the distinction of governance levels into the IT service perspective and the institutional perspective (as suggested by Kubicek and Cimander (2009)), see earlier text): • Strategic level: analysis of the service development and implementation strategy followed by the leading ministry as well as of the importance and challenges of applying an (enhanced) service development methodology • Practical level: understanding the current service development approach, suggesting modifications to the methodology, and applying these on a service that has not yet been implemented (e.g. issuing subway student tickets) The case investigation concentrates on the early stages of developing a portfolio of G2G services which includes the requirement phase, analysis phase and design phase, and the main focus is on those aspects reflecting administrative interaction and collaboration. Therefore, technical aspects and later stages of the life cycle (implementation, testing and deployment) will not be analyzed. Conceptually we confine the scope of service development methods to straightforward “waterfall”-type approaches (i.e. without iterations) because in the case of Egypt (as in many governmental settings) the technical service development is outsourced and the developers usually have no opportunity nor intention to interact with end users of service-based applications in the administration or beyond. For data collection we have traced the development of egovernment in Egypt and in particular the steps of decision making regarding the interoperability initiative based on official and/or published documents since 2004. Additionally, for three months in 2010, one of the researchers had joined the team at the MSAD being in charge of the G2G initiative and contributed to establishing an explicit service development approach. Throughout this participation indepth observations and interviews had been conducted and a variety of written material could be obtained. Information was extracted from MSAD documents, informal meetings with team members, and semistructured interviews with the program manager and program director. While the participating researcher had an active role in interfering with the unit of study, the other researcher remained as observer throughout and served as a second-order interviewer in order to challenge the views of the participating researcher. The results of the case exploration are presented in the following subsections. 4.2. Adopting SOA Egypt's vision of e-government constitutes of three main principles (Ministry of Communication & Information Technology MCIT, 2004, p. 2): (a) “citizen centric service delivery” (reflecting the “government intention to develop a one stop shop e-services approach focused at citizen's needs”, (b) “community participation” (meaning that “citizens' demands are constantly being analyzed and reflected, and private/public sector companies are active participants in project's implementation and management”), and (c) “efficient allocation of government resources” (i.e. “productivity, cost reduction, and efficient allocation of resources are among the major expected outcomes from project implementation”). The leading role in Egypt's

e-government program is now held by the Ministry of State for Administrative development (MSAD) after taking it from the Ministry of Communication and Information Technology (MCIT) in 2004. One of the important milestones in the development of egovernment in Egypt is the opening of the “El Bawaba” portal (at www.egypt.gov.eg). This portal, meant to implement a one-stop shop solution, calls also for appropriate backend solutions enabling data exchange and process integration between the various governmental agencies involved on a vertical and horizontal (intra and inter agency) level. With this interoperability need in mind, and in view of developing and integrating national databases, a project was initiated in 2005 with aim of enabling various agencies to share and exchange information and services, and eventually orchestrating joint administrative processes. This effort was then coined as the development of G2G, with the objectives shifting over time more to enabling ministry interoperation than connecting to “El Bawaba” services. In September 2005, a “project definition workshop” was conducted under the directive of MSAD's e-government program director in which seven representatives from the IT vendor met with another seven members of MSAD to lay the foundation for a broader SOAbased IT infrastructure roll out. The workshop report points out the benefits of SOA for MSAD as follows: “The use of a SOA will enable the integration of common services into the operating infrastructure of both new and existing MSAD business initiatives. The use of common services can help enable the rapid instantiation of new business initiatives, improve the ability to monitor and manage activities across MSAD business initiatives, reduce operating costs and business risk through automation and simplification of business processes, and consolidate specialized IT and business skills. A Services Oriented Architecture will allow common processes to be more easily streamlined across the MSAD business initiatives […]”. Based on the workshop recommendations, the first G2G pilot project in the Egyptian e-government was initiated in late 2005. The purpose of the pilot was to automate the process of registering a new employee for pension at the Social Insurance Office. In 2007, the process of employee registration for pension was completely automated based on connecting the three governmental agencies involved (Klischewski & Abubakr, 2010). The SOA project in the Egyptian e-government has been planned to unfold in four phases (Klischewski & Abubakr, 2010): • Phase 0: requirements and architecture documents of SOA and ESB • Phase 1: fully functioning ESB hub, a portal for G2G and deployments of ten atomic web services • Phase 2: Deployment of composite services • Phase 3: Deployment of transactional services The project has started in 2009 and was scheduled to complete the second phase (“phase 1”) by the end of 2010. 1 At the time of on-site visit some atomic web services have already been developed such as the national ID validation and tax information validation. Previous research on SOA adoption for G2G interoperability in Egypt (Klischewski & Abubakr, 2010) has provided the several lessons learned such as data accuracy and meta models are key enablers which do not come through SOA but their absence is a major inhibitor; SOA is not an efficient backbone for providing bulk data needed for political decision support; vendor-driven SOA introduction increases the risk of technology lock-in; a legal framework is prerequisite for establishing an integrated management structure and ensuring the conditions and sustainability of collaboration among ministries, governorates, municipalities etc.; organizational readiness to address semantic and organizational issues of G2G is key to reaping benefits of early technology investments. 1 Note that the political turbulences starting early 2011 have practically caused a standstill in project activities.

R. Klischewski, E. Askar / Government Information Quarterly 29 (2012) S22–S31

Meanwhile, one of these significant challenges has been addressed: in April 2010 the prime minister of Egypt issued the decree no. 856 concerning the commitment of ministries, government bodies and affiliated authorities to allow and exchange data between them in accordance to the national plan on data exchange and integration. This supports developing and upgrading citizen services as well as political decisions making. In terms of organizational readiness also some progress has been achieved. An important step has been the identification of roles and stakeholders pinpointing the responsibilities and the need for coordination when developing services supporting G2G interoperation in Egypt (see Fig. 1). Initially, during phase zero, the “G2G Project” was assigned to a team of nine members with various technical and business backgrounds. Three of the nine were representatives of the IT vendor out of which two with technical expertise and one acting as the project manager. The remaining team members had been three MSAD employees with profound technical backgrounds, the program director of SOA development at MSAD, and two externals hired by MSAD as technical consultants with already longstanding experience of working with the ministry. With entering the next phase of service development, the role of the initial G2G team now also acts as a steering group of the “G2G Project”, with the MSAD program director responsible for handling all negotiations to take place with the vendor company and with the various governmental agencies that shall participate in SOA, providing feedback to the minister, ensuring that the implementation of SOA and ESB takes place according to planned schedule and according to agreed upon quality. According to the new organizational governance setup, MSAD is responsible for executing the e-government services automation plan by studying the services and providing analysis and design. There are two committees in MSAD, the “high committee”, which selects the services to be developed and selects executives to work on them, and the “executive committee”, which coordinates the service development. The MSAD is also responsible for coordinating the multi-party agreements for service provision and monitoring the service implementation. The National Management Institute (NMI) is responsible for technical communication of the services, i.e. for running the ESB (developed by the company IBM) and monitoring service operations. Service requesters (depicted as “data requester”) are government entities on various levels providing service requirements for development, and service providers (alias “data provider”) also provide service specification as well as the actual data requested. However, in practice the development and deployment of G2G services still remains a cumbersome and thorny task, and managing the related processes across the stakeholders has not yet reached a degree of maturity which would ensure the success of the G2G project. In the following sections we explore in more detail the

S27

currently practiced approach with the objective of identifying success factors for G2G service development. 4.3. Service development practices The management at MSAD is basically aware of the need for a methodology-driven approach to providing e-government services to citizen as well as for ensuring the readiness of other stakeholders to contribute to this approach. In the original plan of the e-government program, MSAD conducted a study on more than 790 services offered by different governmental agencies. These services were prioritized according to frequency of requests and number of governmental documents required. On the basis of this two implementation plans were created; one plan is concerned with the most commonly asked documents (or information entities) requested from citizens or other agencies, respectively, identifying the kind of documents and the specific data requested (e.g. the national identity card for complete name and birth date). The other plan is a selection of a small number of “atomic” services to be developed in “phase 1,” including which agencies are the administrative service provider and what documents are requested from other agencies. By the prime minister's decree no. 856, all ministries are obliged to cooperate in order to developing and implementing these plans accordingly. Since MSAD has the overall responsibility for developing administrative services, it takes the lead in analyzing and designing the web services. Inside MSAD the aforementioned committees select the services to be developed and coordinate the overall development process, as the program director states: “Being the regulator of the service development process, we are responsible for the overall process management, and since we see the whole picture and get requirements from all parties, we translate the these requirements into features and hand in these features to the developers.” Reviewing the strategy of G2G interoperability so far, MSAD is confident that opting for SOA was the right decision. The program director notes that SOA has been an effective facilitator in convincing the other entities to participate in G2G projects because it ensured existing data ownership and privacy (“we're not dealing with databases, we're dealing with web services”) as well as the freedom of the participating entities to keep their IT platforms and vendors. However, even though the decree no. 856 has forced data-owning entities to commit themselves, more support regarding information sharing is needed. An “Information Exchange Law” is under preparation in order to force the governmental entities more explicitly into cooperation and mutually sharing important information in order to provide efficient services for the citizens. As far as technical service development and implementation is concerned, MSAD plans to continue relying on outsourcing partners

Fig. 1. “G2G Project Stakeholder Chart” (source: MSAD).

S28

R. Klischewski, E. Askar / Government Information Quarterly 29 (2012) S22–S31

(“we prefer to let the businesses in our country work”). This is certainly in line with MSAD's role definition which is “to regulate and not to implement.” For developing G2G services MSAD has defined a general process to interrelate the contributions of the stakeholders involved (see Fig. 2): • The administrative service at the front-end is studied in order to identify the required back-end services that need to be implemented (if not available already). • Gathering the stakeholders' requirements is based on a standardized questionnaire for service requesters as well as service providers; the questionnaire templates mainly focus on aspects of the current work practices and the feasibility of computerization but only marginally on the data to be shared. • Having shared the requirements (translated into features) among requester and provider and, developers are asked to provide the specifications of the service interface to be implemented in XML, based on web service standards and internal guidelines (e.g. naming conventions). • MSAD mediates a template-based multi-party agreement and commitment on service operations (“service protocol”). • Finally a time plan (“work plan”) for the service implementation and operations is created and shared with the parties involved. The activities in between gathering the requirements and the implementing the web service the project manager described as follows: “First, we study the requirements and decide on the technical specifications and web services that need to be developed. Second, we design each web service in XML. Third, we explain to each entity involved in the project what their web service does and how they should deal with it. Fourth, each entity implements the web service at their side. Finally, we configure the web services on the ESB.” Recalling the most recurring challenges to be addressed in service development (as discussed earlier), the assessment of efforts by MSAD to address these challenges can be summarized as follows: • Service scoping is based on the standardized questionnaire and the preset schedule of e-government service implementation. However, this requirement analysis so far is rather rudimentary and, for example, not requesting details of data specification and information quality.

• Currently MSAD decides about the reuse and combination of existing services to let them contribute to high-level services or processes, thus determining service granularity, choreography and interaction modes. However, the business logic is kept simple, and for the majority of the front-end services the aim is to map each to one or two back-end services. So far there is no explicit approach in sight that would allow for a systematic decomposition based on business process analysis and evaluation of the service portfolio. • Issues of semantic interoperability seem to not yet have appeared on the agenda, at least not beyond ensuring consistency of naming in message headers and bodies, — which is expected to change when services are productive and being reused, and the overall complexity increases. So far, the jump from the requirements to the XML-based interface is not supported by any explicit methodology. And while MSAD has been involved in coding some initial services, the objective is to let the developers on the side of service providers and requesters do the programming work. To that end a refined methodology was suggested covering the early stages of the service development life cycle with the following inputs and outputs (combining approaches of Britton & Bye, 2007 and Lee et al., 2006): 1. Requirements Input: User requirements pertaining to service deliverables, governmental entities are involved (including their roles and informational needs), drawbacks and change objectives in view of the existing process Output: Service requirements specified by service description, entity and roles, information exchanged, automated service process 2. Analysis Input: Service requirements, decomposition into sub-services (according to the existing service portfolio, in this case decided by MSAD committees) Output: Service features and informational needs specified by service providers and service requesters, process implementation diagram, message diagram 3. Design Input: Service features and informational needs

Fig. 2. “G2G Context Diagram” (source: MSAD, translation added, original in Arabic with only the title in English).

R. Klischewski, E. Askar / Government Information Quarterly 29 (2012) S22–S31

S29

Output: Web service design elements specified by service interface granularity and service interaction modes This approach was applied on developing a new service for issuing subway tickets for students which needs automatic exchange of information between the Subway Registration Office (SRO) and the Supreme Council for Universities (SCU), based on the national identity number (NID) as the key for authentication. The outputs of the service analysis included a process implementation diagram (Fig. 3) showing that validating the requester's information is initiated at the SRO side by inserting the requester's NID, and then the web service at the SCU is initiated to search and display the record with the inserted ID. After that, the ticket is either produced or not (at the SRO side), depending on the information sent from the SRO. Another output is the message diagram (Fig. 4) indicating that the first transaction taking place is the validation process. This happens by searching for the record with a NID, to view its information (read only). A ticket is then produced for a certain trip (update trip). This approach increases the degree of detailed documentation and visualization compared to the approach practiced so far. When presented to stakeholders involved, both the project manager and the program director welcomed it as an enhancement, but at the same time it sparked a discussion on who is actually in need of understanding these “details”. 4.4. Service development methods and interoperability governance Following the aforementioned definition of governance as “the existence of appropriate decision making rules and procedures to direct and oversee government interoperability initiatives that are planned or underway” we can easily identify and even explain shortcomings in the case of Egypt because many of the mentioned capabilities for networked development and management of government interoperability (governance, strategic planning, business case development, project management, resource management, stakeholder identification and engagement, leaders and champions, business and technology architectures, performance evaluation; (Papazoglou et al., 2007)) are still underdeveloped. Also, compared to the demands of elaborated SOA frameworks (Marks & Bell, 2006; Schelp & Stutz, 2007), the observable practice has clearly not reached the desired level of oversight, stewardship, and standardization. However, in this case our main research interest to explore how the stakeholders involved perceive and maintain the link between service development methods and interoperability governance, and to what extent service development methods in use actually support the interoperability governance.

Fig. 3. Process implementation diagram for developing a new service for issuing student subway tickets.

Fig. 4. Message diagram for a new front-end service for issuing student subway tickets.

On the practical level, the current approach to service development focuses primarily on data provision (note also the wording in Fig. 1) but hardly on the functional behavior, the non-functional aspects and the interaction of the services to be developed. Hence the currently applied method is designed to support rather the interoperability dimension of information sharing but does not well support the dimension of service interoperation and its management. Contracted service developers are left with unnecessary degrees of freedom for implementation and testing which is expected to have a negative impact on the options for future service reuse. Improvements have been suggested to structure more comprehensively the inputs and outputs of each development phase, to highlight the architecture of service decomposition and to denote the interaction behavior before implementation. However, while our case study was ongoing, the proposed enhancements were welcomed in principle, but at the same time their importance was questioned, apparently the problem solving potential was not considered significant enough in relation to the expected effort of required change management. In search for more appropriate decision making rules and procedures, methodological enhancements could be helpful for supporting the decomposition into sub-services which is currently decided by MSAD committees in view of the existing service portfolio, but (according to our knowledge) without further decision support. On the strategic level, MSAD has reiterated the commitment to standardized and methodology-driven approach to service development since the initial workshop in 2005. The ministry has realized that the main benefits of service consistency, reuse and interoperability do not materialize by themselves but need dedicated effort. In consequence it has defined roles and assigned responsibilities, and it has enforced a basic procedure to ensure collaboration during service development. At the same time, the ministry apparently has not yet set any strategy nor implemented any instrument to measure the degree of goal achievement. Thus, any methodological insufficiencies are not perceived as a bottleneck on the road to SOA implementation. In search for more appropriate decision making rules and procedures, any choice or further improvement of a service development method should be explicitly aligned with requirements for measurable deliverables through this method (e.g. the type of documents produced throughout the development life cycle, the type and number of test cases applied etc.). While the current approach might be adequate for the start-up phase, it is foreseeable that mastering the complexity of a state-wide e-government environment needs further methodological enhancements. However, these enhancements need to be linked well with the overall effort of improving the interoperability governance. And while methodological advice for service development is easy to find in general, the scope of the intended regulation and the future of the interoperability governance in Egypt is still vague, thus impairing methodological enhancements and their successful link to the overall governance.

S30

R. Klischewski, E. Askar / Government Information Quarterly 29 (2012) S22–S31

5. Conclusion In this paper, we set out to learn more about the challenges faced by e-government “followers” when developing services for the purpose of implementing and maintaining G2G interoperability. The leading research questions have been to what extent the current approach to service development supports the interoperability governance, and what kind of changes in the development methods would yield improvements in interoperability governance. The literature has revealed that governance of the collaborative service development is the key to success, and this is the case, not surprisingly, also in Egypt. However, the neglect and/or underestimation of the role of development methodology in government interoperability has not yet been an issue of reflection in e-government research. Seeking for more appropriate decision making rules and procedures to direct and oversee interoperability initiatives, this case analysis revealed some significant propositions for success factors of linking the methodology of developing G2G services to the overall effort of interoperability governance: • Problem perception: shared understanding of the service development challenges in the context of government interoperability is the basis of stakeholder cooperation; the complexity of SOA application challenges (scoping, interface granularity, choreography, interaction, semantics) needs to be reflected in detail because only then the value of selected and refined development methods becomes visible and an appropriate collaboration agenda can be maintained throughout the whole service development life cycle. • Method scope and deliverables: any chosen and applied method should be described by the interoperability dimensions it addresses and the output it delivers to the environment; with multiple stakeholders involved and development work frequently being outsourced, the preciseness of the method description is an important means to enforce desired outcomes, limit unnecessary degrees of freedom for service implementation, and increase coherence of the implemented services (thus improving the chances for service reuse). • Measuring achievements of method application: within the frame of interoperability governance a strategy must be set and instrument defined for measuring to what extent the methods in use contribute to solving interoperability challenges; only when methodological insufficiencies are perceived as significant bottlenecks on the road to SOA implementation and interoperability improvement, the effort of developing and enforcing upgraded methods can be justified. • Commitment and future options: the link between enforcing and accepting a service development methodology (e.g. through training programs, project office, even legal instruments if needed) is crucial for ensuring stakeholder commitment towards collaboration and aligning them with the overall interoperability governance; appropriate choices of development methods expand the planning horizon, reduce the effort of reaching mutual agreements, and increase the long-term security of IT investments. This list is not meant to be conclusive as research has shown that government interoperability needs to be analyzed through a multidimensional approach. Furthermore, this research is limited by only one case study, not having analyzed comparable experiences in other countries. However, these factors can be used as hypothesis in future e-government research in order to better understand and facilitate service development methodologies in their contribution to governance and implementation of government interoperability. Successful and non-successful endeavors targeting government interoperability in any country should be scrutinized to see how the choice and practice of development methodologies indeed

contribute to the aforementioned factors or other main aspects have to be taken into account. The proposed factors may also serve as guidelines for improving governance, staff development and change management in administrative practice. Especially e-government “followers” on the road of improving their interoperability governance must ask themselves what kind of support for G2G service development is still missing. To this end any program director or project management office should reflect current development practices, choose and enforce methodologies as a strategic means, provide a methodology roll-out plan, and define indicators for each of the aforementioned factors in order to follow up the success of the methodology in use. Acknowledgments The support of the Egyptian Ministry of State for Administrative Development is gratefully acknowledged for allowing us a close-up on their infrastructure development activities. We also thank the anonymous reviewers for their helpful comments. References Abramowicz, W., Bassara, A., Wisniewski, M., & Zebrowski, P. (2008). Interoperability governance for e-government. Information systems and e-business technologies, Proceedings 2nd International United Information Systems Conference UNISCON 2008. Lecture notes in business information processing, Volume 5, Part 2. (pp. 14–24) : Springer. Britton, C., & Bye, P. (2007). IT architecture and middleware. Boston: Pearson Education. Darwish, A. M. (2008). Egypt: From e-government to e-governance — The road to fast pace development. Proceedings ICEGOV 2008 (pp. 1–3). ACM Press. Declercq, K., Vincent, A., De Backer, T., & Loterie, H. (2009). Study on potential reuse of system components, IDABC Program. EIIS Final report study II, Version 1.1. European Communities. Erl, T. (2006). Standardizing service endpoints. : Oracle Technology Network Retrieved on the 1st of May, 2010 from http://www.oracle.com/technology/pub/articles/ erl_wsdl.html Genkin, M. (2007). Best practices for service interface design in SOA, Part 1: Exploring the development, interfaces, and operation semantics of services. : IBM Developer's Work Retrieved on the 1st of May, 2010 from http://www.ibm.com/developerworks/ architecture/library/ar-servdsgn1/#N100B5 Gottschalk, P. (2009). Maturity levels for interoperability in digital government. Government Information Quarterly, 26(1), 75–81. Guijarro, L. (2005). Policy and practice in standards selection for e-government interoperability frameworks. Proceedings EGOV 2005. LNCS 3591. (pp. 163–173). Springer. Guijarro, L. (2009). Semantic interoperability in E-Government initiatives. Computer Standards & Interfaces, 31(1), 174–180. Hirschheim, R., Welke, R., & Schwarz, A. (2010). Service-oriented architecture: Myths, realities, and a maturity model. MIS Quarterly Executive, 9(1), 37–48. Hjort-Madsen, K. (2006). Enterprise architecture implementation and management: A case study on interoperability. Proceedings 39th Hawaii International Conference on System Sciences, IEEE. Isomäki, H., & Liimatainen, K. (2008). Challenges of government enterprise architecture work — Stakeholders' views. Proceedings EGOV 2008. LNCS 5184. (pp. 364–374). Springer. Janssen, M., & Kuk, G. (2006). A complex adaptive system perspective of enterprise architecture in electronic government. Proceedings 39th Hawaii International Conference on System Sciences, IEEE. Klischewski, R. (2004). Information integration or process integration: How to achieve interoperability in administration. Proceedings EGOV 2004. LNCS 3183. (pp. 57–65). Springer. Klischewski, R., & Abubakr, R. (2010). Can e-government adopters benefit from a technology-first approach? The case of Egypt embarking on service-oriented architecture. Proceedings 43rd Hawaii International Conference on System Sciences, IEEE. Kubicek, H., & Cimander, R. (2009). Three dimensions of organizational interoperability. European Journal of ePractice, 6. Lam, W. (2005). Barriers to e-government integration. Journal of Enterprise Information Management, 18(5), 511–530. Lee, E. W. (Ed.). (2005). Web service implementation methodology, public review draft Retrieved on the 1st of May 2010 from http://www.oasis-open.org/committees/ download.php/13420/fwsi-im-1.0-guidlines-doc-wd-publicReviewDraft.htm Lee, S. P., Chan, L. P., & Lee, E. W. (2006). Web services implementation methodology for SOA application. Proceedings IEEE International Conference on Industrial Informatics, 335–340. Marks, E., & Bell, M. (2006). Service-oriented architecture: A planning and implementation guide for business and technology. New Jersey: John Wiley & Sons. Markus, M. L., & Bui, Q. (2011). Governing public sector interorganizational network infrastructures — The importance of formal and legal arrangements. Proceedings 44th Hawaii International Conference on System Sciences, IEEE.

R. Klischewski, E. Askar / Government Information Quarterly 29 (2012) S22–S31 Ministry of Communication and Information Technology MCIT. (2004). The Egyptian and information society for government service and delivery. Retrieved April 15, 20 10 f rom http://www.egypt.gov.eg/english/do cuments/download/ EISI_Gov_English_paper_05012010134554.zip Papazoglou, M. P. (2008). Web services: Principles and technologies. Boston: Pearson Education. Papazoglou, M. P., & van den Heuvel, W. -J. (2007). Service-oriented architectures: Approaches, technologies and research issues. VLDB Journal, 16(3), 289–415. Papazoglou, M. P., Traverso, P., Dustdar, S., & Leymann, F. (2007). Service-oriented computing: State of the art and research challenges. IEEE Computer, 40(11), 38–45. Pardo, T. A., & Burke, G. B. (2008). Improving government interoperability: A capability framework for government managers. Center for technology in government. University at Albany: SUNY available at www.ctg.albany.edu/publications/ reports/improving_government_interoperability Pardo, T. A., & Burke, G. B. (2009). IT governance capability: Laying the foundation for government interoperability. Center for technology in government. University at Albany: SUNY available at www.ctg.albany.edu/publications/reports/it_gov_capability Pardo, T. A., Cresswell, A. M., Dawes, S. S., & Burke, G. B. (2004). Modeling the social & technical processes of interorganizational information integration. Proceedings 37th Hawaii International Conference on System Sciences, IEEE. Pardo, T. A., & Tayi, G. K. (2007). Interorganizational information integration: A key enabler for digital government. Government Information Quarterly, 24(2007), 691–715. Schelp, J., & Stutz, M. (2007). SOA-governance. In H. -P. Fröschle, & S. Reinheimer (Eds.), Serviceorientierte Architekturen (SOA). HMD Praxis der Wirtschaftsinformatik, 44 (253). (pp. 66–73).

S31

Scholl, H. J., & Klischewski, R. (2007). E-government integration and interoperability: Framing the research agenda. International Journal of Public Administration, 30(8), 889–920. Thomas, O., Leyking, K., & Scheid, M. (2010). Serviceorientierte Vorgehensmodelle: Überblick, Klassifikation und Vergleich. Informatik-Spektrum, 33(4), 363–379. UNDP United Nations Development Program. (2007). E-government interoperability guide. Bangkok, Thailand. Retrieved from http://www.unapcict.org/ecohub/ resources/e-government-interoperability-guide Weill, P., & Ross, J. W. (2004). IT governance: How top performers manage IT. Watertown, MA: Harvard Business School Press. Weill, P., & Ross, J. W. (2005). A matrixed approach to designing IT governance. Sloan Management Review, 46(2), 26–34.

Ralf Klischewski is a professor of information systems in the Faculty of Management Technology, German University in Cairo, Egypt. He is co-editor of several works on organizational aspects of computing, including Social Thinking–Software Practice (MIT Press, 2002) and Wissenbasiertes Prozessmanagment im E-Government (LIT Verlag, 2005). His research has appeared in Springer Lecture Notes in Computer Science and journals such as International Journal of Public Administration, Business Process Management Journal, and Electronic Government: An International Journal. His recent research focuses on information infrastructures and the interrelation of semantic web and e-government.

Eman Askar is a teaching assistant of information systems in the Faculty of Management Technology, German University in Cairo, Egypt.