Design of the architecture

The revision of the architecture builds on the current model, and provides a view of how e-government can be put into practice. It lays out the various components that will allow the system, in this case the entire business system for the delivery of government services, to work effectively. Like components of the architecture have been grouped into categories for ease of understanding and analysis.

In the architecture we have classified the components into six categories or building blocks. The categories are a useful construct to identify the required business functionality in a generic service delivery process, together with the components that need to exist to provide that functionality. These categories are:

• user access;

• user services and guidance;

• service enabling tools;

• connection tools;

• business delivery systems; and

• the surrounding e-government environment - governance, policy and management regime.

The building block approach to design of the architecture provides sufficient flexibility for the government to develop business systems without many of the risks associated with having a prescribed architecture (listed above). In particular, it allows quicker and more effective linking and unlinking of business systems and processes as need dictates

The design of the architecture highlights the front office, back-office view of e-government. It also indicates which part of the architecture is oriented toward the customer, which parts should be viewed from an all-of-government perspective, and where the business systems of individual agencies feature in this expanded view of service delivery.

The architecture requires that some elements of agencies' service delivery will in future be developed from an all-of-government perspective (i.e. 'develop once, use many times'). In particular, there are benefits to having a common architecture for:

• how services are presented to people (User services & guidance);

• how service delivery is actually electronically enabled (Service enabling tools); and

• how agencies connect to one another and their customers (Connection tools).

View this picture in more detail.

This is because many aspects of agencies' service provision are or will become generic (e.g. 'accept an electronic payment', 'authenticate an individual', 'change address', 'deliver a secure e-mail') and therefore are best done in a standardised manner by all agencies. This does not mean that agencies will all share exactly the same information and technology. Instead, the architecture will be comprised of:

• shared components: components developed and implemented only once, and used by many or all agencies (e.g. the Portal);

• generic components: standardised components that support a generic activity, but are implemented locally (e.g. a technology solution for handling an online registration process that can be incorporated into different business processes in different agencies); and

• unique components: components that are specific to a particular agency, function or service (note: these will still need to be e-GIF compliant).

Traditionally, agencies' business systems have tightly coupled the front and back office i.e. they have been vertically integrated. This design views the different components of the business system as separate elements and thus offers the ability to implement separate components in both a vertical and horizontal fashion.

The architecture is recursive. The same pattern is repeated at the all levels of government, i.e. public sector, agency cluster, agencies, business unit and so on. Each detail describes the business at a number of levels, from the individual business process to the whole organisation through to all of government. Each level is exactly the same as the whole.

The architecture has been designed so that it applies to the public sector (all of government), individual organisations, or business units within organisations. The architecture can scale as required. The design of the architecture allows service delivery to be structured in many ways, without "hard-wiring" business systems together.

Having deconstructed the generic components of service delivery processes, we can more clearly define the role of different actors in these processes. Any service delivery process comprises all five "boxes", from user access through to business system. In a loosely coupled environment different actors may have different roles for defining and providing the different boxes. They may come from separate agencies.

The overall implication of this architecture for government is increased flexibility in the way services are delivered. It will allow single agencies to potentially provide more varied services than they do today (say, by providing over the counter or web-based access to services provided by other agencies). It will also allow new types of integrated services to be delivered by groups of agencies working together to make use of the components that will be built to support the architecture (e.g. using a standard "make a payment to government" module, or connecting systems together with e-GIF compliant interfaces and approved XML schemas).

In an all-of-government environment, user access can be provided by any number of service providers, not necessarily limited to public sector organisations. Provided the rules of working with User Services & Guidance box are followed, anyone can be a User Access-box service provider. Clearly individual agencies will have responsibility for the Business Delivery Systems box, as they currently do.

The middle column of "whole-of-government" boxes is the domain of government to collectively decide what these components will be and how they will work. Primarily the interest is to define the business requirements, standards and/or business rules in each of the boxes, with a last resort being to decide who will provide various elements/components required for implementation of that box. An example of such collective decision-making is the e-GIF.