1. Product Guide Version 1.0 03.10.03 Baselined
ISB Pilots
Product Guide
Version Baselined

2. New e-Government Services Pilots
Purpose and overall architecture
Notifications Engine
Forms Engine and Forms Store
Personalisation and Circumstances Engine
Rules Engine
LA Portal Components
Web Services Broker

3. Purpose and Overall Architecture
Pilots
Purpose and Overall Architecture
the principle is to pilot the “build once, use many times” approach
the pilots will identify and develop common re-usable components and services that accelerate and assist with e-government delivery
the approach will ensure the overall e-government services architecture is developed within a common architectural framework
all pilots will be underpinned with industry-accepted open interoperability standards
where authentication/authorisation and/or transaction services are required, Gateway will be used
new components will in general act as both ‘spokes’ of Gateway as well as exposing direct web services interfaces where appropriate

4. Pilots
Security Framework
the existing best practice security approach will be maintained, including:
use of Gateway authentication/ authorisation and security infrastructure
use of industry-accepted security standards (eg. 128bit SSL, including mutual authentication where appropriate)
use of eg. WS-Security and other recognised standards as appropriate
compliance with BS7799
independent security code and infrastructure reviews as required

5. Pilot Scope and Approach
these projects are intended to be pilots – not production systems
during the period between now and March 2004 the pilots will:
identify the full business requirements with the active involvement of stakeholders
prove and refine the proposed components through a series of pilot systems built in the OeE’s R&D labs
develop full business and technical requirements to be taken to full procurement, where applicable
those stakeholders who participate in the pilots will be able, by mutual consent, to continue using the interim pilot systems until the full production systems are procured and operational
note that as with any pilot, 24x7 availability of the systems cannot be guaranteed and expectations should be set accordingly with consumers of the pilot systems

6. Summary of Pilot Components
Pilots
Summary of Pilot Components
Notifications
enables departments to send user’s notifications via the user’s chosen channel
provides a repository of all government forms – schema, style sheets, etc
provides storage area for part-completed forms
single repository for user’s preferences for web sites and store of personal data
central storage/service facility for business-related rules calculations
“shop-window” demonstrator, proving the use of the other pilot components
provision of web services / data retrieval interface for the Government Gateway
Forms
Engine
Forms
Store
Personalisation
&
Circumstances
Rules
Portal
WSB

7. Services Architecture Conceptual Overview
Pilots
Services Architecture Conceptual Overview

8. Pilots
Result: Consistent Citizen/Business/ Intermediary-Centric Government Services
Appointments
Authorisation

9. SMS text
Portal
Backend
Systems
Notifications
Forms
Engine
Store
Personalisation /
Circumstances
Rules
WSB
Transaction
Registration /
Enrolment
Secure
Messaging
Payments
user logs in/authenticates
data retrieved from back-end system to pre-populate online form(s)
site is configured using the user’s preferences
completed form is submitted
user subscribes to alerts (eg. Planning Applications)
user makes online payment (eg Council Tax)
calculations for eg. Housing Benefit
successfully submitted forms
form definitions retrieved for online rendering
forms in process of completion stored/ retrieved
routing of web service calls
statements etc provided for online viewing
viewing of statements and secure 2-way communications
alerts sent through channel of choice

10. Notification Engine Pilot
Notifications
Notification Engine Pilot
allows departments to send user’s notifications via the user’s chosen channel
examples of notifications include
new Government mail (secure messaging system)
flood warnings
exam results
appointment changes
example channels include
SMS text message
MSN alerts and IM
AOL IM

11. Notification Engine Pilot Illustration
Notifications
Notification Engine Pilot Illustration
Notifications
Department Portal
SMS text
MSN Alerts
Other
5. Notification engine decides upon channel and carries out communication.
1. User logs on to a Department Portal (using their Gateway User ID and password)
2. User subscribes to the flood warning service (supplies postcode)
3. User sets the channel for the notification on the notification engine (defaults to )
4. Area has flood warning for that postcode area, dept processor sends out notifications with CredentialIdentifier and message to Notification Engine via Gateway
Subscriptions
Gateway
6. User receives alert via their chosen channel(s)

12. Notification Engine Pilot
Notifications
Notification Engine Pilot
departments only need to interface to one engine to get full use of multi channel capability for notifications
the business logic for trigger events is managed locally by departments
easy to add new notification methods (transparent to departments)
XML based up to point of delivery to channel

13. Forms service: Forms Engine and Forms Store Pilot
a SOAP service that will allow a portal or application to pick up a copy of the latest form and render it
makes form distribution easier
portals build one form rendering engine rather than hard coding all government forms
forms store
a SOAP based secure storage system used to store part completed forms
allows a user to continue a form at a different site than they started (handy if each site could help pre-fill different parts of the form, your bank could pre-fill your SA form, then you save it to the store, go to your employer site and log in, it retrieves the form and pre-fills it with the information it holds on you… and so on)
allows a helpdesk or IR tax person to view your part completed form (if you were to permit them) and so they could provide better help
access controlled by Gateway authentication/authorisation services

14. Forms Overview Potential Use Scenario
Engine
XSD
XSL
etc
Portal
User completes online form(s) (and eg. payment details)
completed XML doc
Government
Gateway
TxE
Payments
Store
XML
Authentication
Other portals /
applications
dept
retrieve appropriate form definitions
store part-completed forms data
deduct CC/DC payment(s)
Dept/
owner
create/ maintain schema
Dept
Helpdesk
access for user assistance

15. Personalisation and Circumstances Engine Pilot
&
Circumstances
Personalisation and Circumstances Engine Pilot
as most web sites allow users to personalise them, the result is duplicated information around various websites and portals
the personalisation and circumstances engine will allow users to enter their information once and then select which Government sites are allowed to see it
examples include preferred language, date of birth, post code, etc
each time a user logs on to any Government site it would (if permitted) already know a user’s preferences
the circumstances part extends this (for use with the rules engine)
it will permit a user to store and control far more general information such as marital state, number of children, other dependants etc..

16. Rules
Rules Engine Pilot
the rules engine is a central storage facilities for service rules
the rules (for example, benefit entitlement rules) can then be run against a user’s circumstances. The more information that has been provided the more accurate the resulting view of benefit entitlement will be
would allow a ‘what if’ facility to find out how entitlements could change:
what if my husband is made redundant?
what happens if I have to care for my mother?
what happens if my new child is disabled?
the rules would be produced once by the service-owning departments allowing any portal or website to provide the rules service

17. ISB Portal Demonstrator
during the pilot the portal will act as the ‘shop window’ that illustrates how all the pilots integrate together to provide an enriched user experience

18. Web Services Broker Pilot
WSB
Web Services Broker Pilot
provides a consistent interface for developers (one web service delivery endpoint rather than 100s), with no touch on client
provides a ‘pull’ facility to parallel the existing asynchronous submission interface (enabling backend data to be retrieved for pre-population into online forms, for example)
changing the location of web services becomes transparent to the client rather than hard coded to a particular server
the existing Gateway security environment ensures all government web services are protected by a common, consistent, strong security regime
a dept’s XML Web service could be taken offline for maintenance without modifying either the client code or its configuration. A Gateway administrator can ensure redirection of the SOAP messages to an alternative endpoint

19. Gateway web services broker
WSB
Gateway web services broker
Dept B
web service
Gateway as intermediary for govt Web Services (SOAP router)
User
SOAP
Gateway
single point of access for all e-govt web services TO
VIA
FOR:
GO VIA:
Dept A
web service