e-SENS Electronic Simple European Networked Services

e-SENSElectronic Simple European Networked Services

e-SENS General AssemblyPresentation of the Work PackagesGeneral timeline & high-level objectives

Berlin, GermanyApr 9th 2013

What e-SENS is about:Presentation of the Work

Packages

6.1: e-Delivery & e-Interaction

6.2: Semantics, Processes and

Documents6.3: Identity,

Security and Trust 6.4: Conformance &

Tests

5.1: e-Procurement

WP1: Project Management (General Coordination, Administrative Management & Advocacy)

WP2: Communication & Marketing

WP3: Sustainability and long-term governance

WP4: Project Legal Expertise Centre

5.2: e-Health 5.3: e-Justice 5.4: Business life-cycle

5.5: New domain

WP5: Piloting

WP6: Building blocks ProvisionWP6: Building blocks Provision

e-SENS WP Structure

WP5: Piloting

WP5: PilotingObjectives• Develop a Requirements Framework as a “demand

landscape” for public ICT services• Coordinate mapping of Requirements to Building Blocks,

together with WP6, within indentified and new domains• Define domain specific and cross-domain use cases and

pilot scenarios• Establish pilot implementation projects at specific pilot

sites, engaging relevant stakeholders and pilot participants and supporting them along their full lifecycle

• Support WP3 to assess the LTS potential of building blocks and services through pilot experience and requirement validation

• Support WP2 marketing and recruitment activities to engage and commit stakeholders in new domains and pilots

WP5 Structure and Interfaces: Conceptual View

OtherDomain 1

OtherDomain 2

Consolidation of Requirements Mapping and Validation

Identification of new pilots and expansion in new domains

Pilot Coordination and Lifecycle Management

WP5 Management

WP6: TechnologyBuilding Blocks

WP3: LTS andGovernance

WP4: Legal Validation

WP2: Advocacyand Marketing

WP5.x domain driven: Requirements extraction and validation per domain and across domains

Pilot Implementation of building blocks and services at Pilot Sites

OtherDomain 3

5.4: Business Lifecycle

5.3: e-Justice

5.2:e-Health

5.1:e-Procurement

Member State driven:

WP5 Workstreams, Milestones and Deliverables

• D5.1, D5.7: Requirements Framework v.1, 2• D5.2, D5.6: Pilot Lifecycle Management, Pilot Evaluation• D5.3, D5.4, D5.5: Pilot Scenarios and Plans (3 Waves)

– 1st Wave Pilots: Decision M12, going live M24– 2nd Wave Pilots: Decision M21, going live M30– 3rd Wave Pilots: Decision M30, going live M36

M0 M6 M12 M18 M21 M24 M30 M36D5.1 D5.7D5.2 D5.6D5.3 D5.4 D5.5

Taking Stock W1P Dec. W1P LiveW2P Dec. W2P Live

W3P Dec W3P LiveM5.1 M5.2 M5.3 M5.4 M5.5 M5.6 M5.7

Three Pilot Waves going live M24, M30, M36

e-SENS Piloting Scope

Implementation Communities“old LSP” Sustainable infrastructure

Other national and European initiatives

E-SENS Domain/BB scope

E-SENS Piloting

E-SENS funding

E-SENS Scope ofCommon Components

and Pilot Implementation

E-SENS Domain/BB scope target (indicative)

eDelivery

eSignatures

Semantics and eDocs

eID (from STORK)

Core Services:

In other LSPsBBs in e-SENS

Specific Service Domains:

In other LSPsIn e-SENS only

Other Initiatives

Domain Use of Building Blocks

• Taking Stock of what’s already there• Where do we want to go• How far are we from getting there

SUB-DOMAINS, USE CASES PRIOR LSPs MS infrastructure1 eDelivery & e-Inyrtactter

1.1 Transportation of docs/structured info1.2 Discovery of endpoints1.3 end-to-end services1.4 other

2 Semantics, Processes and Documents2.1 Common data sets (Taxonomies, classifications, ontologies)2.2 Structured content profiles and schemas for eDocuments2.3 Structured document content/container specifications2.4 Semantic mapping services 2.5 Common Process Definition and Orchestration2.6 other

