1. EPAN eGovernment Working Group Interoperability
Justification for Interoperability Theme
Terms of Reference
Work Plan
Mid Term Programme
Public Service Delivery from the customer point of view
Primary Customer demands are: - next slide
22nd & 23rd April, 2004

2. What is not covered? Open Standards Open Document Formats
Open Source Software

3. Potential Outcomes from Discussion Paper
To share experience and information on Interoperability
To achieve consensus on the principles of Interoperability
To provide input to EU initiatives on Interoperability

4. High-Level Architecture
Governance Regime
Technical Framework
Organisational Framework
Semantic Framework
Supported By
Structured Customer Contact & Support

5. Architectural Approach
Governance Model
Hub-based Messaging & Web Services
Service Modernisation Programme
Registers of Standardised Elements
Supported By
Customer Contact Centre

6. Customer Contact
One of the principle aims of an eGovernment programme must be the development of a structured customer contact & support service

7. What do customers want? Deal with Government as a single entity
Deal with public servants who have the knowledge and information to process a query
Have a single point of contact
Deal with agencies through the channel of their choice

8. Customer Contact is Key
Transactional knowledge is formalised in procedures, tools and workflows
Retained by organisation
Call Center
Representative
Self -
Service
Technologies
Case Mgt
Rep
Self Service Technologies
Call Centre Representative
Case Mgmt. Representative
Technology Filter (Tier 0)
“High Touch” Filter (Tier 1)
Resolution Filter (Tier 2)
Planning & Policy Filter (Tier 3)
Slide from Accenture
To delivery we need a cohesive interoperability framework

9. Organisational Interoperability
A key element to delivering on the eGovernment vision is the development and implementation of a service delivery modernisation programme.

10. Organisational Barriers
scheme complexity
means testing
supplementary documentation or certification
delivery channels
payment channels
levels and methods of authentication
requirements for signatures
custom & practice – lack of standards
legacy systems
staff training

11. European Drivers
“screen” regulations and legislation that govern the establishment or authorisation of service providers
identify “prohibited requirements” that need to be eliminated
identify “requirements to be evaluated” that may need to be altered or eliminated
establishment of “single points of contact” by “electronic means”

12. Issues to be Addressed how services are delivered
possible common functionality across services
means of providing any such common functionality
means of multi-channel service delivery
legislative and regulatory barriers to customer centricity
funding of service delivery initiatives
appropriate mechanisms for managing the change processes

13. Approach to Organisational Interoperability
Service Delivery Analysis
Common Functionality
Expenditure Reviews
Change Management Programme

14. Integration Framework
Integration channel
Security
Reliable Messaging
Central Messaging Hub
Registration
Authentication
Auditing & Logging
Forms Engine
Case Management
C2G
Information Service
Human Facing
Other Administrations
Private Sector
Citizen Identity Service
Business Identity Service
Sectoral & Agency
Hubs
Core Services, e.g., Administration Workflow Rules Engine
Fullfillment Agencies

15. Semantic Interoperability
To support organisational change, public administrations need to develop pan-public service registers/catalogues of standardised business elements.

16. Standards Rationale Efficient exchange of data
Re-use of data over time and across multiple agencies
Prevention of lock-in to proprietary formats
Contribution by all
Acceptance by all

17. Approach to Semantic Interoperability
Language
Syntax
Message Wrapper (Envelope)
Business Meaning
Communities of Practice
Registration
Legacy Systems

18. Technical Interoperability
To support the interchange of data and use of system functionality in the provision of services, administrations need to develop hub-based standardised XML messaging architectures and XML Web Services.

19. Architectural Principles
simple, in terms of the number of components
capable of linear growth
Interventionist
loosely coupled
capable of supporting system and human interaction
declarative and interrogative
non-proprietary
capable of supporting virtual services
synchronous and asynchronous
capable of being interconnected

20. Traditional Approach HR Payroll Time & Attendance Management Reporting
Organisation Chart
Statistics
Pensions
Accounts
Expenses

21. Issues with Traditional Approach
Does not scale well as more and more bilateral exchanges are required and new connections are required for each additional “service”
Is costly to develop and maintain as each bilateral exchange must be “hand-crafted” to suit the applications involved
Does not easily accommodate the development of common or aggregated services

22. Approach to Technical Interoperability
Statistics
Management Reporting
Time & Attendance
Pensions
Payroll
Message Bus (sync/async)
XML
Integration Server
Workflow
Routing
Security
Auditing
Accounts
Organisation Chart HR
Expenses

23. Technical Interoperability Rationale
All of the defined architectural principles
A single, standardised interface for each organisation connecting to the hub
Ease of maintenance and linear growth of the architecture
The ability to hook virtual services to the hub with changes to the functionality updated once and reflected in all business processes that use it
Once and once-only delivery of requested information
The use of common or shared services

24. Governance Regime
To implement a vision for eGovernment that achieves all of its objectives and is sustainable over time, public administrations must develop a pan-public service governance regime.

25. Governance Rationale
Each agency will continue to take an insular view of service delivery
There will be no clear vision of what is required of agencies at a pan-public service level
The cost of development of technologies, standards, protocols and policies will be replicated across multiple agencies
Each agency will be required to meet eGovernment targets solely from within their own budgetary constraints
New and innovative ways of working will not be easily identified
Provision of aggregated services to allow customers view service delivery from the “life event” approach will not be easily achievable

26. Governance Model Technical & Semantic
One Agency
separate from all sectoral domains
seen as expert in the field of interoperability
pro-active in the promotion and promulgation of standards
responsible for monitoring usage of and policing adherence to standards, guidelines, policies and protocols
singularly focussed on standardising and providing interoperability on a pan-public service basis
an advisory body to fulfilment agencies and to communities of practice

27. Governance Model Common Functionality
One Agency with responsibility for
customer contact centre
customer registration process & protocols
identity services
authentication processes & protocols
information services, forms services, C2G
case management & status checking
search engines and indexing
multi-channel support including Web, DTV, phone, mobile
security regime including auditing & logging
workflow engines, rules engines, publish & subscribe mechanisms
central messaging hub
standards definition, registration and publishing
service level agreements - for virtual services and with back-end agencies

28. Governance Model Organisational
Possible Multiple Agencies
Public Administration
Project Funding
Legislation
Information Society
Modernisation programme(s)
Dependant on Member State’s internal organisational structures

29. EPAN eGovernment Working Group Interoperability
Justification for Interoperability Theme
Terms of Reference
Work Plan
Mid Term Programme
Public Service Delivery from the customer point of view
Primary Customer demands are: - next slide
22nd & 23rd April, 2004