IS of a State Administration | Managing Globally with Information Technology

Any e-government must be based on a state information system (SIS). The SIS must satisfy many obvious requirements being unfortunately often (even worse - as a rule) not considered. The information system of any state administration is one of the largest software systems to be built in any country. The most important properties of the SIS are:

SIS should service all the citizens, enterprises, and/or state and municipal offices. It should provide data to anyone excluding the data excluded by law. The laws can specify different access rights for different users. The system must therefore be open and able to communicate with an unpredictable collection of collaborating systems outside SIS (banks, municipal systems, etc.). Any citizen should be able to communicate with all offices from one place. He should not bother with what offices should collaborate during the response to his request.
Secrecy and privacy rights must be supported.
SIS should support the collaboration of all state offices and majorities. Examples are the collaboration during the investigation of car robberies and/or document verifications.
The availability of many local functions of any (sub-) system need not depend on the global system and on the activities and services of the middleware.
SIS should be able to communicate with information systems of private companies at least at the territory of the state.
SIS should reflect almost in "real time" the changes in laws. Steady and seamless modification of the system is crucial. The modification process should not be too centralized, as then it would cause unacceptable delays. The central authority would then be a bottleneck.
The system should provide tools for the data filtering, mining, and analyzing. Various tools are necessary. It is very likely that many new tools will have to be added in the future.
As there are many systems used by particular offices, it is very difficult to rewrite them in time. The existing systems must be easily integrated into SIS without rewriting their application and data tier. The system cannot be developed from scratch, as it is too large. Such a system is difficult to develop and maintain in a centralized way as a monolith. If it is built as a monolith, then according to the known empirical laws, the development time must be long (it is proportional to the third root of the number of lines of the programs implementing the system (Boehm, 1981). The maintenance of such systems is very difficult and expensive, sometimes not feasibly implemented by any means.
There are, however, more substantial reasons not to design the system as a monolith. No office will take responsibility for "its" (sub-) system if there is any doubt the subsystem supports its activities correctly. Any office can feel responsible for the data it produces and for the services it provides, only if it can trust the information system it uses. The office will therefore be required to influence or take part in the development and/or maintenance of its information subsystem. The office will oppose any changes of the kernel of the existing local (sub-) system if it works correctly. The office therefore tends to defend its subsystem. It usually implies that the office should take part in the (possibly autonomous) development and the modifications of "its" information system. Any actions and measures weakening the feeling of the responsibility of the office members for "their" (i.e., local) operations and data lead often to unpleasant consequences. We must also take into account such problems as prestige, lobbying, changes in political positions, corruption, etc. It is optimal under these conditions to prefer the integration of the existing (sub-) systems into the built confederation "as such," i.e., as black boxes.

It follows that any state information system should satisfy the following requirements:

As the end user should not bother about the internal structure of the confederation, the user interface should be transparent; the users should need no knowledge about the internal structure and the implementation details and even implementation philosophy of the confederation and its components. The interface of the confederation should be easy to modify. Solution: Internet browsers and XSLT utility.
Security services (access rights, cryptographic services, rules of data replications, etc.) are provided.
As the structure of confederations changes, the collaboration between autonomous subsystems should facilitate a quite easy modification and integration of components. So there must be a middleware supporting changeable complex message formats and standards for (meta-) data communicated between information subsystems.
As there are many different groups of users with different and changing needs, the regulations and methods how to implement communication and/or collaboration between components must be very flexible. The management of the SIS therefore need not and often should not take part in all the negotiations. Nevertheless, the management must develop the standards for the development of agreements and for the evidence of them as well as for the collecting the experience and development of generally acceptable standards.

It is not difficult to see that the communication subsystem (middleware) must offer further facilities like the data replication, general firewall tools, data warehouse facilities etc. Some services could be provided by components, some by the middleware. It is often not easy for the project management to decide what solution is better under given circumstances.

IS of a Global Company

Globalization enforces the international companies to be a worldwide network of relatively independent autonomous divisions (or autonomous enterprises). We shall call such enterprises global enterprises (GEN). The following features are typical for global enterprises:

Dynamic changes of size. Quick changes of activity types. Heterogeneous activities.
Acquisition of previously independent companies (Hewlett-Packard bought Compaq).
A GEN often sells or outsources some its parts or it divides itself into several pieces (example: separation of health technologies from Hewlett-Packard).
The divisions of GEN's are usually active in countries with different legislatives and local cultures. Individual divisions can differ both by the kind of their activities and by their business culture.
A seamless coordination with varying collection of business partners and state administration offices including the support of SCM (supply chain management), CRM (customer relationships management), purchase coalitions mentioned above, collaboration with existing and new business partners and/or customers.
The management of any global enterprise needs a wide support of analytical tools that should be obtained from specialized manufacturers (OLAP, workflow systems, statistical packages).
The partners should not need any knowledge o the structure of GEN. Points 1 and 2 imply the need of an easy integration of existing applications and IS (legacy systems) into the information system of the GEN. System changes, modification, and scaling should be easy.

Information systems of the divisions therefore ought to be autonomous and integration able. Heterogeneity and autonomy of constituent units of the GEN needs a rather big autonomy of the functions and an autonomous development of individual information subsystems (units). The reason is that some specific solutions are needed for the given unit only due to the diversity of the activities. The corresponding software entity must therefore be also autonomous, used as a black box, able to be integrated easily and eventually developed almost independently. In other words: any technical feasible structure of the information system of the GEN should have the mean features of software confederations.

There are many software engineering reasons for the use the architecture of software confederation in the discussed case. The development of a huge IS of a GEN as a monolith (one whole, no large parts are used as black boxes) is expensive, time consuming, and inflexible. If the subsystems are autonomous and loosely related (i.e., the system is a confederation), any possible failure of one of the subsystems need not necessary cause important consequences for other subsystems and for information system (IS) as a whole (compare the situation on WWW).

Splitting a company or selling out of some of its sub-units is substantially easier and economically more advantageous if it is possible to sell the sub-unit together with its IS. The possibility of the easy separation of such an IS and the possibility to sell it with as little knowledge about the IS of the whole GEN as possible is critical.

The connection between software components needs a powerful middleware. It can be used also for the communication with business partners and state authorities. The middleware should also allow end users (employees and business partners' agents) easy access to the information systems (e.g., to support e-commerce). An acceptable solution in the case of confederations discussed up to now is the Internet.

Activities in the countries with different legislative systems and culture have consequences also for the message formats. Heterogeneity of rules (e.g., shape and sometimes also the contents of invoices) forces the use of the data formats allowing the transformation of the document data into different forms.

We shall consider the IS like the IS of a GEN and/or of a state administration global information systems.

Shown facts imply following requirements on global information systems:

Global information systems should be designed as a network of loosely coupled subsystems — it is as a confederation of subsystems.
The subsystems offer permanent services.
The subsystems should be autonomous — a failure of a subsystem should not spoil the run of the system as a whole.
A parallel running of the subsystems is necessary; this is why asynchronous communication and the peer-to-peer philosophy should be used.
There must be a powerful supporting middleware.
The communication should allow exchange of data together with metadata to ensure flexibility needed for cooperation of the components in heterogeneous environments (countries). Some messages can be commands rather than data queries.
The enterprise management often requires analytical tools. The easiest solution is integration of third-party products (e.g., OLAP or workflow systems) into the system.

There are many other cases when the use of confederated architecture is necessary or at least optimal. Give some of them:

The information system of municipal offices
Units of heath care systems
Any enterprise having a decentralized architecture
Information systems of large universities
Education networks

Common Features of Global Information Systems

It follows from the above discussion that the following requirements are typical for global information systems. These requirements can be fulfilled by software confederations:

Incomplete, contradictory, often obscure, continuously growing and changing requirements due to changing business conditions or changing legislation.
The necessity to integrate third-party products as well as existing (legacy) systems.
The necessity to communicate with the software system of partners on different levels of interoperability varying from the communication between software entities of the organizational sub-units (e.g., divisions) to the communication with the software of a occasional customer.
The software supporting the activities of sub-units should provide local services also in the case when the whole system is down (e.g., the middleware does not work).
A changing, complex, and always growing set of users and user roles and the changing internal structure and the size of the software confederation.
The necessity to keep the autonomy of certain subsystems, e.g., a police information system inside the information system of state administration or an information system of a newly purchased company in the case of GEN. Besides it, there are many software engineering reasons for the autonomy of components.
The necessity to collaborate with information systems of changing and unpredictable set of partner organizations (business partners in the case of a worldwide company, information systems of the companies residing on the state territory should communicate with IS of the state authorities).
The distributed changeable user access rules and standards. The user interface should be easily modifiable and it should hide the system internal structure.
As the number of components can be very large and some IS members need not be known at development time, it is not feasible to coordinate and/or to confirm the communication agreements between the components in a strictly centralized way.
The continuous and seamless modification of the system is crucial. The modification process should not be too centralized, as it would cause unacceptable delays, as the bottleneck would be the central authority. It implies that the message formats (the syntax of messages) must be usually agreed in a decentralized way by the designers of the components. A feasible solution is a metatool able to define all the possible variants of the message syntax. A promising solution is XML. The problem is the optimal balance between the freedom in the choice of formats and the rules of standardization.

Note that Points 2, 4, 5 and 6 imply that the system must have the structure a network of large loosely coupled autonomous software units (autonomous components) providing permanent services interconnected by a powerful middleware.

All the components work like many services in human society or like www servers — i.e., they form a peer-to-peer network. The practice indicates that the network should be based on a middleware able to transport complex text messages. The messages are then words in a complex language having a quite rich structure and/or contents.

Autonomous component (AC) is usually a quite complex software entity, often provided by a third-party or it is a legacy system. AC is usually a complete application (often an IS) providing appropriate gates for the communication with other autonomous components of the network.

In business systems, a component can be OLAP or a complete warehouse control system. The inner structure of autonomous components is as a rule hidden. Autonomous components are therefore used as (total) black boxes. The only external knowledge on the AC is its interface defined via a complex language understood by their gates. The messages used in the communication should be rather declarative — they should specify what to do rather than how to do it. It facilitates the modifiability of the confederation. This feature can be strengthened if we use XSLT-based autonomous components as general message formats transducers. The architecture of the resulting systems can follow the principles shown in Figure 2.

Figure 2: The gates of a three-tier information system

Let us specify some details of the implementation of the communication between the components. A feasible solution is implemented via construction of gates opening the data and/or commands paths to and from the components. If a component is a three-tier (user interface tier, application tier, data tier, see Figure 2). The gate can be connected either to the application tier or to the data tier. In the former case, the messages addressed to the component will be rather command-oriented and can be sometimes specified by SOAP (Simple Object Access Protocol). In the second case, the messages will be data-oriented (their format will be based on some metadata based structure, e.g., UDDI or RDF). Both cases have their pros and cons. The command interface enables the access to all the functions of the component but need not provide all the component data. It can be quite secure. Data gate provides in principle all the data, but not all functions.

Software Confederations in the Small

There is yet another variant of software confederations having origin in the design and development real-time (process control) systems like atom plant control systems, flexible manufacturing systems or simply the systems controlling a collection of automated house-hold devices in an automated family house. Such systems can work on one computer and can be quite small. Their middleware services are provided by the underlying operating system able to support symmetrical multiprocessing. We call these systems confederations in the small. The confederations discussed above will be called confederations in the large. The testing of real-time systems consists of:

Software testing of the data correctness of the responses on the simulated signals of the controlled processes (i.e., the testing off line). Simulation uses software simulators. If the user interface is sophisticated enough, it can be used as a simulator.
Off line testing of the timeliness of the responses with software simulators.
Off line testing with hardware simulators. Some catastrophic cases are simulated as well.
Testing the whole system, controlled process inclusive.
During the system run, all the commands and reactions of the system operators must be logged.

The solution of the problem can be following one (see Figure 3). The system is designed as a confederation consisting of at least the following permanently active services (autonomous components, i.e., processes in the sense of a multiprogramming operating system allowing symmetrical multiprocessing):

A component L containing the process control logic.
A user (operator) interface component UC.
A component D containing all the I/O drivers. This is the only component communicating with the controlled system (process).
A communication component P called Post. All important messages in the system must be sent via the Post P. P sends the messages to the addressees and it can optionally log the messages. The messages can be redirected to other destinations (e.g., to a simulator or to UC) by a system administrator command.
Optionally, a simulator S containing some parts of the run time support of discrete event simulation languages like Simula 67 or at least the calendar of events. The task of S is to simulate the dynamics of the controlled system.

Figure 3: Structure of a real-time control system

The point (a) can be implemented via redirecting messages to UC being able to accept and present them and being able to generate the messages for the logic L. UC is under these conditions used as a prototyping tool. The conditions are fulfilled if UC contains a browser. The point (b) can be implemented via redirecting messages to the simulation component S. The messages are logged together with the values TY-TS, where TY is the system time and TS is the cumulative time (duration) when the simulator S was active (running). It is not difficult to implement such a system.

Note that it is not necessary that L is one component only. If UC is sophisticated enough and L is formed by more than one component, then one can implement prototypes of the components not implemented yet via UC and via redirecting messages to UC. This is a feature very usable in the confederations in the large as well, but its implementation should be based on new tools allowing implement the concept of the Post as a modification of user interface components (see below).

The just described paradigm can and should be used in the case of quite small systems if the message administration is not too slow (ineffective). Such effectiveness problems appear, however, quite rare.

The implementation of real-time system described above is a very old application of the SWC paradigm.