3 Idenrity, Security and Trust3.1 Identification of Actors3.2 eSignature 3.3 Authentication and Access Management3.4 Authorization and mandates3.5 Attribute exchange services3.6 Privacy, trust and security implications3.7 other

e-SENS BUILDING BLOCKSDOMAIN STATE-OF-ART, GAPS, FURTHER REQUIREMENTS

• Started the consultations!• Still a long way to go• WP5/WP6 alignment

Current WP5 Scope/MSParticipation in Piloting Participation in

Domain-level work

1 Austria 1 x 1 x3 Denmark 1 x 2 x x4 Estonia 3 x x x 3 x x x5 France 1 x 2 x x6 Germany 2 x x 3 x x x7 Greece 3 x x x 3 x x x8 Italy 3 x x x 4 x x x x9 Luxemburg 1 x 1 x

10 Netherlands 3 x x x 3 x x x11 Norway 1 x 1 x12 Poland 3 x x x 4 x x x x13 Portugal 3 x x x 4 x x x x14 Romania 2 x x 2 x x16 Slovenia 3 x x x 3 x x x17 Spain 3 x x x 3 x x x18 Sweden 2 x x 2 x x19 Turkey 3 x x x 3 x x x20 Ireland 1 x 2 x x21 OpenPEPPOL 1 x 1 x

40 11 9 10 10 47 13 12 10 12

Active Contribution to Domain-wide Requirements, Profiling, Implementation, Support

Requirement Domains per

MS

5.1: e-Procure

ment5.2 : e-Health

5.3: e-Justice

5.4: Business Lifecycle

TOTAL

Piloting Participation across e-SENS Domains

Piloting Domains per MS

5.1: e-Procure

ment5.2 : e-Health

5.3: e-Justice

5.4: Business LifecycleCountries

WP5: Meeting the Challenges

• Domain and Piloting Scope• Budget size and distribution, resource

management• Requirements validation by Domains and MS• Common Principles for cross-Domain cooperation• Common Principles for Piloting Value• Pilot Prioritization and Governance• Expansion into new Domains

WP6: Building Blocks Provision

Year 1 – WP5-6 Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar

M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12

Domain requirements & gap analysis

SGCC Business Modelling

•D6.1 Executable ICT Baseline Architecture (M6)

SGCC Requirements Analysis & Design

•D5.1 Requirements Framework n°1 (M12)•D5.2 Pilot Lifecycle Management Methodology & Workflow Support Tools (M12)•D5.3 First-wave Pilot Scenarios and Plans n°1 (M12)

Development of cross-domain use cases

Requirements Framework & Mapping with Architecture Framework

Pilot Lifecycle Management, Methodology & Procedures

Pilot Project Planning & Particpation

Pilot Scenario Definition & mapping with Building Blocks

Pilot Support & Monitioring Tools

WP6: Building Blocks Provision

D6.1 (M6)Executable ICT Baseline Architecture

M6.1 (M4)Business Modelling Consolidated (M4)

M6.2 (M6)InceptionPhase Ended

Individual placement ofBuilding BlocksDependent on LCM, Maturity and WP5 Requirements

Overall WP6 Plan

WP6: Building blocks Provision

Goals & Objectives

Application ViewTechnology View

Business View

European Interoperability Architecture (EIA) – Conceptual Reference ArchitecturesThe goal of this One Pager overview is to provide a high level view on the conceptual reference architecture for the EIA.

Version 0.1 (10/08/2012)

The architecture repository contains the conceptual reference models providing different perspectives and detail, providing insight for the diverse stakeholder group involved with the EIA. The models of this EIA repository will enhance internal and external communication, enhance a common understanding of the necessary building blocks, ensure alignment between project teams and leverage synergies and reuse.

Data View The Data View shows the core elements for the data and information exchange between the applications in the operations of electronic cross-border European public services.

Repository structure and definition of the artefacts are based on Open Group Architecture Framework (TOGAF®).

