(Un-)Sustainability of e-Government: Hazards and Questions for Future Research

Hazard I - the expiration date

At the design-time of an e-government system, only then-valid law can be taken into consideration (needless to say, it is impossible to predict which regulations will be in force in the future) and hence, changes in law will require a change of such system. Here are a few examples:

Bezeljak [5] describes the development of a novel e-justice system for handling insolvency proceedings according to the then-valid law, the Slovenian Financial Operations, Insolvency Proceedings and Compulsory Dissolution Act (ZFPIPP). The ZFPIPP was enacted in 2007 and underwent approximately ten changes between 2009 and 2013, a few of them caused by decisions of the Slovenian supreme court. All of these changes occurred after Bezeljak’s publication. (We have no information on how severely later changes affected the developed solution.)

As Bezeljak (ibid.) reports, the system provides users pre-prepared PDF templates of documents that represent particular action-steps in legal proceedings together with user interfaces and functionality for entering data, electronically signing the documents and verifying such signatures, as well as functionality for retrieving data from web services offered by other e-government systems. It is likely that certain parts of this highly complex e-government system became meanwhile legally obsolete and that they had to be re-engineered.

Horvat [6] describes the design of a population registry in Montenegro, which integrated various administrative proceedings as individual workflows according to the then-valid law. During the requirements-analysis phase the team found discrepancies in law, which caused that the latter had to be changed first by the parliament in order for the system to fit its purpose. Needless to say, future lawmakers will face a system too big to be changed that will limit their freedom in drafting new legislation.

Naraks & Golob [7], Kolar [8], and Kos & Zorman [9] report of various e-government systems that required massive re-engineering due to changes in law: Thus, Naraks & Golob [7] describe the re-engineering of a system for the requirements of Slovenian market inspectorate, which was required due to the “high number of changes in different acts” (ibid., own translation). (Doesn’t this imply that redesign was delayed until the system became unbearable?) The resulting new system is a fully-fledged document management system with more than two hundred predefined templates that either fully or partly automatize different administrative workflows. The system is designed to be extendable so that future workflows can be added at runtime. The authors however note that updates and adaptations in future will be required to keep the system fit for use when law will change.

Kolar [8], who reports on the design of an e-government system for public procurements, reports of severe challenges with a “continually changing legislation” (ibid., own translation) during the process of development, as well as with an opposing bureaucracy that was not particularly fond to deal with a new system and thus was searching “for excuses of all kind” (ibid., own translation). The system was at the time of reporting in an advanced stage of use which allowed Kolar (ibid.) himself to conclude that the system already needed renovations, updates, and readjustments due to changed law. Two years later Korač [10], writing on the same topic, found that finding e-government systems for managing public procurements of adequate quality is not easy – meanwhile obviously private providers have flooded the market with their own tools and own flaws.

Kos & Zorman [9] describe the reengineering of the Central Dog Registry at Slovenia’s veterinary agency, which was first established in 2000. Due to “changes in national and EU legislation” (ibid., own translation) during the first eight years of operation, a new registry had to be engineered. Amongst the key reasons for the development of a new system Kos & Zorman (ibid.) note obsolete technology of both back- and frontend, an inefficient data model, missing connectivity to other vital registries, and unfitness to respond to changes in veterinary practice and regulations. Furthermore, several new workflows were introduced.

Also Levstek [11] reports of a massive reengineering of the existing solution for managing the treasury of Slovenia. Before the reengineering, a multitude of heterogeneous e-government systems managed public finances, which however failed to provide sustainable functionality. Thus in 2007-2010 a unified system was developed and engineered, whose development (in terms of functional adaptations and updates) shall continue into the future.

A further, far simpler and probably more common vulnerability of e-government systems was reported by Burton [12], who describes how the US Department of Defense run into a situation when in 2005 the Federal Republic of Yugoslavia changed its name to Serbia and Montenegro. As the system’s development and maintenance has been outsourced to a company whose contract did not enable them to make changes to entries in the database, the name-change in official communication had to be postponed.

