One key difference between e-government initiatives and private sector projects is the separation of concerns on the project.

A private-sector project is intended to create a competitive advantage for its owner by offering a unique and compelling value to the user of the system. This often leads to architectures that are tightly coupled and require centralized control of the entire system from the user experience to the back-end technology. In the commercial world, this is perfectly acceptable because there will usually be multiple competing providers and the market is free to decide which of the offerings provides the best value.

With e-government projects, the key concern is to deliver universal access to government processes and services to the widest range of potential end users. In the medium term it can be difficult to predict how, when and where those services will be used.

The most sensible approach therefore is not to seek end-to-end control of the entire system, but to separate the front-end from the back-end. Public agencies can develop back-end services and a core of necessary front-end interfaces, while allowing others to develop novel and value added services for citizens or indeed government itself.

A good example is US personal income tax returns, which can be difficult for even highly numerate people to calculate. Rather than attempting to create a standard spreadsheet or even an application to assist the preparation of filing, the IRS simply published the acceptable data format for tax returns. This spurred the creation of an entire market which now supports many providers of software packages and online services at a variety of prices from free to several hundred dollars.

No matter how much time and effort the IRS put into software development, it could not have matched the variety of novel filing modes offered, at no public cost, by the market.

In the private sector, much lip service is paid to the need to support multiple languages and interfaces accessible to people with disabilities, but commercial pressures limit the extent to which this actually happens. Public institutions quite rightly take their responsibilities in these areas much more seriously.

The fact of the matter is that no single front-end is capable of simultaneously serving both top-of-the-line graphical user interfaces and all the various disabilities that users may have. Therefore a clean separation of front-ends from back-ends is required to allow multiple specialized front-ends to all feed through to a single e-government process.

Public institutions have a paramount responsibility to protect the confidentiality of the personal information entrusted to it by citizens. Citizens are rightly concerned that increasingly automated flows of information across government agencies and to the private sector creates the potential for misuse and harm. It is vital to establish and publish the principles and rules that will govern the use of private data across e-government, and Europe leads the world in data protection legislation.

Ensuring compliance with data protection laws and principles represents an extremely tough technical challenge. Intervening in XML dataflows is easily done and can remove explicitly private information as it flows beyond the boundaries of its home agency can remove many systematic breaches of privacy and data protection statute, but the propriety of many data exchanges will depend on whether the subject of the data has consented to that specific exchange.

There is no simple and obvious balance between valid privacy concerns and the astronomical complexity of creating a technology-based enforcement of all relevant Data Protection legislation and principles.

One route is to ensure that all agencies and third parties contractually agree, under threat of appropriately severe penalty to use information only in a manner consistent with current data protection laws and principles.

Fortunately e-government initiatives based on message-based XML workflows can readily log the Who What and When of workflow events across multiple agencies to provide a permanent audit trail, and the flow of information between agencies can be spot-checked for compliance. Suspected breaches of data protection can therefore be identified and investigated and appropriate action taken.

Public institutions have lifespans much longer than commercial enterprises, and their existing processes and procedures have evolved over much longer periods. Processes are likely to be more complex and are certain to be subject to more constraints than those in commercial enterprises.

When commercial enterprises engage in large technology infrastructure projects they often spend considerably more time and money than originally planned. It can be difficult to cancel out-of-control projects because none of the benefits are realized until every link in the chain is automated.

When public institutions attempt the same all-or-nothing approach to automating complex processes, the results can be truly catastrophic - billions of euros spent on projects that are ultimately cancelled with no productive results.

For a public institution, it makes sense to consider an incremental approach to e-government which phases automation over a period of time. One can identify the processes with the highest ROI or public utility and automate them first.

For example, in Ireland birth records are created by the Government Records Office, but are used by many different agencies including health, taxation and education. Implementing an XML based publish and subscribe service enabled automatic notification of births to all interested government agencies and delivered an immediate and significant public saving by eliminating manual processing and human error. The exchange of other life-event notifications (for example deaths and marriages) can happen later as required, using much of the same design pattern. For many public sector business processes partial and incremental automation is the most appropriate route.

Unfortunately partial automation cannot be considered if the framework for integration is all-or-nothing real-time communication between a chain of tightly-coupled systems.