Architecture Principles1* Comply with subsidiarity and proportionality principle2* User-friendly access to services3* Secure and flexible access to services4* Multichannel delivery of services5* Access through a single point of contact6* Guarantee the privacy and data protection7* Public and non -discriminating access to services8* Cater for multilingualism9* Use of language-independent format10* Reduce redundant information exchange11* Transparency and feedback on administrative processes12* Preservation of information exchanged between public administrations13* Ensure openness between public administrati ons14* Ensure the sharing and reuse of solutions15* Avoid imposing specific technological solutions16* Delivering efficient and effective public services17 Apply service orientation18 Ensure the interoperability and standardisation19 Cater for scalable solutions20 Ensure data availability between public administrations21 Ensure the governance and business continuity22 Promoting multilateral solutions

The Application View shows the core elements for the systems, applications and components used in the establishment of electronic cross-border European public services.

Better understanding by public administrations of the architecture and necessary building

blocks for the establishment of electronic cross-border public services

Better use of existing (or to be provided) European solutions and tools for the

establishment of electronic cross-border public services

Improved digital cross-border collaboration between public administrations

The Business View shows the core elements for the creation of a European public service from an operational, organisational and legal perspective.

European Interoperability Architecture Repository

Goals are identified to address the identified interoperability challenges and requirements for the establishment of European public services, initially defined at a high level, and subsequently decomposed into sub-goals and objectives that are more concrete and measurable.

The Technology View shows the core elements for the infrastructure and fysical components and connectors for establishing the technical interoperability for the applications in the delivery of electronic cross-border European public services.

More efficient and effective creation of cross-border and cross-sector electronic public services

- Number of European and Member States’ public administrations using the architecture and building blocks for establishment of electronic cross -border public services

- Number of comments and additions received from European and Member States’ public administrations on the architecture and building blocks

- Number of European solutions and tools developed and provided at European or Member State level

- Number of European solutions and tools used by European and Member States’ public administrations

- Reduced time for the establishment of electronic cross-border public services

- Reduced costs and resources for the establishment of electronic cross -border public services

- Number of public administrations involved in electronic cross-border public services

Users (Citizens and Businesses)

Cross-border processes

European public services

Contact points

Interoperability agreements

Legal framework

Cross- border business data

Access to base registries

Presentation layer Orchestration layer

Business logicPresentation logic

Semantic schemas

Catalogue of datasets

Catalogue of reference data

Interoperability Agreements

Data translation

Multilingualism

Syntax translation

Semantic translation

Public administration infrastructure

Cross-border technical connectionData sources

Document storage

Structured data storage

Data transport Security functions

Access to applications

Reusable solution components

Base registries

Communications layer

Secure data exchangeSecure

communications management

Identity and access management

Data certification

Audit trail & log

Public administrations

Cross-border documents

Business requirements and

drivers

Services Layer

Service registry

External services

Basic application service

Architecture Governance The architecture governance shows the core elements for the overall governance of the European Interoperability Architecture, including the elements from the other views.

Governance Processes

Policy Management & Take-on

Compliance assessment

Monitoring and reporting

Environment Management

Governance Content

Needs & requirements

Service Level Agreements (SLAs)

Cartography

Interoperability solutions

Interoperability architectures

Governance Organisation

Assessment method for standards and specifications

European

Interopera

bility

Archite

ctureUnifie

d

process

Maturity

Model


Methodology

D6.1 ‘Executable ICT Baseline Architecture’• Taking Stock (brain storm on building blocks)• Collect descriptions and relationships• Classify according to EIA and Maturity Model• Life Cycle Management (ownership and stakeholders)• Business Relationships• Prioritise• Model and Plan (Place in UP development cycle)Result: ICT Architectural Baseline: A draft version of EIA Cartography

with plans and objectives for the individual Building Blocks


Issues• A WP6 Deliverable is the aggregate of deliverables from each

subgroup • Milestones and Deliverables are minimum requirements,

meaning that a Subgroup can be futher down the road and leaving room for agility and flexibility

• Collaboration with WP3 and WP5• Collaboration with Standard Organisations• Collaboration with EC initiatives


Who’s Who in WP6WP6 Leader: Klaus Vilstrup Pedersen ([email protected])

Lead Architect: Sven Rasmussen ([email protected])

SG 6.1 manager: Susanne Wigard ([email protected])