The implied expiration date of e-government systems is a crucial factor for their unsustainability and unlike the other factors which we discuss below, this one is by far the most comprehensible as users of such systems can themselves experience changes. The reason for this type of vulnerability lies in the separation between the law, agencies and contractors who finally engineer massive black-box systems with functionality tailored to the wishes of agencies.

Another example of an unsustainable governance system was one we personally were able to observe from 2012 on, in the higher-education domain. The system we observed has been developed by technical staff to cater the needs of administering a university course. The functionality encompassed monitoring the progress of several hundred students, scheduling of exercises, lessons and examinations, assessment of students and providing insight into students’ past achievements, etc. The system has been developed several years ago and at that time was tailored to fit the needs of one single staff member. The functionality of the system was thus fixed to a defined workflow of how to manage students throughout their participation in the course.

Through time new staff joined the team, which brought-in new views and experiences how to deal with students. As their approach differed from the pre-defined workflow, soon demands for modifications of the system’s functionality reached the developers, which were met with objections and resulted in a conflicting situation. The new staff requested access to the code itself and the underlying databases in order to take development into their own hands, which however was rejected by the developers, who thus strengthened their influence in how the course was performed.

Although that system was only subject to individual requirements rather than mandatory regulations, a severe discrepancy between what is required by the teaching staff and what is finally produced could be observed. In e-government scenarios a further juncture implies risk for conflicts and faults, namely the juncture between the legislator and the agency responsible for the execution of the particular law. Thus, inaccurate functional requirements have led to chaos in Slovenia’s electronic cadaster system, where common functionality has been simply forgotten at design-time [13], [14].

Hazard II - monopolization and exclusion

In the above-described university course the relation between the formally appointed academic staff and the formally subordinate developers was reversed by the latter, who used their de-facto control over the modalities of the course to keep them in a position where they were indispensable. After all, would they be still required if the academic staff would gain control over the system or transfer that to somebody else?

In the case of the university course the academic staff lacked resources and motivation to meddle with the existing workflow. The lack of motivation was caused by the fact that that arrangement helped in efficiently coping with a huge workload that could not be managed otherwise. This modus operandi corresponds to what the German sociologist Luhmann termed brauchbare Illegalität (useful illegality) [15, p. 44], i.e. a situation in which an organization deliberately does not operate by the book, as it is beneficial to go against formal rules and regulations.

Such kind of useful illegality, as Walter points out, plays a vital role in stabilizing state bureaucracies by e.g. filling gaps in legislation in order to allow agencies to operate in accordance to their core mission. Filling these gaps, which yawn between what the legislator defined and what state agencies need to deliver, is a frequent task when it comes to e-government systems, where legislators merely define the gross functionality, while the fine details of the concrete implementation are delegated to system designers and developers.

Bovens & Zouridis [16] pointed out at the matter of useful illegality in e-government systems, which they quite appropriately call system-level-bureaucracies. They emphasize that a new class of politically unauthorized people, such as system designers, legal policy staff, and IT experts, gain “discretionary power to convert legal frameworks into concrete algorithms, decision trees, and modules” (ibid.). While this new class of informal bureaucrats can play a beneficiary role similar in effect as beneficial corruption in general, they do contribute their fair share in making e-government unsustainable.

Let us have a look at two e-government systems in which discretionary power of system designers and technical staff played a crucial role in bringing the system into life: the European electronic identity framework, and the Slovenian secure electronic delivery system, which makes up the backbone of electronic delivery in legal proceedings.

Hazard III: legal certainty

Legal theory distinguishes between public law and private law, whereby public law regulates the relations between the state and its citizens – ergo relations between the sovereign and its subjects, while private law regulates relations amid the subjects based on their will [22], [23, p. 23]. A major difference between public and private law is that private law restricts the freedom of the subjects, while public law empowers the sovereign.

In societies that adhere to the rule of law, the sovereign (ergo the state through its bodies) operates in accordance to the principle of legality, which means that every action and every decision made by the state must be explicitly defined by law. This applies both to stated decisions, as well as the procedures that lead to them [24, pp. 28–29]. This fundamental legal principle allows subjects not only to exercise control over the sovereign, but guarantees also legal certainty, which makes the sovereign’s actions transparent and foreseeable. Legal certainty prevents the state’s bodies (e.g. government, police, judges, etc.) to act or decide arbitrarily, which is crucial, as state arbitrariness would break crucial legal principles, such as the equality before law [25, p. 31].