Messaging is the he only approach to partial automation of processes and services. When System A wants to communicate with System B it sends a message over a reliable messaging network and forgets about the request until it receives a reply. System B receives the message, services the request, and replies when it has the time to do so.

The beauty of this approach is that no system expects a reply within milliseconds (which can never be guaranteed over a large distributed networks anyway). It therefore does not know or care whether the request is being processed by another computer or a human being. One element of the process could easily be a public servant using a cheap and ultimately disposable browser interface to respond to the requests that then re-enter automated workflow.

Considering e-government services as long-lived message-based conversations works because it is closely aligned to the way people and processes work in the real world. It allows quick automation when possible and useful, while leaving other manual processes intact until there is a case to automate them.

In cases workflows where all processes are automated, the overall system has the appearance to a user of being completely real-time. It may be a few milliseconds slower than a tightly coupled API-based integration but for almost e-government applications it is simpler, cheaper, more flexible and fast enough.

There are many possible services in the public sector that are not possible today because of inter-organizational boundaries. For example a work permit application typically requires processes in foreign affairs, law enforcement, taxation and employment. A key benefit of e-government is the presentation of complex inter-agency processes to user as a single integrated service.

The primary barriers to enabling cross-agency processes and services are not technical - they are legal, political and procedural. Government agencies each have unique, long-standing and cherished heritages with clearly defined physical, organizational and cultural boundaries.

Attempts to mandate a uniform technology strategy or instantaneous implementation from above will swiftly encounter resistance at departmental, regional and local levels. The notion of a single centralized e-government hub with everyone using identical XML data formats is extraordinarily difficult to achieve in reality.

Thankfully one does need to break down these long-established organisational structures in order to deliver e-government initiatives. The most effective approach is the one used for centuries by autonomous groups who have needed to work together for a common purpose -- a federated structure. It is perfectly reasonable for different departments or regions to control their own technology environments and data structures while supporting shared processes and services across a wider government network.

This can be accomplished by having multiple rings of data and process flow, linked by bridges that automatically convert XML data into the expected format as the messages flow between networks.

This approach enables the rapid creation of government-wide processes and services without the need for every affected agency to rip and replace perfectly good systems. It also reduces the requirement for every single person in every agency to understand the bigger picture in order to deliver new services. As requirements for processes and services at a supra-national level emerge, it is clear that only a federated information infrastructure can deliver.

A critical function of e-government is the support it can offer to policy creation and delivery monitoring and improvement. Basing the architecture on the flow of service requests between agencies makes it possible to create holistic views of how collections of services, agencies and functions are working together.

Because these documents represent time-stamped checkpoints on real tax returns, passport applications and medical procedures, they contain invaluable information on service delivery. The way the documents pass through (or wait for) specific services and processes can provide an immediate and highly visual tool to identify service delivery bottlenecks, which can never be predicted in advance.

The dataflows themselves should become the most effective real-time diagnostic tools to incrementally improve overall delivery at all levels of government. At the most senior policy levels, they can provide timely and relevant information for policymakers seeking ways to improve services and cut costs, and provide the best way for states to benchmark performance and delivery against each other.

Within privacy and data protection constraints e-government services should be offered widely and in a manner that makes them reusable by other agencies and third parties. Natural disasters, diseases like Foot and Mouth and major one-off events all require the rapid creation and mobilization of cross-functional teams that may exist for short periods of time. A federated approach drawing on multiple reusable processes and services offers an invaluable mechanism for creating temporary agencies.

The architecture should also allow the sharing of common services like identity management without having to centralize entire departmental systems -- leaving ownership of the process or service where it belongs but removing duplication of effort across all agencies.

A wider point is that nobody knows what novel and useful services could in principle be developed under the umbrella of e-government -- indeed it would be foolish to attempt to design a structure that placed limits on what could be possible. The creators of the internet understood this intuitively, and called it the end-to-end principle of network design. They rejected building sophisticated rules into the network and instead focused on getting any packet of data from one node to another in a reasonably efficient manner.

The success of the internet is due in large part to an architecture that allows the development and offering of new services without the need to seek permission from a central authority. The network itself should be relatively simple, and existing services on the network should have the potential to be combined in many ways to deliver new and useful services. Those who wish to see e-government fulfill its fullest transformational and integrative potential can draw much from the history and development of the internet.