|
A project can fall into or support one of the following categories:
On this page… (hide) These are a candidate work programme only; for completeness the Projects below and the Project Candidates cover every initiative the Working Party identified. Each will require a business case and priority before being taken further. Some may become agency projects with a link to ESAF; others will be delivered under the ESAF framework; and some will be out of scope. Other steps that are required are an elaboration of the approach, and an indicative Project Timeline?, with an assessment of the fit and synergies with the ISSPs from the Ministry and other participants, and a leveraging off of the Ministry’s work in the Architecture area including modelling, and enterprise application integration. QSector Authentication & Authorisation (eKey) Currently, most people in the education sector have multiple “network identities” and use a different ID and password to connect to different services from different providers. As more electronic services become available, the number of times people have to log in and out will increase. The purpose of sector authentication is to offer people an eKey that they can reuse to access services for which they are authorised. In some cases, a service will recognise the key automatically; in others, the person will have to enter an ID and password. The same key will work in many places. A goal of “single sector sign-on” is unrealistic in the short term, but “fewer keys that work in more places” is practical. Usage is likely to be compulsory — if a provider offers an electronic service using the sector authentication, then their users will need an eKey to access it. Whether an individual can choose to have more than one eKey for different purposes is an open question. An approach based on open, vendor-independent standards will ensure people can use their eKeys with a wide range of services. Users see it as an access management service, like validating a credit card transaction. The service will be aligned with the eGovernment Authentication Blueprint.
To facilitate exchange and sharing of information between different parts of the sector, there needs to be a common model showing the structure and flow of information between “touch-points”. This will form the basis for a catalogue of structural specifications for effecting exchange of information. The model will identify who are the accountable owners of shared information and where custodianship lies (ie where to go to get the latest version). The model also needs to cover issues associated with Meta Data, discoverability or advertising of holdings, and federated searching across multiple information repositories. It will bring together and integrate the modelling work carried out in a number of agencies. It will identify ways to consolidate data collection and promote data reuse. The scope is the data shared across the sector, not data local to particular organisations. The primary output is a subject area map, showing ownership, usage and standards for shared sector data resources.
QFederated Meta Data Standards Ensuring that all services advertised to the sector follow the same standards will make it easier for people to discover the information and services they need. This will facilitate a shift from provider-oriented searching to task-oriented and context-specific searching. Searchers will have increased confidence that they will find information that’s relevant to their needs and that search results are complete. Once the standards are in place, federated searching within the sector will be achievable without undue technical complexity. Wherever possible, the sector will adopt existing standards and not adapt them.
Develop frameworks, policies, standards, and guidelines for the education portal (education.edu.nz) to support capabilities such as consistent use and management of Meta Data, federated searching, distributed portals (enter one, go anywhere).
The key goal of the framework is to ensure that, regardless of how individual organisations establish their own portals, portal visitors get a seamless experience from the sector as a whole. It facilitates collaboration and consistency across sector portal initiatives. It enables new services to be added easily and seamlessly.
Develop and communicate guidelines describing what people can do to ensure their services are open and inclusive. This can address issues such as giving a timetable for phasing out support for older browsers, so people can plan their infrastructure upgrades. It can develop sector-wide “building codes” — standards which will ensure different systems can interoperate. It can act as a clearing house for sharing information about sector interoperability resources. It can establish processes and procedures that people can use when collaborating to resolve interoperability issues. It can provide connectivity tools and services to make it easier for organisations to exchange information. It will lead to separation of structure — the data — from presentation — views of the data. It can provide information on how to move from proprietary to open standards.
This service enables asynchronous communication between loosely coupled systems. Open sector interoperability requires a mechanism for securely, safely and quickly moving data from source to destination, with verification that the data has been received, understood, and processed. The service can check that the message is well-formed (conforms to the defined message markup) and valid (complies with the specified DTD or schema) and reject non-compliant messages. The recipient may send a subsequent message to the originator giving confirmation of the transaction. The message transport service takes care of picking up packages of data from one part of the sector and delivering them to another.
Conceptually, every organisation has an out box and an in box. The sender system is responsible for dropping an addressed message into the out box. The message service picks it up, delivers it to the recipient’s in box, and reports delivery back to the sender. The recipient system is responsible for clearing the in box.
QHub Infrastructure Design and Management ESAF will be setting up and running a number of Shared Services on behalf of the sector. We (who is the we)? need to work out collectively what range of services the sector wants ESAF to provide, seek commitments from various agencies that they will use the services once they are built, and define the service level standards to which the services will operate. We also need to work out how these services get managed on behalf of the sector — once built, they will quickly become indispensable. We also need to provide guidance on how to subscribe to and use the services, so that individual projects are aware of how they can best take advantage of the hub. We will coordinate and facilitate interoperability testing. The components of the hub will come about as a result of other ESAF initiatives.
|
Quick Links Principles
|