E-government challenges the principle of legality, as it delegates government behavior to machines. Bovens & Zouridis [16] argued that from the perspective of equality before law, e-government (there: system-level-bureaucracy) “may be regarded as the zenith of legal rational authority [as] thanks to ICT, implementation of the law has been almost wholly disciplined” (ibid., p.181), if it was not for the issue regarding the delegation of discretionary power, which we summarized above (ibid., p.181).

But can e-government really perfectly implement law? From a technical perspective, functionality offered through e-government contains often procedures which subjects can trigger (and communicate with) remotely, whereby such procedures are executed on the server of the particular state agency. The communication between the subject and the sovereign (represented by the agency) is thus channeled through technical communication between the technical equipment of the subject and the serving terminal of the sovereign. Unlike human-to-human communication, which is based on the interpretation of analogue messages, the digital communication is discrete, exact and unambiguous. Human communication for example does not rely on strict grammar or correct pronunciation of words – two foreigners will be able to perfectly communicate in English despite their ignorance of its grammatical rules. Also general human perception is based on the interpretation of analogue, ambiguous information – we can visually recognize e.g. a car even though we have never seen it in the exactly same environment, angle, shape, etc. However, it is impossible for two computers to communicate without adhering to strict protocols that regulate the exact semantics of the transmitted signals and information. We can say that human interaction is analogue and computer interaction is digital – the former is ambiguous and therefore must be interpreted while the latter is unambiguous by nature.

Also e-government should adhere to this digital nature of machine interaction, which brings us back to the problem of legal certainty: In the real/analogue world the interactions are subject to interpretation, and thus legal certainty can be achieved by defining spaces of discretion within which interaction takes place. Thus, an administrative proceeding is initiated by submitting a written and signed application to the responsible government agency, whereby there are no legal provisions defining the material on which the application must be written on, the font that must be used, or the exact wording. Because the interaction takes place in the analogue dimension, it can be reasonably expected from the addressee to be able to understand the request. If the application however is an electronic document sent to an endpoint of an IT system, then in such case the structure and semantics of the transmitted message need to be rigorously defined.

If a user (the client) interacts with an e-government service, then this interaction is an exchange of electronic messages, which accords to a particular schema that the serving endpoint (the server) understands. An example interaction with a Web-based e-government system would be as follows: the user first sends a HTTP (the de-facto standard for communication with Web servers cf. [26]) request to the Web server of the e-government system; the system then responds with e.g. an HTML Web page, which the user’s terminal equipment may (or may not!) visualize and present as a user interface for further interaction. Over a series of such requests, the user consumes the e-government service, whereby the server has neither influence on how the client treats the response, nor does it know whether the response was received at all.

This exchange of messages – the user’s requests and the server’s responses, in the e-government interaction is an essential part of an administrative proceeding initiated by the citizen with the goal to influence her legal statuses or rights, or to just receive information. With focus laid on this perspective, it becomes evident that legal principles must be applied also to this dimension in order to assure legitimated, non-discriminative access to e-government systems.

The interaction between citizens and governments over the Internet is a novel experience for both the legislative, executive, and judicative branch, which all severely lack technical knowledge required to cope with the challenge of structured data exchange. As an increasing part of the population is acquiring skills required to create IT artefacts and to interact with digital structures on a low level, new issues will have to be resolved, such as: Is the government allowed to prevent citizens from interacting with governmental services in an automated manner – e.g. through bots [27]? Or: is it legal to make web sites render properly only in a limited set of web clients and system configurations?

Alas, whoever would be courageous to start documenting and properly legitimizing each and every technical endpoint, each communicational protocol, each piece of code used in existing e-government applications, would be about to fall down the rabbit hole, ending up punished by the gods as Sisyphus, facing a nightmare of endless recursion so to speak.