SG 6.2 manager: Olgierd Dziamski ([email protected])

SG 6.3 manager: Antonio Lioy ([email protected])

SG 6.3 manager: Cagatay Karabat ([email protected])

SG 6.4 manager: Tuncay Namli ([email protected])



Objectives:• Long-term consolidation of the building blocks of the

LSPs with a view to overall acceptance• Sustainability models • Bringing business cases of building blocks together • Governance structure for Cross-border delivery of

eGovernment services• Working towards legal stability• Handover of what is done in the EC policy framework

(e.g. CEF).


Issues to be resolved• Interfaces:

– National vs international– Private vs Public– Generic vs Sectoral– …..

• Infrastructure or paper?• Governance organisation


Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb MarM1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12

T3.1 Preparation Phase

T3.5 Governance implementation

T3.2 Sustainability Assessment phase

T3.3 Scenarios and recommendations for sustainability models

D3.1 Guidelines to the assessment the sustainability and maturity of building blocks (M6)

D3.2 Assessment maturity of building blocks (M6)

D3.3 Report on the integrated view of LSP strategies (M6)D3.6 Scenarios for governance models on short, medium and long-term (M9)

T3.4 Common business case

D3.4 Preliminary proposal for a governance body (M6) D3.5 Preliminary proposal for long-term sustainability

within the CEF (M6)


Year 1 – WP3

WP3: Breakdown of PMs

Participant No.

Member State

T3.0 WP Management

T3.1: Preparation

phase

T3.2 Sustainability assessment

phase

T3.3 Scenarios & recommendations for sustainability

models; T.3.4: Common business

case T3.5: Governance implementation

Total per MS

1 DE 1 6 5 3 152 AT 1 2 33 CZ 2 3 2 74 DK 2 3 55 EE 2 8 3 4 176 ES 4 7 4 157 FR 6 2 2 108 GR 1 6 5 3 159 IT 2 5 5 3 15

10 LU 4 4 6 1 1511 NL 30 2 9 5 9 5512 NO 4 4 2 1013 PL 2 3 514 PT 2 3 515 RO 5 5 2 1216 SE 1 2 2 517 SI 1 1 218 SK 10 5 1519 TR 2 4 6 3 1520 IE 0

21 Open PEPPOL 1 3 4 2 10TOTAL 30 15 85 79 42 251

Note: PMs in T3.3 and T3.4 need to be separated.

ResponsibilitiesWP3 leader: Freek van Krevel ([email protected])

T3.1 manager: Jaak Tepandi ([email protected])

T3.2 manager : Jack Verhoosel ([email protected])

T3.3 manager : Carmen Ciciriello ([email protected])

T3.4 manager : Bertrand Gregoire ([email protected])

T3.5 manager : Katrin Weigend ([email protected])

Subtask manager T3.5.1: Roberto Zuffada ([email protected])

Subtask manager T3.5.2: Luc Ferrand ([email protected])

Subtask manager T3.5.3: Aleida Alcaide ([email protected])




Objectives of WP4

• Draw on the experience of previous LSPs• Maintain a network of legal experts who can provide

legal advice on request, both on the themes of the pilots as well as on general, cross-sector EU legislation

• Along with sector knowledge, incorporate horizontal legal expertise, related to the great principles and the wide-encompassing instruments of EU law, such as the Services Directive


Objectives of WP4

• Explore the horizontal regulations applicable to eGovernment in each participating country, as well as the applicability of the Administrative Cooperation articles included in the Lisbon Treaty to the field of eGovernment

• Monitor legislative developments at EU and national level


Work approach Year 1

• Set up a core group able to give legal advice at short notice

• D4.1 Inventory of legal issues encountered by LSPs, including identification of unexplored legal, due Sept. 2013• Collaboration with other projects

• D4.2 Legal process modelling of the proposed pilots, due Nov. 2013• Collaboration with other WPs



Objectives of WP2:

BUILDING BUILDING A SUSTAINABLE COMMUNITY AROUND THE E-SENSA SUSTAINABLE COMMUNITY AROUND THE E-SENS

to raise awareness across Europe of the project’s objectives and achievements

to actively engage relevant stakeholders groups to collect feedback and opinions about the project to promote e-SENS solutions as re-usable in other domains


