A Pragmatic Approach to the Introduction of E-Government Peter Salhofer Dept. for Information Management FH JOANNEUM, University of Applied Sciences Graz, Austria [email protected]David Ferbas Dept. for Information Management FH JOANNEUM, University of Applied Sciences Graz, Austria [email protected]ABSTRACT Adaption of processes inside a public administration are often seen as a necessary precondition for the introduction of mature e-Government services. Bureaucracies however, are specifically reluctant to change. Following the principles of agile software development and applying them to organizational aspects as well, this paper describes a pragmatic approach to the introduction of high quality e-Government services with minimal influence on the existing business processes. Categories and Subject Descriptors J.1 Administrative Data Processing – Government D.2.11 Software Architectures – Domain-specific architectures General Terms Management, Design, Security Keywords e-Government, Business Process Automation, Agile Software Engineering, Web-Applications 1. INTRODUCTION E-Government is the execution of business processes that involve public agencies by the means of information and communication technologies (ICT) and electronic media[1]. Thus, by definition, the introduction of e-Government involves technical as well as organizational aspects. This is specifically true when the desired sophistication level of e- Government services should be “Stage 4 / fully transactional” [2][3][4], which means that from the citizens' point of view, the entire underlying process is run electronically, including the delivery of the expected result. While information technology (IT) is often seen as an important enabler of Business Process Reengineering (BPR)[5][6], some authors claim that the introduction of e- Government, and therefore the introduction of new IT inevitably requires adoptions to a public agency's business processes. Scholl[7], for example, has set up no less then 18 propositions that should be considered in order to avoid process change efforts failing. He also argues that the introduction of e-Government services at Stage 4 “require significant and increasing changes to the underlying business processes”. However, knowing that approximately 70% of all BPR projects fail[8], the best strategy to avoid failure is to avoid any business process change entirely. Thus, an approach is needed that minimizes the influence of e-Government on underlying business processes wherever possible in order to prevent reluctance. At the same time the resulting e- Government services offered to citizens should be fully transactional. This paper presents a pragmatic approach to the introduction of e-Government that is influenced by the spirit of agile software engineering methods[9]. It was created and applied during the development of a municipal e-Government platform for the City of Graz. The City of Graz is Austria's second largest city with a population of about 250,000 citizens. It has launched its e- Government efforts back in 2003. The major goals behind these efforts were to bring the city's most important services online by the end of 2005. Whereas ,at that time, most of the known e-Government efforts have had a relatively small scope and had been Figure 1: Introducation of e-Government by sequential and more or less isolated projects Deploy e-Gov Service Optimize Process Analyze Process O P Analyze Process Deploy e-Gov Service Optimize Process Analyze Process Service 2 Service 3 Service 1 Time Services The Proceedings of the 8th Annual International Digital Government Research Conference 183
Transcript
A Pragmatic Approach to the Introduction of EGovernment
Peter SalhoferDept. for Information Management
FH JOANNEUM, University of Applied SciencesGraz, Austria
peter.salhofer@fhjoanneum.at
David FerbasDept. for Information Management
FH JOANNEUM, University of Applied SciencesGraz, Austria
david.ferbas@fhjoanneum.at
ABSTRACTAdaption of processes inside a public administration are often seen as a necessary precondition for the introduction of mature e-Government services. Bureaucracies however, are specifically reluctant to change. Following the principles of agile software development and applying them to organizational aspects as well, this paper describes a pragmatic approach to the introduction of high quality e-Government services with minimal influence on the existing business processes.
Categories and Subject DescriptorsJ.1 Administrative Data Processing – GovernmentD.2.11 Software Architectures – Domain-specific architectures
General TermsManagement, Design, Security
Keywordse-Government, Business Process Automation, Agile Software Engineering, Web-Applications
1. INTRODUCTIONE-Government is the execution of business processes that involve public agencies by the means of information and communication technologies (ICT) and electronic media[1]. Thus, by definition, the introduction of e-Government involves technical as well as organizational aspects. This is specifically true when the desired sophistication level of e-Government services should be “Stage 4 / fully transactional” [2][3][4], which means that from the citizens' point of view, the entire underlying process is run electronically, including the delivery of the expected result.
While information technology (IT) is often seen as an important enabler of Business Process Reengineering (BPR)[5][6], some authors claim that the introduction of e-Government, and therefore the introduction of new IT inevitably requires adoptions to a public agency's business processes. Scholl[7], for example, has set up no less then 18 propositions that should be considered in order to avoid process change efforts failing. He also argues that the introduction of e-Government services at Stage 4 “require
significant and increasing changes to the underlying business processes”.
However, knowing that approximately 70% of all BPR projects fail[8], the best strategy to avoid failure is to avoid any business process change entirely. Thus, an approach is needed that minimizes the influence of e-Government on underlying business processes wherever possible in order to prevent reluctance. At the same time the resulting e-Government services offered to citizens should be fully transactional. This paper presents a pragmatic approach to the introduction of e-Government that is influenced by the spirit of agile software engineering methods[9]. It was created and applied during the development of a municipal e-Government platform for the City of Graz.
The City of Graz is Austria's second largest city with a population of about 250,000 citizens. It has launched its e-Government efforts back in 2003. The major goals behind these efforts were to bring the city's most important services online by the end of 2005.
Whereas ,at that time, most of the known e-Government efforts have had a relatively small scope and had been
Figure 1: Introducation of e-Government by sequential and more or less isolated projects
Deploye-Gov Service
OptimizeProcess
Analyze Process
OptimizeProcess
Analyze Process
Deploye-Gov Service
OptimizeProcess
Analyze Process
Service 2
Service 3
Service 1
Time
Ser
vice
s
The Proceedings of the 8th Annual International Digital Government Research Conference
183
designed to bring certain specific services online (one-by-one in separate projects as shown in Figure 1), the City of Graz was aiming at an integrated e-Government solution that was able to offer almost any type of service to its citizens[10].
The most important goals, requirements and constraints that were defined at the beginning of the project can be summarized as:
• Ability to provide every single service via a unique platform with minimal deployment effort per service
• Accessibility [11][12]• Intensive usage of open source software (OOS) and
therefore exploiting its benefits [13]• Integration of existing and upcoming standards in
the field of e-Government• “Stage 4” sophistication level of offered services • Keeping everything as general and re-usable as
possible to allow other agencies to also use this system
2. THE RESEARCH/DEVELOPMENT PARADIGMThe situation at the beginning of the project back in 2003 was characterized by a huge range of emerging but not yet published standards (e.g. XML data exchange formats) and legislative regulations (e.g. the E-Government Act). While the municipality wanted to deploy its e-Government services as soon as possible, the 'instable' environment imposed significant risks to the project. To deal with these risks a project and software engineering proceeding model based on Barry Boehms Spiral Model [14] was chosen. This model is an iterative one that puts a strong emphasis on risk management. Every iteration allows for a reaction to changes in the environment and the incorporation of new standards and laws.
The core statement of agile methods (specifically eXtreme Programming) is to “do the simplest thing that might possibly work”[15]. So what is the simplest solution for achieving the given requirements?
The e-Government definition from above can be reduced to the fact that any e-Government solution provides an electronic interface to a public agency's business processes. This directly leads to a business model, where the e-Government platform is kind of a service broker as shown in Figure 2.
(Virtual) E-Government processes simply utilize business processes already in place. There is only an electronic interface to existing services leading to the behavior of an one-stop e-Government shop[16]. The result is a cascade of processes where the actual work is delegated to conventional processes.
Treating all public services as top level processes allows for a very simple abstraction that, in turn, is needed to meet the requirement of being able to offer virtually any service. In a further simplification, all these processes can be seen as order fulfillment processes offering more or less uniform interfaces to customers, namely order entry and delivery. To allow electronic access, the e-Government platform had to augment at least the following functions to the already existing processes:
• Electronic forms and form submission (including the ability to submit arbitrary attachments)
• Support for electronic signature• Electronic delivery
This approach eventually allows the specifics of the actual business processes involved in providing a service to be simply ignored. Therefore there is also no need to analyse or optimize these processes prior to making them available via the internet.
Figure 2: e-Government Platform on top of the process cascade
The Proceedings of the 8th Annual International Digital Government Research Conference
184
Figure 3 depicts the advantages of this pragmatic approach. After Step 1 a service is already available as an e-Government service but might not be optimized in terms of efficiency and speed. In a second step however, the underlying processes can be more closely integrated and supported if needed as shown later in this article. All that is needed is a software system that is capable of enacting any kind of business process.
3. THE INITIAL SYSTEM ARCHITECTUREThe ability to provide the city's residents with virtually every single municipal service at a minimal deployment effort has been and still is the most important requirement. Currently it takes about two days to bring a new service online, including design and testing of the required electronic form, which takes most of the effort.
As mentioned above, the e-Government platform was seen as a single electronic access point to the municipality's business processes. This significantly reduces the system's complexity from an organizational point of view. However, e-Government means the electronic execution of business processes and therefore a the systems used in the back offices had to be examined more closely.
The IT infrastructure within the municipality was dominated by a workflow system [17] that had been introduced in 2002. It is still forming the backbone of the city's internal information systems. Apart from this system however, some departments use SAP or other proprietary solutions as their major information system. Thus, several different systems – called backend-systems – had to be supported in order to electronically activate business processes.
One of the requirements was to also allow other organizations to utilize the platform. However, these organizations might use different, yet unknown, backend-systems. For these reasons the design of the platform had to be as open as possible. To meet this requirement a component based software engineering approach was pursued [18]. The result was a framework consisting of a set of components that allows for easy extension by adding new components and also easy replacement of single components by providing alternative implementations [19].
Figure 4 gives an overview of the systems architecture. The security layer is based on a public key infrastructure1 (PKI) that provides a nation wide electronic identity. The interface layer comprises all components needed to interact either with human or non-human users (other systems). The actual business logic (e.g. logic for document and form management, signature verification, plausibility checks) is contained in the function layer. The transaction layer forms an abstraction of all possible underlying backend-system. It provides a uniform application programming interface (API) that is implemented by different backend-system adapters. Every service is, depending on the underlying business process, bound to a specific backend-system. The transaction manager automatically selects the appropriate adapter, thus all systems can be treated uniformly. The range of supported backend-systems ranges from ordinary email to sophisticated workflow-management solutions.
To further support the scalability of the system and to minimize the impact of changes on the entire system, individual components had to be decoupled as far as possible. This was achieved by using technologies and data formats that had originally been introduced to support the communication between different e-Government systems also for the internal data representation. Currently the platform is using XML-a [20] but will be re-factored to use EDIAKT II [21] in the near future. Both data formats can be seen as the Austrian version of e-GIF [22] and comply with the European Commission's recommendations for e-Government interoperability [23].
The platform provides the following basic functionality:
1 http://www.buergerkarte.at/index_en.html
Figure 4: Layered Architecture of the e-Government Platform
Figure 3: The pragmatic approach. Bring services online without modifying the underlying processes in a first step
Step 2Step 1
Step 2Step 1
Step 2Step 1
Step 2Step 1
Step 2Step 1
Step 2Step 1
Serv
ice
s
Time
Step1: Provide electronic access to the service
Step 2: Improve the integration of the underlying business process
The Proceedings of the 8th Annual International Digital Government Research Conference
185
• start of new procedures by the submission of electronic application forms (including attachments). Depending on the specific use case forms might have to be digitally signed.
• electronic notification service concerning the progress of the underlying business process
• electronic payment• overview of the current state of all procedures
(requires login using the PKI card)• electronic delivery
4. E-GOVERNMENT BY NUMBERS – A SUCCESS STORY
In April 2005 the first five services had been made available via the e-Government platform. These initial services had just been used for test and evaluation purposes and had not been linked with the city's web site. The official launch of the platform happened in September 2005 when 13 services were already available. Figure 5 shows the development of the number of services offered and the total number of submissions since the launch of the platform. 31 services are currently provided and the total number of submissions made was appr. 16.000 by the end of November 2006.
One of the benefits of e-Government that is usually most appreciated by users is that e-Government makes it possible to deal with authorities at more convenient times and places [24]. Whereas no conclusions about the importance of a more convenient place can be made from the available data, Figure6 shows that the weekend is not intensively used to interact
with the municipality. However, a closer analysis of the submissions from Monday to Friday shows that 42% of them are made outside office hours. Adding submissions made over the weekend increases this number to 51%. In other words, more than half of the requests are made while municipal offices are closed. Thus, the availability of municipal services outside the usual office hours meets an existing demand.
Since the existence of the e-Government platform was not particularly advertised, the steadily increasing number of submissions reflects an obvious demand for e-Government services. All of this services have been made accessible without any business process adaption (see “Step 1” in Figure1).
5. REVISITING THE BUSINESS MODEL – STEP 2Since success is always a very good argument for further development the initial version of the platform was a precursor for further improvement of the system as well as the business model. As a matter of fact, representatives of the back-office departments that were owners of the offered business processes demanded even better integration of some of the tools they had to use. For example, to check whether a person is actually a citizen of the City of Graz, which is an important prerequisite for most of the services, they had to lookup the person in a central register of citizens. This however seemed to be a task that is very apt to be automated.
Thus, the decision was made to transfer activities that can be executed electronically from the original business processes at back-office layer up into the e-Government platform as shown in Figure 7.
Tasks that are now executed as part of the e-Government platform are: additional plausibility checks, inquiries at central registers (e.g. register of residents), integration of e-Government functionality provided by other organizations and e-payment. Some of these tasks had to be performed manually by civil servants using different information systems (e.g. web applications from other authorities) so far. By adding these tasks to the e-Government platform by the means of automatically performed functions, data quality will be improved significantly and processes will be notably faster (indicated by the shorter business process at back-office layer as shown in figure 7).
Figure 5: Development of the total number submissions and the number of services offered
Figure 6: Total number of submissions made per day of week from January to Nov 2006
The Proceedings of the 8th Annual International Digital Government Research Conference
186
6. IMPLEMENTING THE NEW BUSINESS MODEL
In the initial version of the platform, business processes had been treated as black boxes providing well defined interfaces. With the shift in the business model, business processes in place cannot be seen as uniform order delivery processes any longer. Since functionality provided by platform components is actively contributing to these processes, differences between the actual business processes utilized have to be considered (e.g. not all processes require electronic payment, some only under certain circumstances). Therefore, a way to minimize the effort for representing different processes had to be identified.
Two different technologies that allow for constructing processes out of a set of building blocks and are thus suitable to be integrated into the platform were considered:
• Worklow management (WMF)/business process engine
• Web service orchestration (WSO)
Gortmaker et al [25] compared these two approaches and tried to identify advantages specific to WSO and WFM along the dimensions organization, management, strategy, technology and operation. Their overall conclusion is that the major difference between WSO and WMF is that web service orchestration takes more of a technical perspective whereas workflow management focuses more on organizational issues. Thus, one outcome of their study was that WMF has significantly more advantages in the field of organizational, operational and process issues compared to WSO.
The technology chosen to be adapted for use within the e-Government platform was a lightweight workflow management solution. One reason for this decision lies in the nature of SOAP [26], which is typically used as web services protocol and implies an enormous communication overhead [27]. Since all platform components are written in Java and are running in the same virtual machine there is no need for any remote technologies that need serialization/de-serialization of method calls. Wherever web services are used (e.g. for making inquiries at central registers) these web service calls are
wrapped with adapters [28].
In a short feasability study, two different open source workflow / business process engines had been evaluated. One product was Enhydra Shark[29] the other one was JBoss jBPM[30]. Both products had turned out to be equally suitable for the use within the e-Goverment platform. The biggest advantage of Enhydra Shark over jBPM is its use of standards[31]. Yet the decision was made in favor of jBPM since a more comprehensive and up-to-date documentation was available. This was an important criterion for the project. In order to prevent any dependency on the product chosen, a business process engine (BPE) abstraction layer was introduced that works as a proxy for the underlying engine. Thus, any other engine could be easily integrated without influencing the rest of the platform.
The use of a business process engine (the terms “workflow management engine” and “business process engine” are used synonymously in this paper) allows for defining business processes by aggregating different building blocks. The most important building blocks and constructs are [32]:
• Task-node: This node represents a required user interaction. The process stays in a waiting state unless this task is explicitly completed.
• State-node: Similar to a task-node, however the process waits for an action by an external system
• Node: This is a representation of an automated action. Typically a pre-defined function is called
• Decision-Node: Used to select one of several possible branches in a process
• Fork-Node: Splits one path of execution into multiple concurrent paths of execution
• Join-Node: Synchronizes several concurrent flows.
Different workflow requirements are modeled by the means of so called process definition templates. Every template contains business rules that cover a wide variety of scenarios. Current experience shows that probably no more than five process definition templates will be needed to meet the requirements of almost all different business processes. Thus, every service can be mapped to one process definition whereas the cardinality of the relation between services and processes is many-to-one. This means that a single process definition can be used by an arbitrary number of services. For every new submission in a first step the business process template mapped to the requested service is determined. A new instance of this process is then created and started.
Figure 8 shows a part of a sample process. The swim lanes represent responsibilities. The introduction of a business process engine eases asynchronous interaction with citizens. Generally the BPE is used to control the internal flow within the web application rather than to control a classical workflow based on human interaction. However, when a task has to be completed by a citizen, this task is added to this citizen's task list. Depending on the importance of the task that has to be completed different ways to inform the citizen concerned are provided. The task list can be accessed via the e-Government platform similarly to an electronic work desk. Open tasks do not have to be accomplished immediately but within certain deadlines which are specific for the given process. Whenever a
Figure 7: The modified business process model for e-Government services
Public ServicePublic Service
Public Service
Mun
icip
al O
ffice
s
Public ServicePublic Service
E-Government Service
E-G
over
nmen
t Pla
tform
Electronic Services Provisioning
Business Processes offered by the municipality
Business processes offered via the Internet
Public Service
Uni
form
aut
omat
ion
Uni
form
aut
omat
ion
The Proceedings of the 8th Annual International Digital Government Research Conference
187
deadline is exceeded (e.g. no payment was made within two weeks), an exception handling – also depending on the given process definition – is initialized. For every type of task that might be assigned to a citizen, a tool is provided (e.g. a web application for electronic payments) allowing the user to comfortably accomplish the task. Thus the task list is a central navigation point within the web application.
Using the electronic work desk every resident can easily obtain an overview over all ongoing or already completed proceedings. Activities that require interaction are specifically marked.
7. CONCLUSION
The experience made so far shows that there is significant need for e-Government services of decent quality. Minimizing the effort to bring a specific service online is one of the success factors that allows for easy and rapid service adaption as well as for cost reduction in the medium and long run.
The use of a business process engine is an important enabler that provides the flexibility needed for an easy integration of virtually any service. By transferring more and more functionality from the back-office to the platform layer additional value is added to the e-Government business processes. This Enterprise Application Integration behavior allows for a significantly higher degree of automation (see Figure 9). A fully automated process in turn allows for synchronous service delivery wherever possible. This means that the required result is available immediately to the citizen. Starting with lower ambitions (“just bring our services online”) creates short-term wins that are necessary to convince important stakeholders[33] and prepares them to appreciate changes in their business processes. Subsequently these processes are streamlined as well.
Thus, e-Government platforms based on the outlined paradigm and architecture create significant benefits and notably reduce the risk of failure.
8. References[1] von Lucke J., Reinemann H., "Speyerer Definition von
Electronic Government (german)" [online], 2000, foev.dhv-speyer.de/ruvii/Sp-EGov.pdf, p1
[2] Layne, K and Lee, J., "Developing Full Functional E-government: A Four Stage Model", in Government Information Quarterly, , 2001, pp122-136
[3] Wauters, P. and Van Durne, P, "eGovernment Benchmarking 2005" [online], 2005, http://europa.eu.int/information_society/soccul/egov/egov_benchmarking_2005.pdf, p7
[4] Irani Z., Al-Sebie M., Elliman T., "Transaction Stage of e-Government Systems: Identification of its Location & Importance", Proceedings of the 39th Hawaii International Conference on System Sciences - 2006, 2006, pp1-9
[5] Hammer M., "Beyond Reengineering", HarperCollins
Publishers, 1996 p101[6] Davenport, Thomas H., "Process Innovation", Harvard
Business School Press, 1993 [7] Scholl, Hans Jochen, "E-government: A Special Case of
ICT-enabled Business Process Change", Proceeding of the 36th Hawaii International Conference on System Sciences (HICSS'03), 2003,
[8] Malhotra, Yogesh, "Business Process Redesign: An Overview", in IEEE Engineering Management Review,4 , 1998,
[9] Fowler, Martin, "The New Methodology" [online], 2005, http://www.martinfowler.com/articles/newMethodology.html
[10] Christine Leitner (Ed.), "eGovernment in Europe: The State of Affairs" [online], 2003, http://www.e-europeawards.org/view_extern.asp?id=4706
Figure 8: Sample process
Figure 9: Improving e-Government Services by Pushing the Degree of Automization and Integration
The Proceedings of the 8th Annual International Digital Government Research Conference
[12] Ukowitz E., "Barrierefrei und attraktiv - Accessibility, Usability und E-Government Richtlinien in einer Oberfläche vereint [german]", in E-Government 2005: Knowlegde Transfer und Status, Wimmer Maria (Ed.), 2005, pp357-364
[13] Salhofer P., Pickl M., "Using Open Source Software Development Models for e-Government Solutions", Proceedings of the International Conference on e-Government, Ottawa, Canada 27-28 October, 2005, pp363-374
[14] Boehm, Barry W., "A spiral model of software development and enhancement", in SIGSOFT Softw. Eng. Notes,11 , 1986, 14-24
[15] Jeffries, Ronald E, "Do the simplest thing that could possibly work" [online], 1998, http://www.xprogramming.com/Practices/PracSimplest.html
[16] Wimmer M., Tambouris E., "Online One-Stop GovernmentA working framework and requirements", Proceedings of the IFIP World ComputerCongress, August 26-30, 2002, Montreal, 2002,
[23] European Commission, "EUROPEAN INTEROPERABILITY FRAMEWORKFOR PAN-EUROPEAN eGOVERNMENT SERVICES", Office for Official Publications of the European Communities, 2004
[24] Graafland-Essers I., Ettedgui E., "Benchmarking e-Governmentin Europe and the US", RAND, 2003
[25] Gortmaker J., Marijn Janssen, Wagenaar R. W., "The Advantages of Web Orchestration in Perspective", Proceedings of the Sixth International Conference on Electronic Commerce, ICEC'04, 2004, pp506-513
[26] Box D., Ehnebuske D., Kakivay G., Layman A., Mendelsohn N., Nielsen H. F., Thatte S., Winer D., "Simple Object Access Protocol (SOAP) 1.1" [online], 2000, http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
[27] Chiu K., Govindaraju M., Bramley R., "Investigating theLimits of SOAP Performance for Scientic Computing.", Proceedings of HPDC-11, 2002, pp246-254
[28] Gamma E., Helm R., Johnson R., Vlissides J., "Design patterns: elements of reusable object-oriented software", Addison-Wesley, Boston, Mass., 2002 pp139-150
[31] Workflow Management Coalition, "Workflow Process Definition Interface-- XML Process Definition Languagee" [online], , http://www.wfmc.org/standards/docs/TC-1025_10_xpdl_102502.pdf
