2 Where should we create content?

2.1.1 The shared workspace needs to consider whether people should use existing client tools they are familiar with, or independent server based facilities.

Option 1: Client based - existing client software: User creates content using their existing client software. On completion, they use a browser or e-mail to load the file onto the fileserver.

+ Files can be worked on locally (without a connection)

+ Users are comfortable with e-mail and their own software

+ Licensing clearly defined

-Accessible only from those PCs with the client software loaded

- Security risk - files stored on many local PCs

- Requires translation software to common format on server

- Requires messaging handshaking (to update workflow)

- Requires robust document check-in / check-out

- Probably requires customised client software

- Information inaccessible until checked-in

- Integration with ALL existing client software difficult

Option 2: Server based - use client browser: User creates content using a web application interface. E-mail (or alternative alert messaging such as SMS) used to alert user of an action being required.

+ Accessible from anywhere

+ Simple document check-in / check-out flag

+ Security good - files stored on single server

+ Could use remote control of Microsoft product or web creation

+ Probably not require additional software on client

+ Reduced messaging requirements (change of state for workflow purposes)

+ Reduced bandwidth and storage requirements at the client end (no longer need to store local copies of large documents)

+ Information available, even in draft form

+ Easier integration, as it mainly happens at server

+ Could gain savings by using concurrent licensing

- Connection-based - - must be on-line to work

- Users may resist using new software

- Users need to know how to use two systems: their own agency and the

common system

- Licensing not clearly defined - could be ASP

2.2 Recommendation

2.2.1 The recommended option is "Option 2: Server based - use client browser". Content should be created on the server, because of standardised tools, simpler design and better security.

3 How distributed should we be?

3.1.1 The shared workspace faces a significant issue surrounding the centralisation of the shared workspace and its associated information store, or the accommodation of existing agency silos.

Option 1: Fully centralised: The shared workspace provides all facilities and stores all information. It is the definitive source of reference, for government information. It provides the tools necessary for individual agencies to collaborate.

• The shared workspace will meet 80% of requirements. When agencies can demonstrate their needs aren't satisfied by the common workspace, they can create a specialist workspace. The shared workspace will act as a redirection portal to the specialist workspaces.

+ Everyone uses a common tool set.

+ Simple security requirements - files are not moved offsite, access control is only required at entry, there are no synchronisation, replication issues.

+ Service/performance levels are transparent and the resourcing required is obvious.

+ The knowledge base is independent of any agency, so can be accessed even after restructurings.

+ Ownership is perceived to be "the Crown", not "the agency".

+ Flexible, workspaces are "fit for purpose"

+ Encourages innovation, good ideas from specialist systems will flow to the common workspace

+ Agency autonomy preserved, yet common workspace will be used as it will be cost effective, well managed, and immediately available

- Single point of failure for 80% of cross-agency policy development.

- Conflicts with initial project assumption - use agencies existing architectures

- Critical information infrastructure - attractive target for hackers, foreign intelligence.

Option 2: Central workspace | Disperse infostores: As above, except at the completion of the project, the information will be copied to the lead agency file stores, with relevant meta-data entries.

+ The shared workspace is perceived to be "the Crown", not "the agency".

+ Everyone uses a common tool set.

- Double-handling of information when project is completed.

- Possible conversion problems when information is moved.

Option 3: Fully dispersed: The shared workspace will provide minimal infrastructure. It will act as a redirection portal to resources held by individual agencies.

+ Agency autonomy is clearly defined.

+ Multiple redundancy - any loss will only affect a portion of the knowledge base.

- Different tool sets may be needed for each agency.

- To ensure access when required by all users of the policy workspace, service level agreements will need to be agreed and monitored with agencies providing access to their resources.

- Agency operational requirements will impact on their resourcing for the support of the shared workspace.

- Agencies will require effective systems to recover costs.

- Rework will be required whenever an agency is restructured, to ensure that information is still available (e.g. URLs to old domain name still work).

- More extensive security requirements, as access controls will be required at each access point, at each agency.

- More complex synchronisation and updating required, as connectors will be required to each agency's interface.

- The public service knowledge base is spread over disparate systems, formats, connectors and schema.

3.2 Recommendation

3.2.1 "Option 1: Fully centralised" is the recommended option. It is likely to meet resistance from some autonomous agencies, as the shared workspace will challenge most existing policies and processes.  A reasonable compromise is to offer agencies the ability to maintain specialist workspaces & infostore, if they can justify it (to the steering group) with links from the centralised workspace.

3.2.2 "Option 2: Loosely coupled" and "Option 3: Fully dispersed" have inefficiencies and complex requirements, to maintain integrity across disparate systems.

[ Previous | Next ]