Year 1 Year 2 Year 3

Website

Marketing Strategy

Report Report Report Pilot

Marketing Strategy

cooperation with LSPs

social media

newsletters, articles, events

cooperation with other WPs

Marketing according to AIDA model

CCommunication success factorsommunication success factors::

active national marketing broad scope identifying stakeholders needsclose cooperation with LSPs cooperation with other WPs


WP1 Project Management

WP1 Project Management

•Alignment of partners

•Achievement of project milestones and goals

•Monitoring of progress

•Quality assurance and change management

•Involvement of the EC Institutions

•Timely delivery of high quality outputs

•Respect of budgetary constraints

•Distribution of Community funds

•Reporting towards the European Commission

•Coordination of external relations with WP2

Project Management is about ensuring the smooth running of the e-SENS project through timely and sound management

e-SENS project governance and organisation

Coordinator (WP1)

Administration, advocacy &

overall management

WP1

WP1leader

WP4

WP4leader

Management Board

General Assembly(1 representative per beneficiary)

. . . .

WP2

WP2leader

EC, Council, Etc.

WP6

WP6leader

WP5

WP5leader

WP3

WP3leader

Partner = Beneficiary (national consortium)

Technical governanceAdministrativegovernance

Advisory Policy Board

WPLEC

Policygovernance

Domain Board

Architectural

Board

Partner 1

…..

Partner 1 Partner 2 Partner n

Partner 2

Partner n

QMWP1leader

WP2leader

WP3leader

WP5leader

WP4leader

WP6leader eHealth

eJustice

eProc.

eBusiness

eID eDelivery

eSign. eDoc.

General timeline & high-level objectives

Zoom on first year of the project

e-SENS: 6 WPs but One Project

Assessment & DesignSustainability

Year 1 Year 2 Year 3

Communication & Marketing

Project Management

Legal advice LSP & Pilots Legal advice

Scenarios for Governance Models Recommendations & Final Sustainability Plan

Pilot Requirements Framework & Planning

Go live preparationRevision of Framework

1st Wave live2nd Wave live

Evaluation & Consolidation

Business Modelling &Requirements Design & Implementation Deploy

Evaluation & Consolidation

e-SENS Global Project Plan

Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb MarM1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12

Year 1 - WP1,2,3,4

Internal Guidelines

•D1.1 How to Write a Good Deliverable (M2)•D1.2 Internal Communication Plan (M2)•D1.3Risk Management and Quality Assurance (M2)

Interim Report

•D1.4 Interim Activity Report (M7) Annual Report

Website

Communication Plan

•D2.1 Project Website (M3)•D2.2 Communication and marketing plan (M3)

Comm. Report

•D2.3 Report on Communication (M12)

Preparation Phase

Common Business Case

•D3.1 Guidelines to Assessment of Building Blocks (M6)•D3.2 Assessment of Building Blocks (M6)•D3.3 Report on Integrated Views of LSPs (M6)•D3.4 Preliminary Proposal for a Governance Body (M6)•D3.5 Preliminary Proposal for Long-term Sustainability (M6)

InventoryOf Legal Issues

•D4.1 Inventory of Legal Issues encountered by LSPs (M4)

InventoryOf Legal Issues

•D4.2 Legal Process Modelling of Proposed Pilots (M6)

Annual Summary

•D4.3 Summary of Activity (M12)

•D3.9 Scenarios for Governance models (M9)

Year 1 – WP5-6 Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar

M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12

Domain requirements & gap analysis

SGCC Business Modelling

•D6.1 Executable ICT Baseline Architecture (M6)

SGCC Requirements Analysis & Design

•D5.1 Requirements Framework n°1 (M12)•D5.2 Pilot Lifecycle Management Methodology & Workflow Support Tools (M12)•D5.3 First-wave Pilot Scenarios and Plans n°1 (M12)

Development of cross-domain use cases

Requirements Framework & Mapping with Architecture Framework

Pilot Lifecycle Management, Methodology & Procedures

Pilot Project Planning & Particpation

Pilot Scenario Definition & mapping with Building Blocks

Pilot Support & Monitioring Tools